Protocol Action: 'IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities' to Proposed Standard

[The IESG <[e-mail]>]

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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-announce