The MPLS WG Archive

[Adrian Farrel <AF@dataconnection.com>]

Gangxiang,

Thanks for your interest in this draft.

>Thanks for your draft! I have some doubts on this draft:
>
>1. Draft uses FT Protection TLV to secure the FT message. 
>However, in LDP specification, there is a field Message ID
>in each LDP message. It seems that there is some redundancy
>on this ID inforamtion. I guess it is possible to dirctly 
>use the Message ID field to secure those FT messages.

For LDP FT we require ...

   An LDP peer maintains a separate FT sequence number for each LDP
   session it participates in.  The FT Sequence number is incremented by
   one for each FT LDP message (i.e. containing the FT Protection TLV)
   issued by this LSR on the FT LDP session with which the FT sequence
   number is associated.

That is, the FT sequence number has meaning at both ends of the 
session.

Message ID in LDP has no such limitations ...

   Message ID
     32-bit value used to identify this message.  Used by the sending
     LSR to facilitate identifying notification messages that may apply
     to this message.  An LSR sending a notification message in response
     to this message should include this Message Id in the Status TLV
     carried by the notification message; see Section "Notification
     Message".

Thus Message ID is not suitable.

>2. After sender sends an FT message, it will receive an ACk 
>message from the reciever as a confirmation. Following this 
>rule, we may further consider some special situations:

>(a) TCP connection between LSRs is working properly, but some 
>FT messages can't be confirmed because their receiver can't send 
>back the corresponding ACK messages due to some other reasons 
>rather than TCP disconnection. 
>(For example, in CR-LDP, peer A sends a Label Request message 
>L1 to peer B, but peer B can't ACK it because peer B's 
>downstream can't provide Label Mapping message due to something
>wrong)

Ack'ing a message does NOT imply that it has been processed with 
allocation of labels etc.  That is what Label Mapping is for.

The Ack simply confirms that the message has been received and 
secured in such a way that its effect can be recreated on 
recovery.  This might involve storing the message in flash or
it might involve processing the message to completion and 
replicating the control blocks (or anything else you care to
name - it is an implementation choice).

>(b)In a Label Request message with FT sequence number S, there 
>could be more than one FECs, e.g. {FEC1, FEC2,...,FECn}. For 
>these FECs, the mapping labels may arrive at the node at the 
>different time, and some labels may even not be able to arrive
>due to the reasons like in (a). So how should we deal with such
>a kind of situation? How will we send the ACK sequence number?

As above.  You Ack the message not the FEC.
Ack the Label Request when you receive it.  Later when you have
sent the Label Request onwards, you receive Label Mappings and
process them as normal.  We are not changing the basic protocol
in anyway, simply adding a handshake.

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