Subject: [mpls] comments on draft-thomas-mpls-ldp-capabilities-00

From: "Aamer Akhter \(aakhter\)" <[email-masked]>
Date: Thu, 13 Jul 2006 09:14:34 -0400

Hi Bob,

Thank-you for writing draft-thomas-mpls-ldp-capabilities draft.

Couple of comments:

1) 
RFC3031 has a MUST statement that says label distribution protocols must
negotiate exp-null capabilities. It would be good to get this into LDP
;-). However, I would agree I don't know anybody that doesn't support
exp-null in frame-mode. To be backward compatible, it might be
preferable to have a default behavior of supporting exp-null (like the
ipv4 fec support mentioned in the draft), and non support would have to
be explicitly disabled by signaling.

RFC3031 3.16
"   Initial label distribution protocol negotiations MUST allow each LSR
   to determine whether its neighboring LSRS are capable of popping the
   label stack.  A LSR MUST NOT request a label distribution peer to pop
   the label stack unless it is capable of doing so."

2) 
Not sure how this is usually done, but perhaps a vendor specific range
(or high order bit) for capability codes? or is this usually done after
the IANA engagement ?

3) 

>From reading the draft it is unclear:

 At session establishment, if a capability ack is requested, is an
explicit cap-ack is sent for each cap? Or will a single keepalive will
suffice.

4)
section 5. Let's say CAP-enabled LDP peer sends CAP-LIST-TLV with INIT
message. 

* In the case the peer sends back a keepalive, this is seen as an
'implicit acknowledgement for any announced capabilities that may
require acknowledgement'. However, a peer that does not support CAP
would also send back a keepalive (when the U bit == 1 ).

The above condition is resolved by setting the U bit to 0, but the draft
leaves open the above confusing possibility where it is not really known
if the peer even supports CAP-TLV at all. Is there any benefit in this
openness, and should we have a recommendation?

5) 

It is unclear (from a quick read of RFC3036) what kind of notification
(fatal or otherwise) is sent in the case U bit == 0 and peer is not CAP
enabled. If it _is_ a fatal error, should the session reestablishment
backoff timer be ignored?

Regards,

-- 
Aamer Akhter / [email-masked]
NSITE, cisco Systems

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls