doc: Add RFC documents

1 files changed, 1010 insertions, 0 deletions

diff --git a/doc/rfc/rfc9346.txt b/doc/rfc/rfc9346.txt
new file mode 100644
index 0000000..df3c2ed
--- /dev/null
+++ b/doc/rfc/rfc9346.txt
@@ -0,0 +1,1010 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           M. Chen
+Request for Comments: 9346                                        Huawei
+Obsoletes: 5316                                              L. Ginsberg
+Category: Standards Track                                  Cisco Systems
+ISSN: 2070-1721                                               S. Previdi
+                                                     Huawei Technologies
+                                                                 X. Duan
+                                                            China Mobile
+                                                           February 2023
+
+
+  IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and
+                       GMPLS Traffic Engineering
+
+Abstract
+
+   This document describes extensions to the Intermediate System to
+   Intermediate System (IS-IS) protocol to support Multiprotocol Label
+   Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
+   (TE) for multiple Autonomous Systems (ASes).  It defines IS-IS
+   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.
+
+   This document builds on RFC 5316 by adding support for IPv6-only
+   operation.
+
+   This document obsoletes RFC 5316.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9346.
+
+Copyright Notice
+
+   Copyright (c) 2023 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
+   (https://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.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  Problem Statement
+     2.1.  A Note on Non-objectives
+     2.2.  Per-Domain Path Determination
+     2.3.  Backward-Recursive Path Computation
+   3.  Extensions to IS-IS TE
+     3.1.  Choosing the TE Router ID Value
+     3.2.  Inter-AS Reachability Information TLV
+     3.3.  TE Router ID
+     3.4.  Sub-TLVs for Inter-AS Reachability Information TLV
+       3.4.1.  Remote AS Number Sub-TLV
+       3.4.2.  IPv4 Remote ASBR Identifier Sub-TLV
+       3.4.3.  IPv6 Remote ASBR Identifier Sub-TLV
+       3.4.4.  IPv6 Local ASBR Identifier Sub-TLV
+     3.5.  Sub-TLVs for IS-IS Router CAPABILITY TLV
+       3.5.1.  IPv4 TE Router ID Sub-TLV
+       3.5.2.  IPv6 TE Router ID Sub-TLV
+   4.  Procedure for Inter-AS TE Links
+     4.1.  Origin of Proxied TE Information
+   5.  Security Considerations
+   6.  IANA Considerations
+     6.1.  Inter-AS Reachability Information TLV
+     6.2.  Sub-TLVs for the Inter-AS Reachability Information TLV
+     6.3.  Sub-TLVs for the IS-IS Router CAPABILITY TLV
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  Changes to RFC 5316
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   [RFC5305] defines extensions to the IS-IS protocol [RFC1195] 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 [RFC5305], 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.
+
+   [RFC6119] and [RFC5307] define similar extensions to IS-IS in support
+   of IPv6 and GMPLS TE, respectively.
+
+   Requirements for establishing Multiprotocol Label Switching (MPLS) TE
+   Label Switched Paths (LSPs) that cross multiple Autonomous Systems
+   (ASes) are described in [RFC4216].  As described in [RFC4216], a
+   method SHOULD provide the ability to compute a path spanning multiple
+   ASes.  So a path computation entity that may be the head-end Label
+   Switching Router (LSR), an AS Border Router (ASBR), or a Path
+   Computation Element (PCE) [RFC4655] 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, the Inter-AS Reachability Information TLV is
+   defined to advertise inter-AS TE information, and four sub-TLVs are
+   defined for inclusion in the Inter-AS Reachability Information TLV to
+   carry the information about the Remote AS Number, Remote ASBR
+   Identifier, and IPv6 Local ASBR Identifier.  The sub-TLVs defined in
+   [RFC5305], [RFC6119], 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
+   Information TLV for describing the TE properties of an inter-AS TE
+   link as well.  Also, two more 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 IS-IS
+   routing domain.  The extensions are equally applicable to IPv4 and
+   IPv6 as identical extensions to [RFC5305] and [RFC6119].  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 IS-IS.  See Section 2.1 for
+   a full list of non-objectives for this work.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  Problem Statement
+
+   As described in [RFC4216], 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 have been described
+   elsewhere.  The per-domain method [RFC5152] determines the path one
+   domain at a time.  The backward-recursive method [RFC5441] 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.
+
+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 [RFC4216].
+
+   The following features are explicitly excluded:
+
+   *  There is no attempt to distribute TE information from within one
+      AS to another AS.
+
+   *  There is no mechanism proposed to distribute any form of TE
+      reachability information for destinations outside the AS.
+
+   *  There is no proposed change to the PCE architecture or usage.
+
+   *  TE aggregation is not supported or recommended.
+
+   *  There is no exchange of private information between ASes.
+
+   *  No IS-IS 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.
+
+   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 an 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 [RFC5152], 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:
+
+   *  List of all inter-AS TE links for the local AS.
+
+   *  TE properties of each inter-AS TE link.
+
+   *  AS number of the neighboring AS connected to by each inter-AS TE
+      link.
+
+   *  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 [RFC5307].
+
+   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.
+
+2.3.  Backward-Recursive Path Computation
+
+   Another scenario using PCE techniques has the same problem.
+   [RFC5441] defines a PCE-based TE LSP computation method (called
+   "Backward-Recursive Path Computation (BRPC)") 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 Path Computation Client (PCC) (R1) is
+   relayed by PCE1 and PCE2 along the PCE chain to PCE3.  Then, PCE3
+   begins to compute the path 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 BRPC, 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 IS-IS 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, the Inter-AS Reachability Information TLV is
+   defined for the advertisement of inter-AS TE links.  Four sub-TLVs
+   are also defined for inclusion in the Inter-AS Reachability
+   Information TLV to carry the information about the neighboring AS
+   number, the Remote ASBR Identifier, and IPv6 Local ASBR Identifier of
+   an inter-AS link.  The sub-TLVs defined in [RFC5305], [RFC6119], and
+   other documents for inclusion in the extended IS reachability TLV are
+   applicable to be included in the Inter-AS Reachability Information
+   TLV for the advertisement of inter-AS TE links.
+
+   This document also defines two sub-TLVs 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 IS-IS 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.  Choosing the TE Router ID Value
+
+   Subsequent sections specify advertisement of a TE Router ID value for
+   IPv4 and/or IPv6.  This section defines how this value is chosen.
+
+   A TE Router ID MUST be an address that is unique within the IS-IS
+   domain and stable, i.e., it can always be referenced in a path that
+   will be reachable from multiple hops away, regardless of the state of
+   the node's interfaces.
+
+   When advertising an IPv4 address as a TE Router ID, if the Traffic
+   Engineering router ID TLV [RFC5305] is being advertised, then the
+   address SHOULD be identical to the address in the Traffic Engineering
+   router ID TLV.  The TE Router ID MAY be identical to an IP Interface
+   Address [RFC1195] advertised by the originating IS so long as the
+   address meets the requirements specified above.
+
+   When advertising an IPv6 address as a TE Router ID, if the IPv6 TE
+   Router ID TLV [RFC6119] is being advertised, then the address SHOULD
+   be identical to the address in the IPv6 TE Router ID TLV.  The TE
+   Router ID MAY be identical to a non-link-local IPv6 Interface Address
+   advertised by the originating IS in a Link State PDU using the IPv6
+   Interface Address TLV [RFC5308] so long as the address meets the
+   requirements specified above.
+
+3.2.  Inter-AS Reachability Information TLV
+
+   The Inter-AS Reachability Information TLV has type 141 (see
+   Section 6.1) and contains a data structure consisting of:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Router ID                                     (4 octets)    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Default Metric                              | (3 octets)
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Flags     |                                 (1 octet)
+      +-+-+-+-+-+-+-+-+
+      |Sub-TLVs Length|                                 (1 octet)
+      +-+-+-+-+-+-+-+-+-+-+-+-
+      | Sub-TLVs ...                                    (0-246 octets)
+      +-+-+-+-+-+-+-+-+-+-+-+-
+
+   Flags consists of the following:
+
+          0 1 2 3 4 5 6 7
+         +-+-+-+-+-+-+-+-+
+         |S|D| Rsvd      |
+         +-+-+-+-+-+-+-+-+
+
+   where:
+
+   S bit:  If the S bit is set(1), the Inter-AS Reachability Information
+      TLV MUST be flooded across the entire routing domain.  If the S
+      bit is not set(0), the TLV MUST NOT be leaked between levels.
+      This bit MUST NOT be altered during the TLV leaking.
+
+   D bit:  When the Inter-AS Reachability Information TLV is leaked from
+      Level 2 (L2) to Level 1 (L1), the D bit MUST be set.  Otherwise,
+      this bit MUST be clear.  Inter-AS Reachability Information TLVs
+      with the D bit set MUST NOT be leaked from Level 1 to Level 2.
+      This is to prevent TLV looping.
+
+   Reserved (Rsvd):  Reserved bits MUST be zero when originated and
+      ignored when received.
+
+   Compared to the extended IS reachability TLV, which is defined in
+   [RFC5305], the Inter-AS Reachability Information 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 Information TLV is 4
+   octets in length and has a value as defined in Section 3.1.  If the
+   originating node does not support IPv4, then the reserved value
+   0.0.0.0 MUST be used in the Router ID field, and the IPv6 Router ID
+   sub-TLV MUST be present in the Inter-AS Reachability Information TLV.
+   The Router ID could be used to indicate the source of the Inter-AS
+   Reachability Information TLV.
+
+   The flooding procedures for the Inter-AS Reachability Information TLV
+   are identical to the flooding procedures for the GENINFO TLV, which
+   are defined in Section 4 of [RFC6823].  These procedures have been
+   previously discussed in [RFC7981].  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 IS-IS 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 [RFC5305], [RFC6119], and other documents for
+   describing the TE properties of a TE link are also applicable to the
+   Inter-AS Reachability Information TLV for describing the TE
+   properties of an inter-AS TE link.  Apart from these sub-TLVs, four
+   sub-TLVs are defined for inclusion in the Inter-AS Reachability
+   Information TLV defined in this document:
+
+          +==============+========+=============================+
+          | Sub-TLV type | Length | Name                        |
+          +==============+========+=============================+
+          | 24           | 4      | Remote AS Number            |
+          +--------------+--------+-----------------------------+
+          | 25           | 4      | IPv4 Remote ASBR Identifier |
+          +--------------+--------+-----------------------------+
+          | 26           | 16     | IPv6 Remote ASBR Identifier |
+          +--------------+--------+-----------------------------+
+          | 45           | 16     | IPv6 Local ASBR Identifier  |
+          +--------------+--------+-----------------------------+
+
+                                  Table 1
+
+   Detailed definitions of these four sub-TLVs are described in Sections
+   3.4.1, 3.4.2, 3.4.3, and 3.4.4.
+
+3.3.  TE Router ID
+
+   The Traffic Engineering router ID TLV and IPv6 TE Router ID TLV,
+   which are defined in [RFC5305] and [RFC6119], 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 IS-IS routing
+   domain, and it MUST have the same flooding scope as the Inter-AS
+   Reachability Information TLV does.
+
+   [RFC7981] defines a generic advertisement mechanism for IS-IS, which
+   allows a router to advertise its capabilities within an IS-IS area or
+   an entire IS-IS routing domain.  [RFC7981] 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 IS-
+   IS routing domain.  Two sub-TLVs are defined for inclusion in the IS-
+   IS Router CAPABILITY TLV to carry the TE Router IDs.
+
+               +==============+========+===================+
+               | Sub-TLV type | Length | Name              |
+               +==============+========+===================+
+               | 11           | 4      | IPv4 TE Router ID |
+               +--------------+--------+-------------------+
+               | 12           | 16     | IPv6 TE Router ID |
+               +--------------+--------+-------------------+
+
+                                  Table 2
+
+   Detailed definitions of these sub-TLVs are described in Sections
+   3.4.1 and 3.4.2.
+
+3.4.  Sub-TLVs for Inter-AS Reachability Information TLV
+
+3.4.1.  Remote AS Number Sub-TLV
+
+   The Remote AS Number sub-TLV is defined for inclusion in the Inter-AS
+   Reachability Information 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.
+
+   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, 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.4.2.  IPv4 Remote ASBR Identifier Sub-TLV
+
+   The IPv4 Remote ASBR Identifier sub-TLV is defined for inclusion in
+   the Inter-AS Reachability Information TLV when advertising inter-AS
+   links.  The IPv4 Remote ASBR Identifier sub-TLV specifies the IPv4
+   identifier of the remote ASBR to which the advertised inter-AS link
+   connects.  The value advertised is selected as defined in
+   Section 3.1.
+
+   The IPv4 Remote ASBR Identifier sub-TLV is TLV type 25 (see
+   Section 6.2) and is 4 octets in length.  The format of the IPv4
+   Remote ASBR Identifier 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 Identifier                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The IPv4 Remote ASBR Identifier sub-TLV MUST be included if the
+   neighboring ASBR has an IPv4 address.  If the neighboring ASBR does
+   not have an IPv4 address, the IPv6 Remote ASBR Identifier sub-TLV
+   MUST be included instead.  An IPv4 Remote ASBR Identifier sub-TLV and
+   IPv6 Remote ASBR Identifier sub-TLV MAY both be present in an
+   extended IS reachability TLV.
+
+3.4.3.  IPv6 Remote ASBR Identifier Sub-TLV
+
+   The IPv6 Remote ASBR Identifier sub-TLV is defined for inclusion in
+   the Inter-AS Reachability Information TLV when advertising inter-AS
+   links.  The IPv6 Remote ASBR Identifier sub-TLV specifies the IPv6
+   identifier of the remote ASBR to which the advertised inter-AS link
+   connects.  The value advertised is selected as defined in
+   Section 3.1.
+
+   The IPv6 Remote ASBR Identifier sub-TLV is TLV type 26 (see
+   Section 6.2) and is 16 octets in length.  The format of the IPv6
+   Remote ASBR Identifier 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 Identifier                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Remote ASBR Identifier (continued)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Remote ASBR Identifier (continued)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Remote ASBR Identifier (continued)         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The IPv6 Remote ASBR Identifier 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 Identifier sub-TLV
+   MUST be included instead.  An IPv4 Remote ASBR Identifier sub-TLV and
+   IPv6 Remote ASBR Identifier sub-TLV MAY both be present in an
+   extended IS reachability TLV.
+
+3.4.4.  IPv6 Local ASBR Identifier Sub-TLV
+
+   The IPv6 Local ASBR Identifier sub-TLV is defined for inclusion in
+   the Inter-AS Reachability Information TLV when advertising inter-AS
+   links.  The IPv6 Local ASBR Identifier sub-TLV specifies the IPv6
+   identifier of the remote ASBR to which the advertised inter-AS link
+   connects.  The value advertised is selected as defined in
+   Section 3.1.
+
+   The IPv6 Local ASBR Identifier sub-TLV is TLV type 45 (see
+   Section 6.2) and is 16 octets in length.  The format of the IPv6
+   Local ASBR Identifier 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            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Local ASBR Identifier                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Local ASBR Identifier (continued)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Local ASBR Identifier (continued)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    Local ASBR Identifier (continued)          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   If the originating node does not support IPv4, the IPv6 Local ASBR
+   Identifier sub-TLV MUST be present in the Inter-AS Reachability
+   Information TLV.  Inter-AS Reachability Information TLVs that have a
+   Router ID of 0.0.0.0 and do not have the IPv6 Local ASBR Identifier
+   sub-TLV present MUST be ignored.
+
+3.5.  Sub-TLVs for IS-IS Router CAPABILITY TLV
+
+3.5.1.  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                            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The value advertised is selected as defined in Section 3.1.
+
+   When the TE Router ID is needed to reach all routers within an entire
+   IS-IS 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 ID 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.5.2.  IPv6 TE Router ID Sub-TLV
+
+   The IPv6 TE Router ID sub-TLV is TLV type 12 (see Section 6.3) and is
+   16 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)              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The value advertised is selected as defined in Section 3.1.
+
+   When the TE Router ID is needed to reach all routers within an entire
+   IS-IS 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 ID 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 [RFC5305].
+   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.
+
+   Hellos MUST NOT be exchanged over the inter-AS link, and
+   consequently, an IS-IS 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 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 IS-IS TE, the LSRs at each end of a TE
+   link emit LSPs 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 LSPs 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 LSP 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 LSP 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 Identifier 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.
+
+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 the information described in Section 4 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 IS-IS security mechanisms (e.g., using the cleartext
+   passwords or Hashed Message Authentication Codes, which are defined
+   in [RFC1195], [RFC5304], and [RFC5310] separately).
+
+   There is no exchange of information between ASes and no change to the
+   IS-IS security relationship between the ASes.  In particular, since
+   no IS-IS adjacency is formed on the inter-AS links, there is no
+   requirement for IS-IS security between the ASes.
+
+   Some of the information included in these advertisements (e.g., the
+   Remote AS Number and the Remote ASBR Identifier) 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 provide incorrect information, or some manual misconfigurations
+   or mistakes may be made by the operators).  For example, if a
+   different Remote AS Number is received in a BGP OPEN [RFC4271] from
+   that locally configured to IS-IS TE, as we describe here, then local
+   policy SHOULD be applied to determine whether to alert the operator
+   to a potential misconfiguration or to suppress the IS-IS
+   advertisement of the inter-AS TE link.  Advertisement of incorrect
+   information could result in an inter-AS TE LSP that traverses an
+   unintended AS.  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 such as described in [RFC5925] to
+   provide authentication and integrity checks.
+
+   For a discussion of general security considerations for IS-IS, see
+   [RFC5304].
+
+6.  IANA Considerations
+
+6.1.  Inter-AS Reachability Information TLV
+
+   IANA has registered the following IS-IS TLV type, described in
+   Section 3.1, in the "IS-IS Top-Level TLV Codepoints" registry:
+
+      +=======+==============+=====+=====+=====+=======+===========+
+      | Value | Name         | IIH | LSP | SNP | Purge | Reference |
+      +=======+==============+=====+=====+=====+=======+===========+
+      | 141   | Inter-AS     | n   | y   | n   | n     | RFC 9346  |
+      |       | Reachability |     |     |     |       |           |
+      |       | Information  |     |     |     |       |           |
+      +-------+--------------+-----+-----+-----+-------+-----------+
+
+                                 Table 3
+
+6.2.  Sub-TLVs for the Inter-AS Reachability Information TLV
+
+   IANA has registered the following sub-TLV types of top-level TLV 141
+   (see Section 6.1) in the "IS-IS Sub-TLVs for TLVs Advertising
+   Neighbor Information" registry.  These sub-TLVs are described in
+   Sections 3.4.1, 3.4.2, 3.4.3, and 3.4.4.
+
+   +=======+=============+====+====+====+=====+=====+=====+===========+
+   | Value | Description | 22 | 23 | 25 | 141 | 222 | 223 | Reference |
+   +=======+=============+====+====+====+=====+=====+=====+===========+
+   | 24    | Remote AS   | n  | n  | n  | y   | n   | n   | RFC 9346  |
+   |       | Number      |    |    |    |     |     |     |           |
+   +-------+-------------+----+----+----+-----+-----+-----+-----------+
+   | 25    | IPv4 Remote | n  | n  | n  | y   | n   | n   | RFC 9346  |
+   |       | ASBR        |    |    |    |     |     |     |           |
+   |       | Identifier  |    |    |    |     |     |     |           |
+   +-------+-------------+----+----+----+-----+-----+-----+-----------+
+   | 26    | IPv6 Remote | n  | n  | n  | y   | n   | n   | RFC 9346  |
+   |       | ASBR        |    |    |    |     |     |     |           |
+   |       | Identifier  |    |    |    |     |     |     |           |
+   +-------+-------------+----+----+----+-----+-----+-----+-----------+
+   | 45    | IPv6 Local  | n  | n  | n  | y   | n   | n   | RFC 9346  |
+   |       | ASBR        |    |    |    |     |     |     |           |
+   |       | Identifier  |    |    |    |     |     |     |           |
+   +-------+-------------+----+----+----+-----+-----+-----+-----------+
+
+                                 Table 4
+
+   As described in Section 3.1, the sub-TLVs that are defined in
+   [RFC5305], [RFC6119], 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 Information TLV
+   when adverting inter-AS TE links.
+
+6.3.  Sub-TLVs for the IS-IS Router CAPABILITY TLV
+
+   IANA has registered the following sub-TLV types of top-level TLV 242
+   (see [RFC7981]) in the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY
+   TLV" registry.  These sub-TLVs are described in Sections 3.4.1 and
+   3.4.2.
+
+                 +======+===================+===========+
+                 | Type | Description       | Reference |
+                 +======+===================+===========+
+                 | 11   | IPv4 TE Router ID | RFC 9346  |
+                 +------+-------------------+-----------+
+                 | 12   | IPv6 TE Router ID | RFC 9346  |
+                 +------+-------------------+-----------+
+
+                                 Table 5
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
+              dual environments", RFC 1195, DOI 10.17487/RFC1195,
+              December 1990, <https://www.rfc-editor.org/info/rfc1195>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+              DOI 10.17487/RFC4271, January 2006,
+              <https://www.rfc-editor.org/info/rfc4271>.
+
+   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
+              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
+              2008, <https://www.rfc-editor.org/info/rfc5305>.
+
+   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
+              DOI 10.17487/RFC5308, October 2008,
+              <https://www.rfc-editor.org/info/rfc5308>.
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
+              June 2010, <https://www.rfc-editor.org/info/rfc5925>.
+
+   [RFC6119]  Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
+              Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
+              February 2011, <https://www.rfc-editor.org/info/rfc6119>.
+
+   [RFC7981]  Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
+              for Advertising Router Information", RFC 7981,
+              DOI 10.17487/RFC7981, October 2016,
+              <https://www.rfc-editor.org/info/rfc7981>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+7.2.  Informative References
+
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <https://www.rfc-editor.org/info/rfc3209>.
+
+   [RFC4216]  Zhang, R., Ed. and J.-P. Vasseur, Ed., "MPLS Inter-
+              Autonomous System (AS) Traffic Engineering (TE)
+              Requirements", RFC 4216, DOI 10.17487/RFC4216, November
+              2005, <https://www.rfc-editor.org/info/rfc4216>.
+
+   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+              Computation Element (PCE)-Based Architecture", RFC 4655,
+              DOI 10.17487/RFC4655, August 2006,
+              <https://www.rfc-editor.org/info/rfc4655>.
+
+   [RFC5152]  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, DOI 10.17487/RFC5152, February 2008,
+              <https://www.rfc-editor.org/info/rfc5152>.
+
+   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
+              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
+              2008, <https://www.rfc-editor.org/info/rfc5304>.
+
+   [RFC5307]  Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
+              in Support of Generalized Multi-Protocol Label Switching
+              (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
+              <https://www.rfc-editor.org/info/rfc5307>.
+
+   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
+              and M. Fanto, "IS-IS Generic Cryptographic
+              Authentication", RFC 5310, DOI 10.17487/RFC5310, February
+              2009, <https://www.rfc-editor.org/info/rfc5310>.
+
+   [RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
+              Support of Inter-Autonomous System (AS) MPLS and GMPLS
+              Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
+              December 2008, <https://www.rfc-editor.org/info/rfc5316>.
+
+   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
+              "A Backward-Recursive PCE-Based Computation (BRPC)
+              Procedure to Compute Shortest Constrained Inter-Domain
+              Traffic Engineering Label Switched Paths", RFC 5441,
+              DOI 10.17487/RFC5441, April 2009,
+              <https://www.rfc-editor.org/info/rfc5441>.
+
+   [RFC6823]  Ginsberg, L., Previdi, S., and M. Shand, "Advertising
+              Generic Information in IS-IS", RFC 6823,
+              DOI 10.17487/RFC6823, December 2012,
+              <https://www.rfc-editor.org/info/rfc6823>.
+
+Appendix A.  Changes to RFC 5316
+
+   The following is a summary of the substantive changes this document
+   makes to RFC 5316.  Some editorial changes were also made.
+
+   RFC 5316 only allowed a 32-bit Router ID in the fixed header of TLV
+   141.  This is problematic in an IPv6-only deployment where an IPv4
+   address may not be available.  This document specifies:
+
+   1.  The Router ID should be identical to the value advertised in the
+       Traffic Engineering router ID TLV (134) if available.
+
+   2.  If no Traffic Engineering Router ID is assigned, the Router ID
+       should be identical to an IP Interface Address [RFC1195]
+       advertised by the originating IS.
+
+   3.  If the originating node does not support IPv4, then the reserved
+       value 0.0.0.0 must be used in the Router ID field and the IPv6
+       Local ASBR Identifier sub-TLV must be present in the TLV.
+
+Acknowledgements
+
+   In the previous version of this document [RFC5316], the authors
+   thanked Adrian Farrel, Jean-Louis Le Roux, Christian Hopps, and
+   Hannes Gredler for their review and comments.
+
+Authors' Addresses
+
+   Mach(Guoyi) Chen
+   Huawei
+   Email: mach.chen@huawei.com
+
+
+   Les Ginsberg
+   Cisco Systems
+   Email: ginsberg@cisco.com
+
+
+   Stefano Previdi
+   Huawei Technologies
+   Italy
+   Email: stefano@previdi.net
+
+
+   Xiaodong Duan
+   China Mobile
+   Email: duanxiaodong@chinamobile.com