The MPLS WG Archive

[Adrian Farrel <AF@dataconnection.com>]

Hi Mani,

>I read through the draft-ietf-mpls-ldp-ft-00.txt.

Thanks for your interest in the draft.

>I have a few doubts and can you please clarify?
>
>1) In the section 7 Example Use Page 21, in (12) we have
>
>                 LDP Init(n/a,n/a,95)
>                 --------------------------->
>
>This should mean that P1 indicates that it has secured
>messages with sequence number until 95.
>
>Subsequently we have in (14) 
>                       Label Mapping(L2,95,-)
>                 <--------------------------- 
>
>Is this correct? Since 95 has been given by P1, is it not
>sufficient that p2 provides only the Label Abort message 
>which is given next in (14)?

Correct.  To comply with the text accompanying the example,
the LDP Init should ack only up to 94.

I will update the diagram.

>2) In Section 4.4 Page 12, Second Paragraph. "Hold Timer"
>has been mentioned. I am not sure of this "Hold Timer".
>Is this the Hello Hold Timer (Section 2.5.5 in ldp-11 draft)?

It is.  There names are used interchangeably in LDP-11.
I will add a reference for clarity.

>3) Does 
>     "The Hold Timer for an FT LDP Session SHOULD be ignored 
>while the FT
>      Reconnection Timer is running" mean that the hello
>messages need not be expected from the Peer during the
>Reconnection time?

Correct.  They need not be expected, but they could be received.
You could view the Reconnection Timer as replacing the Hold Timer
for the period immediately after failure.

>4) I am not clear with the advantage meant in the statement
>   "This ensures that network resources are not permanently
>   lost by one LSR if its LDP peer is forced to undergo a cold start."
>in page 8. 
>
>My confusion is, when a LDP Peer P1 is made to undergo a 
>cold start, the TCP session will be initiated again 
>with "FT Reconnect Flag set to 0". This will cause the other
>LDP Peer P2 to release all the information. 

Precisely.  All we are saying is that if this rule did not exist
there would be a risk that the peer that stayed up would retain
resources that are no longer valid.  The statement is necessary
since we are replacing the rule about releasing resources when 
the TCP session fails.

>5) What should be done in case of receipt of a "FT ACK Sequence
>Error"? This is generated by a Peer P1 to P2 when it receives
>an out of sequence ACK from P2. 

Well, the most probable solution is to fix the code :-)

Section 6.1 shows that the E-bit must be set for this status code,
indicating that this is a fatal error as defined by LDP-11.

LDP-11 says...

   1. Error notifications, used to signal fatal errors.  If an LSR
      receives an error notification from a peer for an LDP session,
      it terminates the LDP session by closing the TCP transport
      connection for the session and discarding all label mappings
      learned via the session.

>6) When do we generate Notification with Status code
>   " FT Sequence Numbers Exhausted"

Good point, missing text.
The answer is simple.  When an implementation determines that it is
unable to allocate a sequence number to a message because it has
none available.

This might be because they are all unacked by the peer, or because it
fears that to allocate another one would cause wrapping confusion, or
because it is implemented with a fixed size array of un-acked seq	nos.

>7) It has been mentioned (very clearly) in the second
>paragraph in Section 4.4, that the Reconnection timeout is
>an implementation choice. Will it be possible to indicate
>the possible Reconnection timeout value?

Yes, we will add a suggested value.

>8) Let P1 and P2 are two LDP Peers. Let us assume 
>   that P1 has transmitted a set of label requests
>   to P2. Can P2 provide a reply to one of the label
>   request messages LRQ1 from P1, without containing FT 
>   ACK TLV? and if such a message is received by P1
>   can P1 assume that the FT sequence number provided in 
>   LRQ1 is secured at P2?

Good question.  Implicit acknowledgement.
Personally I don't like it, and it can't be too much effort
to add an Ack TLV to the response (e.g. Label Mapping).

We will discuss this and get back to you.

Regards,
Adrian
--
Adrian Farrel  mailto:af@dataconnection.com
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.dataconnection.com/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422