doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc5316.txt b/doc/rfc/rfc5316.txt
new file mode 100644
index 0000000..9135bd3
--- /dev/null
+++ b/doc/rfc/rfc5316.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                            M. Chen
+Request for Comments: 5316                                      R. Zhang
+Category: Standards Track                   Huawei Technologies Co., Ltd
+                                                                 X. Duan
+                                                            China Mobile
+                                                           December 2008
+
+
+      ISIS Extensions in Support of Inter-Autonomous System (AS)
+                   MPLS and GMPLS Traffic Engineering
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2008 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents (http://trustee.ietf.org/
+   license-info) in effect on the date of publication of this document.
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   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.
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 1]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Conventions Used in This Document ..........................3
+   2. Problem Statement ...............................................3
+      2.1. A Note on Non-Objectives ...................................4
+      2.2. Per-Domain Path Determination ..............................4
+      2.3. Backward Recursive Path Computation ........................6
+   3. Extensions to ISIS-TE ...........................................7
+      3.1. Inter-AS Reachability TLV ..................................7
+      3.2. TE Router ID ...............................................9
+      3.3. Sub-TLV Detail .............................................9
+           3.3.1. Remote AS Number Sub-TLV ............................9
+           3.3.2. IPv4 Remote ASBR ID Sub-TLV ........................10
+           3.3.3. IPv6 Remote ASBR ID Sub-TLV ........................11
+           3.3.4. IPv4 TE Router ID sub-TLV ..........................11
+           3.3.5. IPv6 TE Router ID sub-TLV ..........................12
+   4. Procedure for Inter-AS TE Links ................................12
+      4.1. Origin of Proxied TE Information ..........................14
+   5. Security Considerations ........................................14
+   6. IANA Considerations ............................................15
+      6.1. Inter-AS Reachability TLV .................................15
+      6.2. Sub-TLVs for the Inter-AS Reachability TLV ................15
+      6.3. Sub-TLVs for the IS-IS Router Capability TLV ..............17
+   7. Acknowledgments ................................................17
+   8. References .....................................................17
+      8.1. Normative References ......................................17
+      8.2. Informative References ....................................17
+
+1.  Introduction
+
+   [ISIS-TE] defines extensions to the ISIS protocol [ISIS] to support
+   intra-area Traffic Engineering (TE).  The extensions provide a way of
+   encoding the TE information for TE-enabled links within the network
+   (TE links) and flooding this information within an area.  The
+   extended IS reachability TLV and traffic engineering router ID TLV,
+   which are defined in [ISIS-TE], are used to carry such TE
+   information.  The extended IS reachability TLV has several nested
+   sub-TLVs that describe the TE attributes for a TE link.
+
+   [ISIS-TE-V3] and [GMPLS-TE] define similar extensions to ISIS [ISIS]
+   in support of IPv6 and GMPLS traffic engineering, respectively.
+
+   Requirements for establishing Multiprotocol Label Switching (MPLS) TE
+   Label Switched Paths (LSPs) that cross multiple Autonomous Systems
+   (ASes) are described in [INTER-AS-TE-REQ].  As described in [INTER-
+   AS-TE-REQ], a method SHOULD provide the ability to compute a path
+   spanning multiple ASes.  So a path computation entity that may be the
+
+
+
+Chen, et al.                Standards Track                     [Page 2]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+   head-end Label Switching Router (LSR), an AS Border Router (ASBR), or
+   a Path Computation Element (PCE [PCE]) needs to know the TE
+   information not only of the links within an AS, but also of the links
+   that connect to other ASes.
+
+   In this document, a new TLV, which is referred to as the inter-AS
+   reachability TLV, is defined to advertise inter-AS TE information,
+   and three new sub-TLVs are defined for inclusion in the inter-AS
+   reachability TLV to carry the information about the remote AS number
+   and remote ASBR ID.  The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3],
+   and other documents for inclusion in the extended IS reachability TLV
+   for describing the TE properties of a TE link are applicable to be
+   included in the inter-AS reachability TLV for describing the TE
+   properties of an inter-AS TE link as well.  Also, two more new sub-
+   TLVs are defined for inclusion in the IS-IS router capability TLV to
+   carry the TE Router ID when the TE Router ID needs to reach all
+   routers within an entire ISIS routing domain.  The extensions are
+   equally applicable to IPv4 and IPv6 as identical extensions to
+   [ISIS-TE] and [ISIS-TE-V3].  Detailed definitions and procedures are
+   discussed in the following sections.
+
+   This document does not propose or define any mechanisms to advertise
+   any other extra-AS TE information within ISIS.  See Section 2.1 for a
+   full list of non-objectives for this work.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC-2119 [RFC2119].
+
+2.  Problem Statement
+
+   As described in [INTER-AS-TE-REQ], in the case of establishing an
+   inter-AS TE LSP that traverses multiple ASes, the Path message
+   [RFC3209] may include the following elements in the Explicit Route
+   Object (ERO) in order to describe the path of the LSP:
+
+   -  a set of AS numbers as loose hops, and/or
+
+   -  a set of LSRs including ASBRs as loose hops.
+
+   Two methods for determining inter-AS paths are currently being
+   discussed.  The per-domain method [PD-PATH] determines the path one
+   domain at a time.  The backward recursive method [BRPC] uses
+   cooperation between PCEs to determine an optimum inter-domain path.
+   The sections that follow examine how inter-AS TE link information
+   could be useful in both cases.
+
+
+
+Chen, et al.                Standards Track                     [Page 3]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+2.1.  A Note on Non-Objectives
+
+   It is important to note that this document does not make any change
+   to the confidentiality and scaling assumptions surrounding the use of
+   ASes in the Internet.  In particular, this document is conformant to
+   the requirements set out in [INTER-AS-TE-REQ].
+
+   The following features are explicitly excluded:
+
+   o  There is no attempt to distribute TE information from within one
+      AS to another AS.
+
+   o  There is no mechanism proposed to distribute any form of TE
+      reachability information for destinations outside the AS.
+
+   o  There is no proposed change to the PCE architecture or usage.
+
+   o  TE aggregation is not supported or recommended.
+
+   o  There is no exchange of private information between ASes.
+
+   o  No ISIS adjacencies are formed on the inter-AS link.
+
+2.2.  Per-Domain Path Determination
+
+   In the per-domain method of determining an inter-AS path for an
+   MPLS-TE LSP, when an LSR that is an entry-point to an AS receives a
+   Path message from an upstream AS with an ERO containing a next hop
+   that is an AS number, it needs to find which LSRs (ASBRs) within the
+   local AS are connected to the downstream AS.  That way, it can
+   compute a TE LSP segment across the local AS to one of those LSRs and
+   forward the Path message to that LSR and hence into the next AS.  See
+   Figure 1 for an example.
+
+                R1------R3----R5-----R7------R9-----R11
+                        |     | \    |      / |
+                        |     |  \   |  ----  |
+                        |     |   \  | /      |
+                R2------R4----R6   --R8------R10----R12
+                           :              :
+                <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
+
+                    Figure 1: Inter-AS Reference Model
+
+   The figure shows three ASes (AS1, AS2, and AS3) and twelve LSRs (R1
+   through R12).  R3 and R4 are ASBRs in AS1.  R5, R6, R7, and R8 are
+   ASBRs in AS2.  R9 and R10 are ASBRs in AS3.
+
+
+
+
+Chen, et al.                Standards Track                     [Page 4]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+   If an inter-AS TE LSP is planned to be established from R1 to R12,
+   the AS sequence will be: AS1, AS2, AS3.
+
+   Suppose that the Path message enters AS2 from R3.  The next hop in
+   the ERO shows AS3, and R5 must determine a path segment across AS2 to
+   reach AS3.  It has a choice of three exit points from AS2 (R6, R7,
+   and R8), and it needs to know which of these provide TE connectivity
+   to AS3, and whether the TE connectivity (for example, available
+   bandwidth) is adequate for the requested LSP.
+
+   Alternatively, if the next hop in the ERO is the entry ASBR for AS3
+   (say R9), R5 needs to know which of its exit ASBRs has a TE link that
+   connects to R9.  Since there may be multiple ASBRs that are connected
+   to R9 (both R7 and R8 in this example), R5 also needs to know the TE
+   properties of the inter-AS TE links so that it can select the correct
+   exit ASBR.
+
+   Once the Path message reaches the exit ASBR, any choice of inter-AS
+   TE link can be made by the ASBR if not already made by the entry ASBR
+   that computed the segment.
+
+   More details can be found in Section 4 of [PD-PATH], which clearly
+   points out why advertising of inter-AS links is desired.
+
+   To enable R5 to make the correct choice of exit ASBR, the following
+   information is needed:
+
+   o  List of all inter-AS TE links for the local AS.
+
+   o  TE properties of each inter-AS TE link.
+
+   o  AS number of the neighboring AS connected to by each inter-AS TE
+      link.
+
+   o  Identity (TE Router ID) of the neighboring ASBR connected to by
+      each inter-AS TE link.
+
+   In GMPLS networks, further information may also be required to select
+   the correct TE links as defined in [GMPLS-TE].
+
+   The example above shows how this information is needed at the entry-
+   point ASBRs for each AS (or the PCEs that provide computation
+   services for the ASBRs).  However, this information is also needed
+   throughout the local AS if path computation functionality is fully
+   distributed among LSRs in the local AS, for example to support LSPs
+   that have start points (ingress nodes) within the AS.
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 5]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+2.3.  Backward Recursive Path Computation
+
+   Another scenario using PCE techniques has the same problem.  [BRPC]
+   defines a PCE-based TE LSP computation method (called Backward
+   Recursive Path Computation) to compute optimal inter-domain
+   constrained MPLS-TE or GMPLS LSPs.  In this path computation method,
+   a specific set of traversed domains (ASes) are assumed to be selected
+   before computation starts.  Each downstream PCE in domain(i) returns
+   to its upstream neighbor PCE in domain(i-1) a multipoint-to-point
+   tree of potential paths.  Each tree consists of the set of paths from
+   all boundary nodes located in domain(i) to the destination where each
+   path satisfies the set of required constraints for the TE LSP
+   (bandwidth, affinities, etc.).
+
+   So a PCE needs to select boundary nodes (that is, ASBRs) that provide
+   connectivity from the upstream AS.  In order for the tree of paths
+   provided by one PCE to its neighbor to be correlated, the identities
+   of the ASBRs for each path need to be referenced.  Thus, the PCE must
+   know the identities of the ASBRs in the remote AS that are reached by
+   any inter-AS TE link, and, in order to provide only suitable paths in
+   the tree, the PCE must know the TE properties of the inter-AS TE
+   links.  See the following figure as an example.
+
+                   PCE1<------>PCE2<-------->PCE3
+                   /       :             :
+                  /        :             :
+                R1------R3----R5-----R7------R9-----R11
+                        |     | \    |      / |
+                        |     |  \   |  ----  |
+                        |     |   \  | /      |
+                R2------R4----R6   --R8------R10----R12
+                           :              :
+                <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
+
+               Figure 2: BRPC for Inter-AS Reference Model
+
+   The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1,
+   PCE2, and PCE3), and twelve LSRs (R1 through R12).  R3 and R4 are
+   ASBRs in AS1.  R5, R6, R7, and R8 are ASBRs in AS2.  R9 and R10 are
+   ASBRs in AS3.  PCE1, PCE2, and PCE3 cooperate to perform inter-AS
+   path computation and are responsible for path segment computation
+   within their own domain(s).
+
+   If an inter-AS TE LSP is planned to be established from R1 to R12,
+   the traversed domains are assumed to be selected: AS1->AS2->AS3, and
+   the PCE chain is: PCE1->PCE2->PCE3.  First, the path computation
+   request originated from the PCC (R1) is relayed by PCE1 and PCE2
+   along the PCE chain to PCE3.  Then, PCE3 begins to compute the path
+
+
+
+Chen, et al.                Standards Track                     [Page 6]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+   segments from the entry boundary nodes that provide connection from
+   AS2 to the destination (R12).  But, to provide suitable path
+   segments, PCE3 must determine which entry boundary nodes provide
+   connectivity to its upstream neighbor AS (identified by its AS
+   number), and must know the TE properties of the inter-AS TE links.
+   In the same way, PCE2 also needs to determine the entry boundary
+   nodes according to its upstream neighbor AS and the inter-AS TE link
+   capabilities.
+
+   Thus, to support Backward Recursive Path Computation, the same
+   information listed in Section 2.2 is required.  The AS number of the
+   neighboring AS connected to by each inter-AS TE link is particularly
+   important.
+
+3.  Extensions to ISIS-TE
+
+   Note that this document does not define mechanisms for distribution
+   of TE information from one AS to another, does not distribute any
+   form of TE reachability information for destinations outside the AS,
+   does not change the PCE architecture or usage, does not suggest or
+   recommend any form of TE aggregation, and does not feed private
+   information between ASes.  See Section 2.1.
+
+   In this document, for the advertisement of inter-AS TE links, a new
+   TLV, which is referred to as the inter-AS reachability TLV, is
+   defined.  Three new sub-TLVs are also defined for inclusion in the
+   inter-AS reachability TLV to carry the information about the
+   neighboring AS number and the remote ASBR ID of an inter-AS link.
+   The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents
+   for inclusion in the extended IS reachability TLV are applicable to
+   be included in the inter-AS reachability TLV for inter-AS TE links
+   advertisement.  Also, two other new sub-TLVs are defined for
+   inclusion in the IS-IS router capability TLV to carry the TE Router
+   ID when the TE Router ID is needed to reach all routers within an
+   entire ISIS routing domain.
+
+   While some of the TE information of an inter-AS TE link may be
+   available within the AS from other protocols, in order to avoid any
+   dependency on where such protocols are processed, this mechanism
+   carries all the information needed for the required TE operations.
+
+3.1.  Inter-AS Reachability TLV
+
+   The inter-AS reachability TLV has type 141 (see Section 6.1) and
+   contains a data structure consisting of:
+
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 7]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+      o  4 octets of Router ID
+      o  3 octets of default metric
+      o  1 octet of control information, consisting of:
+         -  1 bit of flooding-scope information (S bit)
+         -  1 bit of up/down information (D bit)
+         -  6 bits reserved
+      o  1 octet of length of sub-TLVs
+      o  0-246 octets of sub-TLVs, where each sub-TLV consists of a
+         sequence of:
+         -  1 octet of sub-type
+         -  1 octet of length of the value field of the sub-TLV
+         -  0-244 octets of value
+
+   Compared to the extended reachability TLV, which is defined in
+   [ISIS-TE], the inter-AS reachability TLV replaces the "7 octets of
+   System ID and Pseudonode Number" field with a "4 octets of Router ID"
+   field and introduces an extra "control information" field, which
+   consists of a flooding-scope bit (S bit), an up/down bit (D bit), and
+   6 reserved bits.
+
+   The Router ID field of the inter-AS reachability TLV is 4 octets in
+   length, which contains the Router ID of the router who generates the
+   inter-AS reachability TLV.  The Router ID MUST be unique within the
+   ISIS area.  If the router generates inter-AS reachability TLV with
+   entire ISIS routing domain flooding scope, then the Router ID MUST
+   also be unique within the entire ISIS routing domain.  The Router ID
+   could be used to indicate the source of the inter-AS reachability
+   TLV.
+
+   The flooding procedures for inter-AS reachability TLV are identical
+   to the flooding procedures for the GENINFO TLV, which are defined in
+   Section 4 of [GENINFO].  These procedures have been previously
+   discussed in [ISIS-CAP].  The flooding-scope bit (S bit) SHOULD be
+   set to 0 if the flooding scope is to be limited to within the single
+   IGP area to which the ASBR belongs.  It MAY be set to 1 if the
+   information is intended to reach all routers (including area border
+   routers, ASBRs, and PCEs) in the entire ISIS routing domain.  The
+   choice between the use of 0 or 1 is an AS-wide policy choice, and
+   configuration control SHOULD be provided in ASBR implementations that
+   support the advertisement of inter-AS TE links.
+
+   The sub-TLVs defined in [ISIS-TE], [ISIS-TE-V3], and other documents
+   for describing the TE properties of a TE link are also applicable to
+   the inter-AS reachability TLV for describing the TE properties of an
+   inter-AS TE link.  Apart from these sub-TLVs, three new sub-TLVs are
+   defined for inclusion in the inter-AS reachability TLV defined in
+   this document:
+
+
+
+
+Chen, et al.                Standards Track                     [Page 8]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+   Sub-TLV type    Length  Name
+   ------------    ------  ---------------------------
+             24        4   remote AS number
+             25        4   IPv4 remote ASBR identifier
+             26       16   IPv6 remote ASBR identifier
+
+   The detailed definitions of the three new sub-TLVs are described in
+   Section 3.3.
+
+3.2.  TE Router ID
+
+   The IPv4 TE Router ID TLV and IPv6 TE Router ID TLV, which are
+   defined in [ISIS-TE] and [ISIS-TE-V3] respectively, only have area
+   flooding-scope.  When performing inter-AS TE, the TE Router ID MAY be
+   needed to reach all routers within an entire ISIS routing domain and
+   it MUST have the same flooding scope as the inter-AS reachability TLV
+   does.
+
+   [ISIS-CAP] defines a generic advertisement mechanism for ISIS, which
+   allows a router to advertise its capabilities within an ISIS area or
+   an entire ISIS routing domain.  [ISIS-CAP] also points out that the
+   TE Router ID is a candidate to be carried in the IS-IS router
+   capability TLV when performing inter-area TE.
+
+   This document uses such mechanism for TE Router ID advertisement when
+   the TE Router ID is needed to reach all routers within an entire ISIS
+   Routing domain.  Two new sub-TLVs are defined for inclusion in the
+   IS-IS router capability TLV to carry the IPv4 and IPv6 TE Router IDs,
+   respectively:
+
+   Sub-TLV type   Length  Name
+   ------------    ------  -----------------
+             11        4   IPv4 TE Router ID
+             12       16   IPv6 TE Router ID
+
+   Detailed definitions of the two new sub-TLVs are described in Section
+   3.3.
+
+3.3.  Sub-TLV Detail
+
+3.3.1.  Remote AS Number Sub-TLV
+
+   A new sub-TLV, the remote AS number sub-TLV, is defined for inclusion
+   in the inter-AS reachability TLV when advertising inter-AS links.
+   The remote AS number sub-TLV specifies the AS number of the
+   neighboring AS to which the advertised link connects.
+
+
+
+
+
+Chen, et al.                Standards Track                     [Page 9]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+   The remote AS number sub-TLV is TLV type 24 (see Section 6.2) and is
+   4 octets in length.  The format is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Type             |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Remote AS Number                        |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The Remote AS number field has 4 octets.  When only 2 octets are used
+   for the AS number, as in current deployments, the left (high-order) 2
+   octets MUST be set to 0.  The remote AS number sub-TLV MUST be
+   included when a router advertises an inter-AS TE link.
+
+3.3.2.  IPv4 Remote ASBR ID Sub-TLV
+
+   A new sub-TLV, which is referred to as the IPv4 remote ASBR ID sub-
+   TLV, is defined for inclusion in the inter-AS reachability TLV when
+   advertising inter-AS links.  The IPv4 remote ASBR ID sub-TLV
+   specifies the IPv4 identifier of the remote ASBR to which the
+   advertised inter-AS link connects.  This could be any stable and
+   routable IPv4 address of the remote ASBR.  Use of the TE Router ID as
+   specified in the Traffic Engineering router ID TLV [ISIS-TE] is
+   RECOMMENDED.
+
+   The IPv4 remote ASBR ID sub-TLV is TLV type 25 (see Section 6.2) and
+   is 4 octets in length.  The format of the IPv4 remote ASBR ID sub-TLV
+   is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Type             |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Remote ASBR ID                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The IPv4 remote ASBR ID sub-TLV MUST be included if the neighboring
+   ASBR has an IPv4 address.  If the neighboring ASBR does not have an
+   IPv4 address (not even an IPv4 TE Router ID), the IPv6 remote ASBR ID
+   sub-TLV MUST be included instead.  An IPv4 remote ASBR ID sub-TLV and
+   IPv6 remote ASBR ID sub-TLV MAY both be present in an extended IS
+   reachability TLV.
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 10]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+3.3.3.  IPv6 Remote ASBR ID Sub-TLV
+
+   A new sub-TLV, which is referred to as the IPv6 remote ASBR ID sub-
+   TLV, is defined for inclusion in the inter-AS reachability TLV when
+   advertising inter-AS links.  The IPv6 remote ASBR ID sub-TLV
+   specifies the IPv6 identifier of the remote ASBR to which the
+   advertised inter-AS link connects.  This could be any stable and
+   routable IPv6 address of the remote ASBR.  Use of the TE Router ID as
+   specified in the IPv6 Traffic Engineering router ID TLV [ISIS-TE-V3]
+   is RECOMMENDED.
+
+   The IPv6 remote ASBR ID sub-TLV is TLV type 26 (see Section 6.2) and
+   is 16 octets in length.  The format of the IPv6 remote ASBR ID sub-
+   TLV is as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Type             |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Remote ASBR ID                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Remote ASBR ID (continued)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Remote ASBR ID (continued)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       Remote ASBR ID (continued)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The IPv6 remote ASBR ID sub-TLV MUST be included if the neighboring
+   ASBR has an IPv6 address.  If the neighboring ASBR does not have an
+   IPv6 address, the IPv4 remote ASBR ID sub-TLV MUST be included
+   instead.  An IPv4 remote ASBR ID sub-TLV and IPv6 remote ASBR ID
+   sub-TLV MAY both be present in an extended IS reachability TLV.
+
+3.3.4.  IPv4 TE Router ID sub-TLV
+
+   The IPv4 TE Router ID sub-TLV is TLV type 11 (see Section 6.3) and is
+   4 octets in length.  The format of the IPv4 TE Router ID sub-TLV is
+   as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Type             |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       TE Router ID                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Chen, et al.                Standards Track                    [Page 11]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+
+   When the TE Router ID is needed to reach all routers within an entire
+   ISIS routing domain, the IS-IS Router capability TLV MUST be included
+   in its LSP.  If an ASBR supports Traffic Engineering for IPv4 and if
+   the ASBR has an IPv4 TE Router ID, the IPv4 TE Router ID sub-TLV MUST
+   be included.  If the ASBR does not have an IPv4 TE Router ID, the
+   IPv6 TE Router sub-TLV MUST be included instead.  An IPv4 TE Router
+   ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an
+   IS-IS router capability TLV.
+
+3.3.5.  IPv6 TE Router ID sub-TLV
+
+   The IPv6 TE Router ID sub-TLV is TLV type 12 (see Section 6.3) and is
+   4 octets in length.  The format of the IPv6 TE Router ID sub-TLV is
+   as follows:
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Type             |             Length            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       TE Router ID                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       TE Router ID   (continued)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       TE Router ID   (continued)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                       TE Router ID   (continued)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   When the TE Router ID is needed to reach all routers within an entire
+   ISIS routing domain, the IS-IS router capability TLV MUST be included
+   in its LSP.  If an ASBR supports Traffic Engineering for IPv6 and if
+   the ASBR has an IPv6 TE Router ID, the IPv6 TE Router ID sub-TLV MUST
+   be included.  If the ASBR does not have an IPv6 TE Router ID, the
+   IPv4 TE Router sub-TLV MUST be included instead.  An IPv4 TE Router
+   ID sub-TLV and IPv6 TE Router ID sub-TLV MAY both be present in an
+   IS-IS router capability TLV.
+
+4.  Procedure for Inter-AS TE Links
+
+   When TE is enabled on an inter-AS link and the link is up, the ASBR
+   SHOULD advertise this link using the normal procedures for ISIS-TE
+   [ISIS-TE].  When either the link is down or TE is disabled on the
+   link, the ASBR SHOULD withdraw the advertisement.  When there are
+   changes to the TE parameters for the link (for example, when the
+   available bandwidth changes), the ASBR SHOULD re-advertise the link
+   but MUST take precautions against excessive re-advertisements.
+
+
+
+Chen, et al.                Standards Track                    [Page 12]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+   Hellos MUST NOT be exchanged over the inter-AS link, and
+   consequently, an ISIS adjacency MUST NOT be formed.
+
+   The information advertised comes from the ASBR's knowledge of the TE
+   capabilities of the link, the ASBR's knowledge of the current status
+   and usage of the link, and configuration at the ASBR of the remote AS
+   number and remote ASBR TE Router ID.
+
+   Legacy routers receiving an advertisement for an inter-AS TE link are
+   able to ignore it because they do not know the new TLV and sub-TLVs
+   that are defined in Section 3 of this document.  They will continue
+   to flood the LSP, but will not attempt to use the information
+   received.
+
+   In the current operation of ISIS TE, the LSRs at each end of a TE
+   link emit LSAs describing the link.  The databases in the LSRs then
+   have two entries (one locally generated, the other from the peer)
+   that describe the different 'directions' of the link.  This enables
+   Constrained Shortest Path First (CSPF) to do a two-way check on the
+   link when performing path computation and eliminate it from
+   consideration unless both directions of the link satisfy the required
+   constraints.
+
+   In the case we are considering here (i.e., of a TE link to another
+   AS), there is, by definition, no IGP peering and hence no
+   bidirectional TE link information.  In order for the CSPF route
+   computation entity to include the link as a candidate path, we have
+   to find a way to get LSAs describing its (bidirectional) TE
+   properties into the TE database.
+
+   This is achieved by the ASBR advertising, internally to its AS,
+   information about both directions of the TE link to the next AS.  The
+   ASBR will normally generate an LSA describing its own side of a link;
+   here we have it 'proxy' for the ASBR at the edge of the other AS and
+   generate an additional LSA that describes that device's 'view' of the
+   link.
+
+   Only some essential TE information for the link needs to be
+   advertised; i.e., the Interface Address, the remote AS number, and
+   the remote ASBR ID of an inter-AS TE link.
+
+   Routers or PCEs that are capable of processing advertisements of
+   inter-AS TE links SHOULD NOT use such links to compute paths that
+   exit an AS to a remote ASBR and then immediately re-enter the AS
+   through another TE link.  Such paths would constitute extremely rare
+   occurrences and SHOULD NOT be allowed except as the result of
+   specific policy configurations at the router or PCE computing the
+   path.
+
+
+
+Chen, et al.                Standards Track                    [Page 13]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+4.1.  Origin of Proxied TE Information
+
+   Section 4 describes how an ASBR advertises TE link information as a
+   proxy for its neighbor ASBR, but does not describe where this
+   information comes from.
+
+   Although the source of this information is outside the scope of this
+   document, it is possible that it will be a configuration requirement
+   at the ASBR, as are other local properties of the TE link.  Further,
+   where BGP is used to exchange IP routing information between the
+   ASBRs, a certain amount of additional local configuration about the
+   link and the remote ASBR is likely to be available.
+
+   We note further that it is possible, and may be operationally
+   advantageous, to obtain some of the required configuration
+   information from BGP.  Whether and how to utilize these possibilities
+   is an implementation matter.
+
+5.  Security Considerations
+
+   The protocol extensions defined in this document are relatively minor
+   and can be secured within the AS in which they are used by the
+   existing ISIS security mechanisms (e.g., using the cleartext
+   passwords or Hashed Message Authentication Codes - Message Digest 5
+   (HMAC-MD5) algorithm, which are defined in [ISIS] and [RFC5304],
+   respectively).
+
+   There is no exchange of information between ASes, and no change to
+   the ISIS security relationship between the ASes.  In particular,
+   since no ISIS adjacency is formed on the inter-AS links, there is no
+   requirement for ISIS security between the ASes.
+
+   Some of the information included in these new advertisements (e.g.,
+   the remote AS number and the remote ASBR ID) is obtained manually
+   from a neighboring administration as part of a commercial
+   relationship.  The source and content of this information should be
+   carefully checked before it is entered as configuration information
+   at the ASBR responsible for advertising the inter-AS TE links.
+
+   It is worth noting that in the scenario we are considering, a Border
+   Gateway Protocol (BGP) peering may exist between the two ASBRs and
+   that this could be used to detect inconsistencies in configuration
+   (e.g., the administration that originally supplied the information
+   may be lying, or some manual mis-configurations or mistakes may be
+   made by the operators).  For example, if a different remote AS number
+   is received in a BGP OPEN [BGP] from that locally configured to
+   ISIS-TE, as we describe here, then local policy SHOULD be applied to
+   determine whether to alert the operator to a potential mis-
+
+
+
+Chen, et al.                Standards Track                    [Page 14]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+   configuration or to suppress the ISIS advertisement of the inter-AS
+   TE link.  Note further that if BGP is used to exchange TE information
+   as described in Section 4.1, the inter-AS BGP session SHOULD be
+   secured using mechanisms as described in [BGP] to provide
+   authentication and integrity checks.
+
+   For a discussion of general security considerations for IS-IS, see
+   [RFC5304].
+
+6.  IANA Considerations
+
+   IANA has made the following allocations from registries under its
+   control.
+
+6.1.  Inter-AS Reachability TLV
+
+   This document defines the following new ISIS TLV type, described in
+   Section 3.1, which has been registered in the ISIS TLV codepoint
+   registry:
+
+              Type        Description              IIH   LSP   SNP
+              ----        ----------------------   ---   ---   ---
+               141        inter-AS reachability     n     y     n
+                                information
+
+6.2.  Sub-TLVs for the Inter-AS Reachability TLV
+
+   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), which have been 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 defined in [ISIS-TE],
+   [ISIS-TE-V3], and other documents for describing the TE properties of
+   a 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 has updated the registry that was specified as "Sub-TLVs for TLV
+   22" to be named "Sub-TLVs for TLVs 22, 141, and 222".  Three new
+   columns have been added to the registry to show in which TLVs the
+
+
+
+Chen, et al.                Standards Track                    [Page 15]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+   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  [RFC5330]
+     24    remote AS number                      n   y   n  [RFC5316]
+     25    IPv4 remote ASBR identifier           n   y   n  [RFC5316]
+     26    IPv6 remote ASBR identifier           n   y   n  [RFC5316]
+   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.
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 16]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+6.3.  Sub-TLVs for the IS-IS Router Capability TLV
+
+   This document defines the following new sub-TLV types, described in
+   Sections 3.3.4 and 3.3.5, of top-level TLV 242 (which is defined in
+   [ISIS-CAP]) that have been registered in the ISIS sub-TLV registry
+   for TLV 242:
+
+      Type        Description                        Length
+      ----        ------------------------------   --------
+        11        IPv4 TE Router ID                       4
+        12        IPv6 TE Router ID                      16
+
+7.  Acknowledgments
+
+   The authors would like to thank Adrian Farrel, Jean-Louis Le Roux,
+   Christian Hopps, Les Ginsberg, and Hannes Gredler for their review
+   and comments on this document.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]         Bradner, S., "Key words for use in RFCs to Indicate
+                     Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3209]         Awduche, D., Berger, L., Gan, D., Li, T.,
+                     Srinivasan, V., and G. Swallow, "RSVP-TE:
+                     Extensions to RSVP for LSP Tunnels", RFC 3209,
+                     December 2001.
+
+   [RFC5304]         Li, T. and R. Atkinson, "IS-IS Cryptographic
+                     Authentication", RFC 5304, October 2008.
+
+   [ISIS]            Callon, R., "Use of OSI IS-IS for routing in TCP/IP
+                     and dual environments", RFC 1195, December 1990.
+
+   [ISIS-CAP]        Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal,
+                     Ed., "Intermediate System to Intermediate System
+                     (IS-IS) Extensions for Advertising Router
+                     Information", RFC 4971, July 2007.
+
+8.2.  Informative References
+
+   [INTER-AS-TE-REQ] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS
+                     Inter-Autonomous System (AS) Traffic Engineering
+                     (TE) Requirements", RFC 4216, November 2005.
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 17]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+   [PD-PATH]         Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang,
+                     "A Per-Domain Path Computation Method for
+                     Establishing Inter-Domain Traffic Engineering (TE)
+                     Label Switched Paths (LSPs)", RFC 5152, February
+                     2008.
+
+   [BRPC]            Vasseur, JP., Ed., Zhang, R., Bitar, N., JL. Le
+                     Roux, "A Backward Recursive PCE-Based Computation
+                     (BRPC) Procedure to Compute Shortest Inter-Domain
+                     Traffic Engineering Label Switched Paths", Work in
+                     Progress, April 2008.
+
+   [PCE]             Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+                     Computation Element (PCE)-Based Architecture", RFC
+                     4655, August 2006.
+
+   [ISIS-TE]         Li, T. and H. Smit, "IS-IS Extensions for Traffic
+                     Engineering", RFC 5305, October 2008.
+
+   [ISIS-TE-V3]      Harrison, J., Berger, J., and Bartlett, M., "IPv6
+                     Traffic Engineering in IS-IS", Work in Progress,
+                     June 2008.
+
+   [GMPLS-TE]        Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS
+                     Extensions in Support of Generalized Multi-Protocol
+                     Label Switching (GMPLS)", RFC 5307, October 2008.
+
+   [BGP]             Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed.,
+                     "A Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+                     January 2006.
+
+   [GENINFO]         L. Ginsberg., Previdi, S., and M. Shand,
+                     "Advertising Generic Information in IS-IS", Work in
+                     Progress, June 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 18]
+
+RFC 5316            ISIS Extensions for Inter-AS TE        December 2008
+
+
+Authors' Addresses
+
+   Mach (Guoyi) Chen
+   Huawei Technologies Co., Ltd
+   KuiKe Building, No.9 Xinxi Rd.
+   Hai-Dian District
+   Beijing, 100085
+   P.R. China
+
+   EMail: mach@huawei.com
+
+
+   Renhai Zhang
+   Huawei Technologies Co., Ltd
+   KuiKe Building, No.9 Xinxi Rd.
+   Hai-Dian District
+   Beijing, 100085
+   P.R. China
+
+   EMail: zhangrenhai@huawei.com
+
+
+   Xiaodong Duan
+   China Mobile
+   53A, Xibianmennei Ave.
+   Xunwu District
+   Beijing, China
+
+   EMail: duanxiaodong@chinamobile.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                Standards Track                    [Page 19]
+