< draft-ietf-lsr-isis-flood-reflection-05.txt   draft-ietf-lsr-isis-flood-reflection-06.txt >
Network Working Group A. Przygienda, Ed. Network Working Group A. Przygienda, Ed.
Internet-Draft C. Bowers Internet-Draft C. Bowers
Intended status: Experimental Juniper Intended status: Experimental Juniper
Expires: 26 May 2022 Y. Lee Expires: 30 May 2022 Y. Lee
A. Sharma A. Sharma
Comcast Comcast
R. White R. White
Juniper Juniper
22 November 2021 26 November 2021
IS-IS Flood Reflection IS-IS Flood Reflection
draft-ietf-lsr-isis-flood-reflection-05 draft-ietf-lsr-isis-flood-reflection-06
Abstract Abstract
This document describes a backwards compatible, optional ISIS This document describes a backwards 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 allows topologies in which L1 areas topologies. Flood reflection allows topologies in which L1 areas
provide transit forwarding for L2 using all available L1 nodes provide transit forwarding for L2 using all available L1 nodes
internally. It accomplishes this by creating L2 flood reflection internally. It accomplishes this by creating L2 flood reflection
adjacencies within each L1 area. Those adjacencies are used to flood adjacencies within each L1 area. Those adjacencies are used to flood
L2 LSPDUs, and they are used in the L2 SPF computation. However, L2 LSPDUs, and they are used in the L2 SPF computation. However,
they are not used for forwarding within the flood reflection cluster. they are not used for forwarding within the flood reflection cluster.
This arrangement gives the L2 topology significantly better scaling This arrangement gives the L2 topology significantly better scaling
properties. As additional benefit, only those routers directly properties. As additional benefit, only those routers directly
participating in flood reflection have to support the feature. This participating in flood reflection have to support the feature. This
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 May 2022. This Internet-Draft will expire on 30 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Further Details . . . . . . . . . . . . . . . . . . . . . . . 8 3. Further Details . . . . . . . . . . . . . . . . . . . . . . . 8
4. Flood Reflection TLV . . . . . . . . . . . . . . . . . . . . 9 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Flood Reflection Discovery Sub-TLV . . . . . . . . . . . . . 10 4.1. Flood Reflection TLV . . . . . . . . . . . . . . . . . . 9
6. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV . . . . . 11 4.2. Flood Reflection Discovery Sub-TLV . . . . . . . . . . . 11
7. Flood Reflection Adjacency Sub-TLV . . . . . . . . . . . . . 12 4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV . . . 12
8. Flood Reflection Discovery . . . . . . . . . . . . . . . . . 13 4.4. Flood Reflection Adjacency Sub-TLV . . . . . . . . . . . 13
9. Flood Reflection Adjacency Formation . . . . . . . . . . . . 14 4.5. Flood Reflection Discovery . . . . . . . . . . . . . . . 14
10. Route Computation . . . . . . . . . . . . . . . . . . . . . . 14 4.6. Flood Reflection Adjacency Formation . . . . . . . . . . 15
10.1. Tunnel Based Deployment . . . . . . . . . . . . . . . . 15 5. Route Computation . . . . . . . . . . . . . . . . . . . . . . 15
10.2. No Tunnel Deployment . . . . . . . . . . . . . . . . . . 15 5.1. Tunnel Based Deployment . . . . . . . . . . . . . . . . . 16
11. Redistribution of Prefixes . . . . . . . . . . . . . . . . . 15 5.2. No Tunnel Deployment . . . . . . . . . . . . . . . . . . 16
12. Special Considerations . . . . . . . . . . . . . . . . . . . 16 6. Redistribution of Prefixes . . . . . . . . . . . . . . . . . 16
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Special Considerations . . . . . . . . . . . . . . . . . . . 17
13.1. New IS-IS TLV Codepoint . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
13.2. Sub TLVs for TLV 242 . . . . . . . . . . . . . . . . . . 17 8.1. New IS-IS TLV Codepoint . . . . . . . . . . . . . . . . . 17
13.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV . . 17 8.2. Sub TLVs for TLV 242 . . . . . . . . . . . . . . . . . . 18
13.4. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223 . . . . . 17 8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV . . . 18
14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8.4. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223 . . . . . 18
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
16.1. Informative References . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
16.2. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 11.2. Normative References . . . . . . . . . . . . . . . . . . 19
1. Glossary
This section is introduced first with the intention of allowing quick
reference later in the document to terms introduced
Flood Reflector:
Node configured to connect L2 only to flood reflector clients and
reflect (reflood) ISIS L2 LSPs amongst them.
Flood Reflector Client:
Node configured to build flood reflector adjacencies and normal L2
nodes.
Flood Reflector Adjacency:
ISIS L2 adjacency limited by one end being client and the other
reflector and agreeing on the same Flood Reflector Cluster ID.
Flood Reflector Cluster:
Collection of clients and flood reflectors configured with the
same cluster identifier. Cluster ID value of 0 SHOULD NOT be used
since it may be used in the future for special purposes.
Tunnel Deployment: Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Deployment where flood reflector clients build a full mesh of
tunnels in L1 to "shortcut" forwarding of L2 traffic through the
cluster.
No Tunnel Deployment: 1. Introduction
Deployment where flood reflector clients redistribute L2
reachability into L1 to allow forwarding through the cluster
without underlying tunnels.
2. Description This section introduces the problem space and outlines the solution.
Some of the terms may be unfamiliar to reader without extensive IS-IS
background and in such case a glossary is provided in Section 2 and
can be referenced.
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 back-offs, 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.
skipping to change at page 4, line 41 skipping to change at page 4, line 32
| +---------------+ | | | | | | | | | +---------------+ | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | +--------------+ | +-----------------+ | | | +--------------+ | +-----------------+ |
| | | | | | | | | | | | | | | | | | | | | | | | | |
+----+ ++-+--+-+ | | +------+---+---+-----+ | | | ++-----++ +----+ +----+ ++-+--+-+ | | +------+---+---+-----+ | | | ++-----++ +----+
| R3 | | R12 | +----------| R22 | | +----+ R32 | | R6 | | R3 | | R12 | +----------| R22 | | +----+ R32 | | R6 |
| L2 +--+ L1/L2 | +--------| L1 +-------+ | | L1/L2 +--+ L2 | | L2 +--+ L1/L2 | +--------| L1 +-------+ | | L1/L2 +--+ L2 |
| | | +------------+ |---------------+ | | | | | | +------------+ |---------------+ | | |
+----+ +-------+ +-------+-------------+ +-------+ +----+ +----+ +-------+ +-------+-------------+ +-------+ +----+
Figure 1: Example topology Figure 1: Example Topology of L1 with L2 Borders
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 separate L2 flooding domains into a single one, triggering again
maximum L2 scale limitation we try to address in first place. maximum L2 scale limitation we try to address in first place.
A more effective solution would allow to reduce the number of links A more effective solution would allow to reduce the number of links
and routers exposed in L2, while still utilizing the full L1 topology and routers exposed in L2, while still utilizing the full L1 topology
when forwarding through the network. 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 ISIS 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 scale of the topology. The topology in Figure 1 has 6 L1/ limits the scale of the topology. The topology in Figure 1 has 6 L1/
L2 nodes. Figure 2 illustrates a full mesh of L2 adjacencies between L2 nodes. Figure 2 illustrates a full mesh of L2 adjacencies between
the 6 L1/L2 nodes, resulting in (5 * 6)/2 = 15 L2 adjacencies. In a the 6 L1/L2 nodes, resulting in (5 * 6)/2 = 15 L2 adjacencies. In a
somewhat larger topology containing 20 L1/L2 nodes, the number of L2 somewhat larger topology containing 20 L1/L2 nodes, the number of L2
adjacencies in a full mesh rises to 190. adjacencies in a full 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 7, line 8 skipping to change at page 6, line 45
| 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 LSPDUs. At the same
time, R20 and R22 remain L1-only routers. L1-only routers and time, R20 and R22 in Figure 1 remain L1-only routers. L1-only
L1-only links are not visible in L2. In this manner, the flood routers and L1-only links are not visible in L2. In this manner, the
reflector allows us provide L2 control plane connectivity in a flood reflector allows us provide L2 control plane connectivity in a
scalable manner. scalable manner.
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 ISIS 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. R20 and R22 in Figure 1.
Hence, some new functionality is necessary to allow the L1/L2 edge Hence, some new functionality is necessary 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 to be built that use
the entire forwarding capacity of the L1 areas, while at the same the entire forwarding capacity of the L1 areas, while at the same
time introducing control plane scaling benefits provided by L2 flood time introducing control plane scaling benefits provided by L2 flood
skipping to change at page 7, line 42 skipping to change at page 7, line 34
reflector deployment: reflector deployment:
* A 'flood reflector adjacency' for all the adjacencies built for * A 'flood reflector adjacency' for all the adjacencies built for
the purpose of reflecting flooding information. This allows these the purpose of reflecting flooding information. This allows these
'flood reflectors' to participate in the IS-IS control plane 'flood reflectors' to participate in the IS-IS control plane
without being used in the forwarding plane. This is a purely without being used in the forwarding plane. This is a purely
local operation on the L1/L2 ingress; it does not require local operation on the L1/L2 ingress; it does not require
replacing or modifying any routers not involved in the reflection replacing or modifying any routers not involved in the reflection
process. Deployment-wise, it is far less tricky to just upgrade process. Deployment-wise, 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 on the whole ISIS domain. day on the whole IS-IS domain.
* An (optional) full mesh of tunnels between the L1/L2 routers, * An (optional) full mesh of tunnels between the L1/L2 routers,
ideally load-balancing across all available L1 links. This ideally load-balancing across all available L1 links. This
harnesses all forwarding paths between the L1/L2 edge nodes harnesses all forwarding paths between the L1/L2 edge nodes
without injecting unneeded state into the L2 flooding domain or without injecting unneeded state into the L2 flooding domain or
creating 'choke points' at the 'flood reflectors' themselves. The creating 'choke points' at the 'flood reflectors' themselves. The
draft is agnostic as to the tunneling technology used but provides draft is agnostic as to the tunneling technology used but provides
enough information for automatic establishment of such tunnels. enough information for automatic establishment of such tunnels.
The discussion of ISIS adjacency formation and/or liveness The discussion of IS-IS adjacency formation and/or liveness
discovery on such tunnels is outside the scope of this draft and discovery on such tunnels is outside the scope of this draft and
is largely choice of the underlying implementation. A solution is largely choice of the underlying implementation. A solution
without tunnels is also possible by applying judicious scoping of without tunnels is also possible by applying judicious scoping of
reachability information between the levels as described in more reachability information between the levels as described in more
details later. details later.
* Some way to support reflector redundancy, and potentially some way * Some way to support reflector redundancy, and potentially some way
to auto-discover and advertise such adjacencies as flood reflector to auto-discover and advertise such adjacencies as flood reflector
adjacencies. Such advertisements may allow L2 nodes outside the adjacencies. Such advertisements may allow L2 nodes outside the
L1 to perform optimizations in the future based on this L1 to perform optimizations in the future based on this
information. information.
2. Glossary
This section is introduced with the intention of allowing quick
reference in the more detailed parts of the document to terms used
Flood Reflector:
Node configured to connect L2 only to flood reflector clients and
reflect (reflood) IS-IS L2 LSPs amongst them.
Flood Reflector Client:
Node configured to build flood reflector adjacencies and normal L2
nodes.
Flood Reflector Adjacency:
IS-IS L2 adjacency limited by one end being client and the other
reflector and agreeing on the same Flood Reflector Cluster ID.
Flood Reflector Cluster:
Collection of clients and flood reflectors configured with the
same cluster identifier. Cluster ID value of 0 SHOULD NOT be used
since it may be used in the future for special purposes.
Tunnel Deployment:
Deployment where flood reflector clients build a full mesh of
tunnels in L1 to "shortcut" forwarding of L2 traffic through the
cluster.
No Tunnel Deployment:
Deployment where flood reflector clients redistribute L2
reachability into L1 to allow forwarding through the cluster
without underlying tunnels.
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, this allows multi-area IS-IS deployments to scale without any
major modifications in the IS-IS implementation on most of the nodes major modifications in the IS-IS implementation on most of the nodes
deployed in the network. Unmodified (traditional) L2 routers will deployed in the network. Unmodified (traditional) L2 routers will
compute reachability across the transit L1 area using the flood compute reachability across the transit L1 area using the flood
reflector adjacencies. reflector adjacencies.
skipping to change at page 9, line 7 skipping to change at page 9, line 34
L2 even when 01 and 02 are participating in flood reflection. This L2 even when 01 and 02 are participating in flood reflection. This
information would allow the L2 nodes to build 'shortcuts' when the L2 information would allow the L2 nodes to build 'shortcuts' when the L2
flood reflected part of the topology looks more expensive to cross flood reflected part of the topology looks more expensive to cross
distance wise. distance wise.
Another possible variation is for an implementation to approximate Another possible variation is for an implementation to approximate
with the tunnel cost the cost of the underlying topology. with the tunnel cost the cost of the underlying topology.
Redundancy can be achieved by building multiple flood reflectors in a Redundancy can be achieved by building multiple flood reflectors in a
L1 area. Multiple flood reflectors do not need any synchronization L1 area. Multiple flood reflectors do not need any synchronization
mechanisms amongst themselves, except standard ISIS flooding and mechanisms amongst themselves, except standard IS-IS flooding and
database maintenance procedures. database maintenance procedures.
4. Flood Reflection TLV 4. Encodings
4.1. Flood Reflection TLV
The Flood Reflection TLV is a new top-level TLV that MAY appear in L2 The Flood Reflection TLV is a new top-level TLV that MAY appear in L2
IIHs. The Flood Reflection TLV indicates the flood reflector cluster IIHs. The Flood Reflection TLV indicates the flood reflector cluster
(based on Flood Reflection Cluster ID) that a given router is (based on Flood Reflection Cluster ID) that a given router is
configured to participate in. It also indicates whether the router configured to participate in. It also indicates whether the router
is configured to play the role of either flood reflector or flood is configured to play the role of either flood reflector or flood
reflector client. The Flood Reflection Cluster ID and flood reflector client. The Flood Reflection Cluster ID and flood
reflector roles advertised in the IIHs are used to ensure that flood reflector roles advertised in the IIHs are used to ensure that flood
reflector adjacencies are only formed between a flood reflector and reflector adjacencies are only formed between a flood reflector and
flood reflector client, and that the Flood Reflection Cluster IDs flood reflector client, and that the Flood Reflection Cluster IDs
skipping to change at page 9, line 50 skipping to change at page 10, line 32
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: Flood Reflection Cluster Identifier.
These same 32-bit value MUST be assigned to all of the flood These same 32-bit value MUST be assigned to all of the flood
reflectors and flood reflector clients in the same L1 area. The reflectors and flood reflector clients in the same L1 area. The
value MUST be unique across different L1 areas within the IGP value MUST be unique across different L1 areas within the IGP
domain. On a given router, the same value of the Flood Reflection domain. In case of violation of those rules multiple L1 areas may
Cluster ID MUST be advertised across all interfaces advertising become a single cluster or a single area may split in flood
the Flood Reflection TLV in IIHs. This implies that a flood reflection sense and several mechanisms such as auto-discovery of
reflector can participate in a single L1 area only. In case of tunnels may not work correctly. On a given router, the same value
Cluster ID value of 0, the TLV MUST be ignored. of the Flood Reflection Cluster ID MUST be advertised across all
interfaces advertising the Flood Reflection TLV in IIHs. When a
router discovers that a node is using multiple Cluster IDs based
on its advertised TLVs and IIHs, the node MAY adequately log such
violations subject to rate limiting. This implies that a flood
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
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 multiple Flood Reflection TLVs in the same IIH A router receiving multiple Flood Reflection TLVs in the same IIH
MUST use the values in the first TLV and it SHOULD adequately log MUST use the values in the first TLV and it SHOULD adequately log
such violations subject to rate limiting. such violations subject to rate limiting.
5. Flood Reflection Discovery Sub-TLV 4.2. Flood Reflection Discovery Sub-TLV
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 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
skipping to change at page 11, line 11 skipping to change at page 12, line 5
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 and obeys
the same rules. 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 multiple Flood Reflection once in TLV 242. A router receiving multiple 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 and it SHOULD adequately log such violations subject to rate TLV and it SHOULD adequately log such violations subject to rate
limiting. limiting.
6. 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 5. 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:
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 |
skipping to change at page 11, line 42 skipping to change at page 12, line 36
Reserved: SHOULD be 0 on transmission and ignored on reception. Reserved: SHOULD be 0 on transmission and ignored on 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]. Protocol type sub-TLV as defined in [RFC9012] MAY in [RFC9012]. Protocol type sub-TLV as defined in [RFC9012] MAY
be included but MUST when F flag is set include according type be included but MUST when F flag is set include according type
that allows carrying of encapsulated ISIS frames. Such tunnel that allows carrying of encapsulated IS-IS frames. Such tunnel
type MUST provide according mechanisms to carry up to type MUST provide according mechanisms to carry up to
`originatingL2LSPBufferSize` sized ISIS frames across. `originatingL2LSPBufferSize` sized IS-IS frames across.
A flood reflector receiving multiple Flood Reflection Discovery A flood reflector receiving multiple Flood Reflection Discovery
Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F
flag set SHOULD use one or more of the specified tunnel endpoints to flag set SHOULD use one or more of the specified tunnel endpoints to
automatically establish one or more tunnels that will serve as flood automatically establish one or more tunnels that will serve as flood
reflection adjacency(-ies). reflection adjacency(-ies).
A flood reflection client receiving multiple Flood Reflection A flood reflection client receiving multiple 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 from other leaves MAY use one or more of the TLV with F flag clear 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. tunnels that will serve as L1 tunnel shortcuts.
Optional address validation procedures as defined in [RFC9012] MUST Optional address validation procedures as defined in [RFC9012] MUST
be disregarded. be disregarded.
7. 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. Its presence indicates that a TLVs 22, 23, 25, 141, 222, and 223. Its presence indicates that a
given adjacency is a flood reflector adjacency. It is included in L2 given adjacency is a flood reflector adjacency. It is included in L2
area scope flooded LSPs. Flood Reflection Adjacency sub-TLV has the area scope flooded LSPs. Flood Reflection Adjacency sub-TLV has the
following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 5 skipping to change at page 14, line 5
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 and obeys
the same rules. 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 multiple Flood Reflection once in a given TLV. A router receiving multiple 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
and it SHOULD adequately log such violations subject to rate and it SHOULD adequately log such violations subject to rate
limiting. limiting.
8. Flood Reflection Discovery 4.5. Flood Reflection Discovery
A router participating in flood reflection MUST be configured as an A router participating in flood reflection as client or reflector
L1/L2 router. It SHOULD originate the Flood Reflection Discovery MUST be configured as an L1/L2 router. It SHOULD originate the Flood
sub-TLV with area flooding scope in L1 and L2. Normally, all routers Reflection Discovery sub-TLV with area flooding scope in L1 and L2.
on the edge of the L1 area (those having traditional L2 adjacencies) Normally, all routers on the edge of the L1 area (those having
will advertise themselves as route reflector clients. Therefore, a traditional L2 adjacencies) will advertise themselves as route
flood reflector client will have both traditional L2 adjacencies and reflector clients. Therefore, a flood reflector client will have
flood reflector L2 adjacencies. both traditional L2 adjacencies and flood reflector L2 adjacencies.
A router acting as a flood reflector MUST NOT have any traditional L2 A router acting as a flood reflector MUST NOT have any traditional L2
adjacencies. It will be an L1/L2 router only by virtue of having adjacencies. It will be an L1/L2 router only by virtue of having
flood reflector L2 adjacencies. A router desiring to act as a flood flood reflector L2 adjacencies. A router desiring to act as a flood
reflector will advertise itself as such using the Flood Reflection reflector SHOULD advertise itself as such using the Flood Reflection
Discovery sub-TLV in L1 and L2. 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 client SHOULD initiate a tunnel towards acting as flood reflector client SHOULD initiate a tunnel towards
each flood reflector with which it shares an Flood Reflection Cluster each flood reflector with which it shares an Flood Reflection Cluster
ID using one or more of the tunnel encapsulations provided with F ID using one or more of the tunnel encapsulations provided with F
flag being set. The L2 adjacencies formed over such tunnels MUST be flag being set. The L2 adjacencies formed over such tunnels MUST be
marked as flood reflector adjacencies. If the client or reflector marked as flood reflector adjacencies. If the client or reflector
has a direct L2 adjacency with the according remote side it SHOULD has a direct L2 adjacency with the according remote side it SHOULD
use it instead of instantiating a new tunnel. use it instead of instantiating a new tunnel.
In absence of auto-discovery an implementation MAY use statically In absence of auto-discovery an implementation MAY use statically
configured tunnels to create flood reflection adjacencies. configured tunnels to create flood reflection adjacencies.
The ISIS metrics for all flood reflection adjacencies in a cluster The IS-IS metrics for all flood reflection adjacencies in a cluster
SHOULD be uniform. SHOULD be uniform.
Upon reception of Flood Reflection Discover TLVs, a router acting as Upon reception of Flood Reflection Discover 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 new
tunnel. tunnel.
9. Flood Reflection Adjacency Formation 4.6. Flood Reflection Adjacency Formation
In order to simplify both implementations and network deployments, In order to simplify both implementations and network deployments,
this draft does not allow the formation of complex hierarchies of this draft does not allow the formation of complex hierarchies of
flood reflectors and clients or allow multiple clusters in a single flood reflectors and clients or allow multiple clusters in a single
L1 area. Consequently, all flood reflectors and flood reflector L1 area. Consequently, all flood reflectors and flood reflector
clients in the same L1 area MUST share the same Flood Reflector clients in the same L1 area MUST share the same Flood Reflector
Cluster ID. Cluster ID. Deployment of multiple cluster IDs in the same L1 area
are outside the scope of this document.
A flood reflector MUST only form flood reflection adjacencies with A flood reflector MUST only form flood reflection adjacencies with
flood reflector clients with matching Cluster ID. A flood reflector flood reflector clients with matching Cluster ID. A flood reflector
MUST NOT form any traditional L2 adjacencies. MUST NOT form any traditional L2 adjacencies.
Flood reflector clients MUST only form flood reflection adjacencies Flood reflector clients MUST only form flood reflection adjacencies
with flood reflectors with matching Cluster ID. with flood reflectors with matching Cluster ID.
Flood reflector clients MAY form traditional L2 adjacencies with Flood reflector clients MAY form traditional L2 adjacencies with
flood reflector clients or nodes not participating in flood flood reflector clients or nodes not participating in flood
skipping to change at page 14, line 39 skipping to change at page 15, line 40
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 and re-established local or remote side the adjacency has to be reset and re-established
if possible. 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 MT-ISN TLV.
10. Route Computation 5. Route Computation
To ensure loop-free routing, the route reflection client MUST follow To ensure loop-free routing, the route 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.
10.1. Tunnel Based Deployment 5.1. Tunnel Based Deployment
In tunnel based option the reflection client, after L2 and L1 In tunnel based option the reflection client, after L2 and L1
computation, MUST examine all L2 routes and replace all flood computation, MUST examine all L2 routes and replace all flood
reflector adjacencies with the correct underlying tunnel next-hop to reflector adjacencies with the correct underlying tunnel next-hop to
the egress. the egress.
10.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 9 the computation in the resulting topology to the rules in Section 4.6 the computation in the resulting topology
is relatively simple, the L2 SPF from a flood reflector client is is relatively simple, the L2 SPF from a flood reflector client is
guaranteed to reach within a hop the Flood Reflector and in the guaranteed to reach within a hop the Flood Reflector and in the
following hop the L2 egress to which it has a forwarding tunnel following hop the L2 egress to which it has a forwarding tunnel
again. All the flood reflector tunnel nexthops in the according L2 again. All the flood reflector tunnel nexthops in the according L2
route can hence be removed and if the L2 route has no other ECMP L2 route can hence be removed and if the L2 route has no other ECMP L2
nexthops, the L2 route MUST be suppressed in the RIB by some means to nexthops, the L2 route MUST be suppressed in the RIB by some means to
allow the less preferred L2->L1 route to be used to forward traffic allow the less preferred L2->L1 route to be used to forward traffic
towards the advertising egress. towards the advertising egress.
In the particular case the client has L2 routes which are not route In the particular case the client has L2 routes which are not route
skipping to change at page 15, line 42 skipping to change at page 16, line 42
preference. Observe that operationally this can be resolved in a preference. Observe that operationally this can be resolved in a
relatively simple way by configuring flood reflector adjacencies to relatively simple way by configuring flood reflector adjacencies to
have a high metric, i.e. the flood reflector topology becomes "last have a high metric, i.e. the flood reflector topology becomes "last
resort" and the leaves will try to "hot-potato" out the area as fast resort" and the leaves will try to "hot-potato" out the area as fast
as possible which is normally the desirable behavior. as possible which is normally the desirable behavior.
In deployment scenarios where tunnels are not used, all L1/L2 edge In deployment scenarios where tunnels are not used, all L1/L2 edge
nodes MUST be ultimately flood reflector clients except during during nodes MUST be ultimately flood reflector clients except during during
transition phase. transition phase.
11. Redistribution of Prefixes 6. Redistribution of Prefixes
When L2 prefixes need to be redistributed into L1 by the route When L2 prefixes need to be redistributed into L1 by the route
reflector clients a client that does not have any L2 flood reflector reflector clients a client that does not have any L2 flood reflector
adjacencies MUST NOT redistribute those routes into the area in case adjacencies MUST NOT redistribute those routes into the area in case
of application of Section 10.2. The L2 prefixes advertisements of application of Section 5.2. The L2 prefixes advertisements
redistributed into L1 with flood reflectors SHOULD be normally redistributed into L1 with flood reflectors SHOULD be normally
limited to L2 intra-area routes (as defined in [RFC7775]), if the limited to L2 intra-area routes (as defined in [RFC7775]), if the
information exists to distinguish them from other other L2 prefix information exists to distinguish them from other other L2 prefix
advertisements. 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 prefixes advertisements into L2. redistribute L1 prefixes advertisements into L2.
12. 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 a L1
shortcut and the client can use the L2 tunnel to the flood reflector shortcut and the client can use the L2 tunnel to the flood reflector
for forwarding while it MUST initiate an alarm and declare for forwarding while it MUST initiate an alarm and declare
misconfiguration. misconfiguration.
A flood reflector with directly L2 attached prefixes should advertise A flood reflector with directly L2 attached prefixes should advertise
skipping to change at page 16, line 43 skipping to change at page 17, line 43
the L2 prefixes with a 'third-party' next-hop but that would have the L2 prefixes with a 'third-party' next-hop but that would have
less desirable convergence properties than the solution proposed and less desirable convergence properties than the solution proposed and
force a fork-lift of all L2 routers to make sure they disregard such force a fork-lift of all L2 routers to make sure they disregard such
prefixes unless in the same L1 domain as the Flood Reflector. prefixes unless in the same L1 domain as the Flood Reflector.
Depending on pseudo-node choice in case of a broadcast domain with Depending on pseudo-node choice in case of a broadcast domain with
multiple flood reflectors attached this can lead to a partitioned LAN multiple flood reflectors attached this can lead to a partitioned LAN
and hence a router discovering such a condition MUST initiate an and hence a router discovering such a condition MUST initiate an
alarm and declare misconfiguration. alarm and declare misconfiguration.
13. IANA Considerations 8. IANA Considerations
This document requests allocation for the following IS-IS TLVs and This document requests allocation for the following IS-IS TLVs and
Sub-TLVs. Sub-TLVs.
13.1. New IS-IS TLV Codepoint 8.1. New IS-IS TLV Codepoint
This document requests the following IS-IS TLV: This document requests the following IS-IS TLV:
Value Name IIH LSP SNP Purge Value Name IIH LSP SNP Purge
----- --------------------------------- --- --- --- ----- ----- --------------------------------- --- --- --- -----
TBD1 Flood Reflection y n n n TBD1 Flood Reflection y n n n
Suggested value for TBD1 is 161. Suggested value for TBD1 is 161.
13.2. Sub TLVs for TLV 242 8.2. Sub TLVs for TLV 242
This document request the following registration in the "sub-TLVs for This document request the following registration in the "sub-TLVs for
TLV 242" registry. TLV 242" registry.
Type Description Type Description
---- ----------- ---- -----------
TBD2 Flood Reflection Discovery TBD2 Flood Reflection Discovery
Suggested value for TBD2 is 161. Suggested value for TBD2 is 161.
13.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV 8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV
This document request the following registration in the "sub-sub-TLVs This document request the following registration in the "sub-sub-TLVs
for Flood Reflection Discovery sub-TLV" registry. for Flood Reflection Discovery sub-TLV" registry.
Type Description Type Description
---- ----------- ---- -----------
TBD3 Flood Reflection Discovery Tunnel Encapsulation Attribute TBD3 Flood Reflection Discovery Tunnel Encapsulation Attribute
Suggested value for TBD3 is 161. Suggested value for TBD3 is 161.
13.4. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223 8.4. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223
This document requests the following registration in the "sub-TLVs This document requests the following registration in the "sub-TLVs
for TLV 22, 23, 25, 141, 222, and 223" registry. for TLV 22, 23, 25, 141, 222, and 223" registry.
Type Description 22 23 25 141 222 223 Type Description 22 23 25 141 222 223
---- -------------------------------- --- --- --- --- --- --- ---- -------------------------------- --- --- --- --- --- ---
TBD4 Flood Reflector Adjacency y y n y y y TBD4 Flood Reflector Adjacency y y n y y y
Suggested value for TBD4 is 161. Suggested value for TBD4 is 161.
14. Security Considerations 9. Security Considerations
This document introduces no new security concerns to ISIS or other This document introduces tunnels carrying IS-IS control traffic via
specifications referenced in this document. tunnels. In case of statically configured tunnels a deployment
SHOULD provide enough security protection to prevent malicious
attackers from using the tunnel endpoints. For information used to
form dynamically discovered tunnels, it SHOULD be protected by the
the deployed IS-IS security mechanism preventing malicious nodes from
spoofing rogue information on behalf of other members.
15. Acknowledgements 10. Acknowledgements
The authors thank Shraddha Hegde, Peter Psenak, Acee Lindem and Les The authors thank Shraddha Hegde, Peter Psenak, Acee Lindem and Les
Ginsberg for their thorough review and detailed discussions. Ginsberg for their thorough review and detailed discussions. Thanks
are also extended to Michael Richardson for an excellent routing
directorate review.
16. References 11. References
16.1. Informative References 11.1. Informative References
[ID.draft-ietf-idr-bgp-optimal-route-reflection-28] [ID.draft-ietf-idr-bgp-optimal-route-reflection-28]
Raszuk et al., R., "BGP Optimal Route Reflection", July Raszuk et al., R., "BGP Optimal Route Reflection", July
2019, <https://www.ietf.org/id/draft-ietf-idr-bgp-optimal- 2019, <https://www.ietf.org/id/draft-ietf-idr-bgp-optimal-
route-reflection-28.txt>. route-reflection-28.txt>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
skipping to change at page 18, line 34 skipping to change at page 19, line 46
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>. <https://www.rfc-editor.org/info/rfc4456>.
[RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF
Topology-Transparent Zone", RFC 8099, Topology-Transparent Zone", RFC 8099,
DOI 10.17487/RFC8099, February 2017, DOI 10.17487/RFC8099, February 2017,
<https://www.rfc-editor.org/info/rfc8099>. <https://www.rfc-editor.org/info/rfc8099>.
16.2. Normative References 11.2. Normative References
[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>.
[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>.
 End of changes. 52 change blocks. 
114 lines changed or deleted 138 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/