Area Proxy for IS-IS
draft-ietf-lsr-isis-area-proxy-06
Internet Engineering Task Force T. Li
Internet-Draft S. Chen
Intended status: Experimental V. Ilangovan
Expires: November 21, 2021 Arista Networks
G. Mishra
Verizon Inc.
May 20, 2021
Area Proxy for IS-IS
draft-ietf-lsr-isis-area-proxy-06
Abstract
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, leading to
scale issues.
To avoid this, this document discusses extensions to the IS-IS
routing protocol that would allow level 1 areas to provide transit,
yet only inject an abstraction of the level 1 topology into level 2.
Each level 1 area is represented as a single level 2 node, thereby
enabling greater scale.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 21, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires November 21, 2021 [Page 1]
Internet-Draft Area Proxy May 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Area Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Segment Routing . . . . . . . . . . . . . . . . . . . . . 6
3. Inside Router Functions . . . . . . . . . . . . . . . . . . . 6
3.1. The Area Proxy TLV . . . . . . . . . . . . . . . . . . . 6
3.2. Level 2 SPF Computation . . . . . . . . . . . . . . . . . 7
3.3. Responsibilities with respect to the Proxy LSP . . . . . 8
4. Area Leader Functions . . . . . . . . . . . . . . . . . . . . 8
4.1. Area Leader Election . . . . . . . . . . . . . . . . . . 8
4.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Distributing Area Proxy Information . . . . . . . . . . . 8
4.3.1. The Area Proxy System Id Sub-TLV . . . . . . . . . . 8
4.3.2. The Area SID Sub-TLV . . . . . . . . . . . . . . . . 9
4.4. Proxy LSP Generation . . . . . . . . . . . . . . . . . . 11
4.4.1. The Protocols Supported TLV . . . . . . . . . . . . . 11
4.4.2. The Area Address TLV . . . . . . . . . . . . . . . . 11
4.4.3. The Dynamic Hostname TLV . . . . . . . . . . . . . . 11
4.4.4. The IS Neighbors TLV . . . . . . . . . . . . . . . . 11
4.4.5. The Extended IS Neighbors TLV . . . . . . . . . . . . 12
4.4.6. The MT Intermediate Systems TLV . . . . . . . . . . . 12
4.4.7. Reachability TLVs . . . . . . . . . . . . . . . . . . 12
4.4.8. The Router Capability TLV . . . . . . . . . . . . . . 13
4.4.9. The Multi-Topology TLV . . . . . . . . . . . . . . . 13
4.4.10. The SID/Label Binding and The Multi-Topology
SID/Label Binding SID TLV . . . . . . . . . . . . . . 14
4.4.11. The SRv6 Locator TLV . . . . . . . . . . . . . . . . 14
4.4.12. Traffic Engineering Information . . . . . . . . . . . 14
4.4.13. The Area SID . . . . . . . . . . . . . . . . . . . . 14
5. Inside Edge Router Functions . . . . . . . . . . . . . . . . 15
5.1. Generating L2 IIHs to Outside Routers . . . . . . . . . . 15
5.2. Filtering LSP information . . . . . . . . . . . . . . . . 15
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Li, et al. Expires November 21, 2021 [Page 2]
Internet-Draft Area Proxy May 2021
9.1. Normative References . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 18
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
The IS-IS routing protocol IS-IS [ISO10589] currently 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, only a summary of the address
space contained within the area, so 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
Level 1 and Level 2 and they are adjacent, 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 [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 to 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 too 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.
Li, et al. Expires November 21, 2021 [Page 3]
Internet-Draft Area Proxy May 2021
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.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [1] [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
2. Area Proxy
To address this, we propose to 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 ensure 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 is 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 Protocol
Data Unit (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
Li, et al. Expires November 21, 2021 [Page 4]
Internet-Draft Area Proxy May 2021
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
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.
Inside Area
+--------+ +--------+
| Inside |-----------------| Inside |
| Router | | Edge |
+--------+ +------------| Router |
| / +--------+
| / |
+--------+ / =============|======
| Area |/ || |
| Leader | || +---------+
+--------+ || | Outside |
|| | Edge |
|| | Router |
|| +---------+
Outside Area
An example of router classes
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 PDUs (IIHs) on all
Outside interfaces. Outside Edge Routers should 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.
Li, et al. Expires November 21, 2021 [Page 5]
Internet-Draft Area Proxy May 2021
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 the 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 native system identifier. This choice of pseudonode identifier
may confuse neighbors with an extremely strict implementation, in
which case the Inside Edge Router may be configured with priority 0,
causing an Outside Router to be elected DIS.
2.1. Segment Routing
If the Inside Area supports Segment Routing [RFC8402], then all
Inside Nodes MUST advertise an SR Global Block (SRGB). The first
value of the SRGB advertised by all Inside Nodes MUST start at the
same value. The range advertised for the area will be the minimum of
all Inside Nodes.
To support Segment Routing, the Area Leader will take the global SID
information found in the L1 LSDB and convey that to L2 through the
Proxy LSP. Prefixes with 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 Segment Routing, it would be 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 (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 that the remainder of L2 can use it for
path construction. (Section 4.4.13).
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 their
readiness to participate in Area Proxy functionality, they will
advertise the Area Proxy TLV in their L2 LSP.
3.1. The Area Proxy TLV
The Area Proxy TLV serves multiple functions:
Li, et al. Expires November 21, 2021 [Page 6]
Internet-Draft Area Proxy May 2021
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 a L1 LSP. Nodes MUST
ignore the Area Proxy TLV if it is found in a 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
3.2. 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. Further, because these systems do 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.
Li, et al. Expires November 21, 2021 [Page 7]
Internet-Draft Area Proxy May 2021
Point-to-Point links between two Inside Routers are considered to be
Inside Area links. LAN links which have a pseudonode LSP in the
Level 1 LSDB are considered to be Inside Area links.
3.3. Responsibilities with respect to the Proxy LSP
The Area Leader will generate a Proxy LSP that will be flooded across
the Inside Area. Inside Routers MUST ignore the contents of the
Proxy LSP other than for flooding. The Proxy LSP uses the Area Proxy
System Identifier as its Source ID.
4. 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.
4.1. Area Leader Election
The Area Leader is selected using the election mechanisms and TLVs
described in Dynamic Flooding for IS-IS
[I-D.ietf-lsr-dynamic-flooding].
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 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.
4.3. 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.
4.3.1. The Area Proxy System Id Sub-TLV
The Area Proxy System Id 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 and an indication that Area
Proxy is active. The format of this sub-TLV is:
Li, et al. Expires November 21, 2021 [Page 8]
Internet-Draft Area Proxy May 2021
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 ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proxy System Identifier continued |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Router Capability. All candidates
advertising the Area Proxy System Identifier TLV MUST be advertising
the same system identifier. Multiple proxy system identifiers in a
single area is a misconfiguration and each unique occurrence SHOULD
be logged.
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 Router Capability. 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 allows the Area Leader to advertise a prefix and
SID that represents 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 format:
Li, et al. Expires November 21, 2021 [Page 9]
Internet-Draft Area Proxy May 2021
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.
SID/Index/Label: as defined in [RFC8667] Section 2.1.1.1
Prefix Length: 1 octet
Prefix: 0-16 octets
The Flags octet is defined as follows:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|F|V|L| |
+-+-+-+-+-+-+-+-+
where:
F: Address-Family Flag. If unset, 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.
L: Local Flag. If set, then the value/index carried by the proxy
SID has local significance.
Other bits: MUST be zero when originated and ignored when
received.
Li, et al. Expires November 21, 2021 [Page 10]
Internet-Draft Area Proxy May 2021
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 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 MAY 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.
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 debugging the network.
4.4.4. The IS Neighbors TLV
The Area Leader MAY 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 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 bi-directional adjacency.
An entry for a neighbor in both the IS Neighbors TLV and the Extended
IS Neighbors would be functionally redundant, so the Area Leader
SHOULD NOT do this.
Li, et al. Expires November 21, 2021 [Page 11]
Internet-Draft Area Proxy May 2021
4.4.5. The Extended IS Neighbors TLV
The Area Leader MAY 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 unset, 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, then the Area Leader
SHOULD copy each Outside Edge Router advertisement that is advertised
by an Inside Edge Router in a 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, Level 2 LSDB, or
redistributed from another routing protocol. This applies to all of
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]
Li, et al. Expires November 21, 2021 [Page 12]
Internet-Draft Area Proxy May 2021
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 Segment Routing 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 Segment Routing 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 value 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 own 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 common 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
Li, et al. Expires November 21, 2021 [Page 13]
Internet-Draft Area Proxy May 2021
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
SID TLV
If an Inside Node advertises the SID/Label Binding or Multi-Topology
SID/Label Binding SID 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 [I-D.ietf-lsr-isis-srv6-extensions] 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
When SR is enabled, it may be useful to advertise an Area SID which
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 (Section 4.3.2) by the Area
Leader.
The Area Leader SHOULD advertise the Area SID information in the
Proxy LSP as a Node SID as defined in [RFC8667] Section 2.1. 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 which 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.
Li, et al. Expires November 21, 2021 [Page 14]
Internet-Draft Area Proxy May 2021
5. 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.
5.1. Generating L2 IIHs to Outside Routers
The Inside Edge Router has one or more Level 2 interfaces to 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 and subsequently flap.
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 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
Li, et al. Expires November 21, 2021 [Page 15]
Internet-Draft Area Proxy May 2021
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. Acknowledgments
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.
7. IANA Considerations
This memo requests that IANA allocate and assign code point 20 from
the IS-IS TLV Codepoints registry for the Area Proxy TLV. The
registry fields should be: IIH:n, LSP:y, SNP:n, Purge:n.
In association with this, this memo requests that IANA create a
registry for code points for the sub-TLVs of the Area Proxy TLV.
Name of the registry: Sub-TLVs for TLV 20 (Area Proxy TLV)
Required information for registrations: Temporary registrations
may be made under the Early IANA Allocation of Standards Track
Code Points policy. [RFC7120] Permanent registrations require the
publication of an RFC describing the usage of the code point.
Applicable registration policy: RFC Required and Expert Review.
We propose the initial experts be Chris Hopps, Tony Li, and Sarah
Chen.
Size, format, and syntax of registry entries: Value (0-255), Name,
and Reference
Initial assignments and reservations: IANA is requested to assign
the following code points:
+-------+------------------------------+---------------+
| Value | Name | Reference |
+-------+------------------------------+---------------+
| 1 | Area Proxy System Identifier | This document |
| 2 | Area SID | This document |
+-------+------------------------------+---------------+
Li, et al. Expires November 21, 2021 [Page 16]
Internet-Draft Area Proxy May 2021
8. 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.
9. References
9.1. Normative References
[I-D.ietf-lsr-dynamic-flooding]
Li, T., Psenak, P., Ginsberg, L., Chen, H., Przygienda,
T., Cooper, D., Jalil, L., Dontula, S., and G. S. Mishra,
"Dynamic Flooding on Dense Graphs", draft-ietf-lsr-
dynamic-flooding-08 (work in progress), December 2020.
[I-D.ietf-lsr-isis-srv6-extensions]
Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and
Z. Hu, "IS-IS Extension to Support Segment Routing over
IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-14
(work in progress), April 2021.
[ISO10589]
International Organization for Standardization,
"Intermediate System to Intermediate System Intra-Domain
Routing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 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>.
Li, et al. Expires November 21, 2021 [Page 17]
Internet-Draft Area Proxy May 2021
[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>.
[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>.
9.2. Informative References
[Clos] Clos, C., "A Study of Non-Blocking Switching Networks",
The Bell System Technical Journal Vol. 32(2), DOI
10.1002/j.1538-7305.1953.tb01433.x, March 1953,
<http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
Li, et al. Expires November 21, 2021 [Page 18]
Internet-Draft Area Proxy May 2021
[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>.
9.3. URIs
[1] https://tools.ietf.org/html/bcp14
Authors' Addresses
Tony Li
Arista Networks
5453 Great America Parkway
Santa Clara, California 95054
USA
Email: tony.li@tony.li
Sarah Chen
Arista Networks
5453 Great America Parkway
Santa Clara, California 95054
USA
Email: sarahchen@arista.com
Vivek Ilangovan
Arista Networks
5453 Great America Parkway
Santa Clara, California 95054
USA
Email: ilangovan@arista.com
Li, et al. Expires November 21, 2021 [Page 19]
Internet-Draft Area Proxy May 2021
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
Li, et al. Expires November 21, 2021 [Page 20]