rfc9377.original   rfc9377.txt 
Network Working Group A. Przygienda, Ed. Internet Engineering Task Force (IETF) T. Przygienda, Ed.
Internet-Draft C. Bowers Request for Comments: 9377 Juniper
Intended status: Experimental Juniper Category: Experimental C. Bowers
Expires: 8 June 2023 Y. Lee ISSN: 2070-1721 Individual
Y. Lee
Comcast Comcast
A. Sharma A. Sharma
Individual Individual
R. White R. White
Akamai Akamai
5 December 2022 April 2023
IS-IS Flood Reflection IS-IS Flood Reflection
draft-ietf-lsr-isis-flood-reflection-12
Abstract Abstract
This document describes a backward-compatible, optional IS-IS This document describes a backward-compatible, optional IS-IS
extension that allows the creation of IS-IS flood reflection extension that allows the creation of IS-IS flood reflection
topologies. Flood reflection permits topologies in which L1 areas topologies. Flood reflection permits topologies in which
provide transit forwarding for L2 using all available L1 nodes IS-IS Level 1 (L1) areas provide transit-forwarding for IS-IS Level 2
internally. It accomplishes this by creating L2 flood reflection (L2) areas using all available L1 nodes internally. It accomplishes
adjacencies within each L1 area. Those adjacencies are used to flood this by creating L2 flood reflection adjacencies within each L1 area.
L2 LSPDUs and are used in the L2 SPF computation. However, they are Those adjacencies are used to flood L2 Link State Protocol Data Units
not ordinarily utilized for forwarding within the flood reflection (LSPs) and are used in the L2 Shortest Path First (SPF) computation.
cluster. This arrangement gives the L2 topology significantly better However, they are not ordinarily utilized for forwarding within the
scaling properties than traditionally used flat designs. As an flood reflection cluster. This arrangement gives the L2 topology
additional benefit, only those routers directly participating in significantly better scaling properties than prevalently used flat
flood reflection are required to support the feature. This allows designs. As an additional benefit, only those routers directly
for incremental deployment of scalable L1 transit areas in an participating in flood reflection are required to support the
existing, previously flat network design, without the necessity of feature. This allows for incremental deployment of scalable L1
upgrading all routers in the network. transit areas in an existing, previously flat network design, without
the necessity of upgrading all routers in the network.
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
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 This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on 8 June 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9377.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Conventions Used in This Document
3. Further Details . . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Terminology
4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Requirements Language
4.1. Flood Reflection TLV . . . . . . . . . . . . . . . . . . 10 3. Further Details
4.2. Flood Reflection Discovery Sub-TLV . . . . . . . . . . . 11 4. Encodings
4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV . . . 12 4.1. Flood Reflection TLV
4.4. Flood Reflection Adjacency Sub-TLV . . . . . . . . . . . 14 4.2. Flood Reflection Discovery Sub-TLV
4.5. Flood Reflection Discovery . . . . . . . . . . . . . . . 15 4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV
4.6. Flood Reflection Adjacency Formation . . . . . . . . . . 16 4.4. Flood Reflection Adjacency Sub-TLV
5. Route Computation . . . . . . . . . . . . . . . . . . . . . . 16 4.5. Flood Reflection Discovery
5.1. Tunnel-Based Deployment . . . . . . . . . . . . . . . . . 17 4.6. Flood Reflection Adjacency Formation
5.2. No-Tunnel Deployment . . . . . . . . . . . . . . . . . . 17 5. Route Computation
6. Redistribution of Prefixes . . . . . . . . . . . . . . . . . 17 5.1. Tunnel-Based Deployment
7. Special Considerations . . . . . . . . . . . . . . . . . . . 18 5.2. No-Tunnel Deployment
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. Redistribution of Prefixes
8.1. New IS-IS TLV Codepoint . . . . . . . . . . . . . . . . . 19 7. Special Considerations
8.2. Sub TLVs for IS-IS Router CAPABILITY TLV . . . . . . . . 19 8. IANA Considerations
8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV . . . 19 8.1. New IS-IS TLV Codepoint
8.4. Sub TLVs for TLVs Advertising Neighbor Information . . . 19 8.2. Sub-TLVs for IS-IS Router CAPABILITY TLV
8.3. Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8.4. Sub-TLVs for TLVs Advertising Neighbor Information
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. References
11.1. Informative References . . . . . . . . . . . . . . . . . 20 10.1. Normative References
11.2. Normative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
This section introduces the problem space and outlines the solution. This section introduces the problem space and outlines the solution.
Some of the terms may be unfamiliar to readers without extensive IS- Some of the terms may be unfamiliar to readers without extensive IS-
IS background; for such readers a glossary is provided in Section 2. IS background; for such readers, the terminology is provided in
Section 2.1.
Due to the inherent properties of link-state protocols the number of Due to the inherent properties of link-state protocols, the number of
IS-IS routers within a flooding domain is limited by processing and IS-IS routers within a flooding domain is limited by processing and
flooding overhead on each node. While that number can be maximized flooding overhead on each node. While that number can be maximized
by well-written implementations and techniques such as exponential by well-written implementations and techniques such as exponential
back-offs, IS-IS will still reach a saturation point where no further backoffs, IS-IS will still reach a saturation point where no further
routers can be added to a single flooding domain. In some L2 routers can be added to a single flooding domain. In some L2
backbone deployment scenarios, this limit presents a significant backbone deployment scenarios, this limit presents a significant
challenge. challenge.
The traditional approach to increasing the scale of an IS-IS The standard approach to increasing the scale of an IS-IS deployment
deployment is to break it up into multiple L1 flooding domains and a is to break it up into multiple L1 flooding domains and a single L2
single L2 backbone. This works well for designs where an L2 backbone backbone. This works well for designs where an L2 backbone connects
connects L1 access topologies, but it is limiting where a single, L1 access topologies, but it is limiting where a single, flat L2
flat L2 domain is supposed to span large number of routers. In such domain is supposed to span large number of routers. In such
scenarios, an alternative approach could be to consider multiple L2 scenarios, an alternative approach could be to consider multiple L2
flooding domains connected together via L1 flooding domains. In flooding domains that are connected together via L1 flooding domains.
other words, L2 flooding domains are connected by "L1/L2 lanes" In other words, L2 flooding domains are connected by "L1/L2 lanes"
through the L1 areas to form a single L2 backbone again. through the L1 areas to form a single L2 backbone again.
Unfortunately, in its simplest implementation, this requires the Unfortunately, in its simplest implementation, this requires the
inclusion of most, or all, of the transit L1 routers as L1/L2 to inclusion of most, or all, of the transit L1 routers as L1/L2 to
allow traffic to flow along optimal paths through those transit allow traffic to flow along optimal paths through those transit
areas. Consequently, such an approach fails to reduce the number of areas. Consequently, such an approach fails to reduce the number of
L2 routers involved and with that fails to increase the scalability L2 routers involved and, with that, fails to increase the scalability
of the L2 backbone as well. of the L2 backbone as well.
Figure 1 is an example of a network where a topologically rich L1 Figure 1 is an example of a network where a topologically rich L1
area is used to provide transit between six different L2-only routers area is used to provide transit between six different L2-only routers
(R1-R6). Note that the six L2-only routers do not have connectivity (R1-R6). Note that the six L2-only routers do not have connectivity
to one another over L2 links. To take advantage of the abundance of to one another over L2 links. To take advantage of the abundance of
paths in the L1 transit area, all the intermediate systems could be paths in the L1 transit area, all the intermediate systems could be
placed into both L1 and L2, but this essentially combines the placed into both L1 and L2, but this essentially combines the
separate L2 flooding domains into a single one, triggering again the separate L2 flooding domains into a single one, again triggering the
maximum L2 scale limitation we try to address in first place. maximum L2 scale limitation we were trying to address in first place.
+====+ +=======+ +=======+ +======-+ +====+ +====+ +=======+ +=======+ +======-+ +====+
I R1 I I R10 +-------------+ R20 +---------------+ R30 I I R4 I I R1 I I R10 +-------------+ R20 +---------------+ R30 I I R4 I
I L2 +--+ L1/L2 I I L1 I I L1/L2 +--+ L2 I I L2 +--+ L1/L2 I I L1 I I L1/L2 +--+ L2 I
I I I + +--+ I +------------+ I I I I I I + +--+ I +------------+ I I I
+====+ ++====+=+ | +===+===+ | +=+==+=++ +====+ +====+ ++====+=+ | +===+===+ | +=+==+=++ +====+
| | | | | | | | | | | | | |
| | | | | +-----------+ | | | | | | +-----------+ |
| +-------+ | | | | | | +-------+ | | | | |
| | | | | | | | | | | | | |
skipping to change at page 4, line 34 skipping to change at line 169
| | +----------------+ | +-----------------+ | | | +----------------+ | +-----------------+ |
| | | | | | | | | | | | | | | | | |
+====+ ++=+==+=+ +-------+===+===+-----+ | ++=====++ +====+ +====+ ++=+==+=+ +-------+===+===+-----+ | ++=====++ +====+
I R3 I I R12 I I R22 I | + R32 I I R6 I I R3 I I R12 I I R22 I | + R32 I I R6 I
I L2 +--+ L1/L2 I I L1 +-------+ I L1/L2 +--+ L2 I I L2 +--+ L1/L2 I I L1 +-------+ I L1/L2 +--+ L2 I
I I I +-------------+ +---------------+ I I I I I I +-------------+ +---------------+ I I I
+====+ +=======+ +=======+ +=======+ +====+ +====+ +=======+ +=======+ +=======+ +====+
Figure 1: Example Topology of L1 with L2 Borders Figure 1: Example Topology of L1 with L2 Borders
A more effective solution would allow to reduce the number of links A more effective solution would allow the reduction of the number of
and routers exposed in L2, while still utilizing the full L1 topology links and routers exposed in L2, while still utilizing the full L1
when forwarding through the network. topology when forwarding through the network.
[RFC8099] describes Topology Transparent Zones (TTZ) for OSPF. The [RFC8099] describes Topology Transparent Zones (TTZ) for OSPF. The
TTZ mechanism represents a group of OSPF routers as a full mesh of TTZ mechanism represents a group of OSPF routers as a full mesh of
adjacencies between the routers at the edge of the group. A similar adjacencies between the routers at the edge of the group. A similar
mechanism could be applied to IS-IS as well. However, a full mesh of mechanism could be applied to IS-IS as well. However, a full mesh of
adjacencies between edge routers (or L1/L2 nodes) significantly adjacencies between edge routers (or L1/L2 nodes) significantly
limits the practically achievable scale of the resulting topology. limits the practically achievable scale of the resulting topology.
The topology in Figure 1 has 6 L1/L2 nodes. Figure 2 illustrates a The topology in Figure 1 has six L1/L2 nodes. Figure 2 illustrates a
full mesh of L2 adjacencies between the 6 L1/L2 nodes, resulting in full mesh of L2 adjacencies between the six L1/L2 nodes, resulting in
(5 * 6)/2 = 15 L2 adjacencies. In a somewhat larger topology (5 * 6)/2 = 15 L2 adjacencies. In a somewhat larger topology
containing 20 L1/L2 nodes, the number of L2 adjacencies in a full containing 20 L1/L2 nodes, the number of L2 adjacencies in a full
mesh rises to 190. mesh rises to 190.
+----+ +-------+ +-------------------------------+-------+ +----+ +----+ +-------+ +-------------------------------+-------+ +----+
| R1 | | R10 | | | R30 | | R4 | | R1 | | R10 | | | R30 | | R4 |
| L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 |
| | | | | | | | | | | | | | | | | |
+----+ ++-+-+--+-+ | +-+--+---++ +----+ +----+ ++-+-+--+-+ | +-+--+---++ +----+
| | | | | | | | | | | | | | | |
skipping to change at page 5, line 36 skipping to change at line 216
| | | | +----------+ | | | | | +----------+ |
| | | | | | | | | | | | | | | |
| | | | +-----+ | | | | | | +-----+ | |
| | | | | | | | | | | | | | | |
+----+ ++----+-+-+ | +-+-+--+-++ +----+ +----+ ++----+-+-+ | +-+-+--+-++ +----+
| R3 | | R12 | | L2 adjacency | R32 | | R6 | | R3 | | R12 | | L2 adjacency | R32 | | R6 |
| L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 |
| | | | | | | | | | | | | | | | | |
+----+ +-------+----+ +-------+ +----+ +----+ +-------+----+ +-------+ +----+
Figure 2: Example topology represented in L2 with a full mesh of Figure 2: Example Topology Represented in L2 with a Full Mesh of
L2 adjacencies between L1/L2 nodes L2 Adjacencies between L1/L2 Nodes
BGP, as specified in [RFC4271], faced a similar scaling problem, BGP, as specified in [RFC4271], faced a similar scaling problem,
which has been solved in many networks by deploying BGP route which has been solved in many networks by deploying BGP route
reflectors [RFC4456]. We note that BGP route reflectors do not reflectors [RFC4456]. We note that BGP route reflectors do not
necessarily have to be in the forwarding path of the traffic. This necessarily have to be in the forwarding path of the traffic. This
non-congruity of forwarding and control path for BGP route reflectors non-congruity of forwarding and control path for BGP route reflectors
allows the control plane to scale independently of the forwarding allows the control plane to scale independently of the forwarding
plane and represents an interesting degree of freedom in network plane and represents an interesting degree of freedom in network
architecture. architecture.
We propose in this document a similar solution for IS-IS and call it We propose in this document a similar solution for IS-IS and call it
"flood reflection" in fashion analogous to "route reflection". A "flood reflection" in a fashion analogous to "route reflection". A
simple example of what a flood reflector control plane approach would simple example of what a flood reflector control plane approach would
look like is shown in Figure 3, where router R21 plays the role of a look like is shown in Figure 3, where router R21 plays the role of a
flood reflector. Each L1/L2 ingress/egress router builds a tunnel to flood reflector. Each L1/L2 ingress/egress router builds a tunnel to
the flood reflector, and an L2 adjacency is built over each tunnel. the flood reflector, and an L2 adjacency is built over each tunnel.
In this solution, we need only 6 L2 adjacencies, instead of the 15 In this solution, we need only six L2 adjacencies, instead of the 15
needed for a full mesh. In a somewhat larger topology containing 20 needed for a full mesh. In a somewhat larger topology containing 20
L1/L2 nodes, this solution requires only 20 L2 adjacencies, instead L1/L2 nodes, this solution requires only 20 L2 adjacencies, instead
of the 190 needed for a full mesh. Multiple flood reflectors can be of the 190 needed for a full mesh. Multiple flood reflectors can be
used, allowing the network operator to balance between resilience, used, allowing the network operator to balance between resilience,
path utilization, and state in the control plane. The resulting L2 path utilization, and state in the control plane. The resulting L2
adjacency scale is R*n, where R is the number of flood reflectors adjacency scale is R*n, where R is the number of flood reflectors
used and n is the number of L1/L2 nodes. This compares quite used and n is the number of L1/L2 nodes. This compares quite
favorably with n*(n-1)/2 L2 adjacencies required in a topologically favorably with n*(n-1)/2 L2 adjacencies required in a topologically
fully meshed L2 solution. fully meshed L2 solution.
skipping to change at page 6, line 35 skipping to change at line 263
| L2 +--+ L1/L2 +-----------+ L1/L2 +--------------+ L1/L2 +--+ L2 | | L2 +--+ L1/L2 +-----------+ L1/L2 +--------------+ L1/L2 +--+ L2 |
| | | | L2 adj | flood | L2 adj | | | | | | | | L2 adj | flood | L2 adj | | | |
+----+ +-------+ over |reflector| over +-------+ +----+ +----+ +-------+ over |reflector| over +-------+ +----+
tunnel +--+---+--+ tunnel tunnel +--+---+--+ tunnel
+----+ +-------+ | | +-------+ +----+ +----+ +-------+ | | +-------+ +----+
| R3 | | R12 +--------------+ +-----------------+ R32 | | R6 | | R3 | | R12 +--------------+ +-----------------+ R32 | | R6 |
| L2 +--+ L1/L2 | L2 adj L2 adj | L1/L2 +--+ L2 | | L2 +--+ L1/L2 | L2 adj L2 adj | L1/L2 +--+ L2 |
| | | | over over | | | | | | | | over over | | | |
+----+ +-------+ tunnel tunnel +-------+ +----+ +----+ +-------+ tunnel tunnel +-------+ +----+
Figure 3: Example topology represented in L2 with L2 adjacencies Figure 3: Example Topology Represented in L2 with L2 Adjacencies
from each L1/ L2 node to a single flood reflector from Each L1/ L2 Node to a Single Flood Reflector
As illustrated in Figure 3, when R21 plays the role of flood As illustrated in Figure 3, when R21 plays the role of flood
reflector, it provides L2 connectivity among all of the previously reflector, it provides L2 connectivity among all of the previously
disconnected L2 islands by reflooding all L2 LSPDUs. At the same disconnected L2 islands by reflooding all L2 Link State Protocol Data
time, R20 and R22 in Figure 1 remain L1-only routers. L1-only Unit (LSPs). At the same time, R20 and R22 in Figure 1 remain
routers and L1-only links are not visible in L2. In this manner, the L1-only routers. L1-only routers and L1-only links are not visible
flood reflector allows us provide L2 control plane connectivity in a in L2. In this manner, the flood reflector allows us to provide L2
manner more scalable than a flat L2 domain. control plane connectivity in a manner more scalable than a flat L2
domain.
As described so far, the solution illustrated in Figure 3 relies only As described so far, the solution illustrated in Figure 3 relies only
on currently standardized IS-IS functionality. Without new on currently standardized IS-IS functionality. Without new
functionality, however, the data traffic will traverse only R21. functionality, however, the data traffic will traverse only R21.
This will unnecessarily create a bottleneck at R21 since there is This will unnecessarily create a bottleneck at R21 since there is
still available capacity in the paths crossing the L1-only routers still available capacity in the paths crossing the L1-only routers
R20 and R22 in Figure 1. R20 and R22 in Figure 1.
Hence, additional functionality is compulsory to allow the L1/L2 edge Hence, additional functionality is compulsory to allow the L1/L2 edge
nodes (R10-12 and R30-32 in Figure 3) to recognize that the L2 nodes (R10-12 and R30-32 in Figure 3) to recognize that the L2
adjacency to R21 should not be used for forwarding. The L1/L2 edge adjacency to R21 should not be used for forwarding. The L1/L2 edge
nodes should forward traffic that would normally be forwarded over nodes should forward traffic that would normally be forwarded over
the L2 adjacency to R21 over L1 links instead. This would allow the the L2 adjacency to R21 over L1 links instead. This would allow the
forwarding within the L1 area to use the L1-only nodes and links forwarding within the L1 area to use the L1-only nodes and links
shown in Figure 1 as well. It allows networks to be built that use shown in Figure 1 as well. It allows networks that use the entire
the entire forwarding capacity of the L1 areas, while at the same forwarding capacity of the L1 areas to be built, while at the same
time introducing control plane scaling benefits provided by L2 flood time it introduces control plane scaling benefits that are provided
reflectors. by L2 flood reflectors.
It is expected that deployment at scale, and suitable time in It is expected that deployment at scale, and suitable time in
operation, will provide sufficient evidence to either make this operation, will provide sufficient evidence to either put this
extension a standard, or suggest necessary modifications to extension into a Standards Track document or suggest necessary
accomplish this. modifications to accomplish that.
The remainder of this document defines the remaining extensions The remainder of this document defines the remaining extensions
necessary for a complete flood reflection solution: necessary for a complete flood reflection solution:
* It defines a special 'flood reflector adjacency' built for the * It defines a special "flood reflector adjacency" built for the
purpose of reflecting flooding information. These adjacencies purpose of reflecting flooding information. These adjacencies
allow 'flood reflectors' to participate in the IS-IS control plane allow "flood reflectors" to participate in the IS-IS control plane
without necessarily being used in the forwarding plane. without necessarily being used in the forwarding plane.
Maintenance of such adjacencies is a purely local operation on the Maintenance of such adjacencies is a purely local operation on the
L1/L2 ingress and flood reflectors; it does not require replacing L1/L2 ingress and flood reflectors; it does not require replacing
or modifying any routers not involved in the reflection process. or modifying any routers not involved in the reflection process.
In practical deployments, it is far less tricky to just upgrade In practical deployments, it is far less tricky to just upgrade
the routers involved in flood reflection rather than have a flag the routers involved in flood reflection rather than have a flag
day for the whole IS-IS domain. day for the whole IS-IS domain.
* It specifies an (optional) full mesh of tunnels between the L1/L2 * It specifies an (optional) full mesh of tunnels between the L1/L2
ingress routers, ideally load-balancing across all available L1 ingress routers, ideally load-balancing across all available L1
links. This harnesses all forwarding paths between the L1/L2 edge links. This harnesses all forwarding paths between the L1/L2 edge
nodes without injecting unneeded state into the L2 flooding domain nodes without injecting unneeded state into the L2 flooding domain
or creating 'choke points' at the 'flood reflectors' themselves. or creating "choke points" at the "flood reflectors" themselves.
The specification is agnostic as to the tunneling technology used The specification is agnostic as to the tunneling technology used
but provides enough information for automatic establishment of but provides enough information for automatic establishment of
such tunnels if desired. The discussion of IS-IS adjacency such tunnels if desired. The discussion of IS-IS adjacency
formation and/or liveness discovery on such tunnels is outside the formation and/or liveness discovery on such tunnels is outside the
scope of this specification and is largely a choice of the scope of this specification and is largely a choice of the
underlying implementation. A solution without tunnels is also underlying implementation. A solution without tunnels is also
possible by introducing the correct scoping of reachability possible by introducing the correct scoping of reachability
information between the levels. This is described in more detail information between the levels. This is described in more detail
later. later.
* Finally, the document defines support of reflector redundancy and * Finally, this document defines support of reflector redundancy and
an (optional) way to auto-discover and annotate flood reflector an (optional) way to auto-discover and annotate flood reflector
adjacencies on advertisements. Such additional information in adjacencies on advertisements. Such additional information in
link advertisements allows L2 nodes outside the L1 area to link advertisements allows L2 nodes outside the L1 area to
recognize a flood reflection cluster and its adjacencies. recognize a flood reflection cluster and its adjacencies.
2. Glossary 2. Conventions Used in This Document
2.1. Terminology
The following terms are used in this document. The following terms are used in this document.
ISIS Level-1 and Level-2 areas, mostly abbreviated as L1 and L2: IS-IS Level 1 and Level 2 areas (mostly abbreviated as L1 and L2):
Traditional ISIS concepts whereas a routing domain has two IS-IS concepts where a routing domain has two "levels" with a
"levels" with a single L2 area being the "backbone" that connects single L2 area being the "backbone" that connects multiple L1
multiple L1 areas for scaling and reliability purposes. In areas for scaling and reliability purposes. IS-IS architecture
traditional ISIS L2 can be used as transit for L1-L1 traffic but prescribes a routing domain with two "levels" where a single L2
L1 areas cannot be used for that purpose since L2 level must be area functions as the "backbone" that connects multiple L1 areas
"connected" and all traffic flows along L2 routers until it amongst themselves for scaling and reliability purposes. In such
arrives at the destination L1 area. architecture, L2 can be used as transit for traffic carried from
one L1 area to another, but L1 areas themselves cannot be used for
that purpose because the L2 level must be a single "connected"
entity, and all traffic exiting an L1 area flows along L2 routers
until the traffic arrives at the destination L1 area itself.
Flood Reflector: Flood Reflector:
Node configured to connect in L2 only to flood reflector clients Node configured to connect in L2 only to flood reflector clients
and reflect (reflood) IS-IS L2 LSPs amongst them. and to reflect (reflood) IS-IS L2 LSPs amongst them.
Flood Reflector Client: Flood Reflector Client:
Node configured to build Flood Reflector Adjacencies to Flood Node configured to build Flood Reflector Adjacencies to Flood
Reflectors, and normal adjacencies to other clients and L2 nodes Reflectors and to build normal adjacencies to other clients and L2
not participating in flood reflection. nodes not participating in flood reflection.
Flood Reflector Adjacency: Flood Reflector Adjacency:
IS-IS L2 adjacency where one end is a Flood Reflector Client and IS-IS L2 adjacency where one end is a Flood Reflector Client, and
the other a Flood Reflector, and the two have the same Flood the other, a Flood Reflector. Both have the same Flood Reflector
Reflector Cluster ID. Cluster ID.
Flood Reflector Cluster: Flood Reflector Cluster:
Collection of clients and flood reflectors configured with the Collection of clients and flood reflectors configured with the
same cluster identifier. same cluster identifier.
Tunnel-Based Deployment: Tunnel-Based Deployment:
Deployment where Flood Reflector Clients build a partial or full Deployment where Flood Reflector Clients build a partial or full
mesh of tunnels in L1 to "shortcut" forwarding of L2 traffic mesh of tunnels in L1 to "shortcut" forwarding of L2 traffic
through the cluster. through the cluster.
No-Tunnel Deployment: No-Tunnel Deployment:
Deployment where Flood Reflector Clients redistribute L2 Deployment where Flood Reflector Clients redistribute L2
reachability into L1 to allow forwarding through the cluster reachability into L1 to allow forwarding through the cluster
without underlying tunnels. without underlying tunnels.
Tunnel Endpoint: Tunnel Endpoint:
An endpoint that allows the establishment of a bi-directional An endpoint that allows the establishment of a bidirectional
tunnel carrying IS-IS control traffic or alternately, serves as tunnel carrying IS-IS control traffic or, alternately, serves as
the origin of such a tunnel. the origin of such a tunnel.
L1 shortcut: L1 shortcut:
A tunnel between two clients visible in L1 only that is used as a A tunnel established between two clients that is visible in L1
next-hop, i.e. to carry data traffic in tunnel-based deployment only and is used as a next hop, i.e., to carry data traffic in
mode. tunnel-based deployment mode.
Hot-Potato Routing: Hot-Potato Routing:
In context of this document, a routing paradigm where L2->L1 In the context of this document, a routing paradigm where L2->L1
routes are less preferred than L2 routes [RFC5302]. routes are less preferred than L2 routes [RFC5302].
2.2. 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.
3. Further Details 3. Further Details
Several considerations should be noted in relation to such a flood Several considerations should be noted in relation to such a flood
reflection mechanism. reflection mechanism.
First, this allows multi-area IS-IS deployments to scale without any First, the flood reflection mechanism allows multi-area IS-IS
major modifications in the IS-IS implementation on most of the nodes deployments to scale without any major modifications in the IS-IS
deployed in the network. Unmodified (traditional) L2 routers will implementation on most of the nodes deployed in the network.
compute reachability across the transit L1 area using the flood Unmodified (standard) L2 routers will compute reachability across the
reflector adjacencies. transit L1 area using the flood reflector adjacencies. (In this
document, the term "standard" refers to IS-IS as specified in
[ISO10589].)
Second, the flood reflectors are not required to participate in Second, the flood reflectors are not required to participate in
forwarding traffic through the L1 transit area. These flood forwarding traffic through the L1 transit area. These flood
reflectors can be hosted on virtual devices outside the forwarding reflectors can be hosted on virtual devices outside the forwarding
topology. topology.
Third, astute readers will realize that flooding reflection may cause Third, astute readers will realize that flooding reflection may cause
the use of suboptimal paths. This is similar to the BGP route the use of suboptimal paths. This is similar to the BGP route
reflection suboptimal routing problem described in reflection suboptimal routing problem described in [RFC9107]. The L2
[ID.draft-ietf-idr-bgp-optimal-route-reflection-28]. The L2 computation determines the egress L1/L2 and, with that, can create
computation determines the egress L1/L2 and with that can create illusions of ECMP where there is none; and in certain scenarios, the
illusions of ECMP where there is none, and in certain scenarios lead L2 computation can lead to an L1/L2 egress that is not globally
to an L1/L2 egress which is not globally optimal. This represents a optimal. This represents a straightforward instance of the trade-off
straightforward instance of the trade-off between the amount of between the amount of control plane state and the optimal use of
control plane state and the optimal use of paths through the network paths through the network that are often encountered when aggregating
often encountered when aggregating routing information. routing information.
One possible solution to this problem is to expose additional One possible solution to this problem is to expose additional
topology information into the L2 flooding domains. In the example topology information into the L2 flooding domains. In the example
network given, links from router R10 to router R11 can be exposed network given, links from router R10 to router R11 can be exposed
into L2 even when R10 and R11 are participating in flood reflection. into L2 even when R10 and R11 are participating in flood reflection.
This information would allow the L2 nodes to build 'shortcuts' when This information would allow the L2 nodes to build "shortcuts" when
the L2 flood reflected part of the topology looks more expensive to the L2 flood-reflected part of the topology looks more expensive to
cross distance wise. cross distance-wise.
Another possible variation is for an implementation to approximate Another possible variation is for an implementation to use the tunnel
with the tunnel cost the cost of the underlying topology. cost to approximate the cost of the underlying topology.
Redundancy can be achieved by configuring multiple flood reflectors Redundancy can be achieved by configuring multiple flood reflectors
in a L1 area. Multiple flood reflectors do not need any in an L1 area. Multiple flood reflectors do not need any
synchronization mechanisms amongst themselves, except standard IS-IS synchronization mechanisms amongst themselves, except standard IS-IS
flooding and database maintenance procedures. flooding and database maintenance procedures.
4. Encodings 4. Encodings
4.1. Flood Reflection TLV 4.1. Flood Reflection TLV
The Flood Reflection TLV is a top-level TLV that MUST appear in L2 The Flood Reflection TLV is a top-level TLV that MUST appear in L2
IIHs on all Flood Reflection Adjacencies. The Flood Reflection TLV IIHs (IS-IS Hello) on all Flood Reflection Adjacencies. The Flood
indicates the flood reflector cluster (based on Flood Reflection Reflection TLV indicates the flood reflector cluster (based on Flood
Cluster ID) that a given router is configured to participate in. It Reflection Cluster ID) that a given router is configured to
also indicates whether the router is configured to play the role of participate in. It also indicates whether the router is configured
either flood reflector or flood reflector client. The Flood to play the role of either flood reflector or flood reflector client.
Reflection Cluster ID and flood reflector roles advertised in the The Flood Reflection Cluster ID and flood reflector roles advertised
IIHs are used to ensure that flood reflector adjacencies are only in the IIHs are used to ensure that flood reflector adjacencies are
formed between a flood reflector and flood reflector client, and that only formed between a flood reflector and flood reflector client and
the Flood Reflection Cluster IDs match. The Flood Reflection TLV has that the Flood Reflection Cluster IDs match. The Flood Reflection
the following format: TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |C| RESERVED | | Type | Length |C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flood Reflection Cluster ID | | Flood Reflection Cluster ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs ... | Sub-TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 161 Type: 161
Length: The length, in octets, of the following fields. Length: The length, in octets, of the following fields.
C (Client): This bit is set to indicate that the router acts as a C (Client): This bit is set to indicate that the router acts as a
flood reflector client. When this bit is NOT set, the router acts flood reflector client. When this bit is NOT set, the router acts
as a flood reflector. On a given router, the same value of the as a flood reflector. On a given router, the same value of the
C-bit MUST be advertised across all interfaces advertising the C-bit MUST be advertised across all interfaces advertising the
Flood Reflection TLV in IIHs. Flood Reflection TLV in IIHs.
RESERVED: This field is reserved for future use. It MUST be set to Reserved: This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received. 0 when sent and MUST be ignored when received.
Flood Reflection Cluster ID: Flood Reflection Cluster Identifier. Flood Reflection Cluster ID: The same arbitrary 32-bit value MUST be
The same arbitrary 32-bit value MUST be assigned to all of the assigned to all of the flood reflectors and flood reflector
flood reflectors and flood reflector clients in the same L1 area. clients in the same L1 area. The value MUST be unique across
The value MUST be unique across different L1 areas within the IGP different L1 areas within the IGP domain. In case of violation of
domain. In case of violation of those rules multiple L1 areas may those rules, multiple L1 areas may become a single cluster, or a
become a single cluster or a single area may split in flood single area may split in flood reflection sense, and several
reflection sense and several mechanisms such as auto-discovery of mechanisms, such as auto-discovery of tunnels, may not work
tunnels may not work correctly. On a given router, the same value correctly. On a given router, the same value of the Flood
of the Flood Reflection Cluster ID MUST be advertised across all Reflection Cluster ID MUST be advertised across all interfaces
interfaces advertising the Flood Reflection TLV in IIHs. When a advertising the Flood Reflection TLV in IIHs. When a router
router discovers that a node is using more than a single Cluster discovers that a node is using more than a single Cluster IDs
IDs based on its advertised TLVs and IIHs, the node MAY log such based on its advertised TLVs and IIHs, the node MAY log such
violations subject to rate limiting. This implies that a flood violations subject to rate-limiting. This implies that a flood
reflector MUST NOT participate in more than a single L1 area. In reflector MUST NOT participate in more than a single L1 area. In
case of Cluster ID value of 0, the TLV containing it MUST be case of Cluster ID value of 0, the TLV containing it MUST be
ignored. ignored.
Sub-TLVs: Optional sub-TLVs. For future extensibility, the format Sub-TLVs (Optional Sub-TLVs): For future extensibility, the format
of the Flood Reflection TLV allows for the possibility of of the Flood Reflection TLV allows for the possibility of
including optional sub-TLVs. No sub-TLVs of the Flood Reflection including optional sub-TLVs. No sub-TLVs of the Flood Reflection
TLV are defined in this document. TLV are defined in this document.
The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. The Flood Reflection TLV SHOULD NOT appear more than once in an IIH.
A router receiving one or more Flood Reflection TLVs in the same IIH A router receiving one or more Flood Reflection TLVs in the same IIH
MUST use the values in the first TLV and it SHOULD log such MUST use the values in the first TLV, and it SHOULD log such
violations subject to rate limiting. violations subject to rate-limiting.
4.2. Flood Reflection Discovery Sub-TLV 4.2. Flood Reflection Discovery Sub-TLV
The Flood Reflection Discovery sub-TLV is advertised as a sub-TLV of The Flood Reflection Discovery sub-TLV is advertised as a sub-TLV of
the IS-IS Router Capability TLV-242, defined in [RFC7981]. The Flood the IS-IS Router Capability TLV 242, defined in [RFC7981]. The Flood
Reflection Discovery sub-TLV is advertised in L1 and L2 LSPs with Reflection Discovery sub-TLV is advertised in L1 and L2 LSPs with
area flooding scope in order to enable the auto-discovery of flood area flooding scope in order to enable the auto-discovery of flood
reflection capabilities. The Flood Reflection Discovery sub-TLV has reflection capabilities. The Flood Reflection Discovery sub-TLV has
the following format: the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 |C| Reserved | | Type | Length |C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 21 skipping to change at line 538
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 161 Type: 161
Length: The length, in octets, of the following fields. Length: The length, in octets, of the following fields.
C (Client): This bit is set to indicate that the router acts as a C (Client): This bit is set to indicate that the router acts as a
flood reflector client. When this bit is NOT set, the router acts flood reflector client. When this bit is NOT set, the router acts
as a flood reflector. as a flood reflector.
RESERVED: This field is reserved for future use. It MUST be set to Reserved: This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received. 0 when sent and MUST be ignored when received.
Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier
is the same as that defined in the Flood Reflection TLV and obeys is the same as that defined in the Flood Reflection TLV in
the same rules. Section 4.1 and obeys the same rules.
The Flood Reflection Discovery sub-TLV SHOULD NOT appear more than The Flood Reflection Discovery sub-TLV SHOULD NOT appear more than
once in TLV 242. A router receiving one or more Flood Reflection once in TLV 242. A router receiving one or more Flood Reflection
Discovery sub-TLVs in TLV 242 MUST use the values in the first sub- Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-
TLV of the lowest numbered fragment and it SHOULD log such violations TLV of the lowest numbered fragment, and it SHOULD log such
subject to rate limiting. violations subject to rate-limiting.
4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV 4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV
Flood Reflection Discovery Tunnel Type sub-sub-TLV is advertised Flood Reflection Discovery Tunnel Type sub-sub-TLV is advertised
optionally as a sub-sub-TLV of the Flood Reflection Discovery Sub- optionally as a sub-sub-TLV of the Flood Reflection Discovery Sub-
TLV, defined in Section 4.2. It allows the automatic creation of L2 TLV, defined in Section 4.2. It allows the automatic creation of L2
tunnels to be used as flood reflector adjacencies and L1 shortcut tunnels to be used as flood reflector adjacencies and L1 shortcut
tunnels. The Flood Reflection Tunnel Type sub-sub-TLV has the tunnels. The Flood Reflection Tunnel Type sub-sub-TLV has the
following format: following format:
skipping to change at page 13, line 4 skipping to change at line 569
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 | Reserved |F| | Type | Length | Reserved |F|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Encapsulation Attribute | | Tunnel Encapsulation Attribute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 161 Type: 161
Length: The length, in octets, of zero or more of the following Length: The length, in octets, of zero or more of the following
fields. fields.
Reserved: SHOULD be 0 on transmission and MUST be ignored on Reserved: SHOULD be 0 on transmission and MUST be ignored on
reception. reception.
F Flag: When set indicates flood reflection tunnel endpoint, when F Flag: When set, indicates flood reflection tunnel endpoint. When
clear, indicates possible L1 shortcut tunnel endpoint. clear, indicates possible L1 shortcut tunnel endpoint.
Tunnel Encapsulation Attribute: Carries encapsulation type and Tunnel Encapsulation Attribute: Carries encapsulation type and
further attributes necessary for tunnel establishment as defined further attributes necessary for tunnel establishment as defined
in [RFC9012]. In context of this attribute the protocol Type sub- in [RFC9012]. In context of this attribute, the protocol Type
TLV as defined in [RFC9012] MAY be included to ensure proper sub-TLV as defined in [RFC9012] MAY be included to ensure proper
encapsulation of IS-IS frames. In case such a sub-TLV is included encapsulation of IS-IS frames. In case such a sub-TLV is included
and the F flag is set (i.e. the resulting tunnel is a flood and the F flag is set (i.e., the resulting tunnel is a flood
reflector adjacency) this sub-TLV MUST include a type that allows reflector adjacency), this sub-TLV MUST include a type that allows
to carry encapsulated IS-IS frames. Furthermore, such tunnel type to carry encapsulated IS-IS frames. Furthermore, such tunnel type
MUST be able to transport IS-IS frames of size up to MUST be able to transport IS-IS frames of size up to
`originatingL2LSPBufferSize`. "originatingL2LSPBufferSize".
A flood reflector receiving Flood Reflection Discovery Tunnel Type A flood reflector receiving Flood Reflection Discovery Tunnel Type
sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F flag set sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F flag set
(i.e. the resulting tunnel is a flood reflector adjacency) SHOULD use (i.e., the resulting tunnel is a flood reflector adjacency) SHOULD
one or more of the specified tunnel endpoints to automatically use one or more of the specified tunnel endpoints to automatically
establish one or more tunnels that will serve as flood reflection establish one or more tunnels that will serve as a flood reflection
adjacency(-ies) to the clients advertising the endpoints. adjacency and/or adjacencies to the clients advertising the
endpoints.
A flood reflection client receiving one or more Flood Reflection A flood reflection client receiving one or more Flood Reflection
Discovery Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub- Discovery Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-
TLV with F flag clear (i.e. the resulting tunnel is used to support TLV with F flag clear (i.e., the resulting tunnel is used to support
tunnel-based mode) from other leaves MAY use one or more of the tunnel-based mode) from other leaves MAY use one or more of the
specified tunnel endpoints to automatically establish one or more specified tunnel endpoints to automatically establish one or more
tunnels that will serve as L1 tunnel shortcuts to the clients tunnels that will serve as L1 tunnel shortcuts to the clients
advertising the endpoints. advertising the endpoints.
In case of automatic flood reflection adjacency tunnels and in case In case of automatic flood reflection adjacency tunnels and in case
IS-IS adjacencies are being formed across L1 shortcuts all the IS-IS adjacencies are being formed across L1 shortcuts, all the
aforementioned rules in Section 4.5 apply as well. aforementioned rules in Section 4.5 apply as well.
Optional address validation procedures as defined in [RFC9012] MUST Optional address validation procedures as defined in [RFC9012] MUST
be disregarded. be disregarded.
It remains to be observed that automatic tunnel discovery is an It remains to be observed that automatic tunnel discovery is an
optional part of the specification and can be replaced or mixed with optional part of the specification and can be replaced or mixed with
statically configured tunnels for either flood reflector adjacencies statically configured tunnels for flood reflector adjacencies and
and/or tunnel-based shortcuts. Specific implementation details how tunnel-based shortcuts. Specific implementation details how both
both mechanisms interact are specific to an implementation and mode mechanisms interact are specific to an implementation and mode of
of operation and are outside the scope of this document. operation and are outside the scope of this document.
Flood reflector adjacencies rely on IS-IS L2 liveliness procedures. Flood reflector adjacencies rely on IS-IS L2 liveliness procedures.
In case of L1 shortcuts the mechanism used to ensure liveliness and In case of L1 shortcuts, the mechanism used to ensure liveliness and
tunnel integrity are outside the scope of this document. tunnel integrity are outside the scope of this document.
4.4. Flood Reflection Adjacency Sub-TLV 4.4. Flood Reflection Adjacency Sub-TLV
The Flood Reflection Adjacency sub-TLV is advertised as a sub-TLV of The Flood Reflection Adjacency sub-TLV is advertised as a sub-TLV of
TLVs 22, 23, 25, 141, 222, and 223 (the "TLVs Advertising Neighbor TLVs 22, 23, 25, 141, 222, and 223 (the "TLVs Advertising Neighbor
Information"). Its presence indicates that a given adjacency is a Information"). Its presence indicates that a given adjacency is a
flood reflector adjacency. It is included in L2 area scope flooded flood reflector adjacency. It is included in L2 area scope flooded
LSPs. The Flood Reflection Adjacency sub-TLV has the following LSPs. The Flood Reflection Adjacency sub-TLV has the following
format: format:
skipping to change at page 14, line 34 skipping to change at line 649
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 161 Type: 161
Length: The length, in octets, of the following fields. Length: The length, in octets, of the following fields.
C (Client): This bit is set to indicate that the router advertising C (Client): This bit is set to indicate that the router advertising
this adjacency is a flood reflector client. When this bit is NOT this adjacency is a flood reflector client. When this bit is NOT
set, the router advertising this adjacency is a flood reflector. set, the router advertising this adjacency is a flood reflector.
RESERVED: This field is reserved for future use. It MUST be set to Reserved: This field is reserved for future use. It MUST be set to
0 when sent and MUST be ignored when received. 0 when sent and MUST be ignored when received.
Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier
is the same as that defined in the Flood Reflection TLV and obeys is the same as that defined in the Flood Reflection TLV in
the same rules. Section 4.1 and obeys the same rules.
The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than
once in a given TLV. A router receiving one or more Flood Reflection once in a given TLV. A router receiving one or more Flood Reflection
Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV
of the lowest numbered fragment and it SHOULD log such violations of the lowest numbered fragment, and it SHOULD log such violations
subject to rate limiting. subject to rate-limiting.
4.5. Flood Reflection Discovery 4.5. Flood Reflection Discovery
A router participating in flood reflection as client or reflector A router participating in flood reflection as client or reflector
MUST be configured as an L1/L2 router. It MAY originate the Flood MUST be configured as an L1/L2 router. It MAY originate the Flood
Reflection Discovery sub-TLV with area flooding scope in L1 and L2. Reflection Discovery sub-TLV with area flooding scope in L1 and L2.
Normally, all routers on the edge of the L1 area (those having Normally, all routers on the edge of the L1 area (those having
traditional L2 adjacencies) will advertise themselves as flood standard L2 adjacencies) will advertise themselves as flood reflector
reflector clients. Therefore, a flood reflector client will have clients. Therefore, a flood reflector client will have both standard
both traditional L2 adjacencies and flood reflector L2 adjacencies. L2 adjacencies and flood reflector L2 adjacencies.
A router acting as a flood reflector MUST NOT form any traditional L2 A router acting as a flood reflector MUST NOT form any standard L2
adjacencies except with flood reflector clients. It will be an L1/L2 adjacencies except with flood reflector clients. It will be an L1/L2
router only by virtue of having flood reflector L2 adjacencies. A router only by virtue of having flood reflector L2 adjacencies. A
router desiring to act as a flood reflector MAY advertise itself as router desiring to act as a flood reflector MAY advertise itself as
such using the Flood Reflection Discovery sub-TLV in L1 and L2. such using the Flood Reflection Discovery sub-TLV in L1 and L2.
A given flood reflector or flood reflector client can only A given flood reflector or flood reflector client can only
participate in a single cluster, as determined by the value of its participate in a single cluster, as determined by the value of its
Flood Reflection Cluster ID and should disregard other routers' TLVs Flood Reflection Cluster ID and should disregard other routers' TLVs
for flood reflection purposes if the cluster ID is not matching. for flood reflection purposes if the cluster ID is not matching.
Upon reception of Flood Reflection Discovery sub-TLVs, a router Upon reception of Flood Reflection Discovery sub-TLVs, a router
acting as flood reflector SHOULD initiate a tunnel towards each flood acting as flood reflector SHOULD initiate a tunnel towards each flood
reflector client with which it shares a Flood Reflection Cluster ID reflector client with which it shares a Flood Reflection Cluster ID,
using one or more of the tunnel encapsulations provided with F flag using one or more of the tunnel encapsulations provided with F flag
is set. The L2 adjacencies formed over such tunnels MUST be marked is set. The L2 adjacencies formed over such tunnels MUST be marked
as flood reflector adjacencies. If the client or reflector has a as flood reflector adjacencies. If the client or reflector has a
direct L2 adjacency with the according remote side it SHOULD use it direct L2 adjacency with the according remote side, it SHOULD use it
instead of instantiating a tunnel. instead of instantiating a tunnel.
In case the optional auto-discovery mechanism is not implemented or In case the optional auto-discovery mechanism is not implemented or
enabled a deployment MAY use statically configured tunnels to create enabled, a deployment MAY use statically configured tunnels to create
flood reflection adjacencies. flood reflection adjacencies.
The IS-IS metrics for all flood reflection adjacencies in a cluster The IS-IS metrics for all flood reflection adjacencies in a cluster
SHOULD be identical. SHOULD be identical.
Upon reception of Flood Reflection Discovery TLVs, a router acting as Upon reception of Flood Reflection Discovery TLVs, a router acting as
a flood reflector client MAY initiate tunnels with L1-only a flood reflector client MAY initiate tunnels with L1-only
adjacencies towards any of the other flood reflector clients with adjacencies towards any of the other flood reflector clients with
lower router IDs in its cluster using encapsulations with F flag lower router IDs in its cluster using encapsulations with F flag
clear. These tunnels MAY be used for forwarding to improve the load- clear. These tunnels MAY be used for forwarding to improve the load-
balancing characteristics of the L1 area. If the clients have a balancing characteristics of the L1 area. If the clients have a
direct L2 adjacency they SHOULD use it instead of instantiating a new direct L2 adjacency, they SHOULD use it instead of instantiating a
tunnel. new tunnel.
4.6. Flood Reflection Adjacency Formation 4.6. Flood Reflection Adjacency Formation
In order to simplify implementation complexity, this document does In order to simplify implementation complexity, this document does
not allow the formation of complex hierarchies of flood reflectors not allow the formation of complex hierarchies of flood reflectors
and clients or allow multiple clusters in a single L1 area. and clients or allow multiple clusters in a single L1 area.
Consequently, all flood reflectors and flood reflector clients in the Consequently, all flood reflectors and flood reflector clients in the
same L1 area MUST share the same Flood Reflector Cluster ID. same L1 area MUST share the same Flood Reflector Cluster ID.
Deployment of multiple cluster IDs in the same L1 area are outside Deployment of multiple cluster IDs in the same L1 area are outside
the scope of this document. the scope of this document.
A flood reflector MUST NOT form flood reflection adjacencies with A flood reflector MUST NOT form flood reflection adjacencies with
flood reflector clients with a different Cluster ID. A flood flood reflector clients with a different Cluster ID. A flood
reflector MUST NOT form any traditional L2 adjacencies. reflector MUST NOT form any standard L2 adjacencies.
Flood reflector clients MUST NOT form flood reflection adjacencies Flood reflector clients MUST NOT form flood reflection adjacencies
with flood reflectors with a different Cluster ID. with flood reflectors with a different Cluster ID.
Flood reflector clients MAY form traditional L2 adjacencies with Flood reflector clients MAY form standard L2 adjacencies with flood
flood reflector clients or nodes not participating in flood reflector clients or nodes not participating in flood reflection.
reflection. When two flood reflector clients form a traditional L2 When two flood reflector clients form a standard L2 adjacency, the
adjacency the Cluster IDs are disregarded. Cluster IDs are disregarded.
The Flood Reflector Cluster ID and flood reflector roles advertised The Flood Reflector Cluster ID and flood reflector roles advertised
in the Flood Reflection TLVs in IIHs are used to ensure that flood in the Flood Reflection TLVs in IIHs are used to ensure that flood
reflection adjacencies that are established meet the above criteria. reflection adjacencies that are established meet the above criteria.
On change in either flood reflection role or cluster ID on IIH on the On change in either flood reflection role or cluster ID on IIH on the
local or remote side the adjacency has to be reset. It is then re- local or remote side, the adjacency has to be reset. It is then re-
established if possible. established if possible.
Once a flood reflection adjacency is established, the flood reflector Once a flood reflection adjacency is established, the flood reflector
and the flood reflector client MUST advertise the adjacency by and the flood reflector client MUST advertise the adjacency by
including the Flood Reflection Adjacency Sub-TLV in the Extended IS including the Flood Reflection Adjacency Sub-TLV in the Extended IS
reachability TLV or MT-ISN TLV. reachability TLV or Multi-Topology Intermediate System Neighbor (MT-
ISN) TLV.
5. Route Computation 5. Route Computation
To ensure loop-free routing, the flood reflection client MUST follow To ensure loop-free routing, the flood reflection client MUST follow
the normal L2 computation to determine L2 routes. This is because the normal L2 computation to determine L2 routes. This is because
nodes outside the L1 area will generally not be aware that flood nodes outside the L1 area will generally not be aware that flood
reflection is being performed. The flood reflection clients need to reflection is being performed. The flood reflection clients need to
produce the same result for the L2 route computation as a router not produce the same result for the L2 route computation as a router not
participating in flood reflection. participating in flood reflection.
5.1. Tunnel-Based Deployment 5.1. Tunnel-Based Deployment
In the tunnel-based option the reflection client, after L2 and L1 In the tunnel-based option, the reflection client, after L2 and L1
computation, MUST examine all L2 routes with flood reflector next-hop computation, MUST examine all L2 routes with flood reflector next-hop
adjacencies. Such next-hops must be replaced by the corresponding adjacencies. Such next hops must be replaced by the corresponding
tunnel next-hops to the correct egress nodes of the flood reflection tunnel next hops to the correct egress nodes of the flood reflection
cluster. cluster.
5.2. No-Tunnel Deployment 5.2. No-Tunnel Deployment
In case of deployment without underlying tunnels, the necessary L2 In case of deployment without underlying tunnels, the necessary L2
routes are distributed into the area, normally as L2->L1 routes. Due routes are distributed into the area, normally as L2->L1 routes. Due
to the rules in Section 4.6 the computation in the resulting topology to the rules in Section 4.6, the computation in the resulting
is relatively simple, the L2 SPF from a flood reflector client is topology is relatively simple: the L2 SPF from a flood reflector
guaranteed to reach the Flood Reflector within a single hop, and in client is guaranteed to reach the Flood Reflector within a single
the following hop the L2 egress to which it has a forwarding tunnel. hop, and in the following hop, it is guaranteed to reach the L2
All the flood reflector tunnel nexthops in the according L2 route can egress to which it has a forwarding tunnel. All the flood reflector
hence be removed and if the L2 route has no other ECMP L2 nexthops, tunnel next hops in the according L2 route can hence be removed, and
the L2 route MUST be suppressed in the RIB by some means to allow the if the L2 route has no other ECMP L2 next hops, the L2 route MUST be
less preferred L2->L1 route to be used to forward traffic towards the suppressed in the RIB by some means to allow the less preferred
advertising egress. L2->L1 route to be used to forward traffic towards the advertising
egress.
In the particular case the client has L2 routes which are not flood In the particular case the client has L2 routes which are not flood
reflected, those will be naturally preferred (such routes normally reflected, those will be naturally preferred (such routes normally
"hot-potato" packets out of the L1 area). However in the case the L2 "hot-potato" packets out of the L1 area). However, in the case the
route through the flood reflector egress is "shorter" than such L2 route through the flood reflector egress is "shorter" than such
present non flood reflected L2 routes, the node SHOULD ensure that present L2 routes that are not flood reflected, the node SHOULD
such routes are suppressed so the L2->L1 towards the egress still ensure that such routes are suppressed so the L2->L1 towards the
takes preference. Observe that operationally this can be resolved in egress still takes preference. Observe that operationally this can
a relatively simple way by configuring flood reflector adjacencies to be resolved in a relatively simple way by configuring flood reflector
have a high metric, i.e. the flood reflector topology becomes "last adjacencies to have a high metric, i.e., the flood reflector topology
resort" and the leaves will try to "hot-potato" out the area as fast becomes "last resort," and the leaves will try to "hot-potato" out
as possible which is normally the desirable behavior. the area as fast as possible, which is normally the desirable
behavior.
In No-tunnel deployment all L1/L2 edge nodes MUST be flood reflection In no-tunnel deployment, all L1/L2 edge nodes MUST be flood
clients. reflection clients.
6. Redistribution of Prefixes 6. Redistribution of Prefixes
In case of no-tunnel deployment per Section 5.2 a client that does In case of no-tunnel deployment per Section 5.2, a client that does
not have any L2 flood reflector adjacencies MUST NOT redistribute L2 not have any L2 flood reflector adjacencies MUST NOT redistribute L2
routes into the cluster. routes into the cluster.
The L2 prefix advertisements redistributed into an L1 that contains The L2 prefix advertisements redistributed into an L1 that contains
flood reflectors SHOULD be normally limited to L2 intra-area routes flood reflectors SHOULD be normally limited to L2 intra-area routes
(as defined in [RFC7775]), if the information exists to distinguish (as defined in [RFC7775]) if the information exists to distinguish
them from other L2 prefix advertisements. them from other L2 prefix advertisements.
On the other hand, in topologies that make use of flood reflection to On the other hand, in topologies that make use of flood reflection to
hide the structure of L1 areas while still providing transit hide the structure of L1 areas while still providing transit-
forwarding across them using tunnels, we generally do not need to forwarding across them using tunnels, we generally do not need to
redistribute L1 prefix advertisements into L2. redistribute L1 prefix advertisements into L2.
7. Special Considerations 7. Special Considerations
In pathological cases setting the overload bit in L1 (but not in L2) In pathological cases, setting the overload bit in L1 (but not in L2)
can partition L1 forwarding, while allowing L2 reachability through can partition L1 forwarding, while allowing L2 reachability through
flood reflector adjacencies to exist. In such a case a node cannot flood reflector adjacencies to exist. In such a case, a node cannot
replace a route through a flood reflector adjacency with a L1 replace a route through a flood reflector adjacency with an L1
shortcut and the client MAY use the L2 tunnel to the flood reflector shortcut, and the client MAY use the L2 tunnel to the flood reflector
for forwarding but in any case it MUST initiate an alarm and declare for forwarding. In all those cases, the node MUST initiate an alarm
misconfiguration. and declare misconfiguration.
A flood reflector with directly L2 attached prefixes should advertise A flood reflector with directly L2 attached prefixes should advertise
those in L1 as well since based on preference of L1 routes the those in L1 as well since, based on preference of L1 routes, the
clients will not try to use the L2 flood reflector adjacency to route clients will not try to use the L2 flood reflector adjacency to route
the packet towards them. A very unlikely corner case can occur when the packet towards them. A very unlikely corner case can occur when
the flood reflector is reachable via L2 flood reflector adjacency the flood reflector is reachable via L2 flood reflector adjacency
(due to underlying L1 partition) exclusively, in which case the (due to underlying L1 partition) exclusively. In this instance, the
client can use the L2 tunnel to the flood reflector for forwarding client can use the L2 tunnel to the flood reflector for forwarding
towards those prefixes while it MUST initiate an alarm and declare towards those prefixes while it MUST initiate an alarm and declare
misconfiguration. misconfiguration.
A flood reflector MUST NOT set the attached bit on its LSPs. A flood reflector MUST NOT set the attached bit on its LSPs.
In certain cases where reflectors are attached to same broadcast In certain cases where reflectors are attached to the same broadcast
medium, and where some other L2 router, which is neither a flood medium, and where some other L2 router that is neither a flood
reflector nor a flood reflector client (a "non-FR router"), attaches reflector nor a flood reflector client (a "non-FR router", i.e., a
to the same broadcast medium, flooding between the reflectors in router not participating in flood reflection) attaches to the same
question might not succeed, potentially partitioning the flood broadcast medium, flooding between the reflectors in question might
reflection domain. This could happen specifically in the event that not succeed, potentially partitioning the flood reflection domain.
the non-FR router is chosen as the designated intermediate system This could happen specifically in the event that the non-FR router is
("DIS", the designated router). Since, per Section 4.6, a flood chosen as the Designated Intermediate System (DIS) -- the designated
reflector MUST NOT form an adjacency with a non-FR router, the flood router. Since, per Section 4.6, a flood reflector MUST NOT form an
reflector(s) will not be represented in the pseudo-node. adjacency with a non-FR router, the flood reflector(s) will not be
represented in the pseudo-node.
To avoid this situation, it is RECOMMENDED that flood reflectors not To avoid this situation, it is RECOMMENDED that flood reflectors not
be deployed on the same broadcast medium as non-FR routers. be deployed on the same broadcast medium as non-FR routers.
A router discovering such condition MUST initiate an alarm and A router discovering such condition MUST initiate an alarm and
declare misconfiguration. declare misconfiguration.
8. IANA Considerations 8. IANA Considerations
This document requests allocation for the following IS-IS TLVs and IANA has assigned the following IS-IS TLVs and sub-TLVs and has
Sub-TLVs, and requests creation of a new registry. created a new registry.
8.1. New IS-IS TLV Codepoint 8.1. New IS-IS TLV Codepoint
This document requests the following IS-IS TLV under the IS-IS Top- The following IS-IS TLV has been registered in the "IS-IS Top-Level
Level TLV Codepoints registry:: TLV Codepoints" registry:
Value Name IIH LSP SNP Purge +=======+==================+=====+=====+=====+=======+
----- --------------------------------- --- --- --- ----- | Value | Name | IIH | LSP | SNP | Purge |
161 Flood Reflection y n n n +=======+==================+=====+=====+=====+=======+
| 161 | Flood Reflection | y | n | n | n |
+-------+------------------+-----+-----+-----+-------+
8.2. Sub TLVs for IS-IS Router CAPABILITY TLV Table 1: Flood Reflection IS-IS TLV Codepoint
This document request the following registration in the "sub-TLVs for 8.2. Sub-TLVs for IS-IS Router CAPABILITY TLV
IS-IS Router CAPABILITY TLV" registry.
Type Description The following has been registered in the "IS-IS Sub-TLVs for IS-IS
---- ----------- Router CAPABILITY TLV" registry:
161 Flood Reflection Discovery
8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV +======+============================+
| Type | Description |
+======+============================+
| 161 | Flood Reflection Discovery |
+------+----------------------------+
This document requests creation of a new registry named "Sub-sub TLVs Table 2: IS-IS Router CAPABILITY TLV
for Flood Reflection Discovery sub-TLV" under the "IS-IS TLV
Codepoints" grouping. The Registration Procedures for this registry 8.3. Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV
are Expert Review, following the common expert review guidance given
IANA has created a new registry named "IS-IS Sub-Sub-TLVs for Flood
Reflection Discovery Sub-TLV" under the "IS-IS TLV Codepoints"
grouping. The registration procedure for this registry is Expert
Review [RFC8126], following the common expert review guidance given
for the grouping. for the grouping.
The range of values in this registry is 0-255. The registry should The range of values in this registry is 0-255. The registry contains
be seeded with the following initial registration: the following initial registration:
Type Description +======+===========================================================+
---- ----------- | Type | Description |
161 Flood Reflection Discovery Tunnel Encapsulation Attribute +======+===========================================================+
| 161 | Flood Reflection Discovery Tunnel Encapsulation Attribute |
+------+-----------------------------------------------------------+
8.4. Sub TLVs for TLVs Advertising Neighbor Information Table 3: IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV
This document requests the following registration in the "IS-IS Sub- 8.4. Sub-TLVs for TLVs Advertising Neighbor Information
TLVs for TLVs Advertising Neighbor Information" registry.
Type Description 22 23 25 141 222 223 The following has been registered in the "IS-IS Sub-TLVs for TLVs
---- -------------------------------- --- --- --- --- --- --- Advertising Neighbor Information" registry;
161 Flood Reflector Adjacency y y n y y y
+======+===========================+====+====+====+=====+=====+=====+
| Type | Description | 22 | 23 | 25 | 141 | 222 | 223 |
+======+===========================+====+====+====+=====+=====+=====+
| 161 | Flood Reflector | y | y | n | y | y | y |
| | Adjacency | | | | | | |
+------+---------------------------+----+----+----+-----+-----+-----+
Table 4: IS-IS Sub-TLVs for TLVs Advertising Neighbor Information
9. Security Considerations 9. Security Considerations
This document uses flood reflection tunnels to carry IS-IS control This document uses flood reflection tunnels to carry IS-IS control
traffic. If an attacker can inject traffic into such a tunnel, the traffic. If an attacker can inject traffic into such a tunnel, the
consequences could be in the most extreme case the complete consequences could be (in the most extreme case) the complete
subversion of the IS-IS level 2 information. Therefore, a mechanism subversion of the IS-IS Level 2 information. Therefore, a mechanism
inherent to the tunnel technology should be taken to prevent such inherent to the tunnel technology should be used to prevent such
injection. Since the available security procedures will vary by injection. Since the available security procedures will vary by
deployment and tunnel type, the details of securing tunnels are deployment and tunnel type, the details of securing tunnels are
beyond the scope of this document. beyond the scope of this document.
This document specifies information used to form dynamically This document specifies information used to form dynamically
discovered shortcut tunnels. If an attacker were able to hijack the discovered shortcut tunnels. If an attacker were able to hijack the
endpoint of such a tunnel and form an adjacency, it could divert endpoint of such a tunnel and form an adjacency, it could divert
short-cut traffic to itself, placing itself on-path and facilitating shortcut traffic to itself, placing itself on-path and facilitating
on-path attacks or could even completely subvert the IS-IS level 2 on-path attacks, or it could even completely subvert the IS-IS Level
routing. Therefore, steps should be taken to prevent such capture by 2 routing. Therefore, steps should be taken to prevent such capture
using mechanism inherent to the tunnel type used. Since the by using mechanism inherent to the tunnel type used. Since the
available security procedures will vary by deployment and tunnel available security procedures will vary by deployment and tunnel
type, the details of securing tunnels are beyond the scope of this type, the details of securing tunnels are beyond the scope of this
document. document.
Additionally, the usual IS-IS security mechanisms [RFC5304] SHOULD be Additionally, the usual IS-IS security mechanisms [RFC5304] SHOULD be
deployed to prevent misrepresentation of routing information by an deployed to prevent misrepresentation of routing information by an
attacker in case a tunnel is compromised if the tunnel itself does attacker in case a tunnel is compromised and the tunnel itself does
not provide mechanisms strong enough guaranteeing the integrity of not provide mechanisms strong enough to guarantee the integrity of
the messages exchanged. the messages exchanged.
10. Acknowledgements 10. References
The authors thank Shraddha Hegde, Peter Psenak, Acee Lindem, Robert
Raszuk and Les Ginsberg for their thorough review and detailed
discussions. Thanks are also extended to Michael Richardson for an
excellent routing directorate review. John Scudder ultimately spent
significant time helping to make the document more comprehensible and
coherent.
11. References
11.1. Informative References
[ID.draft-ietf-idr-bgp-optimal-route-reflection-28]
Raszuk et al., R., "BGP Optimal Route Reflection", July
2019, <https://www.ietf.org/id/draft-ietf-idr-bgp-optimal-
route-reflection-28.txt>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF 10.1. Normative References
Topology-Transparent Zone", RFC 8099,
DOI 10.17487/RFC8099, February 2017,
<https://www.rfc-editor.org/info/rfc8099>.
11.2. 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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
Distribution with Two-Level IS-IS", RFC 5302, Distribution with Two-Level IS-IS", RFC 5302,
DOI 10.17487/RFC5302, October 2008, DOI 10.17487/RFC5302, October 2008,
<https://www.rfc-editor.org/info/rfc5302>. <https://www.rfc-editor.org/info/rfc5302>.
skipping to change at page 21, line 46 skipping to change at line 975
[RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route [RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route
Preference for Extended IP and IPv6 Reachability", Preference for Extended IP and IPv6 Reachability",
RFC 7775, DOI 10.17487/RFC7775, February 2016, RFC 7775, DOI 10.17487/RFC7775, February 2016,
<https://www.rfc-editor.org/info/rfc7775>. <https://www.rfc-editor.org/info/rfc7775>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981, for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016, DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>. <https://www.rfc-editor.org/info/rfc7981>.
[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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012, "The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021, DOI 10.17487/RFC9012, April 2021,
<https://www.rfc-editor.org/info/rfc9012>. <https://www.rfc-editor.org/info/rfc9012>.
10.2. Informative References
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>.
[RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF
Topology-Transparent Zone", RFC 8099,
DOI 10.17487/RFC8099, February 2017,
<https://www.rfc-editor.org/info/rfc8099>.
[RFC9107] Raszuk, R., Ed., Decraene, B., Ed., Cassar, C., Åman, E.,
and K. Wang, "BGP Optimal Route Reflection (BGP ORR)",
RFC 9107, DOI 10.17487/RFC9107, August 2021,
<https://www.rfc-editor.org/info/rfc9107>.
Acknowledgements
The authors thank Shraddha Hegde, Peter Psenak, Acee Lindem, Robert
Raszuk, and Les Ginsberg for their thorough review and detailed
discussions. Thanks are also extended to Michael Richardson for an
excellent routing directorate review. John Scudder ultimately spent
significant time helping to make the document more comprehensible and
coherent.
Authors' Addresses Authors' Addresses
Tony Przygienda (editor) Tony Przygienda (editor)
Juniper Juniper
1137 Innovation Way 1137 Innovation Way
Sunnyvale, CA Sunnyvale, CA
United States of America United States of America
Email: prz@juniper.net Email: prz@juniper.net
Chris Bowers Chris Bowers
Juniper Individual
1137 Innovation Way Email: chrisbowers.ietf@gmail.com
Sunnyvale, CA
United States of America
Email: cbowers@juniper.net
Yiu Lee Yiu Lee
Comcast Comcast
1800 Bishops Gate Blvd 1800 Bishops Gate Blvd
Mount Laurel, NJ 08054 Mount Laurel, NJ 08054
United States of America United States of America
Email: Yiu_Lee@comcast.com Email: Yiu_Lee@comcast.com
Alankar Sharma Alankar Sharma
Individual Individual
 End of changes. 112 change blocks. 
345 lines changed or deleted 391 lines changed or added

This html diff was produced by rfcdiff 1.48.