RFC 9346

IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering

📅 published February 2023, from ietf

Part 1 of 5 🌸

RFC 9346 🎀 IS-IS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering

Okay bestie, this is RFC 9346 💅 It's an IETF (Internet Engineering Task Force) 🦋 doc on the Standards Track, which means it went through public review and the IESG approved it. It's dated February 2023 and the ISSN is 2070-1721.

The authors are M. Chen of Huawei, L. Ginsberg of Cisco Systems, S. Previdi of Huawei Technologies, and X. Duan of China Mobile. The whole squad 🫶

This one obsoletes RFC 5316, so 5316 is retired and this is the new version. The header doesn't list anything it updates.

Abstract ✨

So this doc describes IS-IS protocol extensions that support MPLS and GMPLS Traffic Engineering (TE) across multiple Autonomous Systems (ASes) 🌈 It adds flooding of TE info about inter-AS links, which can be used to do inter-AS TE path computation.

It doesn't propose or define any support for flooding info from inside one AS over into another AS. Not happening here 🙅‍♀️

It builds on RFC 5316 and adds support for IPv6-only operation 💖

Status of This Memo 📜

This is an Internet Standards Track document. It's a product of the IETF, it represents the consensus of the IETF community, it got public review, and the IESG approved it for publication. For more on Internet Standards, check Section 2 of RFC 7841.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9346 🔥

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this doc have to include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Revised BSD License describes 🧚

Table of Contents 🍓

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 🦋

Okay so [RFC5305] is the one that adds IS-IS protocol extensions (from [RFC1195]) for intra-area Traffic Engineering (TE) 💅 It gives you a way to encode TE info for TE-enabled links inside your network (those are the TE links) and flood that info within an area. The extended IS reachability TLV and the Traffic Engineering router ID TLV, both defined in [RFC5305], carry all of that TE info. The extended IS reachability TLV also has a bunch of nested sub-TLVs that describe the TE attributes of a TE link ✨

[RFC6119] and [RFC5307] do similar stuff for IPv6 and GMPLS TE, respectively 🌸

Now, the requirements for setting up MPLS TE Label Switched Paths (LSPs) that cross multiple ASes are in [RFC4216]. As [RFC4216] explains, a method SHOULD provide the ability to compute a path spanning multiple ASes. So the path computation entity (it could 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 info not just for links inside its own AS, but also for the links that connect to other ASes 🧚

Here's the plan for this doc. The Inter-AS Reachability Information TLV is defined to advertise inter-AS TE info. Four sub-TLVs go inside it to carry the Remote AS Number, the Remote ASBR Identifier, and the IPv6 Local ASBR Identifier. The sub-TLVs already defined in [RFC5305], [RFC6119], and other docs for the extended IS reachability TLV, which describe the TE properties of a TE link, can also go inside the Inter-AS Reachability Information TLV to describe the TE properties of an inter-AS TE link 💖 Then two more sub-TLVs go inside the IS-IS Router CAPABILITY TLV to carry the TE Router ID, for when the TE Router ID needs to reach every router across the whole IS-IS routing domain. These extensions work equally well for IPv4 and IPv6, since they're identical to the extensions in [RFC5305] and [RFC6119]. The detailed definitions and procedures come in the sections after this 🎀

This doc doesn't propose or define any mechanisms for advertising any other extra-AS TE info within IS-IS. For the full list of non-objectives, see Section 2.1 🙈

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 [RFC4216] describes, when you're setting up an inter-AS TE LSP that goes through multiple ASes, the Path message [RFC3209] may include the following elements in the Explicit Route Object (ERO) to describe the LSP's path:

  • a set of AS numbers as loose hops and/or
  • a set of LSRs, including ASBRs, as loose hops.

There are two methods for figuring out inter-AS paths, and they're described elsewhere 👑 The per-domain method [RFC5152] figures out the path one domain at a time. The backward-recursive method [RFC5441] uses PCEs cooperating with each other to find an optimum inter-domain path. The next sections look at how inter-AS TE link info could help in both cases 💅

2.1. A Note on Non-objectives 🚫

It's important to know that this doc doesn't change the confidentiality or scaling assumptions around using ASes on the Internet. In particular, this doc conforms to the requirements in [RFC4216] 🌈

These features are explicitly excluded:

  • There is no attempt to distribute TE info from within one AS to another AS.
  • There is no mechanism proposed to distribute any form of TE reachability info 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 info between ASes.
  • No IS-IS adjacencies are formed on the inter-AS link.

2.2. Per-Domain Path Determination 🗺️

Here's the deal with the per-domain method for finding an inter-AS path for an MPLS-TE LSP. When an LSR that's an entry point to an AS gets a Path message from an upstream AS, and the ERO has a next hop that's an AS number, it has to figure out which LSRs (ASBRs) inside 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, forward the Path message to that LSR, and from there it gets into the next AS. Check out 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 from R1 to R12, the AS sequence goes AS1, AS2, AS3 🎀

Say the Path message enters AS2 from R3. The next hop in the ERO shows AS3, so R5 has to work out a path segment across AS2 to reach AS3. It has three exit points from AS2 to pick from (R6, R7, and R8), and it needs to know which of those give TE connectivity to AS3, and whether that TE connectivity (for example, available bandwidth) is good enough for the requested LSP 😭

Or, if the next hop in the ERO is an entry ASBR for AS3 (say R9), then R5 needs to know which of its exit ASBRs has a TE link that connects to R9. Since more than one ASBR can connect to R9 (both R7 and R8 in this example), R5 also needs to know the TE properties of the inter-AS TE links so it can pick the right exit ASBR 💅

Once the Path message gets to the exit ASBR, the ASBR can make any choice of inter-AS TE link, as long as the entry ASBR that computed the segment didn't already make that choice 🔥

If you want more details, Section 4 of [RFC5152] clearly explains why advertising inter-AS links is wanted 🧠

So for R5 to pick the correct exit ASBR, it needs this info:

  • 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, more info might be needed to select the correct TE links, as defined in [RFC5307] 🌈

The example above shows that this info is needed at the entry-point ASBRs for each AS (or at the PCEs that provide computation services for those ASBRs). But this info is also needed throughout the local AS if path computation is fully distributed among the LSRs in that AS, for example to support LSPs whose start points (ingress nodes) are inside the AS 👑

2.3. Backward-Recursive Path Computation 🔗

Okay, so this one has the same problem, but with PCE vibes 💅 [RFC5441] defines a PCE-based TE LSP computation method called "Backward-Recursive Path Computation (BRPC)" 🦋 It's used to compute optimal inter-domain constrained MPLS-TE or GMPLS LSPs ✨ In this method, the set of traversed domains (ASes) is picked before the computation even starts 🌸 Then each downstream PCE in domain(i) sends back to its upstream neighbor PCE in domain(i-1) a multipoint-to-point tree of potential paths 🌳 Each tree is basically all the paths from every boundary node in domain(i) to the destination, and every path has to satisfy the required constraints for the TE LSP (bandwidth, affinities, etc.) 💜

So a PCE has to pick the boundary nodes (aka ASBRs) that give connectivity from the upstream AS 🎀 For the tree of paths from one PCE to its neighbor to actually line up, the identities of the ASBRs on each path need to be referenced 🙈 That means the PCE has to know the identities of the ASBRs in the remote AS that are reached by any inter-AS TE link. And to only hand over suitable paths in the tree, it also has to know the TE properties of those inter-AS TE links 🔥 Here's the example figure:

                   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

So the figure has 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 work together to do inter-AS path computation, and each one handles path segment computation within its own domain(s) 🧚

Now say you want an inter-AS TE LSP from R1 to R12 🌈 The traversed domains get picked as AS1->AS2->AS3, so the PCE chain is PCE1->PCE2->PCE3. First, the path computation request from the Path Computation Client (PCC), which is R1, gets relayed by PCE1 and PCE2 down the chain to PCE3 💖 Then PCE3 starts computing path segments from the entry boundary nodes that connect AS2 to the destination (R12). But to make good path segments, PCE3 has to figure out which entry boundary nodes connect to its upstream neighbor AS (identified by its AS number), and it has to know the TE properties of the inter-AS TE links ✨ PCE2 does the same thing: it figures out the entry boundary nodes based on its upstream neighbor AS and the inter-AS TE link capabilities 🫶

So, to support BRPC, the same information listed in Section 2.2 is required 📝 The AS number of the neighboring AS on the other side of each inter-AS TE link is especially important 🍓

3. Extensions to IS-IS TE 🎀

Note that this document does not define mechanisms for distributing 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 advertising inter-AS TE links 🦋 Four sub-TLVs are also defined to go inside the Inter-AS Reachability Information TLV, carrying the neighboring AS number, the Remote ASBR Identifier, and the IPv6 Local ASBR Identifier of an inter-AS link 💅 The sub-TLVs defined in [RFC5305], [RFC6119], and other documents for the extended IS reachability TLV can also go inside the Inter-AS Reachability Information TLV when advertising inter-AS TE links 🌸

This document also defines two sub-TLVs for the IS-IS Router CAPABILITY TLV, which carry the TE Router ID when it needs to reach all routers within an entire IS-IS routing domain 👑

Some of the TE information for an inter-AS TE link might already be available within the AS from other protocols. But to avoid depending on where those protocols get processed, this mechanism carries all the information needed for the required TE operations 🧚

3.1. Choosing the TE Router ID Value 🔍

Subsequent sections specify advertising a TE Router ID value for IPv4 and/or IPv6. This section defines how that value gets chosen 💖

A TE Router ID MUST be an address that is unique within the IS-IS domain and stable, meaning it can always be referenced in a path that will be reachable from multiple hops away, no matter what state the node's interfaces are in 🔥

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, as long as the address meets the requirements 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], as long as the address meets the requirements above 🫶

3.2. Inter-AS Reachability Information TLV 🌟

The Inter-AS Reachability Information TLV has type 141 (see Section 6.1) and holds a data structure made up of the following 🍓

    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 has the following layout 🦋

       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 there to prevent TLV looping 🔁
  • Reserved (Rsvd): Reserved bits MUST be zero when originated and ignored when received. 🤍

Compared to the extended IS reachability TLV defined in [RFC5305], the Inter-AS Reachability Information TLV swaps the "7 octets of System ID and Pseudonode Number" field for a "4 octets of Router ID" field, and adds an extra "control information" field. That field has 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 long and has the value 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 were previously discussed in [RFC7981] 🔥 The flooding-scope bit (S bit) SHOULD be set to 0 if the flooding scope is meant to be limited to the single IGP area that the ASBR belongs to. It MAY be set to 1 if the information is meant to reach all routers (including area border routers, ASBRs, and PCEs) in the entire IS-IS routing domain. Choosing between 0 or 1 is an AS-wide policy decision, and configuration control SHOULD be provided in ASBR implementations that support advertising inter-AS TE links ⭐

The sub-TLVs defined in [RFC5305], [RFC6119], and other documents for describing the TE properties of a TE link also apply to the Inter-AS Reachability Information TLV for describing the TE properties of an inter-AS TE link. Apart from those, four sub-TLVs are defined for inclusion in the Inter-AS Reachability Information TLV 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 in Sections 3.4.1, 3.4.2, 3.4.3, and 3.4.4 🧚

3.3. TE Router ID 🎀

Okay so the Traffic Engineering router ID TLV and the IPv6 TE Router ID TLV, defined in [RFC5305] and [RFC6119] respectively, only have area flooding scope 🌸. When you're doing 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 💅. It lets a router 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 you're doing inter-area TE 🦋.

This document uses that 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

The detailed definitions of these sub-TLVs are in Sections 3.4.1 and 3.4.2. Wait, I mean 3.5.1 and 3.5.2 🙈 (the original says Sections 3.4.1 and 3.4.2, so that's what I'm keeping: 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 you're advertising inter-AS links 🔥. It specifies the AS number of the neighboring AS that the advertised link connects to.

The Remote AS Number sub-TLV is TLV type 24 (see Section 6.2) and is 4 octets long. Here's the format 👑:

    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 you're advertising inter-AS links ✨. It specifies the IPv4 identifier of the remote ASBR that the advertised inter-AS link connects to. 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 long. Its 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 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 you're advertising inter-AS links 🔥. It specifies the IPv6 identifier of the remote ASBR that the advertised inter-AS link connects to. 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 long. 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 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 you're advertising inter-AS links 🌈. It specifies the IPv6 identifier of the remote ASBR that the advertised inter-AS link connects to. 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 long. Here's the format 🎀:

    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 long. 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 long. 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 🌸.

okay so bestie, when TE is turned on for an inter-AS link AND the link is up, the ASBR SHOULD advertise it using the normal [RFC5305] stuff 🔗. If the link goes down or TE gets switched off on it, the ASBR SHOULD withdraw that advertisement 🫥. And when the TE params change (like the available bandwidth shifting), the ASBR SHOULD re-advertise, but it MUST take precautions against excessive re-advertisements 🙃 nobody wants a flood of spam LSPs, periodt 💅

Hellos MUST NOT be exchanged over the inter-AS link, so an IS-IS adjacency MUST NOT be formed 🚫🤝 no peeking across the border!

The info that gets advertised comes from three places: the ASBR's knowledge of the link's TE capabilities, the ASBR's knowledge of the link's current status and usage, and the configuration at the ASBR of the Remote AS Number and the remote ASBR TE Router ID 🧠✨

Legacy routers that see an advertisement for an inter-AS TE link can just ignore it, because they don't know the TLV and sub-TLVs defined in Section 3 of this document 🙈 they'll keep flooding the LSP, but they won't try to use the info. Totally chill.

Now here's the tea ☕. In regular IS-IS TE, the LSRs at each end of a TE link each emit LSPs describing the link. So the databases end up with two entries (one local, one from the peer) that describe the two "directions" of the link 🔁. This is what lets Constrained Shortest Path First (CSPF) do a two-way check, so the link gets kicked out of consideration unless both directions meet the required constraints 🙅‍♀️

In our case (a TE link to another AS), there's by definition no IGP peering, so there's no bidirectional TE link info at all 😭 For CSPF to even consider the link as a candidate path, we need some way to get LSPs describing its bidirectional TE properties into the TE database. Iconic problem, honestly 👑

The solution: the ASBR advertises, inside its own AS, info about BOTH directions of the TE link to the next AS 🪞. Normally the ASBR only generates an LSP for its own side. Here it acts as a proxy for the ASBR at the edge of the other AS and generates an extra LSP that describes that device's "view" of the link 🧚

Only some essential TE info needs to be advertised for an inter-AS TE link: the Interface Address, the Remote AS Number, and the Remote ASBR Identifier 🎀 that's it, keep it lean!

Routers or PCEs that can process advertisements of inter-AS TE links SHOULD NOT use those links to compute paths that exit an AS to a remote ASBR and then immediately re-enter the AS through another TE link 🙅‍♀️ Those paths would be super rare, and they SHOULD NOT be allowed except as the result of specific policy configurations at the router or PCE doing the computing ⚠️

4.1. Origin of Proxied TE Information

Section 4 explains how an ASBR advertises TE link info as a proxy for its neighbor ASBR, but it doesn't say where that info comes from 🤷‍♀️ That's outside the scope of this document.

Still, it's possible (and likely) that it'll be a configuration requirement at the ASBR, just like other local properties of the TE link ⚙️ And if BGP is used to swap IP routing info between the ASBRs, there's probably a decent amount of extra local config about the link and the remote ASBR available too 💜

We also note that it's possible, and might be operationally handy, to grab some of the needed config info from BGP 🌈 Whether and how to do that is an implementation matter, so it's up to the implementers 💅

5. Security Considerations 🔐

Okay, security time, and I'm not gonna sugarcoat it 😤 The protocol extensions in this document are relatively minor, and they can be secured within the AS where they're used by the existing IS-IS security mechanisms. Think cleartext passwords or Hashed Message Authentication Codes, which are defined separately in [RFC1195], [RFC5304], and [RFC5310] 🛡️

There's no exchange of info between ASes, and no change to the IS-IS security relationship between them 🙌 Since no IS-IS adjacency forms on inter-AS links, there's no requirement for IS-IS security between the ASes. No IS-IS, no problem 💖

Some of the info in these advertisements (like the Remote AS Number and the Remote ASBR Identifier) is gathered manually from a neighboring administration as part of a commercial relationship 🤝 The source and content of that info SHOULD be carefully checked before it's entered as config at the ASBR responsible for advertising the inter-AS TE links. Double-check, bestie, seriously 🧐

Here's a fun twist: in this scenario, a Border Gateway Protocol (BGP) peering may exist between the two ASBRs 🌉 That could be used to catch config inconsistencies. For example, the other administration might have given incorrect info, or operators might make manual misconfigurations or mistakes 😬 So, if a Remote AS Number arrives in a BGP OPEN [RFC4271] that's different from the one configured for IS-IS TE, local policy SHOULD be applied to decide whether to alert the operator about a potential misconfiguration or to suppress the IS-IS advertisement of the inter-AS TE link 🚨 Advertising incorrect info could lead to an inter-AS TE LSP that goes through an unintended AS. Yikes 💀

Also, if BGP is used to exchange TE info as described in Section 4.1, the inter-AS BGP session SHOULD be secured with mechanisms like the ones described in [RFC5925], which 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 defined in [RFC5305], [RFC6119], and other documents for describing the TE properties of a TE link are applicable to describing an inter-AS TE link 🌸 They MAY be included in the Inter-AS Reachability Information TLV when advertising inter-AS TE links, so you can level up your info if you want 💅

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

7.2. Informative References 📚✨

okay so this is the bibliography bit, aka the "where'd she get all this from" list 💅 every one of these is a real citation, so I kept every detail: numbers, titles, authors, DOIs, and links.

[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 🦋

okay this appendix is the glow-up diary 💖 it's a summary of the big changes this doc makes to [RFC5316]. there were some editorial tweaks too, but the important stuff is below.

so the problem is that [RFC5316] only let you squeeze a 32-bit Router ID into the fixed header of TLV 141. ngl that's a total vibe killer in an IPv6-only setup, where you might not have an IPv4 address at all 😭 so this doc fixes it with three rules:

  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. 🧚

main character energy, honestly 🌈👑

Acknowledgements 🫶

bestie, the authors gave a huge shoutout to the people who helped with the previous version, [RFC5316]. they thanked Adrian Farrel, Jean-Louis Le Roux, Christian Hopps, and Hannes Gredler for reviewing it and dropping their comments 💜 the real MVPs!!

Authors' Addresses 💌

these are the people who wrote the doc, so here are their contact details, exactly as they're listed:

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

and that's a wrap on RFC 9346, slay 💅✨ 🦋

📦 where this page comes from