RFC 9666
Area Proxy for IS-IS
Area Proxy for IS-IS 🦋
okay bestie, this is RFC 9666!! 💖 It's an Experimental doc, so it's a "try it out and see how it goes" kind of spec, not a full Internet Standard yet. 🧪 Here's the title block, served fresh 🍓:
Internet Engineering Task Force (IETF) ✨ The IETF is the group that writes this stuff.
Request for Comments: 9666 👑 That's the number, and it's the one you cite.
Category: Experimental 🧪 Experimental, as above, so it's not on the Standards Track.
ISSN: 2070-1721 🌈 That's the series identifier for the RFC series.
Authors: T. Li (Juniper Networks), S. Chen, V. Ilangovan (Arista Networks), G. Mishra (Verizon Inc.) 💅 Four authors, a whole squad!!
Date: October 2024</yell>ow 🎀 Published in October 2024.
This doc doesn't obsolete or update any earlier RFCs, so it's a fresh start. 🌸
Abstract ✨
Okay so link-state routing protocols already come with hierarchy built in, which is so iconic 👑. The thing is, when the lower levels are used for transit, they have to expose their internal topologies to each other, and that's where the scaling issues come in 😭.
So this doc talks about extensions to IS-IS that let Level 1 (L1) areas provide transit while only injecting an abstraction of the L1 topology into Level 2 (L2). Each L1 area shows up as a single L2 node, which means way better scale. 💖
Status of This Memo 📜
Not an Internet Standards Track spec, babe. 🙈 It's published for examination, experimental implementation, and evaluation.
This doc defines an Experimental Protocol for the Internet community. It's a product of the IETF and it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the deets 🦋.
You can find the current status, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc9666. ✨
Copyright Notice 💅
Copyright (c) 2024 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 stood on the publication date. Please actually read these, because they lay out your rights and restrictions 🙈. Code Components pulled out of this doc must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License. 📜
Table of Contents 🗺️
1. Introduction
1.1. Requirements Language
2. Area Proxy
2.1. Segment Routing
3. Inside Router Functions
3.1. The Area Proxy TLV
3.2. Level 2 SPF Computation
3.3. Responsibilities Concerning the Proxy LSP
4. Area Leader Functions
4.1. Area Leader Election
4.2. Redundancy
4.3. Distributing Area Proxy Information
4.3.1. The Area Proxy System Identifier Sub-TLV
4.3.2. The Area SID Sub-TLV
4.4. Proxy LSP Generation
4.4.1. The Protocols Supported TLV
4.4.2. The Area Address TLV
4.4.3. The Dynamic Hostname TLV
4.4.4. The IS Neighbors TLV
4.4.5. The Extended IS Neighbors TLV
4.4.6. The MT Intermediate Systems TLV
4.4.7. Reachability TLVs
4.4.8. The Router Capability TLV
4.4.9. The Multi-Topology TLV
4.4.10. The SID/Label Binding and the Multi-Topology SID/Label
Binding TLV
4.4.11. The SRv6 Locator TLV
4.4.12. Traffic Engineering Information
4.4.13. The Area SID
5. Inside Edge Router Functions
5.1. Generating L2 IIHs to Outside Routers
5.2. Filtering LSP Information
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction 🌸
The IS-IS routing protocol [ISO10589] supports a two-level hierarchy of abstraction 💅. The fundamental unit is the "area", which is a (hopefully) connected set of systems running IS-IS at the same level. Level 1, the lowest level, gets abstracted by routers that take part in both Level 1 and Level 2, and they inject area information into Level 2. Level 2 systems that want to reach Level 1 use that abstraction to compute the shortest path to the Level 1 area 🦋. The full topology database of Level 1 does not get injected into Level 2. Instead, only a summary of the address space inside the area gets injected, so the scalability of the Level 2 Link State Database (LSDB) stays protected 🫶.
This works well if the Level 1 area is tangential to the Level 2 area. It also works well if there are several routers in both Levels 1 and 2 that are adjacent to one another, so Level 2 traffic never has to transit Level 1-only routers 🙌. Level 1 won't contain any Level 2 topology, and Level 2 only holds area abstractions for Level 1. ✨
Unfortunately, this scheme doesn't work so well if the Level 1-only area needs to provide transit for Level 2 traffic 😭. For Level 2 Shortest Path First (SPF) computations to work correctly, the transit topology also has to appear in the Level 2 LSDB. That means every router that could provide transit, plus any links that might also provide Level 2 transit, has to become part of the Level 2 topology too. If that's a relatively tiny portion of the Level 1 area, it's not overly painful 🍓.
But with today's data center topologies, this is a problem 💀. A common application is a Layer 3 Leaf-Spine (L3LS) topology, which is a folded 3-stage Clos fabric [Clos]. You can also think of it as a complete bipartite graph 🧚. In that setup, the goal is to use Level 1 to contain the routing dynamics of the entire L3LS topology, and then use Level 2 for the rest of the network. Leaves in the L3LS topology are the right spot to connect outside the data center, so they'd provide connectivity for Level 2. If there are multiple connections to Level 2 for redundancy or for other areas, those would also be made to the leaves. 💅 That creates a difficulty, because now there are multiple Level 2 leaves in the topology, with connectivity between them provided by the spines.
Following the current rules of IS-IS, all spine routers would necessarily become part of the Level 2 topology, plus all links between a Level 2 leaf and the spines. In the extreme case, where all leaves need to support Level 2, the entire L3LS topology ends up in Level 2. That is seriously problematic 😭, because it more than doubles the LSDB held in the L3LS topology and wipes out any benefits of the hierarchy 💔.
This document discusses the handling of IP traffic. Supporting MPLS-based traffic is a subject for future 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. 💜
(Part 1 of 4. Keep going, more coming!) 🦋✨
2. Area Proxy ✨
Okay so in this spec we totally hide the messy internal topology of the Level 1 area from Level 2, so the whole area looks like ONE proxy system that's directly connected to all of its Level 2 neighbors 🧚 Level 2 gets its connectivity requirement met without carrying the full overhead of the area's internals, and then it's on the Level 1 area to actually provide the forwarding connectivity that got advertised. It's giving clean. 💅
For this discussion, we'll treat a single Level 1 IS-IS area as the Inside Area, and the rest of the Level 2 area as the Outside Area. All routers inside the Inside Area speak Level 1 and Level 2 IS-IS on all of the links in the topology. We're proposing Area Proxy by having a Level 2 Proxy Link State PDU (LSP) that represents the entire Inside Area, which we'll call the Proxy LSP 🦋 It's the only LSP from the area that gets flooded into the overall Level 2 LSDB, so it's the main character of the whole thing 👑
There are four classes of routers we need to care about here:
- Inside Router: A router inside the Inside Area that runs Level 1 and Level 2 IS-IS. You can tell it's an Inside Router because its LSP exists in the Level 1 LSDB 👀
- Area Leader: The Area Leader is an Inside Router that gets elected to represent the Level 1 area by injecting the Proxy LSP into the Level 2 LSDB. There can be multiple candidates, but only one is elected at a given time, and any Inside Router can be the Area Leader 🫶
- Inside Edge Router: An Inside Edge Router is an Inside Area Router that has at least one Level 2 interface outside of the Inside Area. An interface on an Inside Edge Router that's connected to an Outside Edge Router is an Area Proxy Boundary 🌸
- Outside Edge Router: An Outside Edge Router is a Level 2 router that's outside of the Inside Area and has an adjacency with an Inside Edge Router 🍓
Inside Area
+--------+ +--------+
| Inside |-----------------| Inside |
| Router | | Edge |
+--------+ +------------| Router |
| / +--------+
| / |
+--------+ / =============|======
| Area |/ || |
| Leader | || +---------+
+--------+ || | Outside |
|| | Edge |
|| | Router |
|| +---------+
Outside Area
Figure 1: An Example of Router ClassesAll Inside Edge Routers learn the Area Proxy System Identifier from the Area Proxy TLV that the Area Leader advertises, and they use it as the system identifier in their Level 2 IS-IS Hello (IIH) PDUs on all Outside interfaces. Then the Outside Edge Routers advertise an adjacency to the Area Proxy System Identifier. This lets all Outside Routers use the Proxy LSP in their SPF computations without ever seeing the full topology of the Inside Area. Main character energy, honestly 🦋
Area Proxy functionality assumes that all circuits on Inside Routers are either Level 1-2 circuits within the Inside Area, or Level 2 circuits between Outside Edge Routers and Inside Edge Routers.
Now the tricky bit 😭 Area Proxy Boundary multi-access circuits (i.e., Ethernets in LAN mode) with multiple Inside Edge Routers on them are NOT supported. The Inside Edge Router on any boundary LAN MUST NOT flood Inside Router LSPs on this link. Boundary LANs SHOULD NOT be enabled for Level 1. An Inside Edge Router may get elected as the Designated Intermediate System (DIS) for a Boundary LAN. In that case, using the Area Proxy System ID as the basis for the LAN pseudonode identifier could create a collision, so the Inside Edge Router SHOULD compose the pseudonode identifier using its originally configured system identifier. This choice of pseudonode identifier may confuse neighbors with an extremely strict implementation. In that case, the Inside Edge Router may be configured with priority 0, which causes an Outside Router to be elected as the DIS 💀
2.1. Segment Routing
If the Inside Area supports Segment Routing (SR) [RFC8402], then all Inside Nodes MUST advertise a Segment Routing Global Block (SRGB). The first value of the SRGB advertised by all Inside Nodes MUST start at the same value. If the Area Leader detects SRGBs that don't start with the same value, it MUST log an error and not advertise an SRGB in the Proxy LSP. The range advertised for the area will be the minimum of what's advertised by all Inside Nodes 🎀
To support SR, the Area Leader takes the SRGB information found in the L1 LSDB and conveys it to L2 through the Proxy LSP. Prefixes with Segment Identifier (SID) assignments get copied to the Proxy LSP, and Adjacency SIDs for Outside Edge Nodes get copied to the Proxy LSP too 🌈
To go further with SR, it's helpful to have a segment that refers to the entire Inside Area. This lets a path refer to an area and have any node within that area accept and forward the packet. Basically this becomes an anycast SID that's accepted by all Inside Edge Nodes, which is so iconic ✨ The information about this SID is distributed in the Area SID sub-TLV as part of the Area Leader's Area Proxy TLV (Section 4.3.2). The Inside Edge Nodes MUST establish forwarding based on this SID. The Area Leader SHALL also include the Area SID in the Proxy LSP so the rest of L2 can use it for path construction (Section 4.4.13). Periodt 💜
3. Inside Router Functions 🧚
All Inside Routers run Level 1-2 IS-IS and must be explicitly instructed to enable the Area Proxy functionality. To signal that they're ready to take part in Area Proxy, they advertise the Area Proxy TLV in their L2 LSP 🫶
3.1. The Area Proxy TLV
The Area Proxy TLV does a few jobs at once:
- The presence of the Area Proxy TLV in a node's LSP shows that the node is enabled for Area Proxy.
- An LSP containing the Area Proxy TLV is also an Inside Node. All Inside Nodes, including pseudonodes, MUST advertise the Area Proxy TLV.
- It's a container for sub-TLVs that carry Area Proxy information.
A node advertises the Area Proxy TLV in fragment 0 of its L2 LSP. Nodes MUST NOT advertise the Area Proxy TLV in an L1 LSP. Nodes MUST ignore the Area Proxy TLV if it's found in an L1 LSP. The Area Proxy TLV isn't used in the Proxy LSP. The format of the Area Proxy TLV is:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Type | TLV Length | Sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+TLV Type: 20
TLV Length: Length of the sub-TLVs.
3.2. Level 2 SPF Computation
When Outside Routers do a Level 2 SPF computation, they use the Proxy LSP to compute a path transiting the Inside Area. Because the topology has been abstracted away, the cost of transiting the Inside Area is zero 🌸
When Inside Routers do a Level 2 SPF computation, they MUST ignore the Proxy LSP. Since these systems see the Inside Area topology, the link metrics inside the area are visible to them. This could lead to different and possibly inconsistent SPF results, which could potentially cause forwarding loops 😱
To prevent that, Inside Routers MUST consider the metrics of links outside of the Inside Area (inter-area metrics) separately from the metrics of the Inside Area links (intra-area metrics). Intra-area metrics MUST be treated as less than any inter-area metric. So if two paths have different total inter-area metrics, the path with the lower inter-area metric is preferred no matter what intra-area metrics are involved. However, if two paths have equal inter-area metrics, then the intra-area metrics are used to compare the paths 🎯
Point-to-point links between two Inside Routers are considered Inside Area links. LAN links that have a pseudonode LSP in the Level 1 LSDB are also considered Inside Area links.
3.3. Responsibilities Concerning the Proxy LSP
The Area Leader generates a Proxy LSP that gets flooded across the Inside Area. Inside Routers MUST flood the Proxy LSP and MUST ignore its contents. The Proxy LSP uses the Area Proxy System Identifier as its Source ID 🍓
4. Area Leader Functions 👑
The Area Leader has a few big responsibilities. First, it MUST inject the Area Proxy System Identifier into the Level 2 LSDB. Second, the Area Leader MUST generate the Proxy LSP for the Inside Area 💅
4.1. Area Leader Election
The Area Leader is selected using the election mechanisms and TLVs described in "Dynamic Flooding on Dense Graphs" [RFC9667] 🦋
4.2. Redundancy
If the Area Leader fails, another candidate may become Area Leader and MUST regenerate the Proxy LSP. The failure of the Area Leader isn't visible outside the area, and it just looks like an update to the Proxy LSP 🫠
For consistency, all Area Leader candidates SHOULD be configured with the same Proxy System ID, Proxy Hostname, and any other information that may be inserted into the Proxy LSP 🎀
4.3. Distributing Area Proxy Information
The Area Leader is responsible for telling all Inside Nodes about the area. In particular, the Area Leader distributes the Proxy System ID and the Area SID. It does this using two sub-TLVs of the Area Proxy TLV 🌸
4.3.1. The Area Proxy System Identifier Sub-TLV 🌸
Okay bestie, the Area Leader MUST use the Area Proxy System Identifier sub-TLV to distribute the Area Proxy System ID 💖. It's an extra system identifier that Inside Nodes use as a sign that Area Proxy is active 🧚. Here's the layout:
0 1 2
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy System Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type:1Length: the length of a system ID (6)Proxy System Identifier: the Area Proxy System Identifier
The Area Leader MUST advertise the Area Proxy System Identifier sub-TLV when it observes that all Inside Routers are advertising the Area Proxy TLV ✨. Those advertisements mean they're each individually ready to do Area Proxy functionality 🙌. The Area Leader then advertises the Area Proxy System Identifier TLV to say that the Inside Area MUST enable Area Proxy functionality 👑.
Other candidates for Area Leader MAY also advertise the Area Proxy System Identifier when they see that all Inside Routers are advertising the Area Proxy TLV. All candidates advertising the Area Proxy System Identifier TLV SHOULD be advertising the same system identifier. Multiple proxy system identifiers in a single area is a misconfiguration, and each unique occurrence SHOULD be logged 🙈. Systems should use the Proxy System ID advertised by the Area Leader.
The Area Leader and other candidates for Area Leader MAY withdraw the Area Proxy System Identifier when one or more Inside Routers are not advertising the Area Proxy TLV. This will disable Area Proxy functionality. However, before withdrawing the Area Proxy System Identifier, an implementation SHOULD protect against unnecessary churn from transients by delaying the withdrawal 🫶. The amount of delay is implementation dependent.
4.3.2. The Area SID Sub-TLV 🎀
The Area SID sub-TLV lets the Area Leader advertise a prefix and SID that represent the entirety of the Inside Area to the Outside Area 🦋. All of the Inside Edge Nodes learn this sub-TLV, and they're the ones who should consume this SID at forwarding time 💅. The Area SID sub-TLV has the following format:
0 1 2
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 | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where:
Type:2Length: Variable (1 + SID length)Flags: 1 octet, defined as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|V|L| |
+-+-+-+-+-+-+-+-+F: Address-Family Flag. If this flag is not set, then this proxy SID is used when forwarding IPv4-encapsulated traffic. If set, then this proxy SID is used when forwarding IPv6-encapsulated traffic.V: Value Flag. If set, then the proxy SID carries a value, as defined in [RFC8667], Section 2.1.1.1.L: Local Flag. If set, then the value/index carried by the proxy SID has local significance, as defined in [RFC8667], Section 2.1.1.1.- Other bits: MUST be zero when originated and ignored when received.
SID/Index/Label: As defined in [RFC8667], Section 2.1.1.1.Prefix Length: 1 octetPrefix: 0-16 octets
4.4. Proxy LSP Generation ✨
Each Inside Router generates a Level 2 LSP, and the Level 2 LSPs for the Inside Edge Routers will include adjacencies to Outside Edge Routers 🌈. Unlike normal Level 2 operations, these LSPs are not advertised outside of the Inside Area, and they MUST be filtered by all Inside Edge Routers so they don't get flooded to Outside Routers 🙅. Only the Proxy LSP gets injected into the overall Level 2 LSDB 💜.
The Area Leader uses the Level 2 LSPs generated by the Inside Edge Routers to generate the Proxy LSP. This LSP is originated using the Area Proxy System Identifier. The Area Leader can also insert the following additional TLVs into the Proxy LSP for extra info for the Outside Area. LSPs generated by unreachable nodes MUST NOT be considered 💀.
4.4.1. The Protocols Supported TLV 🍓
The Area Leader SHOULD insert a Protocols Supported TLV (129) [RFC1195] into the Proxy LSP. The values included in the TLV SHOULD be the protocols supported by the Inside Area.
4.4.2. The Area Address TLV 🦋
The Area Leader SHOULD insert an Area Addresses TLV (1) [ISO10589] into the Proxy LSP.
4.4.3. The Dynamic Hostname TLV 🧚
It is RECOMMENDED that the Area Leader insert the Dynamic Hostname TLV (137) [RFC5301] into the Proxy LSP. The contents of the hostname may be specified by configuration. The presence of the hostname helps to simplify network debugging, which is so iconic 🎀.
4.4.4. The IS Neighbors TLV 👑
The Area Leader can insert the IS Neighbors TLV (2) [ISO10589] into the Proxy LSP for Outside Edge Routers. The Area Leader learns of the Outside Edge Routers by examining the LSPs generated by the Inside Edge Routers and copying any IS Neighbors TLVs that refer to Outside Edge Routers into the Proxy LSP. Since the Outside Edge Routers advertise an adjacency to the Area Proxy System Identifier, this results in a bidirectional adjacency 🔥.
An entry for a neighbor in both the IS Neighbors TLV and the Extended IS Neighbors TLV would be functionally redundant, so the Area Leader SHOULD NOT do this. The Area Leader MAY omit either the IS Neighbors TLV or the Extended IS Neighbors TLV, but it MUST include at least one of them 🫶.
4.4.5. The Extended IS Neighbors TLV 💖
The Area Leader can insert the Extended IS Reachability TLV (22) [RFC5305] into the Proxy LSP. The Area Leader SHOULD copy each Extended IS Reachability TLV advertised by an Inside Edge Router about an Outside Edge Router into the Proxy LSP.
If the Inside Area supports Segment Routing, and Segment Routing selects a SID where the L-Flag is not set, then the Area Lead SHOULD include an Adjacency Segment Identifier sub-TLV (31) [RFC8667] using the selected SID 🌸.
If the inside area supports SRv6, the Area Leader SHOULD copy the "SRv6 End.X SID" and "SRv6 LAN End.X SID" sub-TLVs of the Extended IS Reachability TLVs advertised by Inside Edge Routers about Outside Edge Routers ✨.
If the inside area supports Traffic Engineering (TE), the Area Leader SHOULD copy TE-related sub-TLVs ([RFC5305], Section 3) to each Extended IS Reachability TLV in the Proxy LSP 🧠.
4.4.6. The MT Intermediate Systems TLV 🌈
If the Inside Area supports Multi-Topology (MT), then the Area Leader SHOULD copy each Outside Edge Router advertisement that is advertised by an Inside Edge Router in an MT Intermediate Systems TLV into the Proxy LSP.
4.4.7. Reachability TLVs 💅
The Area Leader SHOULD insert additional TLVs describing any routing prefixes that should be advertised on behalf of the area. These prefixes may be learned from the Level 1 LSDB, the Level 2 LSDB, or redistributed from another routing protocol. This applies to all of the various types of TLVs used for prefix advertisement:
- IP Internal Reachability Information TLV (128) [RFC1195]
- IP External Reachability Information TLV (130) [RFC1195]
- Extended IP Reachability TLV (135) [RFC5305]
- IPv6 Reachability TLV (236) [RFC5308]
- Multi-Topology Reachable IPv4 Prefixes TLV (235) [RFC5120]
- Multi-Topology Reachable IPv6 Prefixes TLV (237) [RFC5120]
For TLVs in the Level 1 LSDB, for a given TLV type and prefix, the Area Leader SHOULD select the TLV with the lowest metric and copy that TLV into the Proxy LSP.
When examining the Level 2 LSDB for this function, the Area Leader SHOULD only consider TLVs advertised by Inside Routers. Further, for prefixes that represent Boundary links, the Area Leader SHOULD copy all TLVs that have unique sub-TLV contents.
If the Inside Area supports SR and the selected TLV includes a Prefix Segment Identifier sub-TLV (3) [RFC8667], then the sub-TLV SHOULD be copied as well. The P-Flag SHOULD be set in the copy of the sub-TLV to indicate that penultimate hop popping should not be performed for this prefix. The E-Flag SHOULD be reset in the copy of the sub-TLV to indicate that an explicit NULL is not required. The R-Flag SHOULD simply be copied 🎀.
4.4.8. The Router Capability TLV 👑
The Area Leader MAY insert the Router Capability TLV (242) [RFC7981] into the Proxy LSP. If SR is supported by the inside area, as indicated by the presence of an SRGB being advertised by all Inside Nodes, then the Area Leader SHOULD advertise an SR-Capabilities sub-TLV (2) [RFC8667] with an SRGB. The first value of the SRGB is the same as the first value advertised by all Inside Nodes. The range advertised for the area will be the minimum of all ranges advertised by Inside Nodes. The Area Leader SHOULD use its Router ID in the Router Capability TLV 🦋.
If SRv6 Capability sub-TLV [RFC7981] is advertised by all Inside Routers, the Area Leader should insert an SRv6 Capability sub-TLV in the Router Capability TLV. Each flag in the SRv6 Capability sub-TLV should be set if the flag is set by all Inside Routers 🧚.
If the Node Maximum SID Depth (MSD) sub-TLV [RFC8491] is advertised by all Inside Routers, the Area Leader should advertise the intersection of the advertised MSD types and the smallest supported MSD values for each type 💖.
4.4.9. The Multi-Topology TLV 🌸
If the Inside Area supports multi-topology, then the Area Leader SHOULD insert the Multi-Topology TLV (229) [RFC5120], including the topologies supported by the Inside Nodes.
If any Inside Node is advertising the O (Overload) bit for a given topology, then the Area Leader MUST advertise the O bit for that topology. If any Inside Node is advertising the A (Attach) bit for a given topology, then the Area Leader MUST advertise the A bit for that topology 🔥.
4.4.10. The SID/Label Binding and the Multi-Topology SID/Label Binding TLV ✨
If an Inside Node advertises the SID/Label Binding or Multi-Topology SID/Label Binding TLV [RFC8667], then the Area Leader MAY copy the TLV to the Proxy LSP.
4.4.11. The SRv6 Locator TLV 🌈
If the inside area supports SRv6, the Area Leader SHOULD copy all SRv6 locator TLVs [RFC9352] advertised by Inside Routers to the Proxy LSP.
4.4.12. Traffic Engineering Information 🧠
If the inside area supports TE, the Area Leader SHOULD advertise a TE Router ID TLV (134) [RFC5305] in the Proxy LSP. It SHOULD copy the Shared Risk Link Group (SRLS) TLVs (138) [RFC5307] advertised by Inside Edge Routers about links to Outside Edge Routers 💅.
If the inside area supports IPv6 TE, the Area Leader SHOULD advertise an IPv6 TE Router ID TLV (140) [RFC6119] in the Proxy LSP. It SHOULD also copy the IPv6 SRLG TLVs (139) [RFC6119] advertised by Inside Edge Routers about links to Outside Edge Routers 🌸.
4.4.13. The Area SID ✨
Okay so when SR is turned on, an Area SID 🧚 can be super useful because it steers traffic toward any of the Inside Edge Routers. The info for the Area SID gets shared with every Inside Edge Router through the Area SID sub-TLV (Section 4.3.2), and the Area Leader is the one doing the sharing 💅.
The Area Leader SHOULD advertise the Area SID info in the Proxy LSP as a Node SID as defined in [RFC8667], Section 2.1. This tells the Outside Area that packets sent to the SID will get forwarded to one of the Inside Edge Nodes, and that the Area SID gets consumed there 🦋.
Other uses of the Area SID and Area SID prefix are outside the scope of this document. Documents that define other use cases for the Area SID MUST specify whether the SID value should be the same or different from the one used to support the Area Proxy 🌈.
5. Inside Edge Router Functions 🎀
The Inside Edge Router has two extra-important jobs 👑. First, it MUST generate IIHs that appear to have come from the Area Proxy System Identifier. Second, it MUST filter the L2 LSPs, Partial Sequence Number PDUs (PSNPs), and Complete Sequence Number PDUs (CSNPs) that get advertised to Outside Routers 😭.
5.1. Generating L2 IIHs to Outside Routers
The Inside Edge Router has one or more Level 2 interfaces to the Outside Routers. You can identify these through explicit configuration, or because they aren't also Level 1 circuits 🌸. On these Level 2 interfaces, the Inside Edge Router MUST NOT send an IIH until it has learned the Area Proxy System ID from the Area Leader. Once it has learned that ID, it MUST generate its IIHs on the circuit using the Proxy System ID as the source of the IIH 🫶.
Using the Proxy System ID makes the Outside Router advertise an adjacency to the Proxy System ID, not to the Inside Edge Router, which is what keeps the proxy function working 💖. The normal system ID of the Inside Edge Router MUST NOT be used, because it will cause unnecessary adjacencies to form 🙈.
5.2. Filtering LSP Information
For the area proxy abstraction to be effective, the L2 LSPs generated by the Inside Routers MUST be restricted to the Inside Area 🍓. The Inside Routers know which system IDs are members of the Inside Area based on the advertisement of the Area Proxy TLV. To stop unwanted LSP information from escaping the Inside Area, the Inside Edge Router MUST perform filtering of LSP flooding, CSNPs, and PSNPs. Specifically:
- A Level 2 LSP with a source system identifier that is found in the Level 1 LSDB MUST NOT be flooded to an Outside Router.
- A Level 2 LSP that contains the Area Proxy TLV MUST NOT be flooded to an Outside Router.
- A Level 2 CSNP sent to an Outside Router MUST NOT contain any information about an LSP with a system identifier found in the Level 1 LSDB. If an Inside Edge Router filters a CSNP and there is no remaining content, then the CSNP MUST NOT be sent. The source address of the CSNP MUST be the Area Proxy System ID.
- A Level 2 PSNP sent to an Outside Router MUST NOT contain any information about an LSP with a system identifier found in the Level 1 LSDB. If an Inside Edge Router filters a PSNP and there is no remaining content, then the PSNP MUST NOT be sent. The source address of the PSNP MUST be the Area Proxy System ID.
6. IANA Considerations 🌷
IANA has assigned code point 20 from the "IS-IS TLV Codepoints" registry for the Area Proxy TLV. The registry fields are IIH:n, LSP:y, SNP:n, and Purge:n.
In association with this, IANA has created an "IS-IS Sub-TLVs for the Area Proxy TLV" registry. Temporary registrations may be made via early allocation [RFC7120].
The registration procedure is Expert Review [RFC8126]. The values are from 0-255, and the fields are Value, Name, and Reference. The initial assignments are as follows.
+=======+==============================+===========+
| Value | Name | Reference |
+=======+==============================+===========+
| 1 | Area Proxy System Identifier | RFC 9666 |
+-------+------------------------------+-----------+
| 2 | Area SID | RFC 9666 |
+-------+------------------------------+-----------+
Table 17. Security Considerations 🔐
This document introduces no new security issues 💀. Security of routing within a domain is already addressed as part of the routing protocols themselves. This document proposes no changes to those security architectures. Security for IS-IS is provided by "IS-IS Cryptographic Authentication" [RFC5304] and "IS-IS Generic Cryptographic Authentication" [RFC5310] 🛡️.
8. References 📚
8.1. Normative References
[ISO10589] ISO, "Information technology - Telecommunications and
information exchange between systems - Intermediate System
to Intermediate System intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service (ISO
8473)", Second Edition, ISO/IEC 10589:2002, November 2002.
[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>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301,
October 2008, <https://www.rfc-editor.org/info/rfc5301>.
[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>.
[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>.
[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>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>.
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
"Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
DOI 10.17487/RFC8491, November 2018,
<https://www.rfc-editor.org/info/rfc8491>.
[RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
Extensions for Segment Routing", RFC 8667,
DOI 10.17487/RFC8667, December 2019,
<https://www.rfc-editor.org/info/rfc8667>.
[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
and Z. Hu, "IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
February 2023, <https://www.rfc-editor.org/info/rfc9352>.
[RFC9667] Li, T., Ed., Psenak, P., Ed., Chen, H., Jalil, L., and S.
Dontula, "Dynamic Flooding on Dense Graphs", RFC 9667,
DOI 10.17487/RFC9667, October 2024,
<https://www.rfc-editor.org/info/rfc9667>.8.2. Informative References
[Clos] Clos, C., "A study of non-blocking switching networks",
The Bell System Technical Journal, Volume 32, Issue 2, pp.
406-424, DOI 10.1002/j.1538-7305.1953.tb01433.x, March
1953,
<https://doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.Acknowledgements 💜
The authors would like to thank Bruno Decraene and Gunter Van De Velde for their many helpful comments. The authors would also like to thank a small group that wishes to remain anonymous for their valuable contributions 🫶.
Authors' Addresses 🦋
Tony Li
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Email: tony.li@tony.li
Sarah Chen
Arista Networks
5453 Great America Parkway
Santa Clara, CA 95054
United States of America
Email: sarahchen@arista.com
Vivek Ilangovan
Arista Networks
5453 Great America Parkway
Santa Clara, CA 95054
United States of America
Email: ilangovan@arista.com
Gyan S. Mishra
Verizon Inc.
13101 Columbia Pike
Silver Spring, MD 20904
United States of America
Phone: 301 502-1347
Email: gyan.s.mishra@verizon.com📦 where this page comes from
- ietf: rfc9666 2024-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms