| 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. | ||||