Area Proxy for IS-ISJuniper Networks1133 Innovation WaySunnyvaleCA94089United States of Americatony.li@tony.liArista Networks5453 Great America ParkwaySanta ClaraCA95054United States of Americasarahchen@arista.comArista Networks5453 Great America ParkwaySanta ClaraCA95054United States of Americailangovan@arista.comVerizon Inc.13101 Columbia PikeSilver SpringMD20904United States of America301 502-1347gyan.s.mishra@verizon.com
RTG
lsrdatacenterIGProutingtopologylevelabstractionIS-ISproxy
Link-state routing protocols have hierarchical abstraction
already built into them. However, when lower levels are used
for transit, they must expose their internal topologies to each
other, thereby leading to scaling issues.
To avoid such issues, this document discusses extensions to the
IS-IS routing protocol that allow Level 1 (L1) areas to provide transit
but only inject an abstraction of the Level 1 topology into Level 2 (L2).
Each Level 1 area is represented as a single Level 2 node, thereby
enabling a greater scale.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. 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). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see 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
.
Copyright Notice
Copyright (c) 2024 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
() 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
. Introduction
. Requirements Language
. Area Proxy
. Segment Routing
. Inside Router Functions
. The Area Proxy TLV
. Level 2 SPF Computation
. Responsibilities Concerning the Proxy LSP
. Area Leader Functions
. Area Leader Election
. Redundancy
. Distributing Area Proxy Information
. The Area Proxy System Identifier Sub-TLV
. The Area SID Sub-TLV
. Proxy LSP Generation
. The Protocols Supported TLV
. The Area Address TLV
. The Dynamic Hostname TLV
. The IS Neighbors TLV
. The Extended IS Neighbors TLV
. The MT Intermediate Systems TLV
. Reachability TLVs
. The Router Capability TLV
. The Multi-Topology TLV
. The SID/Label Binding and the Multi-Topology SID/Label Binding TLV
. The SRv6 Locator TLV
. Traffic Engineering Information
. The Area SID
. Inside Edge Router Functions
. Generating L2 IIHs to Outside Routers
. Filtering LSP Information
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
Introduction
The IS-IS routing protocol
supports a two-level hierarchy of abstraction. The
fundamental unit of abstraction is the "area", which is a
(hopefully) connected set of systems running IS-IS at the same
level. Level 1, the lowest level, is abstracted by routers that
participate in both Level 1 and Level 2, and they inject area
information into Level 2. Level 2 systems seeking to access
Level 1 use this abstraction to compute the shortest path to
the Level 1 area.
The full topology database of Level 1 is not injected into Level 2, rather,
only a summary of the address space contained within the area is injected.
Therefore, the scalability of the Level 2 Link State Database (LSDB) is
protected.
This works well if the Level 1 area is tangential to the Level
2 area. This also works well if there are several routers in
both Levels 1 and 2 and they are adjacent to one another,
so Level 2 traffic will never need to transit Level 1 only
routers. Level 1 will not contain any Level 2 topology and
Level 2 will only contain area abstractions for Level 1.
Unfortunately, this scheme does not 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 must also appear in the Level 2
LSDB. This implies that all routers that could provide
transit plus any links that might also provide Level 2 transit
must also become part of the Level 2 topology. If this is a
relatively tiny portion of the Level 1 area, this is not
overly painful.
However, with today's data center topologies, this is problematic. A
common application is to use a Layer 3 Leaf-Spine (L3LS) topology,
which is a folded 3-stage Clos fabric . It can also be thought of as a complete bipartite graph. In
such a topology, the desire is to use Level 1 to contain the routing
dynamics of the entire L3LS topology and then use Level 2 for the
remainder of the network. Leaves in the L3LS topology are appropriate
for connection outside of the data center itself, so they would provide
connectivity for Level 2. If there are multiple connections to Level 2
for redundancy or other areas, these would also be made to the leaves
in the topology. This creates a difficulty because there are now
multiple Level 2 leaves in the topology, with connectivity between the
leaves provided by the spines.
Following the current rules of IS-IS, all spine routers would
necessarily be part of the Level 2 topology plus all links
between a Level 2 leaf and the spines. In the limit, where all
leaves need to support Level 2, it implies that the entire L3LS
topology becomes part of Level 2. This is seriously problematic,
as it more than doubles the LSDB held in the
L3LS topology and eliminates any benefits of the hierarchy.
This document discusses the handling of IP traffic. Supporting
MPLS-based traffic is a subject for future work.
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 when, and only when, they appear in all capitals, as
shown here.
Area Proxy In this specification, we completely abstract away the details of
the Level 1 area topology within Level 2, making the entire area look
like a single proxy system directly connected to all of the area's Level
2 neighbors. By only providing an abstraction of the topology, Level
2's requirement for connectivity can be satisfied without the full
overhead of the area's internal topology. It then becomes the
responsibility of the Level 1 area to provide the forwarding
connectivity that's advertised.
For this discussion, we'll consider a single Level 1 IS-IS area to be
the Inside Area and the remainder of the Level 2 area to be the Outside
Area. All routers within the Inside Area speak Level 1 and Level 2
IS-IS on all of the links within the topology. We propose to implement
Area Proxy by having a Level 2 Proxy Link State PDU (LSP) that
represents the entire Inside Area. We will refer to this as the Proxy
LSP. This is the only LSP from the area that will be flooded into the
overall Level 2 LSDB.
There are four classes of routers that we need to be concerned
with in this discussion:
Inside Router:
A router within the Inside Area that runs Level 1 and Level 2
IS-IS. A router is recognized as an Inside Router by the
existence of its LSP in the Level 1 LSDB.
Area Leader:
The Area Leader is an Inside Router that is
elected to represent the Level 1 area by injecting the
Proxy LSP into the Level 2 LSDB. There may be
multiple candidates for Area Leader, but only one is
elected at a given time. 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 is connected to an
Outside Edge Router is an Area Proxy Boundary.
Outside Edge Router:
An Outside Edge Router is a Level 2 router that is outside
of the Inside Area that has an adjacency with an Inside
Edge Router.
An Example of Router Classes
Inside Area
+--------+ +--------+
| Inside |-----------------| Inside |
| Router | | Edge |
+--------+ +------------| Router |
| / +--------+
| / |
+--------+ / =============|======
| Area |/ || |
| Leader | || +---------+
+--------+ || | Outside |
|| | Edge |
|| | Router |
|| +---------+
Outside Area
All Inside Edge Routers learn the Area Proxy System Identifier
from the Area Proxy TLV advertised by the Area Leader and use
that as the system identifier in their Level 2 IS-IS Hello (IIH) PDUs
on all Outside interfaces. Outside Edge Routers will
then advertise an adjacency to the Area Proxy System
Identifier. This allows all Outside Routers to use the Proxy
LSP in their SPF computations without seeing the full topology
of the Inside Area.
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.
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 be elected as the
Designated Intermediate System (DIS) for a Boundary LAN. In this case,
using the Area Proxy System ID as the basis for the LAN pseudonode
identifier could create a collision, so the Insider 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 this
case, the Inside Edge Router may be configured with priority 0, causing
an Outside Router to be elected as the DIS.
Segment Routing
If the Inside Area supports Segment Routing (SR) , 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 do not 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 that advertised by all Inside Nodes.
To support SR, the Area Leader will take the SRGB information
found in the L1 LSDB and convey that to L2 through the Proxy LSP.
Prefixes with Segment Identifier (SID) assignments will be copied to the Proxy
LSP. Adjacency SIDs for Outside Edge Nodes will be copied to the Proxy LSP.
To further extend SR, it is helpful to
have a segment that refers to the entire Inside Area. This
allows a path to refer to an area and have any node within
that area accept and forward the packet. In effect, this
becomes an anycast SID that is accepted by all Inside Edge
Nodes. The information about this SID is distributed in the
Area SID sub-TLV as part of the Area Leader's Area
Proxy TLV (). 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
that the remainder of L2 can use it for path construction.
().
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
their readiness to participate in Area Proxy functionality,
they will advertise the Area Proxy TLV in their L2 LSP.
The Area Proxy TLV
The Area Proxy TLV serves multiple functions:
The presence of the Area Proxy TLV in a node's LSP
indicates 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 is a container for sub-TLVs with 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 is found in an
L1 LSP. The Area Proxy TLV is not 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.
Level 2 SPF Computation
When Outside Routers perform a Level 2 SPF computation, they
will use the Proxy LSP for computing a path transiting
the Inside Area. Because the topology has been abstracted
away, the cost for transiting the Inside Area will be zero.
When Inside Routers perform a Level 2 SPF computation, they
MUST ignore the Proxy LSP. Because these systems
see the Inside Area topology, the link metrics internal to
the area are visible. This could lead to different and
possibly inconsistent SPF results, potentially leading to
forwarding loops.
To prevent this, the 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. Thus, if two paths have
different total inter-area metrics, the path with the lower
inter-area metric would be preferred regardless of any
intra-area metrics involved. However, if two paths have equal
inter-area metrics, then the intra-area metrics would be used
to compare the paths.
Point-to-point links between two Inside Routers are
considered to be Inside Area links. LAN links that have a
pseudonode LSP in the Level 1 LSDB are considered to be
Inside Area links.
Responsibilities Concerning the Proxy LSPThe Area Leader will generate a Proxy LSP that will be 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.
Area Leader Functions
The Area Leader has several 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.
Area Leader Election
The Area Leader is selected using the election mechanisms and
TLVs described in "Dynamic Flooding on Dense Graphs" .
Redundancy
If the Area Leader fails, another candidate may become Area
Leader and MUST regenerate the Proxy LSP. The
failure of the Area Leader is not visible outside of the area
and appears to simply be an update of 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.
Distributing Area Proxy Information
The Area Leader is responsible for distributing information
about the area to all Inside Nodes. In particular, the Area
Leader distributes the Proxy System ID and the Area SID.
This is done using two sub-TLVs of the Area Proxy TLV.
The Area Proxy System Identifier Sub-TLV
The Area Proxy System Identifier sub-TLV MUST be used by the Area
Leader to distribute the Area Proxy System ID. This is an
additional system identifier that is used by Inside Nodes
as an indication that Area Proxy is active. The format of
this sub-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 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Proxy System Identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
1
Length:
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. Their advertisements
indicate that they are individually ready to perform Area
Proxy functionality. The Area Leader then advertises the
Area Proxy System Identifier TLV to indicate that the
Inside Area MUST enable Area Proxy functionality.
Other candidates for Area Leader MAY also advertise
the Area Proxy System Identifier when they observe 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.
The Area SID Sub-TLV
The Area SID sub-TLV allows the Area Leader to advertise a
prefix and SID that represent the entirety of the Inside
Area to the Outside Area. This sub-TLV is learned by all
of the Inside Edge Nodes 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:
2
Length:
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 .
L:
Local Flag. If set, then the value/index
carried by the proxy SID has local significance, as defined in
.
Other bits:
MUST be zero when
originated and ignored when received.
SID/Index/Label:
As defined in .
Prefix Length:
1 octet
Prefix:
0-16 octets
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
MUST be filtered by all Inside Edge Routers to not be flooded
to Outside Routers. Only the Proxy LSP is 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 additional information for the Outside
Area. LSPs generated by unreachable nodes MUST NOT be
considered.
The Protocols Supported TLV
The Area Leader SHOULD insert a Protocols Supported TLV (129)
into the Proxy LSP. The
values included in the TLV SHOULD be the protocols
supported by the Inside Area.
The Area Address TLV
The Area Leader SHOULD insert an Area Addresses TLV (1)
into the Proxy LSP.
The Dynamic Hostname TLV
It is RECOMMENDED that the Area Leader insert the Dynamic
Hostname TLV (137) into the Proxy
LSP. The contents of the hostname may be specified by
configuration. The presence of the hostname helps to
simplify network debugging.
The IS Neighbors TLV
The Area Leader can insert the IS Neighbors TLV (2) 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 copying any IS Neighbors TLVs referring to Outside
Edge Routers into the Proxy LSP. Since the Outside Edge
Routers advertise an adjacency to the Area Proxy System
Identifier, this will result 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.
The Extended IS Neighbors TLV
The Area Leader can insert the Extended IS Reachability TLV
(22) 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) 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
() to each Extended IS
Reachability TLV in the Proxy LSP.
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.
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, 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)
IP External Reachability Information TLV (130)
Extended IP Reachability TLV (135)
IPv6 Reachability TLV (236)
Multi-Topology Reachable IPv4 Prefixes TLV (235)
Multi-Topology Reachable IPv6 Prefixes TLV (237)
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) , 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.
The Router Capability TLV
The Area Leader MAY insert the Router Capability TLV (242)
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) 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 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 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.
The Multi-Topology TLV
If the Inside Area supports multi-topology, then the Area
Leader SHOULD insert the Multi-Topology TLV (229) , 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.
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 , then the Area Leader MAY copy the TLV
to the Proxy LSP.
The SRv6 Locator TLV
If the inside area supports SRv6, the Area Leader SHOULD
copy all SRv6 locator TLVs
advertised by Inside Routers to the Proxy LSP.
Traffic Engineering Information
If the inside area supports TE, the Area Leader SHOULD
advertise a TE Router ID TLV (134)
in the Proxy LSP. It SHOULD copy the Shared Risk
Link Group (SRLS) TLVs (138)
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)
in the Proxy LSP. It SHOULD also
copy the IPv6 SRLG TLVs (139)
advertised by Inside Edge Routers about links to Outside
Edge Routers.
The Area SID
When SR is enabled, it may be useful to advertise an Area
SID that will direct traffic to any of the Inside
Edge Routers. The information for the Area SID is
distributed to all Inside Edge Routers using the Area SID
sub-TLV () by the Area Leader.
The Area Leader SHOULD advertise the Area SID information
in the Proxy LSP as a Node SID as defined in . The advertisement in the
Proxy LSP informs the Outside Area that packets directed to
the SID will be forwarded to one of the Inside Edge Nodes
and the Area SID will be consumed.
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 that used in
support of Area Proxy.
Inside Edge Router Functions
The Inside Edge Router has two additional and important
functions. 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 are being advertised
to Outside Routers.
Generating L2 IIHs to Outside Routers
The Inside Edge Router has one or more Level 2 interfaces to
the Outside Routers. These may be identified by explicit
configuration or by the fact that they are not 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. Then, once it has learned the
Area Proxy System 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 causes the Outside Router to
advertise an adjacency to the Proxy System ID, not to the
Inside Edge Router, which supports the proxy function. The
normal system ID of the Inside Edge Router MUST NOT be used
as it will cause unnecessary adjacencies to form.
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 prevent 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.
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 a "IS-IS Sub-TLVs for the Area Proxy TLV" registry. Temporary registrations may
be made via early allocation .The registration procedure is Expert Review . 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
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" and "IS-IS Generic
Cryptographic Authentication" .
ReferencesNormative ReferencesInformation 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)International Organization for StandardizationSecond EditionUse of OSI IS-IS for routing in TCP/IP and dual environmentsThis memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)This document describes an optional mechanism within Intermediate System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routing within their clouds. This document describes how to run, within a single IS-IS domain, a set of independent IP topologies that we call Multi-Topologies (MTs). This MT extension can be used for a variety of purposes, such as an in-band management network "on top" of the original IGP topology, maintaining separate IGP routing domains for isolated multicast or IPv6 islands within the backbone, or forcing a subset of an address space to follow a different topology. [STANDARDS-TRACK]Dynamic Hostname Exchange Mechanism for IS-ISRFC 2763 defined a simple and dynamic mechanism for routers running IS-IS to learn about symbolic hostnames. RFC 2763 defined a new TLV that allows the IS-IS routers to flood their name-to-systemID mapping information across the IS-IS network.This document obsoletes RFC 2763. This document moves the capability provided by RFC 2763 to the Standards Track. [STANDARDS-TRACK]IS-IS Cryptographic AuthenticationThis document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]IS-IS Extensions for Traffic EngineeringThis document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]Routing IPv6 with IS-ISThis document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]IS-IS Generic Cryptographic AuthenticationThis document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]IPv6 Traffic Engineering in IS-ISThis document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]IS-IS Extensions for Advertising Router InformationThis document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. This document obsoletes RFC 4971.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Segment Routing ArchitectureSegment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.Signaling Maximum SID Depth (MSD) Using IS-ISThis document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.IS-IS Extensions for Segment RoutingSegment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF).This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.IS-IS Extensions to Support Segment Routing over the IPv6 Data PlaneThe Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane.This document updates RFC 7370 by modifying an existing registry.Dynamic Flooding on Dense GraphsJuniper NetworksCisco Systems, Inc.FutureweiVerizonAT&TInformative ReferencesA study of non-blocking switching networksThe Bell System Technical Journal, Volume 32, Issue 2, pp.
406-424Early IANA Allocation of Standards Track Code PointsThis memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Acknowledgements
The authors would like to thank
and 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' AddressesJuniper Networks1133 Innovation WaySunnyvaleCA94089United States of Americatony.li@tony.liArista Networks5453 Great America ParkwaySanta ClaraCA95054United States of Americasarahchen@arista.comArista Networks5453 Great America ParkwaySanta ClaraCA95054United States of Americailangovan@arista.comVerizon Inc.13101 Columbia PikeSilver SpringMD20904United States of America301 502-1347gyan.s.mishra@verizon.com