rfc9377.original.xml | rfc9377.xml | |||
---|---|---|---|---|
<?xml version='1.0' encoding='utf-8'?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<!DOCTYPE rfc [ | <!DOCTYPE rfc [ | |||
<!ENTITY nbsp " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<?rfc toc="yes"?> | ||||
<?rfc tocompact="yes"?> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" | |||
<?rfc tocdepth="3"?> | exp" consensus="true" docName="draft-ietf-lsr-isis-flood-reflection-12" number=" | |||
<?rfc tocindent="yes"?> | 9377" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" | |||
<?rfc symrefs="yes"?> | tocDepth="3" symRefs="true" sortRefs="true" version="3"> | |||
<?rfc sortrefs="yes"?> | ||||
<?rfc comments="no"?> | ||||
<?rfc inline="yes"?> | ||||
<?rfc compact="yes"?> | ||||
<?rfc subcompact="no"?> | ||||
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" docName="draft-ie | ||||
tf-lsr-isis-flood-reflection-12" ipr="trust200902" obsoletes="" | ||||
submissionType="IETF" updates="" xml:lang="en" tocInclude="true" tocDepth=" | ||||
3" symRefs="true" sortRefs="true" version="3"> | ||||
<!-- xml2rfc v2v3 conversion 3.9.1 --> | <!-- xml2rfc v2v3 conversion 3.9.1 --> | |||
<front> | <front> | |||
<title abbrev="draft-ietf-lsr-isis-flood-reflection"> | <title abbrev="IS-IS Flood Reflection"> | |||
IS-IS Flood Reflection | IS-IS Flood Reflection | |||
</title> | </title> | |||
<seriesInfo name="Internet-Draft" value="draft-ietf-lsr-isis-flood-reflectio | <seriesInfo name="RFC" value="9377"/> | |||
n-12"/> | <author fullname="Tony Przygienda" initials="T." surname="Przygienda" role=" | |||
<author fullname="Tony Przygienda" initials="A." surname="Przygienda" role=" | editor"> | |||
editor"> | ||||
<organization>Juniper</organization> | <organization>Juniper</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>1137 Innovation Way | <street>1137 Innovation Way</street> | |||
</street> | ||||
<city>Sunnyvale</city> | <city>Sunnyvale</city> | |||
<region>CA | <region>CA</region> | |||
</region> | ||||
<code/> | <code/> | |||
<country>USA | <country>United States of America</country> | |||
</country> | ||||
</postal> | </postal> | |||
<phone/> | <phone/> | |||
<email>prz@juniper.net | <email>prz@juniper.net</email> | |||
</email> | ||||
<uri/> | <uri/> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Chris Bowers" initials="C." surname="Bowers"> | <author fullname="Chris Bowers" initials="C." surname="Bowers"> | |||
<organization>Juniper</organization> | <organization>Individual</organization> | |||
<address> | <address> | |||
<postal> | <email>chrisbowers.ietf@gmail.com | |||
<street>1137 Innovation Way | ||||
</street> | ||||
<city>Sunnyvale</city> | ||||
<region>CA | ||||
</region> | ||||
<code/> | ||||
<country>USA | ||||
</country> | ||||
</postal> | ||||
<phone/> | ||||
<email>cbowers@juniper.net | ||||
</email> | </email> | |||
<uri/> | ||||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Yiu Lee" initials="Y" surname="Lee"> | <author fullname="Yiu Lee" initials="Y" surname="Lee"> | |||
<organization>Comcast</organization> | <organization>Comcast</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>1800 Bishops Gate Blvd</street> | <street>1800 Bishops Gate Blvd</street> | |||
<city>Mount Laurel</city> | <city>Mount Laurel</city> | |||
<region>NJ</region> | <region>NJ</region> | |||
<code>08054</code> | <code>08054</code> | |||
<country>US</country> | <country>United States of America</country> | |||
</postal> | </postal> | |||
<email>Yiu_Lee@comcast.com</email> | <email>Yiu_Lee@comcast.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Alankar Sharma" initials="A" surname="Sharma"> | <author fullname="Alankar Sharma" initials="A" surname="Sharma"> | |||
<organization>Individual</organization> | <organization>Individual</organization> | |||
<address> | <address> | |||
<email>as3957@gmail.com</email> | <email>as3957@gmail.com</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<author fullname="Russ White" initials="R." surname="White"> | <author fullname="Russ White" initials="R." surname="White"> | |||
<organization>Akamai</organization> | <organization>Akamai</organization> | |||
<address> | <address> | |||
<email>russ@riw.us</email> | <email>russ@riw.us</email> | |||
</address> | </address> | |||
</author> | </author> | |||
<date year="2022"/> | <date year="2023" month="April"/> | |||
<area>rtg</area> | ||||
<workgroup>lsr</workgroup> | ||||
<keyword>scalability</keyword> | ||||
<abstract> | <abstract> | |||
<t>This document describes a backward-compatible, optional | <t>This document describes a backward-compatible, optional IS-IS | |||
IS-IS extension that allows the creation of IS-IS flood reflecti | extension that allows the creation of IS-IS flood reflection topologies. | |||
on | Flood reflection permits topologies in which IS&nbhy;IS Level 1 | |||
topologies. Flood reflection permits | (L1) areas | |||
topologies in which L1 areas provide transit forw | provide transit-forwarding for IS&nbhy;IS Level 2 (L2) areas usi | |||
arding for L2 using all | ng all | |||
available L1 nodes internally. It accomplishes this by creating | available L1 nodes internally. It accomplishes this by | |||
L2 flood reflection | creating L2 flood reflection adjacencies within each L1 area. Those | |||
adjacencies within each L1 area. Those adjacencie | adjacencies are used to flood L2 Link State Protocol Data Units (LSPs) and | |||
s are | are used in the L2 Shortest Path First (SPF) | |||
used to flood L2 LSPDUs and are used in the L2 SP | computation. However, they are not ordinarily utilized for forwarding | |||
F computation. | within the flood reflection cluster. | |||
However, they are not ordinarily utilized for for | ||||
warding within the flood reflection cluster. | ||||
<!-- | <!-- | |||
not utilized for forwarding within the flood reflection cluster except | not utilized for forwarding within the flood reflection cluster except | |||
in pathological cases mentioned in <xref target="patholody"/>. | in pathological cases mentioned in <xref target="patholody"/>. | |||
--> | --> | |||
This arrangement gives | This arrangement gives | |||
the L2 topology significantly better scaling prop erties than traditionally used | the L2 topology significantly better scaling prop erties than prevalently used | |||
flat designs. As an additional benefit, | flat designs. As an additional benefit, | |||
only those routers directly participating | only those routers directly participating | |||
in flood reflection are required to support the f eature. This allows for | in flood reflection are required to support the f eature. This allows for | |||
incremental deployment of scalable L1 transit are as in an existing, previously | incremental deployment of scalable L1 transit are as in an existing, previously | |||
flat network design, without | flat network design, without | |||
the necessity of upgrading all routers in the net work. | the necessity of upgrading all routers in the net work. | |||
</t> | </t> | |||
</abstract> | </abstract> | |||
<note> | ||||
<name>Requirements Language</name> | ||||
<t> | ||||
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 <xref target="RFC2119" format="default"/> <xref target="RFC8174" fo | ||||
rmat="default"/> when, and only when, they appear in all | ||||
capitals, as shown here. | ||||
</t> | ||||
</note> | ||||
</front> | </front> | |||
<middle> | <middle> | |||
<section toc="default" numbered="true"> | <section toc="default" numbered="true"> | |||
<name>Introduction</name> | <name>Introduction</name> | |||
<t> This section introduces the problem space and outlines the solution. Some of the terms | <t> This section introduces the problem space and outlines the solution. Some of the terms | |||
may be unfamiliar to readers without extensive IS-IS background; for | may be unfamiliar to readers without extensive IS-IS background; for | |||
such readers | such readers, | |||
a glossary is provided in <xref target="glossary"/>. | the terminology is provided in <xref target="terminology"/>. | |||
</t> | </t> | |||
<t> | <t>Due to the inherent properties of link-state protocols, the number of | |||
Due to the inherent properties of link-state protocols the numbe | IS-IS routers within a flooding domain is limited by processing and | |||
r of IS-IS | flooding overhead on each node. While that number can be maximized by | |||
routers within a flooding domain is limited by processing and fl | well-written implementations and techniques such as exponential | |||
ooding | backoffs, IS-IS will still reach a saturation point where no further | |||
overhead on each node. While that number | routers can be added to a single flooding domain. In some L2 backbone | |||
can be maximized by well-written implementations and techniques | deployment scenarios, this limit presents a significant challenge. | |||
such as | ||||
exponential 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 backbone deployment scenarios, this limit presents a | ||||
significant challenge. | ||||
</t> | </t> | |||
<t> | <t> | |||
The traditional approach to increasing the scale of an IS-IS deployment is | The standard approach to increasing the scale of an IS-IS deployment is | |||
to break it up into multiple L1 flooding domains and a single L2 | to break it up into multiple L1 flooding domains and a single L2 | |||
backbone. This works well for designs where an L2 backbone connects L1 | backbone. This works well for designs where an L2 backbone connects L1 | |||
access topologies, but it is limiting where a single, flat L2 do main is supposed to span | access topologies, but it is limiting where a single, flat L2 do main is supposed to span | |||
large number of routers. In such scenarios, an alternative appro ach could be to | large number of routers. In such scenarios, an alternative appro ach could be to | |||
consider multiple | consider multiple | |||
L2 flooding domains connected together via L1 flo oding domains. | L2 flooding domains that are connected together v ia L1 flooding domains. | |||
In other words, L2 flooding domains are connected by "L1/L2 lane s" through | In other words, L2 flooding domains are connected by "L1/L2 lane s" through | |||
the L1 areas to form a single L2 backbone again. Unfortunately, in its | the L1 areas to form a single L2 backbone again. Unfortunately, in its | |||
simplest implementation, this requires the inclus ion of most, or all, of | simplest implementation, this requires the inclus ion of most, or all, of | |||
the transit L1 routers as L1/L2 to allow traffic to flow along optimal | the transit L1 routers as L1/L2 to allow traffic to flow along optimal | |||
paths through those transit areas. Consequently, such an approach | paths through those transit areas. Consequently, such an approach | |||
fails to reduce the number of L2 routers involved and with that | fails to reduce the number of L2 routers involved and, with that, | |||
fails to increase the | fails to increase the | |||
scalability of the L2 backbone as well. | scalability of the L2 backbone as well. | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="f1" format="default"/> is an example of a network wher e a topologically rich L1 area | <xref target="f1" format="default"/> is an example of a network wher e a topologically rich L1 area | |||
is used to provide transit between six different L2-only routers (R1 -R6). Note that | is used to provide transit between six different L2-only routers (R1 -R6). Note that | |||
the six L2-only routers do not have connectivity to one another over L2 links. | the six L2-only routers do not have connectivity to one another over L2 links. | |||
To take advantage of the abundance of paths in the L1 transit area, | To take advantage of the abundance of paths in the L1 transit area, | |||
all the intermediate systems could be placed into both L1 and L2, bu t this | all the intermediate systems could be placed into both L1 and L2, bu t this | |||
essentially combines the separate L2 flooding domains into a single one, | essentially combines the separate L2 flooding domains into a single one, | |||
triggering again the maximum L2 scale limitation we try to address i n first place. | again triggering the maximum L2 scale limitation we were trying to a ddress in first place. | |||
</t> | </t> | |||
<figure anchor="f1"> | <figure anchor="f1"> | |||
<name>Example Topology of L1 with L2 Borders</name> | <name>Example Topology of L1 with L2 Borders</name> | |||
<artwork align="left" alt="" name="" type=""><![CDATA[ | <artwork align="left" alt="" name="" type=""><![CDATA[ | |||
+====+ +=======+ +=======+ +======-+ +====+ | +====+ +=======+ +=======+ +======-+ +====+ | |||
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 line 202 ¶ | skipping to change at line 173 ¶ | |||
| | | | | | | | | | | | | | | | | | | | |||
| +---------------+ | | | | | | | | +---------------+ | | | | | | | |||
| | | | | | | | | | | | | | | | | | | | |||
| | +----------------+ | +-----------------+ | | | | +----------------+ | +-----------------+ | | |||
| | | | | | | | | | | | | | | | | | | | |||
+====+ ++=+==+=+ +-------+===+===+-----+ | ++=====++ +====+ | +====+ ++=+==+=+ +-------+===+===+-----+ | ++=====++ +====+ | |||
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 | |||
+====+ +=======+ +=======+ +=======+ +====+ | +====+ +=======+ +=======+ +=======+ +====+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> A more effective solution would allow to reduce the number of links an d routers exposed | <t> A more effective solution would allow the reduction of the number of l inks and routers exposed | |||
in L2, while still utilizing | in L2, while still utilizing | |||
the full L1 topology when forwarding through the network. | the full L1 topology when forwarding through the network. | |||
</t> | </t> | |||
<t> <xref target="RFC8099" format="default"/> describes Topology Transpare nt Zones (TTZ) for OSPF. | <t> <xref target="RFC8099" format="default"/> describes Topology Transpare nt Zones (TTZ) for OSPF. | |||
The TTZ mechanism represents a group of OSPF routers as a full mesh of adjacencies | The 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 mechanism | 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 adja cencies between edge routers | could be applied to IS-IS as well. However, a full mesh of adja cencies between edge routers | |||
(or L1/L2 nodes) significantly limits the practic ally achievable scale of the | (or L1/L2 nodes) significantly limits the practic ally achievable scale of the | |||
resulting topology. | resulting topology. | |||
The topology in <xref target="f1" format="default | The topology in <xref target="f1" format="default | |||
"/> has 6 L1/L2 nodes. <xref target="f2" format="default"/> illustrates | "/> has six L1/L2 nodes. <xref target="f2" format="default"/> illustrates | |||
a full mesh of L2 adjacencies between the 6 L1/L2 | a full mesh of L2 adjacencies between the six L1/ | |||
nodes, resulting in | L2 nodes, resulting in | |||
(5 * 6)/2 = 15 L2 adjacencies. In a somewhat larg er topology containing 20 L1/L2 nodes, | (5 * 6)/2 = 15 L2 adjacencies. In a somewhat larg er topology containing 20 L1/L2 nodes, | |||
the number of L2 adjacencies in a full mesh rises to 190. | the number of L2 adjacencies in a full mesh rises to 190. | |||
</t> | </t> | |||
<figure anchor="f2"> | <figure anchor="f2"> | |||
<name>Example topology represented in L2 with a full mesh of L2 adjacenc ies between L1/L2 nodes</name> | <name>Example Topology Represented in L2 with a Full Mesh of L2 Adjacenc ies between L1/L2 Nodes</name> | |||
<artwork align="left" alt="" name="" type=""><![CDATA[ | <artwork align="left" alt="" name="" type=""><![CDATA[ | |||
+----+ +-------+ +-------------------------------+-------+ +----+ | +----+ +-------+ +-------------------------------+-------+ +----+ | |||
| R1 | | R10 | | | R30 | | R4 | | | R1 | | R10 | | | R30 | | R4 | | |||
| L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | | | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | | |||
| | | | | | | | | | | | | | | | | | | | |||
+----+ ++-+-+--+-+ | +-+--+---++ +----+ | +----+ ++-+-+--+-+ | +-+--+---++ +----+ | |||
| | | | | | | | | | | | | | | | | | |||
| +----------------------------------------------+ | | | +----------------------------------------------+ | | |||
| | | | | | | | | | | | | | | | | | |||
| +-----------------------------------+ | | | | | | +-----------------------------------+ | | | | | |||
| | | | | | | | | | | | | | | | | | |||
skipping to change at line 255 ¶ | skipping to change at line 224 ¶ | |||
| | | | | | | | | | | | | | | | | | |||
| | | | +----------+ | | | | | | +----------+ | | |||
| | | | | | | | | | | | | | | | | | |||
| | | | +-----+ | | | | | | | +-----+ | | | |||
| | | | | | | | | | | | | | | | | | |||
+----+ ++----+-+-+ | +-+-+--+-++ +----+ | +----+ ++----+-+-+ | +-+-+--+-++ +----+ | |||
| R3 | | R12 | | L2 adjacency | R32 | | R6 | | | R3 | | R12 | | L2 adjacency | R32 | | R6 | | |||
| L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | | | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | | |||
| | | | | | | | | | | | | | | | | | | | |||
+----+ +-------+----+ +-------+ +----+ | +----+ +-------+----+ +-------+ +----+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> | <t> | |||
BGP, as specified in <xref target="RFC4271" format="default"/>, faced a similar scaling problem, which | BGP, as specified in <xref target="RFC4271" format="default"/>, faced a similar scaling problem, which | |||
has been | has been | |||
solved in many networks by deploying BGP route reflectors <xref target="RFC4456" format="default"/>. | solved in many networks by deploying BGP route reflectors <xref target="RFC4456" format="default"/>. | |||
We note that BGP route reflectors do not necessarily have to be in the | We note that BGP route reflectors do not necessarily have to be in the | |||
forwarding path of the traffic. This non-congruity of forwarding and control path for BGP | forwarding path of the traffic. This non-congruity of forwarding and control path for BGP | |||
route reflectors allows the control plane to scal e independently of the forwarding plane and | route reflectors allows the control plane to scal e independently of the forwarding plane and | |||
represents an interesting degree of freedom in network architecture. | represents an interesting degree of freedom in network architecture. | |||
</t> | </t> | |||
<t> | <t> | |||
We propose in this document a similar solution for IS-IS and cal l it "flood reflection" | We propose in this document a similar solution for IS-IS and cal l it "flood reflection" | |||
in fashion analogous to "route reflection". A simple example of what a flood | in a fashion analogous to "route reflection". A simple example of what a flood | |||
reflector control plane approach would look like | reflector control plane approach would look like | |||
is shown in <xref target="f3" format="default"/>, where router R 21 plays the role of a flood reflector. Each | is shown in <xref target="f3" format="default"/>, where router R 21 plays the role of a flood reflector. Each | |||
L1/L2 ingress/egress router builds a tunnel to the flood reflect or, and an L2 adjacency is built | L1/L2 ingress/egress router builds a tunnel to the flood reflect or, and an L2 adjacency is built | |||
over each tunnel. In this solution, we need only 6 L2 adjacencies, | over each tunnel. In this solution, we need only six L2 adjacencies, | |||
instead of the 15 needed for a full mesh. In a s omewhat larger topology containing 20 L1/L2 nodes, | instead of the 15 needed for a full mesh. In a s omewhat larger topology containing 20 L1/L2 nodes, | |||
this solution requires only 20 L2 adjacencies, in stead of the 190 needed for a full mesh. | this solution requires only 20 L2 adjacencies, in stead of the 190 needed for a full mesh. | |||
Multiple flood reflectors can be used, allowing the network oper ator to balance between | Multiple flood reflectors can be used, allowing the network oper ator to balance between | |||
resilience, path utilization, and state in the control plane. Th e resulting | resilience, path utilization, and state in the control plane. Th e resulting | |||
L2 adjacency scale is R*n, where R is the number of flood reflec tors used and n is the number of | L2 adjacency scale is R*n, where R is the number of flood reflec tors used and n is the number of | |||
L1/L2 nodes. This compares quite favorably with n*(n-1)/2 L2 adjacencies | L1/L2 nodes. This compares quite favorably with n*(n-1)/2 L2 adjacencies | |||
required in a topologically fully meshed L2 solut ion. | required in a topologically fully meshed L2 solut ion. | |||
</t> | </t> | |||
<figure anchor="f3"> | <figure anchor="f3"> | |||
<name>Example topology represented in L2 with L2 adjacencies from each L 1/L2 node to a single flood reflector</name> | <name>Example Topology Represented in L2 with L2 Adjacencies from Each L 1/L2 Node to a Single Flood Reflector</name> | |||
<artwork align="left" alt="" name="" type=""><![CDATA[ | <artwork align="left" alt="" name="" type=""><![CDATA[ | |||
+----+ +-------+ +-------+ +----+ | +----+ +-------+ +-------+ +----+ | |||
| R1 | | R10 | | R30 | | R4 | | | R1 | | R10 | | R30 | | R4 | | |||
| L2 +--+ L1/L2 +--------------+ +-----------------+ L1/L2 +--+ L2 | | | L2 +--+ L1/L2 +--------------+ +-----------------+ L1/L2 +--+ L2 | | |||
| | | | L2 adj | | L2 adj | | | | | | | | | L2 adj | | L2 adj | | | | | |||
+----+ +-------+ over | | over +-------+ +----+ | +----+ +-------+ over | | over +-------+ +----+ | |||
tunnel | | tunnel | tunnel | | tunnel | |||
+----+ +-------+ +--+---+--+ +-------+ +----+ | +----+ +-------+ +--+---+--+ +-------+ +----+ | |||
| R2 | | R11 | | R21 | | R31 | | R5 | | | R2 | | R11 | | R21 | | R31 | | R5 | | |||
| 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 | | | | | |||
skipping to change at line 303 ¶ | skipping to change at line 270 ¶ | |||
| R2 | | R11 | | R21 | | R31 | | R5 | | | R2 | | R11 | | R21 | | R31 | | R5 | | |||
| 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 +-------+ +----+ | |||
]]></artwork> | ]]></artwork> | |||
</figure> | </figure> | |||
<t> | <t>As illustrated in <xref target="f3" format="default"/>, when R21 | |||
As illustrated in <xref target="f3" format="defau | plays the role of flood reflector, it provides L2 connectivity among all | |||
lt"/>, when R21 plays the role of flood reflector, | of the previously disconnected L2 islands by reflooding all L2 Link State | |||
it provides L2 connectivity among all of the prev | Protocol Data Unit (LSPs). | |||
iously disconnected L2 islands by | At the same time, R20 and R22 in <xref target="f1"/> remain L1-only | |||
reflooding all L2 LSPDUs. At the same time, R20 | routers. L1-only routers and L1-only links are not visible in L2. In | |||
and R22 in <xref target="f1"/> remain L1-only routers. | this manner, the flood reflector allows us to provide L2 control plane | |||
L1-only routers and L1-only links are not visible | connectivity in a manner more scalable than a flat L2 domain. | |||
in L2. In this manner, the flood | ||||
reflector allows us provide L2 control plane conn | ||||
ectivity in a manner more scalable than a | ||||
flat L2 domain. | ||||
</t> | </t> | |||
<t> | <t> | |||
As described so far, the solution illustrated in <xref target=" f3" format="default"/> relies | As described so far, the solution illustrated in <xref target=" f3" format="default"/> relies | |||
only on currently standardized IS-IS functionalit y. Without new functionality, however, | only on currently standardized IS-IS functionalit y. Without new functionality, however, | |||
the data traffic will traverse only R21. This will unnecessaril y create a bottleneck | the data traffic will traverse only R21. This will unnecessaril y create a bottleneck | |||
at R21 since there is still available capacity in the paths crossing the L1-only | at R21 since there is still available capacity in the paths crossing the L1-only | |||
routers R20 and R22 in <xref target="f1"/>. | routers R20 and R22 in <xref target="f1"/>. | |||
</t> | </t> | |||
<t> | <t>Hence, additional functionality is compulsory to allow the L1/L2 edge | |||
Hence, additional functionality is compulsory to allow the L1/L2 | nodes (R10-12 and R30-32 in <xref target="f3" format="default"/>) to | |||
edge nodes | recognize that the L2 adjacency to R21 should not be used for | |||
(R10-12 and R30-32 in <xref target="f3" format="d | forwarding. The L1/L2 edge nodes should forward traffic that would | |||
efault"/>) to recognize that the L2 adjacency to R21 | normally be forwarded over the L2 adjacency to R21 over L1 links | |||
should not be used for forwarding. The L1/L2 edge | instead. This would allow the forwarding within the L1 area to use the | |||
nodes | L1-only nodes and links shown in <xref target="f1" format="default"/> as | |||
should forward traffic that | well. | |||
would normally be forwarded over the L2 adjacency to R21 | It allows networks that use | |||
over L1 links instead. This would allow the forwarding within t | the entire forwarding capacity of the L1 areas to be built, while | |||
he L1 area | at the same time it introduces control plane scaling benefits that | |||
to use the L1-only nodes and links shown in <xref | are provided by L2 flood reflectors. | |||
target="f1" format="default"/> as well. It allows | ||||
networks to be built that use the entire forwardi | ||||
ng capacity of the L1 areas, | ||||
while at the same time introducing control plane | ||||
scaling benefits provided by L2 flood reflectors. | ||||
</t> | </t> | |||
<t> | ||||
<t> | It is expected that deployment at scale, and suitable time in | |||
It is expected that deployment at scale, and suitable time in operat | operation, will provide sufficient evidence to either put this | |||
ion, will provide | extension into a Standards Track document or suggest necessary | |||
sufficient evidence to either make this extension a standard, or sug | modifications to accomplish that. | |||
gest necessary modifications | ||||
to accomplish this. | ||||
</t> | </t> | |||
<t> The remainder of this document defines the remaining extensions necess ary | <t> The remainder of this document defines the remaining extensions necess ary | |||
for a complete flood reflection solution: | for a complete flood reflection solution: | |||
</t> | </t> | |||
<ul spacing="normal"> | <ul spacing="normal"> | |||
<li> | <li> | |||
It defines a special 'flood reflector adjacency' | It defines a special "flood reflector adjacency" | |||
built for the purpose of reflecting flooding | built for the purpose of reflecting flooding | |||
information. These adjacencies allow 'flood reflectors' to | information. These adjacencies allow "flood reflectors" to | |||
participate in the IS-IS control plane without necessarily being | participate in the IS-IS control plane without necessarily being | |||
used in the forwarding plane. Maintenance of such adjacencies is | used in the forwarding plane. Maintenance of such adjacencies is | |||
a purely local operation on the L1/L2 ingress and flood | a purely local operation on the L1/L2 ingress and flood | |||
reflectors; it does not require replacing or modifying any routers | reflectors; it does not require replacing or modifying any routers | |||
not involved in the reflection process. In practical deployments, i t is | not involved in the reflection process. In practical deployments, i t is | |||
far less tricky to just upgrade the routers involved in flood | far less tricky to just upgrade the routers involved in flood | |||
reflection rather than have a flag day for the whole IS-IS domain. | reflection rather than have a flag day for the whole IS-IS domain. | |||
</li> | </li> | |||
<li> | <li> | |||
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 bu t | The specification is agnostic as to the tunneling technology used bu t | |||
provides enough information for automatic establishment of such | provides enough information for automatic establishment of such | |||
tunnels if desired. The discussion of IS-IS adjacency formation and /or | tunnels if desired. The discussion of IS-IS adjacency formation and /or | |||
liveness discovery on such tunnels is outside the scope of this | liveness discovery on such tunnels is outside the scope of this | |||
specification and is largely a choice of the underlying implementati on. A | specification and is largely a choice of the underlying implementati on. A | |||
solution without tunnels is also possible by introducing the correct | solution without tunnels is also possible by introducing the correct | |||
scoping of reachability information between the levels. This is | scoping of reachability information between the levels. This is | |||
described in more detail later. | described in more detail later. | |||
</li> | </li> | |||
<li> | <li> | |||
Finally, the document defines support of reflector redundancy | Finally, this document defines support of reflector redundancy | |||
and an (optional) way to auto-discover and annotate flood | and an (optional) way to auto-discover and annotate flood | |||
reflector adjacencies on advertisements. Such additional | reflector adjacencies on advertisements. Such additional | |||
information in link advertisements allows L2 nodes outside the L1 | information in link advertisements allows L2 nodes outside the L1 | |||
area to recognize a flood reflection cluster and its adjacencies. | area to recognize a flood reflection cluster and its adjacencies. | |||
</li> | </li> | |||
</ul> | </ul> | |||
</section> | </section> | |||
<section anchor="glossary" numbered="true" toc="default"> | <section anchor="conv"> | |||
<name>Glossary</name> | <name>Conventions Used in This Document</name> | |||
<section anchor="terminology" numbered="true" toc="default"> | ||||
<name>Terminology</name> | ||||
<t> | <t> | |||
The following terms are used in this document. | The following terms are used in this document. | |||
</t> | </t> | |||
<dl newline="true" spacing="normal"> | <dl newline="true" spacing="normal"> | |||
<dt>ISIS Level-1 and Level-2 areas, mostly abbreviated as L1 and L | ||||
2:</dt> | <dt>IS-IS Level 1 and Level 2 areas (mostly abbreviated as L1 and | |||
<dd> | L2):</dt> | |||
Traditional ISIS concepts whereas a routing domain has two "le | <dd>IS-IS concepts where a routing domain has two | |||
vels" with a single L2 area being the | "levels" with a single L2 area being the "backbone" that | |||
"backbone" that | connects multiple L1 areas for scaling and reliability | |||
connects multiple L1 areas for scaling and reliability purpose | purposes. | |||
s. In traditional ISIS L2 can be used as | ||||
transit for L1-L1 traffic but L1 areas cannot be used for that | IS-IS architecture prescribes a routing domain with two | |||
purpose since L2 level must be "connected" | "levels" where a single L2 area functions as the "backbone" that connects | |||
and all traffic flows along L2 routers until it arrives at the | multiple L1 areas amongst themselves for scaling and reliability purposes. | |||
destination L1 area. | In such architecture, L2 can be used as transit for traffic carried from o | |||
ne L1 area to another, but | ||||
L1 areas themselves cannot be used for that purpose because the L2 level m | ||||
ust | ||||
be a single "connected" entity, and all traffic exiting an L1 area flows a | ||||
long L2 routers until the | ||||
traffic arrives at the destination L1 area itself. | ||||
</dd> | </dd> | |||
<dt>Flood Reflector:</dt> | <dt>Flood Reflector:</dt> | |||
<dd>Node configured to connect in L2 only to flood reflector clien | <dd>Node configured to connect in L2 only to flood reflector | |||
ts and reflect (reflood) IS-IS L2 LSPs amongst them.</dd> | clients and to reflect (reflood) IS-IS L2 LSPs amongst them.</dd> | |||
<dt>Flood Reflector Client:</dt> | <dt>Flood Reflector Client:</dt> | |||
<dd>Node configured to build Flood Reflector Adjacencies to Flood | <dd>Node configured to build Flood Reflector Adjacencies to Flood | |||
Reflectors, and normal adjacencies to | Reflectors and to build normal adjacencies to other clients and | |||
other clients and L2 nodes not participating in flood reflecti | L2 nodes not participating in flood reflection.</dd> | |||
on.</dd> | ||||
<dt>Flood Reflector Adjacency:</dt> | <dt>Flood Reflector Adjacency:</dt> | |||
<dd> | <dd>IS-IS L2 adjacency where one end is a Flood Reflector Client, | |||
IS-IS L2 adjacency where one end is a Flood Reflector Client a | and the other, a Flood Reflector. Both have the same Flood | |||
nd the | Reflector Cluster ID. | |||
other a Flood Reflector, and the two have the same Flood Refle | ||||
ctor | ||||
Cluster ID. | ||||
</dd> | </dd> | |||
<dt>Flood Reflector Cluster:</dt> | <dt>Flood Reflector Cluster:</dt> | |||
<dd>Collection of clients and flood reflectors configured with the same cluster identifier.</dd> | <dd>Collection of clients and flood reflectors configured with the same cluster identifier.</dd> | |||
<dt> | <dt> | |||
Tunnel-Based Deployment: | Tunnel-Based Deployment: | |||
</dt> | </dt> | |||
<dd>Deployment where Flood Reflector Clients build a partial or fu ll mesh of tunnels in L1 to "shortcut" | <dd>Deployment where Flood Reflector Clients build a partial or fu ll mesh of tunnels in L1 to "shortcut" | |||
forwarding of L2 traffic through the cluster.</dd> | forwarding of L2 traffic through the cluster.</dd> | |||
<dt> | <dt> | |||
No-Tunnel Deployment: | No-Tunnel Deployment: | |||
</dt> | </dt> | |||
<dd> | <dd> | |||
Deployment where Flood Reflector Clients redistribute L2 reach ability into L1 to allow | Deployment where Flood Reflector Clients redistribute L2 reach ability into L1 to allow | |||
forwarding through the cluster without underlying tunnels. | forwarding through the cluster without underlying tunnels. | |||
</dd> | </dd> | |||
<dt> | <dt> | |||
Tunnel Endpoint: | Tunnel Endpoint: | |||
</dt> | </dt> | |||
<dd> | <dd>An endpoint that allows the establishment of a | |||
An endpoint that allows the establishment of a bi-directional | bidirectional tunnel carrying IS-IS control traffic or, | |||
tunnel carrying IS-IS control traffic or | alternately, serves as the origin of such a tunnel. | |||
alternately, serves as the origin of such a tunnel. | ||||
</dd> | </dd> | |||
<dt> | <dt>L1 shortcut:</dt> | |||
L1 shortcut: | <dd>A tunnel established between two clients that is visible in L1 | |||
</dt> | only and is used as a next hop, i.e., to carry data traffic | |||
<dd> | in tunnel-based deployment mode. | |||
A tunnel between two clients visible in L1 only that is used a | ||||
s a next-hop, i.e. to carry | ||||
data traffic in tunnel-based deployment mode. | ||||
</dd> | </dd> | |||
<dt>Hot-Potato Routing:</dt> | ||||
<dt> | <dd>In the context of this document, a routing paradigm where | |||
Hot-Potato Routing: | L2->L1 routes are less preferred than L2 routes <xref | |||
</dt> | target="RFC5302" format="default"/>. | |||
<dd> | ||||
In context of this document, a routing paradigm where L2->L1 r | ||||
outes are less preferred than L2 | ||||
routes <xref target="RFC5302" format="default"/>. | ||||
</dd> | </dd> | |||
</dl> | </dl> | |||
</section> | ||||
<section numbered="true" toc="default"> | ||||
<name>Requirements Language</name> | ||||
<t> | ||||
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU | ||||
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL | ||||
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14> | ||||
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", | ||||
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to | ||||
be interpreted as | ||||
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> | ||||
when, and only when, they appear in all capitals, as shown here. | ||||
</t> | ||||
</section> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Further Details</name> | <name>Further Details</name> | |||
<t> | <t> | |||
Several considerations should be noted in relation to such a flo od reflection mechanism. | Several considerations should be noted in relation to such a flo od reflection mechanism. | |||
</t> | </t> | |||
<t> | <t> | |||
First, this allows multi-area IS-IS deployments to scale without | First, the flood reflection mechanism allows multi-area IS-IS deployments | |||
any major | to scale without any major modifications in the IS-IS implementation on | |||
modifications in the IS-IS implementation on most of the nodes | most of the nodes deployed in the network. | |||
deployed in the network. Unmodified (traditional) L2 routers wil | Unmodified (standard) L2 routers will | |||
l | ||||
compute reachability across the transit L1 area using the flood reflector | compute reachability across the transit L1 area using the flood reflector | |||
adjacencies. | adjacencies. (In this document, the term "standard" refers to I S-IS as specified in <xref target="ISO10589"/>.) | |||
</t> | </t> | |||
<t> | <t> | |||
Second, the flood reflectors are not required to participate in forwarding | Second, the flood reflectors are not required to participate in forwarding | |||
traffic through the L1 transit area. These flood reflectors can | traffic through the L1 transit area. These flood reflectors can | |||
be hosted on virtual devices outside the forwarding topology. | be hosted on virtual devices outside the forwarding topology. | |||
</t> | </t> | |||
<t> | <t> Third, astute readers will realize that flooding reflection may | |||
Third, astute readers will realize that flooding reflection may | cause the use of suboptimal paths. This is similar to the BGP route | |||
cause the use | reflection suboptimal routing problem described in <xref | |||
of suboptimal paths. This is similar to the BGP route reflection | target="RFC9107" format="default"/>. | |||
suboptimal | ||||
routing problem described in <xref target="ID.draft-ietf-idr-bgp | The L2 | |||
-optimal-route-reflection-28" format="default"/>. | computation determines the egress L1/L2 and, with that, can create | |||
The L2 computation determines the egress L1/L2 and with that can | illusions of ECMP where there is none; and in certain scenarios, | |||
create illusions | the L2 computation can lead to an L1/L2 egress that is not globally | |||
of ECMP where there is none, and in certain scenarios lead to an | optimal. | |||
L1/L2 egress which | ||||
is not globally optimal. This represents a straightforward insta | This represents a straightforward | |||
nce of the trade-off | instance of the trade-off between the amount of control plane state and the | |||
between the amount of control plane state and the optimal use of | optimal use of paths through the network that are often encountered when | |||
paths through | aggregating routing information. | |||
the network often encountered when aggregating routing informati | ||||
on. | ||||
</t> | </t> | |||
<t> | <t>One possible solution to this problem is to expose additional | |||
One possible solution to this problem is to expose additional to | topology information into the L2 flooding domains. In the example | |||
pology information into | network given, links from router R10 to router R11 can be exposed into | |||
the L2 flooding domains. In the example network given, links fro | L2 even when R10 and R11 are participating in flood reflection. This | |||
m router R10 to | information would allow the L2 nodes to build "shortcuts" when the L2 | |||
router R11 can be exposed into L2 even when R10 and R11 are part | flood-reflected part of the topology looks more expensive to cross | |||
icipating in flood reflection. | distance-wise. | |||
This information would allow the L2 nodes to build 'shortcuts' w | ||||
hen the | ||||
L2 flood reflected part of the topology looks more expensive to | ||||
cross distance wise. | ||||
</t> | </t> | |||
<t>Another possible variation is for | <t>Another possible variation is for an implementation to use the tunnel | |||
an implementation to approximate with the tunnel cost the cost o | cost to approximate the cost of the underlying topology. </t> | |||
f the | <t>Redundancy can be achieved by configuring multiple flood reflectors | |||
underlying topology. </t> | in an L1 area. Multiple flood reflectors do not need any synchronization | |||
<t> | mechanisms amongst themselves, except standard IS-IS flooding and | |||
Redundancy can be achieved by configuring multiple flood reflect | database maintenance procedures. | |||
ors | ||||
in a L1 area. Multiple flood reflectors | ||||
do not need any synchronization mechanisms amongst themselves, e | ||||
xcept standard | ||||
IS-IS flooding and database maintenance procedures. | ||||
</t> | </t> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Encodings</name> | <name>Encodings</name> | |||
<section anchor="sec_flood_reflection_tlv" numbered="true" toc="default"> | <section anchor="sec_flood_reflection_tlv" numbered="true" toc="default"> | |||
<name>Flood Reflection TLV</name> | <name>Flood Reflection TLV</name> | |||
<t> | <t>The Flood Reflection TLV is a top-level TLV that <bcp14>MUST</bcp14> | |||
The Flood Reflection TLV is a top-level TLV that | appear in L2 IIHs (IS-IS Hello) on all Flood Reflection Adjacencies. The | |||
MUST appear in L2 | Flood | |||
IIHs on all Flood Reflection Adjacencies. The Fl | Reflection TLV indicates the flood reflector cluster (based on Flood | |||
ood Reflection | Reflection Cluster ID) that a given router is configured to participate | |||
TLV indicates the flood reflector cluster | in. It also indicates whether the router is configured to play the role | |||
(based on Flood Reflection Cluster ID) that a giv | of either flood reflector or flood reflector client. The Flood | |||
en router is configured to | Reflection Cluster ID and flood reflector roles advertised in the IIHs | |||
participate in. It also indicates whether the rou | are used to ensure that flood reflector adjacencies are only formed | |||
ter is configured to | between a flood reflector and flood reflector client and that the Flood | |||
play the role of either flood reflector or flood | Reflection Cluster IDs match. The Flood Reflection TLV has the following | |||
reflector client. The Flood Reflection | format: | |||
Cluster ID and flood reflector roles advertised i | ||||
n the IIHs | ||||
are used to ensure that flood reflector adjacenci | ||||
es are only | ||||
formed between a flood reflector and flood reflec | ||||
tor client, and that | ||||
the Flood Reflection Cluster IDs match. The Flood | ||||
Reflection TLV has the following format: | ||||
</t> | </t> | |||
<artwork align="left" alt="" name="" type=""><![CDATA[ | ||||
<artwork align="left" alt="" name="" type=""><![CDATA[ | ||||
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 ... | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
]]></artwork> | ||||
]]></artwork> | ||||
<dl newline="false" spacing="normal"> | <dl newline="false" spacing="normal"> | |||
<dt>Type:</dt> | <dt>Type:</dt> | |||
<dd>161</dd> | <dd>161</dd> | |||
<dt>Length:</dt> | <dt>Length:</dt> | |||
<dd>The length, in octets, of the following fields.</dd> | <dd>The length, in octets, of the following fields.</dd> | |||
<dt>C (Client):</dt> | <dt>C (Client):</dt> | |||
<dd> | <dd>This bit is set to indicate that the router acts as a flood | |||
This bit is set to indicate that the | reflector client. When this bit is NOT set, the router acts as a | |||
router acts as a flood reflector client. | flood reflector. On a given router, the same value of the C-bit | |||
When this bit is NOT set, the rou | <bcp14>MUST</bcp14> be advertised across all interfaces advertising | |||
ter acts as a flood reflector. On a given router, | the Flood Reflection TLV in IIHs. | |||
the same value of the C-bit MUST | ||||
be advertised across all interfaces advertising the Flood | ||||
Reflection TLV in IIHs. | ||||
</dd> | </dd> | |||
<dt>RESERVED:</dt> | <dt>Reserved:</dt> | |||
<dd> | <dd> | |||
This field is reserved for future use | This field is reserved for future use | |||
. It MUST be set to 0 when sent | . It <bcp14>MUST</bcp14> be set to 0 when sent | |||
and MUST be ignored when received | and <bcp14>MUST</bcp14> be ignore | |||
. | d when received. | |||
</dd> | </dd> | |||
<dt>Flood Reflection Cluster ID:</dt> | ||||
<dd> | ||||
<!-- @todo: do we make it a SHOULD? --> | ||||
Flood Reflection Cluster Identifier. The same arbitrary 32-bit value | <dt>Flood Reflection Cluster ID:</dt> | |||
MUST be | <dd><!-- @todo: do we make it a SHOULD? --> | |||
assigned to all of the flood refl | The same arbitrary 32-bit value <bcp14>MUST</bcp14> be assigned | |||
ectors and flood reflector clients in | to | |||
the same L1 area. The value MUST | all of the flood reflectors and flood reflector clients in the | |||
be unique across different L1 areas within | same L1 area. The value <bcp14>MUST</bcp14> be unique across | |||
the IGP domain. In case of violat | different L1 areas within the IGP domain. In case of violation of | |||
ion of those rules multiple L1 areas | those rules, multiple L1 areas may become a single cluster, or a | |||
may become a single cluster or a single area may split i | single area may split in flood reflection sense, and several | |||
n flood reflection | mechanisms, such as auto-discovery of tunnels, may not work | |||
sense and several mechanisms such as auto-discovery | correctly. | |||
of tunnels may not work correctly. | ||||
<!-- @todo: do we make it a SHOULD? --> | <!-- @todo: do we make it a SHOULD? --> | |||
On a given router, the same value of the Flood Reflection | On a given router, the same value of the Flood Reflection Cluster | |||
Cluster ID MUST be advertised acr | ID <bcp14>MUST</bcp14> be advertised across all interfaces | |||
oss all interfaces advertising the Flood | advertising the Flood Reflection TLV in IIHs. When a router | |||
Reflection TLV in IIHs. When a router discovers that a n | discovers that a node is using more than a single Cluster IDs | |||
ode is using | based on its advertised TLVs and IIHs, the node <bcp14>MAY</bcp14> | |||
more than a single Cluster IDs based on its advertised T | log such violations subject to rate-limiting. This implies that a | |||
LVs and IIHs, the node | flood reflector <bcp14>MUST NOT</bcp14> participate in more than a | |||
MAY log such violations subject to rate limiting. | single L1 area. In case of Cluster ID value of 0, the TLV | |||
This implies that a flood reflector MUST NOT participate | containing it <bcp14>MUST</bcp14> be ignored. | |||
in more than a single L1 area. In case of Cluster ID val | ||||
ue of 0, | ||||
the TLV containing it MUST be ignored. | ||||
</dd> | </dd> | |||
<dt>Sub-TLVs:</dt> | <dt>Sub-TLVs (Optional Sub-TLVs):</dt> | |||
<dd> Optional sub-TLVs. For future extensibility, the | <dd>For future extensibility, the format of the Flood Reflection TLV | |||
format of the Flood Reflection TL | allows for the possibility of including optional sub-TLVs. No | |||
V allows for the possibility of | sub-TLVs of the Flood Reflection TLV are defined in this document. | |||
including optional sub-TLVs. No | ||||
sub-TLVs of the Flood Reflection TLV | ||||
are defined in this document. | ||||
</dd> | </dd> | |||
</dl> | </dl> | |||
<t> | <t>The Flood Reflection TLV <bcp14>SHOULD NOT</bcp14> appear more than | |||
The Flood Reflection TLV SHOULD NOT appear more t | once in an IIH. A router receiving one or more Flood Reflection TLVs in | |||
han once in an IIH. A router | the same IIH <bcp14>MUST</bcp14> use the values in the first TLV, and it | |||
receiving one or more Flood Reflection TLVs in th | <bcp14>SHOULD</bcp14> log such violations subject to rate-limiting. | |||
e same IIH MUST use the values in the | ||||
first TLV and it SHOULD log such violations subje | ||||
ct to rate limiting. | ||||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="sec_flood_reflection_discovery_subtlv" numbered="true" toc= "default"> | <section anchor="sec_flood_reflection_discovery_subtlv" numbered="true" toc= "default"> | |||
<name>Flood Reflection Discovery Sub-TLV</name> | <name>Flood Reflection Discovery Sub-TLV</name> | |||
<t> | <t> | |||
The Flood Reflection Discovery sub-TLV is adverti sed as a sub-TLV of the | The Flood Reflection Discovery sub-TLV is adverti sed as a sub-TLV of the | |||
IS-IS Router Capability TLV-242, defined in <xref target="RFC7981" format="default"/>. | IS-IS Router Capability TLV 242, defined in <xref target="RFC7981" format="default"/>. | |||
The Flood Reflection Discovery sub-TLV is adverti sed in L1 and L2 LSPs with | The Flood Reflection Discovery sub-TLV is adverti sed in L1 and L2 LSPs with | |||
area flooding scope in order to enable the auto-d iscovery of flood | area flooding scope in order to enable the auto-d iscovery of flood | |||
reflection capabilities. The Flood Reflection Dis covery sub-TLV has | reflection capabilities. The Flood Reflection Dis covery sub-TLV has | |||
the following format: | the following format: | |||
</t> | </t> | |||
<artwork align="left" alt="" name="" type=""><![CDATA[ | <artwork align="left" alt="" name="" type=""><![CDATA[ | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
]]></artwork> | ||||
]]></artwork> | ||||
<dl newline="false" spacing="normal"> | <dl newline="false" spacing="normal"> | |||
<dt>Type:</dt> | <dt>Type:</dt> | |||
<dd>161</dd> | <dd>161</dd> | |||
<dt>Length:</dt> | <dt>Length:</dt> | |||
<dd>The length, in octets, of the following fields.</dd> | <dd>The length, in octets, of the following fields.</dd> | |||
<dt>C (Client):</dt> | <dt>C (Client):</dt> | |||
<dd> | <dd> | |||
This bit is set to indicate that the router acts as a flood reflector client. | This bit is set to indicate that the router acts as a flood reflector client. | |||
When this bit is NOT set, the rou ter acts as a flood reflector. | When this bit is NOT set, the rou ter acts as a flood reflector. | |||
</dd> | </dd> | |||
<dt>RESERVED:</dt> | <dt>Reserved:</dt> | |||
<dd> | <dd> | |||
This field is reserved for future use | This field is reserved for future use | |||
. It MUST be set to 0 when sent | . It <bcp14>MUST</bcp14> be set to 0 when sent | |||
and MUST be ignored when received | and <bcp14>MUST</bcp14> be ignore | |||
. | d when received. | |||
</dd> | </dd> | |||
<dt>Flood Reflection Cluster ID:</dt> | <dt>Flood Reflection Cluster ID:</dt> | |||
<dd> The Flood Reflection Cluster Identifier is | <dd>The Flood Reflection Cluster Identifier | |||
the same as that defined in the F | is the same as that defined in the Flood Reflection TLV in <xref target="s | |||
lood Reflection TLV and obeys the same rules. | ec_flood_reflection_tlv"/> and obeys the same rules. | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
<t> | <t> | |||
The Flood Reflection Discovery sub-TLV SHOULD NOT | The Flood Reflection Discovery sub-TLV <bcp14>SHO | |||
appear more than once in TLV 242. A router | ULD NOT</bcp14> appear more than once in TLV 242. A router | |||
receiving one or more Flood Reflection Discovery | receiving one or more Flood Reflection Discovery | |||
sub-TLVs in TLV 242 MUST use the values in the | sub-TLVs in TLV 242 <bcp14>MUST</bcp14> use the values in the | |||
first sub-TLV of the lowest numbered fragment and | first sub-TLV of the lowest numbered fragment, an | |||
it SHOULD log such violations subject to rate limiting. | d it <bcp14>SHOULD</bcp14> log such violations subject to rate-limiting. | |||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="sec_flood_reflection_discovery_tunnel_subtlv" numbered="t rue" toc="default"> | <section anchor="sec_flood_reflection_discovery_tunnel_subtlv" numbered="t rue" toc="default"> | |||
<name>Flood Reflection Discovery Tunnel Type Sub-Sub-TLV</name> | <name>Flood Reflection Discovery Tunnel Type Sub-Sub-TLV</name> | |||
<t> | <t> | |||
Flood Reflection Discovery Tunnel Type sub-sub-TLV is advertised o ptionally as a sub-sub-TLV of the | Flood Reflection Discovery Tunnel Type sub-sub-TLV is advertised o ptionally as a sub-sub-TLV of the | |||
Flood Reflection Discovery Sub-TLV, defined in <xref target="sec_f lood_reflection_discovery_subtlv"/>. | Flood Reflection Discovery Sub-TLV, defined in <xref target="sec_f lood_reflection_discovery_subtlv"/>. | |||
It allows the automatic creation of L2 tunnels to be used as | It allows the automatic creation of L2 tunnels to be used as | |||
flood reflector adjacencies and L1 shortcut tunnels. The Flood Ref lection Tunnel Type sub-sub-TLV has | flood reflector adjacencies and L1 shortcut tunnels. The Flood Ref lection Tunnel Type sub-sub-TLV has | |||
the following format: | the following format: | |||
</t> | </t> | |||
<artwork align="left" alt="" name="" type=""><![CDATA[ | <artwork align="left" alt="" name="" type=""><![CDATA[ | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
]]></artwork> | ]]></artwork> | |||
<dl newline="false" spacing="normal"> | <dl newline="false" spacing="normal"> | |||
<dt>Type:</dt> | <dt>Type:</dt> | |||
<dd>161</dd> | <dd>161</dd> | |||
<dt>Length:</dt> | <dt>Length:</dt> | |||
<dd>The length, in octets, of zero or more of the following fields .</dd> | <dd>The length, in octets, of zero or more of the following fields .</dd> | |||
<dt>Reserved:</dt> | <dt>Reserved:</dt> | |||
<dd> | <dd> | |||
SHOULD be 0 on transmission and MUST be ignored on reception.</dd> | <bcp14>SHOULD</bcp14> be 0 on transmission and <bcp14>MUST</bcp14> be ignored on reception.</dd> | |||
<dt>F Flag:</dt> | <dt>F Flag:</dt> | |||
<dd> | <dd>When set, indicates flood reflection tunnel endpoint. When | |||
When set indicates flood reflection tunnel endpoint, when clea | clear, indicates possible L1 shortcut tunnel endpoint. | |||
r, indicates | ||||
possible L1 shortcut tunnel endpoint. | ||||
</dd> | </dd> | |||
<dt>Tunnel Encapsulation Attribute:</dt> | <dt>Tunnel Encapsulation Attribute:</dt> | |||
<dd> | <dd> | |||
Carries encapsulation type and further attributes necessary fo | Carries encapsulation type and further attributes necessary | |||
r tunnel establishment | for tunnel establishment as defined in <xref | |||
as defined in <xref target="RFC9012"/>. In context of this att | target="RFC9012"/>. In context of this attribute, the | |||
ribute the | protocol Type sub-TLV as defined in <xref target="RFC9012"/> | |||
protocol Type sub-TLV as defined in | <bcp14>MAY</bcp14> be included to ensure proper | |||
<xref target="RFC9012"/> MAY be included to ensure proper enca | encapsulation of IS-IS frames. In case such a sub-TLV is | |||
psulation of | included and the F flag is set (i.e., the resulting tunnel is | |||
IS-IS frames. In case such a sub-TLV is included and the | a flood reflector adjacency), this sub-TLV | |||
F flag is set (i.e. the resulting tunnel is a flood reflector | <bcp14>MUST</bcp14> include a type that allows to carry | |||
adjacency) | encapsulated IS-IS frames. Furthermore, such tunnel type | |||
this sub-TLV MUST include a type | <bcp14>MUST</bcp14> be able to transport IS-IS frames of | |||
that allows to carry encapsulated IS-IS frames. Furthermore, s | size up to "originatingL2LSPBufferSize". | |||
uch tunnel type | ||||
MUST be able to transport IS-IS frames of size up to `origina | ||||
tingL2LSPBufferSize`. | ||||
</dd> | </dd> | |||
</dl> | </dl> | |||
<t> | <t>A flood reflector | |||
A flood reflector | ||||
receiving Flood Reflection Discovery Tunnel Type sub-sub-TLVs in F lood Reflection Discovery | receiving Flood Reflection Discovery Tunnel Type sub-sub-TLVs in F lood Reflection Discovery | |||
sub-TLV with F flag set (i.e. the resulting tunnel is a flood refl | sub-TLV with F flag set (i.e., the resulting tunnel is a flood ref | |||
ector adjacency) | lector adjacency) | |||
SHOULD use one or more of the specified tunnel endpoints to automa | <bcp14>SHOULD</bcp14> use one or more of the specified tunnel endp | |||
tically establish one or more | oints to automatically establish one or more | |||
tunnels that will serve as flood reflection adjacency(-ies) to the | tunnels that will serve as a flood reflection adjacency and/or adj | |||
clients advertising the endpoints. | acencies to the clients advertising the endpoints. | |||
</t> | </t> | |||
<t> | <t> | |||
A flood reflection client | A flood reflection client | |||
receiving one or more Flood Reflection Discovery Tunnel Type sub-s ub-TLVs in Flood Reflection Discovery | receiving one or more Flood Reflection Discovery Tunnel Type sub-s ub-TLVs in Flood Reflection Discovery | |||
sub-TLV with F flag clear (i.e. the resulting tunnel is used to su pport tunnel-based mode) | sub-TLV with F flag clear (i.e., the resulting tunnel is used to s upport tunnel-based mode) | |||
from other leaves | from other leaves | |||
MAY use one or more of the specified tunnel endpoints to automatic ally establish one or more | <bcp14>MAY</bcp14> use one or more of the specified tunnel endpoin ts to automatically establish one or more | |||
tunnels that will serve as L1 tunnel shortcuts to the clients adve rtising the endpoints. | tunnels that will serve as L1 tunnel shortcuts to the clients adve rtising the endpoints. | |||
</t> | </t> | |||
<t> | <t> | |||
In case of automatic flood reflection adjacency tunnels and in cas e IS-IS adjacencies are being formed across | In case of automatic flood reflection adjacency tunnels and in cas e IS-IS adjacencies are being formed across | |||
L1 shortcuts all the aforementioned rules in <xref target="sec_dis covery"/> apply as well. | L1 shortcuts, all the aforementioned rules in <xref target="sec_di scovery"/> apply as well. | |||
</t> | </t> | |||
<t> | <t> | |||
Optional address validation procedures | Optional address validation procedures | |||
as defined in <xref target="RFC9012"/> MUST be disregarded. | as defined in <xref target="RFC9012"/> <bcp14>MUST</bcp14> be disr egarded. | |||
</t> | </t> | |||
<t> | <t> | |||
It remains to be observed that automatic tunnel discovery is an op tional part of the specification | It remains to be observed that automatic tunnel discovery is an op tional part of the specification | |||
and can be replaced or mixed with | and can be replaced or mixed with | |||
statically configured tunnels for either flood reflector adjacenci es and/or tunnel-based shortcuts. | statically configured tunnels for flood reflector adjacencies and tunnel-based shortcuts. | |||
Specific implementation details how both mechanisms interact are s pecific to an implementation and | Specific implementation details how both mechanisms interact are s pecific to an implementation and | |||
mode of operation and are outside the scope of this document. | mode of operation and are outside the scope of this document. | |||
</t> | </t> | |||
<!-- | <!-- | |||
<t> | <t> | |||
Once the tunnels are established based on auto discovery procedure s, the "withdrawal" of previously | Once the tunnels are established based on auto discovery procedure s, the "withdrawal" of previously | |||
seen | seen | |||
Flood Reflection Discovery sub-TLV SHOULD NOT be used to tear down an already | Flood Reflection Discovery sub-TLV SHOULD NOT be used to tear down an already | |||
established tunnel. | established tunnel. | |||
</t> | </t> | |||
--> | --> | |||
<t> | <t> | |||
Flood reflector adjacencies rely on IS-IS L2 liveliness procedures | Flood reflector adjacencies rely on IS-IS L2 liveliness | |||
. In case of L1 shortcuts the | procedures. In case of L1 shortcuts, the mechanism used to | |||
mechanism used to ensure liveliness and tunnel integrity are outsi | ensure liveliness and tunnel integrity are outside the scope of | |||
de the scope of this document. | this document. | |||
</t> | </t> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Flood Reflection Adjacency Sub-TLV</name> | <name>Flood Reflection Adjacency Sub-TLV</name> | |||
<t> | ||||
The Flood Reflection Adjacency sub-TLV is adverti | <t>The Flood Reflection Adjacency sub-TLV is advertised as a sub-TLV of | |||
sed as a sub-TLV | TLVs 22, 23, 25, 141, 222, and 223 (the "TLVs Advertising Neighbor | |||
of TLVs 22, 23, 25, 141, 222, and 223 | Information"). Its presence indicates that a given adjacency is a flood | |||
(the "TLVs Advertising Neighbor Information"). | reflector adjacency. It is included in L2 area scope flooded LSPs. The | |||
Its presence indicates that a | Flood Reflection Adjacency sub-TLV has the following format: | |||
given adjacency is a flood reflector adjacency. | ||||
It is included in L2 area scope flooded LSPs. The | ||||
Flood Reflection Adjacency | ||||
sub-TLV has the following format: | ||||
</t> | </t> | |||
<artwork align="left" alt="" name="" type=""><![CDATA[ | <artwork align="left" alt="" name="" type=""><![CDATA[ | |||
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 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
]]></artwork> | ||||
]]></artwork> | ||||
<dl newline="false" spacing="normal"> | <dl newline="false" spacing="normal"> | |||
<dt>Type:</dt> | <dt>Type:</dt> | |||
<dd>161</dd> | <dd>161</dd> | |||
<dt>Length:</dt> | <dt>Length:</dt> | |||
<dd>The length, in octets, of the following fields.</dd> | <dd>The length, in octets, of the following fields.</dd> | |||
<dt>C (Client):</dt> | <dt>C (Client):</dt> | |||
<dd> | <dd>This bit is set to indicate that the router advertising this | |||
This bit is set to indicate that the | adjacency is a flood reflector client. When this bit is NOT set, the | |||
router advertising this adjacency | router advertising this adjacency is a flood reflector. | |||
is a flood reflector client. When | ||||
this bit is NOT set, the router advertising | ||||
this adjacency is a flood reflect | ||||
or. | ||||
</dd> | ||||
<dt>RESERVED:</dt> | ||||
<dd> | ||||
This field is reserved for future use | ||||
. It MUST be set to 0 when sent | ||||
and MUST be ignored when received | ||||
. | ||||
</dd> | </dd> | |||
<dt>Reserved:</dt> | ||||
<dd>This field is reserved for future use. It <bcp14>MUST</bcp14> be | ||||
set to 0 when sent and <bcp14>MUST</bcp14> be ignored when received.</dd | ||||
> | ||||
<dt>Flood Reflection Cluster ID:</dt> | <dt>Flood Reflection Cluster ID:</dt> | |||
<dd> The Flood Reflection Cluster Identifier is | <dd>The Flood Reflection Cluster Identifier is the same as that | |||
the same as that defined in the F | defined in the Flood Reflection TLV in <xref target="sec_flood_reflectio | |||
lood Reflection TLV and obeys the same rules. | n_tlv"/> and obeys the same rules. | |||
</dd> | </dd> | |||
</dl> | </dl> | |||
<t> | <t>The Flood Reflection Adjacency sub-TLV <bcp14>SHOULD NOT</bcp14> | |||
The Flood Reflection Adjacency sub-TLV SHOULD NOT | appear more than once in a given TLV. A router receiving one or more | |||
appear more than once in a given TLV. A router | Flood Reflection Adjacency sub-TLVs in a TLV <bcp14>MUST</bcp14> use the | |||
receiving one or more Flood Reflection Adjacency | values in the first sub-TLV of the lowest numbered fragment, and it | |||
sub-TLVs in a TLV MUST use the values in the | <bcp14>SHOULD</bcp14> log such violations subject to rate-limiting. | |||
first sub-TLV of the lowest numbered fragment and | ||||
it SHOULD log such violations | ||||
subject to rate limiting. | ||||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="sec_discovery" numbered="true" toc="default"> | <section anchor="sec_discovery" numbered="true" toc="default"> | |||
<name>Flood Reflection Discovery</name> | <name>Flood Reflection Discovery</name> | |||
<t>A router participating in flood reflection as client or reflector MUST | <t>A router participating in flood reflection as client or reflector | |||
be configured as an L1/L2 router. | <bcp14>MUST</bcp14> be configured as an L1/L2 router. It | |||
It MAY originate the Flood Reflection Discovery sub-TLV w | <bcp14>MAY</bcp14> originate the Flood Reflection Discovery sub-TLV with | |||
ith area flooding scope in L1 and L2. | area flooding scope in L1 and L2. Normally, all routers on the edge of | |||
Normally, all routers on the edge of the L1 area (those h | the L1 area (those having standard L2 adjacencies) will advertise | |||
aving traditional L2 adjacencies) | themselves as flood reflector clients. Therefore, a flood reflector | |||
will advertise themselves as flood reflector clients. The | client will have both standard L2 adjacencies and flood reflector L2 | |||
refore, a flood reflector client | adjacencies. | |||
will have both traditional L2 adjacencies and flood refle | ||||
ctor L2 adjacencies. | ||||
</t> | </t> | |||
<t> A router acting as a flood reflector MUST NOT form any traditional L2 | <t>A router acting as a flood reflector <bcp14>MUST NOT</bcp14> form any | |||
adjacencies except | standard L2 adjacencies except with flood reflector clients. It will | |||
with flood reflector clients. It will | be an L1/L2 router only by virtue of having flood reflector L2 | |||
be an L1/L2 router only by virtue of having flood reflec | adjacencies. A router desiring to act as a flood reflector | |||
tor L2 adjacencies. A router | <bcp14>MAY</bcp14> advertise itself as such using the Flood Reflection | |||
desiring to act as a flood reflector MAY advertise itsel | Discovery sub-TLV in L1 and L2. | |||
f as such using | ||||
the Flood Reflection Discovery sub-TLV in L1 and L2. | ||||
</t> | </t> | |||
<t> | <t>A given flood reflector or flood reflector client can only | |||
A given flood reflector or flood reflector client can onl | participate in a single cluster, as determined by the value of its Flood | |||
y participate in a single cluster, | Reflection Cluster ID and should disregard other routers' TLVs for flood | |||
as determined by the value of its Flood Reflection Cluste | reflection purposes if the cluster ID is not matching. | |||
r ID and should disregard other | ||||
routers' TLVs for flood reflection purposes if the cluster ID is not | ||||
matching. | ||||
</t> | </t> | |||
<t>Upon reception of Flood Reflection Discovery sub-TLVs, a router acting | <t>Upon reception of Flood Reflection Discovery sub-TLVs, a router | |||
as | acting as flood reflector <bcp14>SHOULD</bcp14> initiate a tunnel | |||
flood reflector SHOULD initiate a tunnel towards each flo | towards each flood reflector client with which it shares a Flood | |||
od reflector client with which | Reflection Cluster ID, using one or more of the tunnel encapsulations | |||
it shares a Flood Reflection Cluster ID using one or more | provided with F flag is set. The L2 adjacencies formed over such | |||
of the tunnel encapsulations | tunnels <bcp14>MUST</bcp14> be marked as flood reflector adjacencies. | |||
provided with F flag is set. | If the client or reflector has a direct L2 adjacency with the according | |||
The L2 adjacencies formed | remote side, it <bcp14>SHOULD</bcp14> use it instead of instantiating a | |||
over such tunnels MUST be marked as flood reflector adjac | tunnel. | |||
encies. | ||||
If the client or reflector has a direct L2 adjacency with | ||||
the according remote side | ||||
it SHOULD use it | ||||
instead of instantiating a tunnel. | ||||
</t> | </t> | |||
<t>In case the optional auto-discovery mechanism is not implemented or e | <t>In case the optional auto-discovery mechanism is not implemented or | |||
nabled a deployment | enabled, a deployment <bcp14>MAY</bcp14> use statically configured | |||
MAY use statically configured tunnels to create flood reflection adj | tunnels to create flood reflection adjacencies. | |||
acencies. | ||||
</t> | </t> | |||
<t> | <t>The IS-IS metrics for all flood reflection adjacencies in a cluster | |||
The IS-IS metrics for all flood reflection adjacencies in a cluster | <bcp14>SHOULD</bcp14> be identical. | |||
SHOULD be identical. | ||||
</t> | </t> | |||
<t>Upon reception of Flood Reflection Discovery TLVs, a router acting as | <t>Upon reception of Flood Reflection Discovery TLVs, a router acting as | |||
a flood reflector client | a flood reflector client <bcp14>MAY</bcp14> initiate tunnels with | |||
MAY initiate tunnels with L1-only adjacencies towards | L1-only adjacencies towards any of the other flood reflector clients | |||
any of the other flood reflector clients with lower route | with lower router IDs in its cluster using encapsulations with F flag | |||
r IDs in its cluster using encapsulations with | clear. These tunnels <bcp14>MAY</bcp14> be used for forwarding to | |||
F flag clear. These tunnels MAY be used for | improve the load-balancing characteristics of the L1 area. If the | |||
forwarding to improve the load-balancing characteristics | clients have a direct L2 adjacency, they <bcp14>SHOULD</bcp14> use it | |||
of the L1 area. | instead of instantiating a new tunnel. | |||
If the clients have a direct L2 adjacency | ||||
they SHOULD use it | ||||
instead of instantiating a new tunnel. | ||||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="sec_adj" numbered="true" toc="default"> | <section anchor="sec_adj" numbered="true" toc="default"> | |||
<name>Flood Reflection Adjacency Formation</name> | <name>Flood Reflection Adjacency Formation</name> | |||
<t> | <t> | |||
In order to simplify implementation complexity, this docu ment does not | In order to simplify implementation complexity, this docu ment does not | |||
allow the formation of complex hierarchies of flood refle ctors and clients or allow | allow the formation of complex hierarchies of flood refle ctors and clients or allow | |||
multiple clusters in a single L1 area. | multiple clusters in a single L1 area. | |||
<!-- @todo: do we make it a SHOULD? --> | <!-- @todo: do we make it a SHOULD? --> | |||
Consequently, all flood reflectors and flood reflector clients in the same L1 area MUST share the same | Consequently, all flood reflectors and flood reflector clients in the same L1 area <bcp14>MUST</bcp14> share the same | |||
Flood Reflector Cluster ID. Deployment of multiple cluste r IDs in the same L1 area are outside the scope | Flood Reflector Cluster ID. Deployment of multiple cluste r IDs in the same L1 area are outside the scope | |||
of this document. | of this document. | |||
</t> | </t> | |||
<t> | <t> | |||
A flood reflector MUST NOT form flood reflection adjacencies wit h flood reflector clients | A flood reflector <bcp14>MUST NOT</bcp14> form flood reflection adjacencies with flood reflector clients | |||
with a different Cluster ID. | with a different Cluster ID. | |||
A flood reflector MUST NOT form any traditional L2 adjacencies. | A flood reflector <bcp14>MUST NOT</bcp14> form any standard L2 a djacencies. | |||
</t> | </t> | |||
<t> | <t> | |||
Flood reflector clients MUST NOT form flood reflection adjacenci es with flood reflectors | Flood reflector clients <bcp14>MUST NOT</bcp14> form flood refle ction adjacencies with flood reflectors | |||
with a different Cluster ID. | with a different Cluster ID. | |||
</t> | </t> | |||
<t> | <t> | |||
Flood reflector clients MAY form traditional L2 adjacencies with flood reflector clients | Flood reflector clients <bcp14>MAY</bcp14> form standard L2 adja cencies with flood reflector clients | |||
or nodes not participating in flood reflection. When two flood r eflector | or nodes not participating in flood reflection. When two flood r eflector | |||
clients form a traditional L2 | clients form a standard L2 | |||
adjacency the Cluster IDs are disregarded. | adjacency, the Cluster IDs are disregarded. | |||
</t> | </t> | |||
<t> | <t> | |||
The Flood Reflector Cluster ID and flood reflector | The Flood Reflector Cluster ID and flood reflector | |||
roles advertised in the Flood Reflection TLVs in IIHs are used to ensure | roles advertised in the Flood Reflection TLVs in IIHs are used to ensure | |||
that flood reflection adjacencies that are established me et the above criteria. | that flood reflection adjacencies that are established me et the above criteria. | |||
</t> | </t> | |||
<t> | <t> | |||
On change in either flood reflection role or cluster ID on IIH o n the local or remote side | On change in either flood reflection role or cluster ID on IIH o n the local or remote side, | |||
the adjacency has to be | the adjacency has to be | |||
reset. It is then re-established if possible. | reset. It is then re-established if possible. | |||
</t> | </t> | |||
<t> | <t> | |||
Once a flood reflection adjacency is established, the flo od reflector and the flood | Once a flood reflection adjacency is established, the flo od reflector and the flood | |||
reflector client MUST advertise the adjacency by includin | reflector client <bcp14>MUST</bcp14> advertise the adjace | |||
g the Flood Reflection Adjacency | ncy by including the Flood Reflection Adjacency | |||
Sub-TLV in the Extended IS reachability TLV or MT-ISN TLV | Sub-TLV in the Extended IS reachability TLV or Multi-Topo | |||
.</t> | logy Intermediate System Neighbor (MT-ISN) TLV.</t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="sec_route_comp" numbered="true" toc="default"> | <section anchor="sec_route_comp" numbered="true" toc="default"> | |||
<name>Route Computation</name> | <name>Route Computation</name> | |||
<t> | <t> | |||
To ensure loop-free routing, the flood reflection client MUST follow the normal L2 computation | To ensure loop-free routing, the flood reflection client <bcp14>MUST</bcp14> follow the normal L2 computation | |||
to determine L2 routes. This is because nodes outside the L1 area will generally | to determine L2 routes. This is because nodes outside the L1 area will generally | |||
not be aware that flood reflection is being performed. Th e flood reflection clients | not be aware that flood reflection is being performed. Th e flood reflection clients | |||
need to produce the same result for the L2 route computat ion as a router not participating in | need to produce the same result for the L2 route computat ion as a router not participating in | |||
flood reflection. | flood reflection. | |||
</t> | </t> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Tunnel-Based Deployment</name> | <name>Tunnel-Based Deployment</name> | |||
<t> | <t> | |||
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, <bcp14>MUST</bcp14> examine all L2 routes with flood ref | |||
adjacencies. | lector next-hop adjacencies. | |||
Such next-hops must | Such next hops must | |||
be replaced by the corresponding | be replaced by the corresponding | |||
tunnel next-hops to the correct egress nodes of the flood reflection cluster. | tunnel next hops to the correct egress nodes of the flood reflection cluster. | |||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="no_tunnels" numbered="true" toc="default"> | <section anchor="no_tunnels" numbered="true" toc="default"> | |||
<name>No-Tunnel Deployment</name> | <name>No-Tunnel Deployment</name> | |||
<t>In case of deployment without underlying tunnels, the necessary L | <t>In case of deployment without underlying tunnels, the necessary | |||
2 routes are distributed | L2 routes are distributed into the area, normally as L2->L1 | |||
into the area, normally as L2->L1 routes. | routes. | |||
Due to the rules in <xref target="sec_adj" format | ||||
="default"/> | Due | |||
the computation in the resulting topology | to the rules in <xref target="sec_adj"/>, the computation in the resulting to | |||
is relatively simple, the L2 SPF from a flood ref | pology | |||
lector client | is relatively simple: the L2 SPF from a flood reflector client is | |||
is guaranteed to reach the Flood Reflector within a singl | guaranteed to reach the Flood Reflector within a single hop, and in | |||
e hop, and in the following hop the L2 | the following hop, it is guaranteed to reach the L2 egress to which | |||
egress to which it has a forwarding tunnel. All the flood | it has a forwarding tunnel. | |||
reflector tunnel nexthops in the according | ||||
L2 route can hence be removed and if the L2 route has no other E | All the flood reflector tunnel next hops in the according | |||
CMP L2 nexthops, the L2 route MUST | L2 route can hence be removed, and if the L2 route has no other | |||
be suppressed in the RIB by some means to allow the less preferr | ECMP L2 next hops, the L2 route <bcp14>MUST</bcp14> be suppressed | |||
ed L2->L1 route to be used | in the RIB by some means to allow the less preferred L2->L1 route | |||
to forward traffic towards the advertising egress. | to be used to forward traffic towards the advertising egress. | |||
</t> | </t> | |||
<t> | <t>In the particular case the client has L2 routes which are not | |||
In the particular case the client has L2 routes | flood reflected, those will be naturally preferred (such routes | |||
which are not flood reflected, those will be natu | normally "hot-potato" packets out of the L1 area). However, in the | |||
rally preferred (such routes | case the L2 route through the flood reflector egress is "shorter" | |||
normally | than such present L2 routes that are not flood reflected, the node | |||
"hot-potato" packets out of the L1 area). However | <bcp14>SHOULD</bcp14> ensure that such routes are suppressed so | |||
in the case the L2 route through the flood reflector egress is "shor | the L2->L1 towards the egress still takes preference. Observe that | |||
ter" than such present non | operationally this can be resolved in a relatively simple way by | |||
flood reflected L2 | configuring flood reflector adjacencies to have a high metric, | |||
routes, the node SHOULD ensure that such routes are suppressed so th | i.e., the flood reflector topology becomes "last resort," and the | |||
e L2->L1 towards the egress | leaves will try to "hot-potato" out the area as fast as possible, | |||
still takes preference. Observe that operationally this can be resol | which is normally the desirable behavior.</t> | |||
ved in a relatively | ||||
simple way by configuring flood reflector adjacencies to 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 as possible which is normally the desirable behavior.</t> | ||||
<t>In No-tunnel deployment all L1/L2 edge nodes MUST be | <t>In no-tunnel deployment, all L1/L2 edge nodes <bcp14>MUST</bcp14> be | |||
flood reflection | flood reflection | |||
clients.</t> | clients.</t> | |||
<t></t> | <t></t> | |||
</section> | </section> | |||
</section> | </section> | |||
<section anchor="sec_prefixes" numbered="true" toc="default"> | <section anchor="sec_prefixes" numbered="true" toc="default"> | |||
<name>Redistribution of Prefixes</name> | <name>Redistribution of Prefixes</name> | |||
<t> | <t> | |||
In case of no-tunnel deployment per <xref target="no_tunnels"/> a client that does not | In case of no-tunnel deployment per <xref target="no_tunnels"/>, a client that does not | |||
have | have | |||
any L2 flood reflector adjacencies MUST NOT redistribute L2 routes into | any L2 flood reflector adjacencies <bcp14>MUST NOT</bcp14> redistr ibute L2 routes into | |||
the cluster. | the cluster. | |||
</t> | </t> | |||
<t> | <t> | |||
The L2 prefix advertisements redistributed into an L1 that contain s flood reflectors | The L2 prefix advertisements redistributed into an L1 that contain s flood reflectors | |||
SHOULD be normally limited to L2 intra-area routes (as defined in <xref target="RFC7775" format="default"/>), | <bcp14>SHOULD</bcp14> be normally limited to L2 intra-area routes (as defined in <xref target="RFC7775" format="default"/>) | |||
if the information exists to distinguish them from other L2 prefix advertisements. | if the information exists to distinguish them from other L2 prefix advertisements. | |||
</t> | </t> | |||
<t> | <t> | |||
On the other hand, in topologies that make use of flood reflection to hide the structure of L1 areas | On the other hand, in topologies that make use of flood reflection to hide the structure of L1 areas | |||
while still providing transit forwarding across them using tunnels , we generally do not need to | while still providing transit-forwarding across them using tunnels , we generally do not need to | |||
redistribute L1 prefix advertisements into L2. | redistribute L1 prefix advertisements into L2. | |||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="patholody" numbered="true" toc="default"> | <section anchor="patholody" numbered="true" toc="default"> | |||
<name>Special Considerations</name> | <name>Special Considerations</name> | |||
<t> | <t>In pathological cases, setting the overload bit in L1 (but not in L2) | |||
In pathological cases setting the overload bit in L1 (but | can partition L1 forwarding, while allowing L2 reachability through | |||
not in L2) can partition | flood reflector adjacencies to exist. In such a case, a node cannot | |||
L1 forwarding, while allowing L2 reachability through flo | replace a route through a flood reflector adjacency with an L1 shortcut, | |||
od reflector adjacencies | and the client <bcp14>MAY</bcp14> use the L2 tunnel to the flood | |||
to exist. In such a case a node cannot replace a route | reflector for forwarding. In all those cases, the node | |||
through a flood reflector adjacency with a L1 shortcut an | <bcp14>MUST</bcp14> initiate an alarm and declare misconfiguration. | |||
d the client MAY use the | ||||
L2 tunnel to the flood reflector for forwarding but in an | ||||
y case it MUST initiate an alarm | ||||
and declare misconfiguration. | ||||
</t> | </t> | |||
<t> | <t>A flood reflector with directly L2 attached prefixes should advertise | |||
A flood reflector with directly L2 attached prefixes shou | those in L1 as well since, based on preference of L1 routes, the clients | |||
ld advertise those in L1 | will not try to use the L2 flood reflector adjacency to route the packet | |||
as well since based on preference of L1 routes the client | towards them. A very unlikely corner case can occur when the flood | |||
s will not try to use | reflector is reachable via L2 flood reflector adjacency (due to | |||
the L2 flood reflector adjacency to route the packet towa | underlying L1 partition) exclusively. In this instance, the client can use | |||
rds them. A very unlikely | the L2 tunnel to the flood reflector for forwarding towards those | |||
corner case can occur when the flood reflector is reachab | prefixes while it <bcp14>MUST</bcp14> initiate an alarm and declare | |||
le via L2 flood reflector adjacency | misconfiguration. | |||
(due to underlying L1 partition) exclusively, in which ca | ||||
se the client can use the | ||||
L2 tunnel to the flood reflector for forwarding towards t | ||||
hose prefixes | ||||
while it MUST initiate an alarm and declare misconfigurat | ||||
ion. | ||||
</t> | </t> | |||
<t>A flood reflector MUST NOT set the attached bit on its LSPs. | <t>A flood reflector <bcp14>MUST NOT</bcp14> set the attached bit on its | |||
LSPs. | ||||
</t> | </t> | |||
<t> | <t>In certain cases where reflectors are attached to the same broadcast | |||
medium, and where some other L2 router that is neither a flood | ||||
In certain cases where reflectors are attached to | reflector nor a flood reflector client (a "non-FR router", i.e., a router | |||
same broadcast medium, and where some other L2 router, | not participating in flood reflection) attaches to | |||
which is neither a flood reflector nor a flood reflector client (a “no | the same broadcast medium, flooding between the reflectors in question | |||
n-FR router”), | might not succeed, potentially partitioning the flood reflection | |||
attaches to the same broadcast medium, | domain. This could happen specifically in the event that the non-FR | |||
flooding between the reflectors in question might | router is chosen as the Designated Intermediate System (DIS) -- the | |||
not succeed, potentially partitioning the flood reflection domain. Thi | designated router. Since, per <xref target="sec_adj"/>, a flood | |||
s could happen | reflector <bcp14>MUST NOT</bcp14> form an adjacency with a non-FR | |||
specifically in the | router, the flood reflector(s) will not be represented in the | |||
event that the non-FR router is chosen as the designated intermediate | pseudo-node. | |||
system | ||||
(“DIS”, the designated router). | ||||
Since, per <xref target="sec_adj"/>, a flood reflector MUST NOT form a | ||||
n adjacency with a non-FR router, | ||||
the flood reflector(s) will not be represented in the pseudo-node. | ||||
</t> | </t> | |||
<t> | <t> | |||
To avoid this situation, it is RECOMMENDED that flood reflectors not b e deployed on the same broadcast | To avoid this situation, it is <bcp14>RECOMMENDED</bcp14> that flood r eflectors not be deployed on the same broadcast | |||
medium as non-FR routers. | medium as non-FR routers. | |||
</t> | </t> | |||
<t> | <t> | |||
A router discovering such condition | A router discovering such condition | |||
MUST initiate an alarm and declare misconfiguration. | <bcp14>MUST</bcp14> initiate an alarm and declare misconfiguration. | |||
</t> | </t> | |||
</section> | </section> | |||
<section anchor="IANA" toc="default" numbered="true"> | <section anchor="IANA" toc="default" numbered="true"> | |||
<name>IANA Considerations</name> | <name>IANA Considerations</name> | |||
<t>This document requests allocation for the following IS-IS TLVs and | <t>IANA has assigned the following IS-IS TLVs and sub-TLVs and has created | |||
Sub-TLVs, and requests creation of a new registry.</t> | a new registry.</t> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>New IS-IS TLV Codepoint</name> | <name>New IS-IS TLV Codepoint</name> | |||
<t>This document requests the following IS-IS TLV under the | <t>The following IS-IS TLV has been registered in the | |||
IS-IS Top-Level TLV Codepoints registry::</t> | "IS-IS Top-Level TLV Codepoints" registry:</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[Value Name | <table anchor="is-is-tlv-codepoint" align="center"> | |||
IIH LSP SNP Purge | <name>Flood Reflection IS-IS TLV Codepoint</name> | |||
161 Flood Reflection y n n n | <thead> | |||
<tr> | ||||
]]></artwork> | <th>Value</th> | |||
<th>Name</th> | ||||
<th>IIH</th> | ||||
<th>LSP</th> | ||||
<th>SNP</th> | ||||
<th>Purge</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td>161</td> | ||||
<td>Flood Reflection</td> | ||||
<td>y</td> | ||||
<td>n</td> | ||||
<td>n</td> | ||||
<td>n</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Sub TLVs for IS-IS Router CAPABILITY TLV</name> | <name>Sub-TLVs for IS-IS Router CAPABILITY TLV</name> | |||
<t>This document request the following registration in the "sub-TLVs | <t>The following has been registered in the "IS-IS Sub-TLVs | |||
for IS-IS Router CAPABILITY TLV" registry.</t> | for IS-IS Router CAPABILITY TLV" registry:</t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[Type Description | ||||
161 Flood Reflection Discovery | ||||
]]></artwork> | <table anchor="is-is-router-capability" align="center"> | |||
<t/> | <name>IS-IS Router CAPABILITY TLV</name> | |||
<thead> | ||||
<tr> | ||||
<th>Type</th> | ||||
<th>Description</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td>161</td> | ||||
<td>Flood Reflection Discovery</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Sub-sub TLVs for Flood Reflection Discovery sub-TLV</name> | <name>Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV</name> | |||
<t> | <t>IANA has created a new registry named | |||
"IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV" under th | ||||
This document requests creation of a new registry named | e | |||
"Sub-sub TLVs for Flood Reflection Discovery sub-TLV" under th | "IS-IS TLV Codepoints" grouping. The registration procedure for | |||
e | this registry is Expert Review <xref target="RFC8126"/>, following t | |||
"IS-IS TLV Codepoints" grouping. The Registration Procedures | he common expert | |||
for this registry are Expert Review, following the common | review guidance given for the grouping. | |||
expert review guidance given for the grouping. | ||||
</t> | ||||
<t> | ||||
The range of values in this registry is 0-255. The registry | ||||
should be seeded with the following initial registration: | ||||
</t> | </t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[Type Descript | <t>The range of values in this registry is 0-255. The registry | |||
ion | contains the following initial registration:</t> | |||
161 Flood Reflection Discovery Tunnel Encapsulation Attribute | <table anchor="sub-sub-tlv-flood-reflection" align="center"> | |||
<name>IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV</name> | ||||
]]></artwork> | <thead> | |||
<t/> | <tr> | |||
<th>Type</th> | ||||
<th>Description</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td>161</td> | ||||
<td>Flood Reflection Discovery Tunnel Encapsulation Attribute</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</section> | </section> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Sub TLVs for TLVs Advertising Neighbor Information</name> | <name>Sub-TLVs for TLVs Advertising Neighbor Information</name> | |||
<t>This document requests the following registration in the "IS-IS | <t>The following has been registered in the "IS-IS | |||
Sub-TLVs for TLVs Advertising Neighbor Information" registry. | Sub-TLVs for TLVs Advertising Neighbor Information" registry; | |||
</t> | </t> | |||
<artwork name="" type="" align="left" alt=""><![CDATA[ | <table anchor="sub-tlv-advertising-neighbor-info" align="center"> | |||
Type Description 22 23 25 141 222 223 | <name>IS-IS Sub-TLVs for TLVs Advertising Neighbor Information</name> | |||
161 Flood Reflector Adjacency y y n y y y | <thead> | |||
<tr> | ||||
]]></artwork> | <th>Type</th> | |||
<th>Description</th> | ||||
<th>22</th> | ||||
<th>23</th> | ||||
<th>25</th> | ||||
<th>141</th> | ||||
<th>222</th> | ||||
<th>223</th> | ||||
</tr> | ||||
</thead> | ||||
<tbody> | ||||
<tr> | ||||
<td>161</td> | ||||
<td>Flood Reflector Adjacency</td> | ||||
<td>y</td> | ||||
<td>y</td> | ||||
<td>n</td> | ||||
<td>y</td> | ||||
<td>y</td> | ||||
<td>y</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</section> | </section> | |||
</section> | </section> | |||
<section numbered="true" toc="default"> | <section numbered="true" toc="default"> | |||
<name>Security Considerations</name> | <name>Security Considerations</name> | |||
<t>This document uses flood reflection tunnels to carry IS-IS control traf fic. | <t>This document uses flood reflection tunnels to carry IS-IS control traf fic. | |||
If an attacker can inject traffic into such a tunnel, the consequences could | If an attacker can inject traffic into such a tunnel, the consequences could | |||
be in the most extreme case the complete subversion of the IS-IS level | be (in the most extreme case) the complete subversion of the IS-IS Lev | |||
2 information. | el 2 information. | |||
Therefore, a mechanism inherent to the tunnel technology should be tak | Therefore, a mechanism inherent to the tunnel technology should be use | |||
en to prevent such injection. | d to prevent such injection. | |||
Since the available security procedures will vary by deployment and tu nnel type, | Since the available security procedures will vary by deployment and tu nnel type, | |||
the details of securing tunnels are beyond the scope of this document. | the details of securing tunnels are beyond the scope of this document. | |||
</t> | </t> | |||
<t> | <t> | |||
This document specifies information used to form dynamically discove red shortcut tunnels. | This document specifies information used to form dynamically discove red shortcut tunnels. | |||
If an attacker were able to hijack the endpoint of such a tunnel and form an adjacency, it could divert | If an attacker were able to hijack the endpoint of such a tunnel and form an adjacency, it could divert | |||
short-cut traffic to itself, | shortcut traffic to itself, | |||
placing itself on-path and facilitating on-path attacks or could eve | placing itself on-path and facilitating on-path attacks, or it could | |||
n completely subvert the IS-IS level 2 | even completely subvert the IS-IS Level 2 | |||
routing. | routing. | |||
Therefore, steps should be taken to prevent such capture by using me chanism inherent to the | Therefore, steps should be taken to prevent such capture by using me chanism inherent to the | |||
tunnel type used. | tunnel type used. | |||
Since the available security procedures will vary by deployment and | Since the available security procedures will vary by deployment and tu | |||
tunnel type, | nnel type, | |||
the details of securing tunnels are beyond the scope of this documen | the details of securing tunnels are beyond the scope of this document. | |||
t. | ||||
</t> | </t> | |||
<t> | ||||
Additionally, the usual IS-IS security mechanisms <xref target="RFC5 | <t> | |||
304" format="default"/> SHOULD be | Additionally, the usual IS-IS security mechanisms <xref target="RFC5304"/> SH | |||
deployed to prevent misrepresentation of routing information by an a | OULD be | |||
ttacker in case a tunnel is | deployed to prevent misrepresentation of routing information by an | |||
compromised if the tunnel itself does not provide mechanisms strong | attacker in case a tunnel is compromised and the tunnel itself does | |||
enough guaranteeing the integrity of the | not provide mechanisms strong enough to guarantee the integrity of | |||
messages exchanged. | the messages exchanged. | |||
</t> | ||||
</section> | ||||
<section numbered="true" toc="default"> | ||||
<name>Acknowledgements</name> | ||||
<t>The authors thank Shraddha Hegde, Peter Psenak, Acee Lindem, Robert Ras | ||||
zuk and Les Ginsberg for | ||||
their thorough review and detailed discussions. T | ||||
hanks 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. | ||||
</t> | </t> | |||
</section> | </section> | |||
</middle> | </middle> | |||
<back> | <back> | |||
<references> | <references> | |||
<name>References</name> | <name>References</name> | |||
<references> | <references> | |||
<name>Informative References</name> | <name>Normative References</name> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | |||
ence.RFC.4271.xml"/> | FC.2119.xml"/> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | |||
ence.RFC.4456.xml"/> | FC.5302.xml"/> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | |||
ence.RFC.8099.xml"/> | FC.5304.xml"/> | |||
<reference anchor="ID.draft-ietf-idr-bgp-optimal-route-reflection-28" ta | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | |||
rget="https://www.ietf.org/id/draft-ietf-idr-bgp-optimal-route-reflection-28.txt | FC.7775.xml"/> | |||
"> | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | |||
FC.7981.xml"/> | ||||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
FC.8126.xml"/> | ||||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
FC.8174.xml"/> | ||||
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | ||||
FC.9012.xml"/> | ||||
<reference anchor="ISO10589"> | ||||
<front> | <front> | |||
<title>BGP Optimal Route Reflection</title> | <title>Information technology - Telecommunications and information | |||
<author initials="R." surname="Raszuk et al."> | exchange between systems - Intermediate System to Intermediate | |||
<organization/> | System intra-domain routeing information exchange protocol for use | |||
in conjunction with the protocol for providing the | ||||
connectionless-mode network service (ISO 8473)</title> | ||||
<author> | ||||
<organization abbrev="ISO">International Organization for | ||||
Standardization</organization> | ||||
</author> | </author> | |||
<date month="July" year="2019"/> | <date month="November" year="2002"/> | |||
</front> | </front> | |||
<seriesInfo name="ISO/IEC" value="10589:2002"/> | ||||
<refcontent>Second Edition</refcontent> | ||||
</reference> | </reference> | |||
</references> | </references> | |||
<references> | <references> | |||
<name>Normative References</name> | <name>Informative References</name> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | |||
erence.RFC.2119.xml"/> | FC.4271.xml"/> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | |||
erence.RFC.5302.xml"/> | FC.4456.xml"/> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R | |||
erence.RFC.5304.xml"/> | FC.8099.xml"/> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF | |||
ence.RFC.7775.xml"/> | C.9107.xml"/> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | </references> | |||
ence.RFC.7981.xml"/> | </references> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref | ||||
erence.RFC.8174.xml"/> | <section numbered="false" toc="default"> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ref | <name>Acknowledgements</name> | |||
erence.RFC.9012.xml"/> | ||||
</references> | <t>The authors thank <contact fullname="Shraddha Hegde"/>, <contact | |||
</references> | fullname="Peter Psenak"/>, <contact fullname="Acee Lindem"/>, <contact | |||
</back> | fullname="Robert Raszuk"/>, and <contact fullname="Les Ginsberg"/> for their | |||
thorough review and detailed discussions. Thanks are also extended to <contact | ||||
fullname="Michael Richardson"/> for an excellent routing directorate | ||||
review. <contact fullname="John Scudder"/> ultimately spent significant time | ||||
helping to make the document more comprehensible and coherent. </t> | ||||
</section> | ||||
</back> | ||||
</rfc> | </rfc> | |||
End of changes. 146 change blocks. | ||||
677 lines changed or deleted | 606 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |