Protocol Action: 'ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering' to Proposed Standard

[The IESG <[e-mail]>]

The IESG has approved the following document:

- 'ISIS Extensions in Support of Inter-AS Multiprotocol Label Switching 
   (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering '
   <draft-ietf-ccamp-isis-interas-te-extension-04.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-isis-interas-te-extension-04.txt

Technical Summary

   This document describes extensions to the ISIS (ISIS) protocol to 
   support Multiprotocol Label Switching (MPLS) and Generalized MPLS 
   (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems 
   (ASes). It defines ISIS-TE extensions for the flooding of TE 
   information about inter-AS links which can be used to perform inter-
   AS TE path computation. 

   No support for flooding information from within one AS to another AS 
   is proposed or defined in this document.

Working Group Summary

   Good consensus reported. The document has had a good level of   
   discussions and review in CCAMP and in the ISIS working group. 
   In particular, it received considerable input from IS-IS experts
   in its early stages. It was last called in both CCAMP and IS-IS
   working groups and updated in response to comments. 

Document Quality

   There is a known implementation of the extensions, in addition to 
   a known implementation of the very similar OSPF document. There 
   was also good support for the work from other vendors with the 
   same objectives. Document review by the IS-IS working group 
   deserves special mention for its care and thoroughness.

Personnel

   Adrian Farrel is the Document Shepherd for this document.  Ross
   Callon is the Responsible Area Director.

RFC Editor Note

   Please add the following text to the end of the first paragraph
   of section 5 (security considerations):
        (e.g., using the cleartext passwords or Hashed Message
        Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm
        which are defined in [ISIS] and [RFC3567bis] separately.)"

   Please add the following paragraph to the end of section 5 
   (security considerations): 

        For a discussion of general security considerations for 
        IS-IS see [RFC3567bis].

   Please add RFC3567bis to section 8.1 (normative references), 
   this refers to draft-ietf-isis-rfc3567bis (which should be an
   RFC ahead of this draft -- it is now RFC 5304).

   Please update Section 6.2 as follows:

   OLD
    This document defines the following new sub-TLV types, described in
    Sections 3.3.1, 3.3.2 and 3.3.3, of top-level TLV 141 (see section
    6.1 above) that need to be registered in the ISIS sub-TLV registry
    for TLV 141, note that these three new sub-TLVs SHOULD NOT appear in
    TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222):

      Type        Description                        Length
      ----        ------------------------------   -------- 
        23        Remote AS number                        4
        24        IPv4 Remote ASBR Identifier             4
        25        IPv6 Remote ASBR Identifier            16

    As described above in Section 3.1, the sub-TLVs which are defined in
    [ISIS-TE], [ISIS-TE-V3] and other documents for describing the TE
    properties of an TE link are applicable to describe an inter-AS TE
    link and MAY be included in the Inter-AS Reachability TLV when
    adverting inter-AS TE links. And it's possible that some sub-TLVs
    may be defined for inclusion in both TLV 22 and TLV 141 in the
    future. It's better if these sub-TLVs have the same registry value
    no matter where they are included in TLV 22 or TLV 141. The same
    condition will occur when these sub-TLVs need to be included in TLV
    222. So, in order to simplify the registration and reduce the
    potential code point conflict, this document suggests that TLV 22,
    TLV 141 and TLV 222 share the same sub-TLV registry. The proposal is
    that change the current Registry Name from "Sub-TLVs for TLV 22" to
    "Sub-TLVs for TLV 22, 141 and 222" and add three columns ("May be
    present on TLV 22","May be present on TLV 141" and "May be present
    on TLV 222") to the registry for indicating whether a specific sub-
    TLV may be present on the TLV.

   NEW
    This document defines the following new sub-TLV types, described in
    Sections 3.3.1, 3.3.2 and 3.3.3, of top-level TLV 141 (see section
    6.1 above) that need to be registered in the ISIS sub-TLV registry
    for TLV 141, note that these three new sub-TLVs SHOULD NOT appear in
    TLV 22 (or TLV 222) and MUST be ignored in TLV 22 (or TLV 222):

      Type        Description
      ----        ------------------------------
        24        Remote AS number
        25        IPv4 Remote ASBR Identifier
        26        IPv6 Remote ASBR Identifier

    As described above in Section 3.1, the sub-TLVs which are defined in
    [ISIS-TE], [ISIS-TE-V3] and other documents for describing the TE
    properties of an TE link are applicable to describe an inter-AS TE
    link and MAY be included in the Inter-AS Reachability TLV when
    adverting inter-AS TE links. 

    IANA is requested to update the registry currently specified as
    "Sub-TLVs for TLV 22" to be named "Sub-TLVs for TLVs 22, 141, and
    222". Three new columns should be added to the registry to show in
    which TLVs the sub-TLVs may be present. All sub-TLVs currently
    defined may be present in all three TLVs, hence the registry (with
    the definition of the new sub-TLVs defined here) should read as
    follows.
                                                TLV TLV TLV
    Type    Description                          22  141 222 Reference
    ------- ------------------------------------ --- --- --- ---------
       0    Unassigned                            y   y   y
       1    Unassigned                            y   y   y
       2    Unassigned                            y   y   y
       3    Administrative group (color)          y   y   y  [RFC5305]
       4    Link Local/Remote Identifiers         y   y   y
                                                    [RFC4205][RFC5307]
       5    Unassigned                            y   y   y
       6    IPv4 interface address                y   y   y  [RFC5305]
       7    Unassigned                            y   y   y
       8    IPv4 neighbor address                 y   y   y  [RFC5305]
       9    Maximum link bandwidth                y   y   y  [RFC5305]
      10    Maximum reservable link bandwidth     y   y   y  [RFC5305]
      11    Unreserved bandwidth                  y   y   y  [RFC5305]
      12    Unassigned                            y   y   y
      13    Unassigned                            y   y   y
      14    Unassigned                            y   y   y
      15    Unassigned                            y   y   y
      16    Unassigned                            y   y   y
      17    Unassigned                            y   y   y
      18    TE Default metric                     y   y   y  [RFC5305]
      19    Link-attributes                       y   y   y  [RFC5029]
      20    Link Protection Type                  y   y   y
                                                       [RFC4205][RFC5307]
      21    Interface Switching Capability Desc   y   y   y
                                                       [RFC4205][RFC5307]
      22    Bandwidth Constraints                 y   y   y  [RFC4124]
      23    Unconstrained TE LSP Count (sub-)TLV  y   y   y
                               [RFC-ietf-mpls-number-0-bw-te-lsps-12.txt]
      24    Remote AS number                      n   y   n  [This.I-D]
      25    IPv4 Remote ASBR Identifier           n   y   n  [This.I-D]
      26    IPv6 Remote ASBR Identifier           n   y   n  [This.I-D]
    27-249  Unassigned
    250-254 Reserved for Cisco-specific exts
    255     Reserved for future expansion

    Further sub-TLVs may be defined in the future for inclusion in any of




    the TLVs 22, 141, or 222. The re-naming of the registry as above
    ensures that there is no accidental overlap of sub-TLV codepoints.
    The introduction of the columns within the registry clarify the use
    of the sub-TLVs.

IANA Note

   Please note substantial IANA update in the RFC editor's note.