The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2006-Jul> msg00057



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

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

  • From: "Aamer Akhter \(aakhter\)" <aakhter@cisco.com>
  • Date: Thu, 13 Jul 2006 09:14:34 -0400
  • Authentication-Results: rtp-dkim-1.cisco.com; header.From=aakhter@cisco.com;dkim=pass ( sig from cisco.com verified; );
  • Cc: mpls@lists.ietf.org
  • DKIM-Signature: a=rsa-sha1; q=dns; l=2217; t=1152796513; x=1153660513;c=relaxed/simple; s=rtpdkim1001;h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;d=cisco.com; i=aakhter@cisco.com;z=From:=22Aamer=20Akhter=20\(aakhter\)=22=20<aakhter@cisco.com>|Subject:comments=20on=20draft-thomas-mpls-ldp-capabilities-00|To:=22Bob=20Thomas=20\(rhthomas\)=22=20<rhthomas@cisco.com>;X=v=3Dcisco.com=3B=20h=3DUBphAHH2/ZklmNq5gM7vJdFJH+k=3D;b=hN417+k0sBeQBNgaTasgJcT/6Sc7pwijwZHSh0WeU4QbpciGjm39Lu9PHce5t90TtVa9z019mkPKlysWXSr2kyYkd24Ho6JDDQr28Ce85UI3WFNW/Dem21HIK4tamiHE;
  • Thread-Index: AcamOccM+ER7TQ0TQbyUY4G/tDEn+g==
  • Thread-Topic: comments on draft-thomas-mpls-ldp-capabilities-00
  • X-Brightmail-Tracker: AAAAAA==
  • X-IronPort-AV: i="4.06,237,1149490800"; d="scan'208"; a="32099583:sNHT27153744"
  • X-MIME-Autoconverted: from quoted-printable to 8bit by cell.onecall.net id k6DDEiH22723
  • X-OriginalArrivalTime: 13 Jul 2006 13:15:13.0319 (UTC)FILETIME=[5FFDB370:01C6A67E]

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 / aakhter@cisco.com
NSITE, cisco Systems

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls