The IESG has approved the following document: - 'IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities ' <draft-ietf-ccamp-te-node-cap-05.txt> as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-te-node-cap-05.txt-05.txt Technical Summary It is highly desired in several cases to take into account Traffic Engineering (TE) node capabilities during path selection for MPLS and G-MPLS Traffic Engineered LSPs (ie, in picking the route for the LSP), such as for instance the capability to act as a branch Label Switching Router (LSR) of a Point-To-MultiPoint (P2MP) LSP. This requires advertising these capabilities within the Interior Gateway Protocol (IGP). For that purpose, this document specifies OSPF and IS-IS traffic engineering extensions for the advertisement of control plane and data plane traffic engineering node capabilities. Working Group Summary No dissent reported. The document is authored by some key CCAMP WG members and received constructive comments from across the WG during its development. The working group has been relatively quiet on this work, but the chairs judge that to be because it is "done and dusted". It is a small protocol feature. The document was shown to the OSPF and ISIS working groups more than once,and the last call was notified to the two IGP working groups. Protocol Quality Ross Callon has reviewed this for the IESG. Note to RFC Editor Section 4.1, replace the first paragraph as follows: OLD: The OSPF TE Node Capability Descriptor TLV is a variable length TLV that contains a series of bit flags, where each bit correspond to a TE node capability. NEW: The OSPF TE Node Capability Descriptor TLV is a variable length TLV that contains a series of bit flags, where each bit corresponds to a TE node capability. The bit-field MAY be extended with additional 32-bit words if more bit flags needs to be assigned. Any unknown bit flags shall be treated as Reserved bits. Add the following text at the end of section 4.1, right after the definition of the reserved bits: Reserved bits MUST be set to zero on transmission, and MUST be ignored on reception. If the length field is greater than 4, implying that there are more than 32 bits in the value field, then any additional bits (ie, not yet assigned) are reserved. Section 4.2, replace the first paragraph as follows: OLD: The IS-IS TE Node Capability Descriptor sub-TLV is a variable length sub-TLV that contains a series of bit flags, where each bit correspond to a TE node capability. NEW: The IS-IS TE Node Capability Descriptor sub-TLV is a variable length sub-TLV that contains a series of bit flags, where each bit correspond to a TE node capability. The bit-field MAY be extended with additional bytes if more bit flags needs to be assigned. Any unknown bit flags shall be treated as Reserved bits. Update the third paragraph of section 4.2 as follows: OLD The format of the IS-IS TE Node Capability sub-TLV is the same as the TLV format used by the Traffic Engineering Extensions to IS-IS [RFC3784]. That is, the TLV is composed of 1 octet for the type, 1 octet specifying the TLV length and a value field. NEW The format of the IS-IS TE Node Capability sub-TLV is the same as the sub-TLV format used by the Traffic Engineering Extensions to IS-IS [RFC3784]. That is, the sub-TLV is composed of 1 octet for the type, 1 octet specifying the sub-TLV length and a value field. Add the following text at the end of section 4.2, right after the definition of the reserved bits: Reserved bits MUST be set to zero on transmission, and MUST be ignored on reception. If the length field is greater than 1, implying that there are more than 8 bits in the value field, then any additional bits (ie, not yet assigned) are reserved. Section 8.2, first paragraph. Replace: OLD [IS-IS-CAP] defines a new code point registry for sub-TLVs carried in the ISIS CAPABILITY TLV defined in [IS-IS-CAP]. NEW IANA has defined a registry for sub-TLVs of the IS-IS CAPABILITY TLV defined in [IS-IS-CAP]. Please correct the text at the end of the existing section 8.3 as follows: OLD Bit No. Name Reference --------+---------------------------------------+----------- 1 B bit: P2MP Branch LSR capability [This.I-D] 2 E bit: P2MP Bud LSR capability [This.I-D] 3 M bit: MPLS-TE support [This.I-D] 4 G bit: GMPLS support [This.I-D] 5 P bit: P2MP RSVP-TE support [This.I-D] NEW Bit No. Name Reference --------+---------------------------------------+--------------- 0 B bit: P2MP Branch LSR capability | [RFC-ccamp-te-node-cap-05] 1 E bit: P2MP Bud LSR capability | [RFC-ccamp-te-node-cap-05] 2 M bit: MPLS-TE support | [RFC-ccamp-te-node-cap-05] 3 G bit: GMPLS support | [RFC-ccamp-te-node-cap-05] 4 P bit: P2MP RSVP-TE support | [RFC-ccamp-te-node-cap-05] >4: Available for assignment | [RFC-ccamp-te-node-cap-05] IANA Note See RFC editor's note above. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
