rfc9692.original.xml   rfc9692.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- This template is for creating an Internet Draft using xml2rfc, which is ava
ilable here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-rift-rift-24" ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" ver
sion="3">
<!-- xml2rfc v2v3 conversion 2.45.3 -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<front>
<!-- The abbreviated title is used in the page header - it is
only necessary if the
full title is longer than 39 characters -->
<title abbrev="RIFT">RIFT: Routing in Fat Trees</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-rift-rift-24"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Tony Przygienda" initials="A." surname="Przygienda" r <!DOCTYPE rfc [
ole="editor"> <!ENTITY nbsp "&#160;">
<organization>Juniper Networks</organization> <!ENTITY zwsp "&#8203;">
<address> <!ENTITY nbhy "&#8209;">
<postal> <!ENTITY wj "&#8288;">
<street>1137 Innovation Way ]>
</street>
<city>Sunnyvale</city>
<region>CA
</region>
<code>94089</code>
<country>USA
</country>
</postal>
<phone/>
<email>prz@juniper.net
</email>
<uri/>
</address>
</author>
<author fullname="Jordan Head" initials="J." surname="Head" role="editor">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1137 Innovation Way
</street>
<city>Sunnyvale</city>
<region>CA
</region>
<code>94089</code>
<country>USA
</country>
</postal>
<phone/>
<email>jhead@juniper.net
</email>
<uri/>
</address>
</author>
<author fullname="Alankar Sharma" initials="A" surname="Sharma">
<organization>Hudson River Trading</organization>
<address>
<postal>
<country>US</country>
</postal>
<email>as3957@gmail.com</email>
</address>
</author>
<author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization>Individual</organization>
<address>
<postal>
<country>FRANCE</country>
</postal>
<email>pascal.thubert@gmail.com</email>
</address>
</author>
<author fullname="Bruno Rijsman" initials="Bruno" surname="Rijsman">
<organization>Individual</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>brunorijsman@gmail.com</email>
</address>
</author>
<author fullname="Dmitry Afanasiev" initials="Dmitry" surname="Afanasiev">
<organization>Yandex</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>fl0w@yandex-team.ru</email>
</address>
</author>
<date year="2024"/>
<!-- If the month and year are both specified and are the current ones, xml2
rfc will fill
in the current day for you. If only the current year is specified, xml2
rfc will fill
in the current day and month for you. If the year is not the current on
e, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not s
pecified for the
purpose of calculating the expiry date). With drafts it is normally su
fficient to
specify just the year. -->
<!-- Meta-data Declarations --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-rift-rift-24" number="9692" consensus="true" ipr="trust200902" obsoletes="" u pdates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" sym Refs="true" sortRefs="true" version="3">
<area>Routing</area> <front>
<workgroup>RIFT Working Group</workgroup> <title abbrev="RIFT">RIFT: Routing in Fat Trees</title>
<!-- WG name at the upper left corner of the doc, <seriesInfo name="RFC" value="9692"/>
IETF is fine for individual submissions. <author fullname="Tony Przygienda" initials="T." surname="Przygienda" ro
If this element is not present, the default is "Network Working Group", le="editor">
which is used by the RFC Editor as a nod to the history of the IETF. -- <organization>Juniper Networks</organization>
> <address>
<postal>
<street>1137 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>United States of America</country>
</postal>
<email>prz@juniper.net</email>
</address>
</author>
<author fullname="Jordan Head" initials="J." surname="Head" role="editor"
>
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1137 Innovation Way</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>United States of America</country>
</postal>
<email>jhead@juniper.net</email>
</address>
</author>
<author fullname="Alankar Sharma" initials="A" surname="Sharma">
<organization>Hudson River Trading</organization>
<address>
<postal>
<country>United States of America</country>
</postal>
<email>as3957@gmail.com</email>
</address>
</author>
<author initials="P" surname="Thubert" fullname="Pascal Thubert">
<organization>Individual</organization>
<address>
<postal>
<country>France</country>
</postal>
<email>pascal.thubert@gmail.com</email>
</address>
</author>
<author fullname="Bruno Rijsman" initials="B" surname="Rijsman">
<organization>Individual</organization>
<address>
<email>brunorijsman@gmail.com</email>
</address>
</author>
<author fullname="Dmitry Afanasiev" initials="D" surname="Afanasiev">
<organization>Yandex</organization>
<address>
<email>fl0w@yandex-team.ru</email>
</address>
</author>
<date year="2024" month="December"/>
<!-- Keywords will be incorporated into HTML output <area>RTG</area>
files in a meta tag but they have no effect on text or nroff <workgroup>rift</workgroup>
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<keyword>Routing protocol</keyword>
<keyword>IGP</keyword>
<keyword>Anisotropic routing</keyword>
<keyword>Clos</keyword>
<keyword>Fat Tree</keyword>
<keyword>Cloud</keyword>
<keyword>Distance vector</keyword>
<keyword>Link state</keyword>
<keyword>Optimized flooding</keyword>
<keyword>Zeroconf</keyword>
<abstract> <abstract>
<t>This document defines a specialized, dynamic routing protocol for <t>This document defines a specialized, dynamic routing protocol for
Clos, fat tree, and variants thereof. These topologies were init Clos, Fat Tree, and variants thereof. These topologies were init
ially ially
used within crossbar interconnects, and consequently router and used within crossbar interconnects and consequently router and s
switch backplanes, witch backplanes,
but their characteristics make them ideal for constructing IP but their characteristics make them ideal for constructing IP
fabrics as well. The protocol specified by this document fabrics as well. The protocol specified by this document
is optimized toward the minimization of control plane state to s upport very is optimized towards the minimization of control plane state to support very
large substrates as well as the minimization of configuration an d operational complexity to allow large substrates as well as the minimization of configuration an d operational complexity to allow
for simplified deployment of said topologies. for a simplified deployment of said topologies.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default" anchor="intro_sec"> <section numbered="true" toc="default" anchor="intro_sec">
<name>Introduction</name> <name>Introduction</name>
<!--<t> ANISOTROPIC protocol could be used to describe RIFT in contrary to <!--<t> ANISOTROPIC protocol could be used to describe RIFT in contrary to
uniform information distribution</t>--> uniform information distribution</t>-->
<t><xref target="CLOS" format="default">Clos</xref> topologies <t><xref target="CLOS" format="default">Clos</xref> topologies
have gained prominence in today's networking, primarily as a have gained prominence in today's networking, primarily as a
result of result of
the paradigm shift towards a centralized data-center the paradigm shift towards a centralized data center
architecture that is poised to deliver a majority of architecture that is poised to deliver a majority of
computation and storage services computation and storage services
in the future. in the future.
Such networks are called commonly a fat Such networks are commonly called a Fat
tree/network in modern IP fabric considerations Tree / network in modern IP fabric considerations
<xref target="VAHDAT08" format="default"/> <xref target="VAHDAT08" format="default"/>
as homonym to the as a homonym to the
<xref target="FATTREE" format="default">original definition of t he term</xref>. <xref target="FATTREE" format="default">original definition of t he term</xref>.
In most generic terms, and disregarding exceptions like horizont al shortcuts, In most generic terms, and disregarding exceptions like horizont al shortcuts,
those networks are all variations of a structured design isomorp hic those networks are all variations of a structured design isomorp hic
to a ranked lattice to a ranked lattice
where the least upper bound is the "top of the fabric" and links closer where the least upper bound is the "top of the fabric" and links closer
to the top may be "fatter" to guarantee non-blocking bi-sectiona l to the top may be "fatter" to guarantee non-blocking bisectional
capacity. capacity.
</t> </t>
<t> <t>
<!-- removed due to AD input <!-- removed due to AD input
Today's current routing protocols were geared towards a Today's current routing protocols were geared towards a
network with an irregular topology and low degree of connectivit y originally network with an irregular topology and low degree of connectivit y originally
but given but given
they were the only available options, consequently they were the only available options, consequently
several several
skipping to change at line 211 skipping to change at line 151
modify BGP and the immanent difficulties with modify BGP and the immanent difficulties with
<xref <xref
target="DIJKSTRA">link-state</xref> target="DIJKSTRA">link-state</xref>
based protocols to optimize topology exchange and converge quick ly in based protocols to optimize topology exchange and converge quick ly in
large scale densely meshed topologies. The incumbent protocols p recondition large scale densely meshed topologies. The incumbent protocols p recondition
normally extensive configuration or provisioning during bring up and normally extensive configuration or provisioning during bring up and
re-dimensioning. This tends to be viable only for a set of orga nizations with re-dimensioning. This tends to be viable only for a set of orga nizations with
according networking operation skills and budgets. according networking operation skills and budgets.
--> -->
Many builders of such IP fabrics Many builders of such IP fabrics
desire a protocol that auto-configures itself desire a protocol that autoconfigures itself
and deals with failures and mis-configurations with a minimum of and deals with failures and misconfigurations with a minimum amo
human unt of human
intervention. Such a solution would allow local IP fabric bandw intervention.
idth to
be consumed in a 'standard component' fashion, i.e. provision it <!--[rfced] We are having difficulty parsing the final part of this sentence.
much Should "compute" be "computational resources" or otherwise?
Original:
Such a solution would allow local
IP fabric bandwidth to be consumed in a 'standard component' fashion,
i.e. provision it much faster and operate it at much lower costs than
today, much like compute or storage is consumed already.
Perhaps:
Such a solution would allow local
IP fabric bandwidth to be consumed in a "standard component" fashion,
i.e., provision it much faster and operate it at much lower costs than
today, similar to how computational resources (e.g., CPU, storage) are
consumed already.
-->
Such a solution would allow local IP fabric bandwidth to
be consumed in a "standard component" fashion, i.e., provision i
t much
faster and operate it at much lower costs than today, much like compute or storage faster and operate it at much lower costs than today, much like compute or storage
is consumed already. is consumed already.
</t> </t>
<t> <t>
In looking at the problem through the lens of such IP fabric In looking at the problem through the lens of such IP fabric
requirements, RIFT (Routing in Fat Trees) addresses those challe nges requirements, Routing in Fat Trees (RIFT) addresses those challe nges
not through an incremental not through an incremental
modification of either a link-state (distributed computation) modification of either a link-state (distributed computation)
or distance-vector (diffused computation) techniques but rather a or distance-vector (diffused computation) technique but rather a
mixture of both, briefly described as "link-state towards mixture of both, briefly described as "link-state towards
the spines" and "distance vector towards the leaves". In other words, "bottom" levels the spines" and "distance vector towards the leaves". In other words, "bottom" levels
are flooding their link-state information in are flooding their link-state information in
the "northern" direction while each node generates under normal the "northern" direction while each node generates under normal
conditions a "default route" and floods it in the "southern" dir ection. conditions a "default route" and floods it in the "southern" dir ection.
This type of protocol naturally supports This type of protocol naturally supports
highly desirable address aggregation. Alas, such highly desirable address aggregation.
<!--[rfced] To improve readability, may we make this sentence into two?
Original:
Alas, such aggregation could
drop traffic in cases of misconfiguration or while failures are being
resolved or even cause persistent network partitioning and this has
to be addressed by some adequate mechanism.
Perhaps:
Alas, such aggregation could
drop traffic in cases of misconfiguration or while failures are being
resolved. It could also cause persistent network partitioning, which has
to be addressed by some adequate mechanism.
-->
Alas, such
aggregation could drop aggregation could drop
traffic in cases of misconfiguration or while failures are being traffic in cases of misconfiguration or while failures are being
resolved or even cause persistent network partitioning and this resolved or even cause persistent network partitioning and this
has to be addressed by some adequate mechanism. has to be addressed by some adequate mechanism.
The approach RIFT takes The approach RIFT takes
is described is described
in <xref target="disaggregate" format="default"/> and is based o n automatic, sufficient disaggregation of prefixes in case in <xref target="disaggregate" format="default"/> and is based o n automatic, sufficient disaggregation of prefixes in case
of link and node failures.</t> of link and node failures.</t>
<t>The protocol further provides: <t>The protocol further provides:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>optional <li>optional fully automated construction of Fat Tree topologies based
fully automated construction of fat tree topologies base on detection of links without any configuration (<xref target="ZTP"
d format="default"/>) while allowing for conventional configuration
on detection of links without any configuration (<xref t methods or an arbitrary mix of both, </li>
arget="ZTP" format="default"/>), <li>the minimum amount of routing state held by nodes,</li>
while allowing for conventional configuration methods or <li>automatic pruning and load balancing of topology flooding
an arbitrary mix exchanges over a sufficient subset of links (<xref target="mpr"
of both, format="default"/>), </li>
</li> <li>automatic address aggregation (<xref target="defaultrouterules"
<li>minimum amount of routing format="default"/>) and consequently automatic disaggregation (<xref
state held by nodes,</li> target="disaggregate" format="default"/>) of prefixes on link and node
<li>automatic pruning and load balancing of topology flooding exchanges failures to prevent traffic loss and suboptimal routing, </li>
over a sufficient subset of links (<xref target="mpr" format="default"/>),
</li>
<li>automatic address aggregation (<xref target="defaultrouterules" form
at="default"/>) and consequently
automatic disaggregation (<xref target="disaggregate" fo
rmat="default"/>) of prefixes on link and node failures to
prevent traffic loss and suboptimal routing,
</li>
<li>loop-free non-ECMP forwarding due to its inherent valley-free <li>loop-free non-ECMP forwarding due to its inherent valley-free
nature, nature, </li>
</li> <li> fast mobility (<xref target="mobility"/>), </li>
<li> <li>rebalancing of traffic towards the spines based on bandwidth
fast mobility (<xref target="mobility"/>), available (<xref target="varydefault"/>), and finally</li>
</li> <li> mechanisms to synchronize a limited key-value datastore (<xref
<li>re-balancing of traffic towards the spines based on target="kv"/>) that can be used after protocol convergence to, e.g.,
bandwidth available (<xref target="varydefault"/>), and bootstrap higher levels of functionality on nodes.</li>
finally
</li>
<li>
mechanisms to synchronize a limited key-value data-store
(<xref target="kv"/>) that
can be used after protocol convergence to e.g.
bootstrap higher levels of functionality on nodes.
</li>
</ul> </ul>
<t><xref target="first-simple" format="default"/> <t><xref target="first-simple" format="default"/>
illustrates a simplified, conceptual view of a RIFT fabric with its routing tables and illustrates a simplified, conceptual view of a RIFT fabric with its routing tables and
topology databases using IPv4 as address family. topology databases using IPv4 as the address family.
The top of the fabric's link-state database holds information ab out the nodes below it The top of the fabric's link-state database holds information ab out the nodes below it
and the routes to them. When referring to <xref target="first-si mple" format="default"/>, and the routes to them. When referring to <xref target="first-si mple" format="default"/>,
/32 notation corresponds to each node's IPv4 loopback address /32 notation corresponds to each node's IPv4 loopback address
(e.g. A/32 is node A's loopback, etc.) and 0/0 indicates a defau lt IPv4 route. (e.g., A/32 is node A's loopback, etc.) and 0/0 indicates a defa ult IPv4 route.
The first row of database information represents the nodes for w hich full topology The first row of database information represents the nodes for w hich full topology
information is available. information is available.
The second row of database information indicates that partial in formation of other nodes in The second row of database information indicates that partial in formation of other nodes in
the same level is also available. Such information will be neede d the same level is also available. Such information will be neede d
to perform certain algorithms necessary for correct protocol ope ration. to perform certain algorithms necessary for correct protocol ope ration.
When the "bottom" (or in other words leaves) of the fabric is co nsidered, the topology is When the "bottom" (or in other words leaves) of the fabric is co nsidered, the topology is
basically empty and, under normal conditions, the leaves basically empty and, under normal conditions, the leaves
hold a load balanced default route to the next level. hold a load-balanced default route to the next level.
</t> </t>
<t>The remainder of this document fills in the protocol <t>The remainder of this document fills in the protocol
specification details. specification details.
</t> </t>
<figure anchor="first-simple"> <figure anchor="first-simple">
<name>RIFT Information Distribution</name> <name>RIFT Information Distribution</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rift- information-distribution.svg"><svg xmlns:dc="http://purl.org/dc/elements/1.1/" x mlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cc="http://creative commons.org/ns#" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org /2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile= "tiny" id="Layer_1" viewBox="0 0 439.6 493.8" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rift- information-distribution.svg"><svg xmlns:dc="http://purl.org/dc/elements/1.1/" x mlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:cc="http://creative commons.org/ns#" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org /2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile= "tiny" id="Layer_1" viewBox="0 0 439.6 493.8" xml:space="preserve">
<g id="layer3" transform="translate(-86.83375,-35.118133)"> <g id="layer3" transform="translate(-86.83375,-35.118133)">
skipping to change at line 482 skipping to change at line 450
0/0 @ [C,D] | A | | B | 0/0 @ [C,D] 0/0 @ [C,D] | A | | B | 0/0 @ [C,D]
+---------+ +---------+ +---------+ +---------+
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHAL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
L IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
, and only when, they be interpreted as
appear in all capitals, as shown here. described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default" anchor="digest"> <section numbered="true" toc="default" anchor="digest">
<name>A Reader's Digest</name> <name>A Reader's Digest</name>
<t>This section is an initial guided tour through the document in <t>This section is an initial guided tour through the document in
order to convey the necessary information for different readers, dependi ng on order to convey the necessary information for different readers, dependi ng on
their level of interest. The authors recommend reading the HTML or PDF v ersions their level of interest. The authors recommend reading the HTML or PDF v ersions
of this document due to the inherent limitation of text version to repre sent of this document due to the inherent limitation of text version to repre sent
complex figures.</t> complex figures.</t>
<t>The <xref target="glossary">Terminology</xref> section <t>The <xref target="glossary">"Terminology"</xref> section
should be used as a supporting reference as the document is read.</t> should be used as a supporting reference as the document is read.</t>
<t>The indications of direction (i.e. "top", "bottom", etc.) referenced <t>The indications of direction (i.e., "top", "bottom", etc.) referenced
in <xref target="intro_sec"/> are of paramount importance. in <xref target="intro_sec"/> are of paramount importance.
RIFT requires a topology with a sense of top and bottom in order to prop erly RIFT requires a topology with a sense of top and bottom in order to prop erly
achieve a sorted topology. Clos, Fat Tree, and other similarly structure d achieve a sorted topology. Clos, Fat Tree, and other similarly structure d
networks are conducive to such requirements. Where RIFT does allow for networks are conducive to such requirements. Where RIFT allows for furth
further er
relaxation of these constraints, this will be mentioned later in this relaxation of these constraints will be mentioned later in this
section.</t> section.</t>
<t>Several of the images in this document are annotated with "northern vie w" or "southern view" <t>Several of the images in this document are annotated with "northern vie w" or "southern view"
to indicate perspective to the reader. A "northern view" should be inter preted as "from the top of the fabric to indicate perspective to the reader. A "northern view" should be inter preted as "from the top of the fabric
looking down", looking down",
whereas "southern view" should be interpreted as "from the bottom lookin g up". whereas "southern view" should be interpreted as "from the bottom lookin g up".
</t> </t>
<t>Operators and implementors alike must decide whether multi-plane IP <t>Operators and implementors alike must decide whether multi-plane IP
fabrics are of interest for them. <xref target="topology_sec"/> fabrics are of interest for them. <xref target="topology_sec"/>
illustrates an example of both single-plane in illustrates an example of both single-plane in
<xref target="pic-topo-three" format="default"/> and multi-plane fabric in <xref target="pic-topo-three" format="default"/> and multi-plane fabric in
<xref target="partitioned-spine" format="default"/>. Multi-plane <xref target="partitioned-spine" format="default"/>. Multi-plane
fabrics require understanding of additional RIFT concepts (e.g. fabrics require understanding of additional RIFT concepts (e.g.,
negative disaggregation in <xref target="negdisaggreg"/>) negative disaggregation in <xref target="negdisaggreg"/>)
that are unnecessary in the context that are unnecessary in the context
of fabrics consisting of a single-plane only. The of fabrics consisting of a single-plane only.
<xref target="overview_sec">Overview</xref> and <xref target="overview_sec">"Overview"</xref> and
<xref target="Planes"/> aim to provide enough <xref target="Planes">"Generalized Topology View"</xref> aim to provide
enough
context to determine if multi-plane fabrics are of interest to the reade r. context to determine if multi-plane fabrics are of interest to the reade r.
The <xref target="Fallen">Fallen Leaf part</xref>, and additionally <xref target="Fallen">"Fallen Leaf Problem"</xref> and additionally
<xref target="discFallen"/> and Sections <xref target="discFallen" format="counter"/> and
<xref target="FixFallen"/> describe further <xref target="FixFallen" format="counter"/> describe further
considerations that are specific to multi-plane fabrics.</t> considerations that are specific to multi-plane fabrics.</t>
<t>The fundamental protocol concepts are described starting in the <t>The fundamental protocol concepts are described starting in
<xref target="specification_sec">specification part</xref>, but some <xref target="specification_sec">"Specification"</xref>, but some
sub-sections are less relevant unless the protocol is being implemented. subsections are less relevant unless the protocol is being implemented.
The <xref target="transportaiton_sec">protocol transport</xref> is of The <xref target="transportaiton_sec">protocol transport</xref> is of
particular importance for two reasons. First, it introduces RIFT's particular importance for two reasons. First, it introduces RIFT's
packet format content in the form of a normative <xref target="thrift" f ormat="default">Thrift</xref> model given in packet format content in the form of a normative <xref target="thrift" f ormat="default">Thrift</xref> model given in
<xref target="encoding_thrift_app"/> which is carried in according <xref target="encoding_thrift_app"/>, which is carried in an according
security envelope as described in <xref target="security-envelope"/>. Second, the security envelope as described in <xref target="security-envelope"/>. Second, the
Thrift model component is a prerequisite to understanding the RIFT's Thrift model component is a prerequisite to understanding the RIFT's
inherent security features as defined in both <xref target="security-sec inherent security features as defined in both <xref target="security-sec
tion">security models part</xref> and the tion">"Security"</xref> and
<xref target="security">security segment</xref>. The normative <xref target="security">"Security Considerations"</xref>. The normati
ve
schema defining the Thrift model can be found in schema defining the Thrift model can be found in
<xref target="common_thrift_app"/> and Sections <xref target="common_thrift_app" format="counter"/> and
<xref target="encoding_thrift_app"/>. Furthermore, <xref target="encoding_thrift_app" format="counter"/>. Furthermore,
while a detailed understanding of <xref target="thrift">Thrift</xref> an while a detailed understanding of <xref target="thrift">Thrift</xref> an
d the models is not required unless d the model is not required unless
implementing RIFT, they may provide additional useful information for implementing RIFT, they may provide additional useful information for
other readers.</t> other readers.</t>
<t>If implementing RIFT to support multi-plane topologies <t>If implementing RIFT to support multi-plane topologies,
<xref target="specification_sec"/> should be <xref target="specification_sec"/> should be
reviewed in its entirety in conjunction with the previously mentioned reviewed in its entirety in conjunction with the previously mentioned
Thrift schemas. Sections not relevant to single-plane implementations Thrift schemas. Sections not relevant to single-plane implementations
will be noted later in this section. will be noted later in this section.
</t> </t>
<t> All readers dealing with implementation of the protocol <t> All readers dealing with implementation of the protocol
should pay special attention should pay special attention
to the <xref target="LIE">Link Information Element (LIE) definitions par to the <xref target="LIE">Link Information Element (LIE) definitions</xr
t</xref> as it ef> as it
not only outlines basic neighbor discovery and adjacency formation, not only outlines basic neighbor discovery and adjacency formation
but also provides necessary context for RIFT's optional <xref target="ZT but also provides necessary context for RIFT's optional <xref target="ZT
P">Zero Touch Provisioning (ZTP)</xref> and mis-cabling P">Zero Touch Provisioning (ZTP)</xref> and miscabling
detection capabilities that allow it to automatically detect and build t he detection capabilities that allow it to automatically detect and build t he
underlay topology with basically no configuration. These specific underlay topology with basically no configuration. These specific
capabilities are detailed in <xref target="ZTP"/>.</t> capabilities are detailed in <xref target="ZTP"/>.</t>
<t>For other readers, the following sections provide a more detailed <t>For other readers, the following sections provide a more detailed
understanding of the fundamental properties and highlight some additiona l benefits understanding of the fundamental properties and highlight some additiona l benefits
of RIFT such as link state packet formats, efficient flooding, synchroni of RIFT, such as link-state packet formats, efficient flooding, synchron
zation, ization,
loop-free path computation and loop-free path computation, and
link-state link-state
database maintenance - database maintenance (see Sections
<xref target="ties"/>, <xref target="ties" format="counter"/>,
<xref target="n_and_s_rep_sec"/>, <xref target="n_and_s_rep_sec" format="counter"/>,
<xref target="flooding_sec"/>, <xref target="flooding_sec" format="counter"/>,
<xref target="tiescopes"/>, <xref target="tiescopes" format="counter"/>,
<xref target="lsdb_sync_sec"/>, <xref target="lsdb_sync_sec" format="counter"/>,
<xref target="lsdb_purge_sec"/>, <xref target="lsdb_purge_sec" format="counter"/>,
<xref target="defaultrouterules"/>, <xref target="defaultrouterules" format="counter"/>,
<xref target="calculate"/>, <xref target="calculate" format="counter"/>,
<xref target="nspf"/>, <xref target="nspf" format="counter"/>,
<xref target="sspf"/>, <xref target="sspf" format="counter"/>,
<xref target="ringspf"/>, <xref target="ringspf" format="counter"/>, and
<xref target="tofew"/>. RIFT's ability to perform <xref target="tofew" format="counter"/>). RIFT's ability to perform
weighted unequal-cost load balancing of traffic across all available weighted unequal-cost load balancing of traffic across all available
links is outlined in <xref target="bwb"/> with an links is outlined in <xref target="bwb"/> with an
accompanying example.</t> accompanying example.</t>
<t><xref target="disaggregate"/> is the place where <t><xref target="disaggregate"/> is the place where
the single-plane vs. multi-plane requirement is explained in more detail . the single-plane vs. multi-plane requirement is explained in more detail .
For those interested in single-plane fabrics, only For those interested in single-plane fabrics, only
<xref target="posdisaggreg"/> is required. For the <xref target="posdisaggreg"/> is required. For the
multi-plane interested reader <xref target="negdisaggreg"/>, multi-plane-interested reader, Sections <xref target="negdisaggreg" form
<xref target="cable_tof_sec"/>, at="counter"/>,
<xref target="neg_advertise_sec"/>, and <xref target="cable_tof_sec" format="counter"/>,
<xref target="neg_dis_computation_sec"/> are also <xref target="neg_advertise_sec" format="counter"/>, and
<xref target="neg_dis_computation_sec" format="counter"/> are also
mandatory. mandatory.
<xref target="sec_attaching_prefixes"/> is <xref target="sec_attaching_prefixes"/> is
especially important for any multi-plane interested reader as it outline especially important for any multi-plane-interested reader as it outline
s how the RIB (Routing Information Base) s how the Routing Information Base (RIB)
and FIB (Forwarding Information Base) are and Forwarding Information Base (FIB) are
built via the disaggregation mechanisms, but also illustrates how they built via the disaggregation mechanisms but also illustrates how they
prevent defective routing decisions that cause traffic loss in both sing prevent defective routing decisions that cause traffic loss in both sing
le or multi-plane le-plane or multi-plane
topologies.</t> topologies.</t>
<t> <xref target="examples_sec"/> contains <t> <xref target="examples_sec"/> contains
a set of comprehensive examples that show how RIFT contains the impact o f failures a set of comprehensive examples that show how RIFT contains the impact o f failures
to only the required set of nodes. It should also help cement some of R IFT's core to only the required set of nodes. It should also help cement some of R IFT's core
concepts in the reader's mind.</t> concepts in the reader's mind.</t>
<t>Last, but not least, RIFT has other optional capabilities. One example <t>Last but not least, RIFT has other optional capabilities. One example
is is
the key-value data-store, which enables RIFT to advertise data post-conv the key-value datastore, which enables RIFT to advertise data post-conve
ergence rgence
in order to bootstrap higher levels of functionality (e.g. operational t in order to bootstrap higher levels of functionality (e.g., operational
elemetry). telemetry).
Those are covered in Those are covered in
<xref target="further_mech_sec"/>.</t> <xref target="further_mech_sec"/>.</t>
<t> <t>
More information related to RIFT can be found in the More information related to RIFT can be found in the
<xref target="I-D.ietf-rift-applicability" format="default"> <xref target="I-D.ietf-rift-applicability" format="default">
"RIFT Applicability"</xref> document, which discusses alternate topologies "RIFT Applicability"</xref> document, which discusses alternate topologies
upon which RIFT may be deployed, use cases where it is applicable, and upon which RIFT may be deployed, describes use cases where it is applicabl
presents operational considerations that complement this document. The e, and
<xref target="DayOne">RIFT DayOne</xref> book presents operational considerations that complement this document.
<xref target="DayOne">"RIFT Day One"</xref>
covers some practical details of existing RIFT implementations and deploym ent details. covers some practical details of existing RIFT implementations and deploym ent details.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Reference Frame</name> <name>Reference Frame</name>
<section toc="default" anchor="glossary" numbered="true"> <section toc="default" anchor="glossary" numbered="true">
<name>Terminology</name> <name>Terminology</name>
<t> <t>
This section presents the terminology used in this document. This section presents the terminology used in this document.
<!-- removed based on Alvaro <!-- removed based on Alvaro
skipping to change at line 639 skipping to change at line 607
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>Bandwidth Adjusted Distance (BAD):</dt> <dt>Bandwidth Adjusted Distance (BAD):</dt>
<dd> <dd>
Each RIFT node Each RIFT node
can calculate the amount of northbound bandwidth can calculate the amount of northbound bandwidth
available towards a node available towards a node
compared to other nodes at the same level and compared to other nodes at the same level and
can modify the can modify the
route distance accordingly to allow for the lower le vel to route distance accordingly to allow for the lower le vel to
adjust their load balancing towards spines.</dd> adjust their load balancing towards spines.</dd>
<dt>Bi-directional Adjacency:</dt> <dt>Bidirectional Adjacency:</dt>
<dd> <dd>
Bidirectional adjacency is an adjacency where nodes of both sides of the Bidirectional adjacency is an adjacency where nodes of both sides of the
adjacency advertised it in the Node TIEs with the co rrect levels and System adjacency advertised it in the Node TIEs with the co rrect levels and System
IDs. Bi-directionality is used to check in different algorithms whether the IDs. Bidirectionality is used to check in different algorithms whether the
link should be link should be
included. included.
</dd> </dd>
<dt>Bow-tying:</dt> <dt>Bow-tying:</dt>
<dd>Traffic patterns in fully converged IP fabrics traverse normally t <dd>Traffic patterns in fully converged IP fabrics normally traverse t
he shortest route based on hop count he shortest route based on hop count
toward their destination (e.g., leaf, spine, leaf). Some failure sce towards their destination (e.g., leaf, spine, leaf). Some failure sc
narios with partial routing enarios with partial routing
information cause nodes to lose the information cause nodes to lose the
required downstream reachability to a destination and force traffic to utilize routes that required downstream reachability to a destination and force traffic to utilize routes that
traverse higher levels in the fabric in order to turn south again us ing a different route traverse higher levels in the fabric in order to turn south again us ing a different route
to resolve reachability (e.g., leaf, spine-1, super-spine, spine-2 , leaf). to resolve reachability (e.g., leaf, spine-1, super-spine, spine-2 , leaf).
</dd> </dd>
<dt>Clos/Fat Tree:</dt> <dt>Clos / Fat Tree:</dt>
<dd> <dd>
This document uses the terms Clos and Fat Tree inter changeably This document uses the terms "Clos" and "Fat Tree" i nterchangeably
where it always refers to a folded spine-and-leaf to pology with possibly multiple where it always refers to a folded spine-and-leaf to pology with possibly multiple
Points of Delivery (PoDs) and one or multiple Top of Fabric (ToF) planes. Points of Delivery (PoDs) and one or multiple Top of Fabric (ToF) planes.
Several modifications such as leaf-2-leaf
shortcuts and multiple level shortcuts are possible <!--[rfced] May we update "multiple level" to "multi-level"?
and described further in
Original:
Several modifications such as leaf-
2-leaf shortcuts and multiple level shortcuts are possible and
described further in the document.
Perhaps:
Several modifications such as leaf-
2-leaf shortcuts and multi-level shortcuts are possible and
described further in the document.
-->
Several modifications such as leaf-to-leaf
shortcuts and shortcuts that span multiple levels ar
e possible and described further in
the document. the document.
</dd> </dd>
<dt>Cost:</dt> <dt>Cost:</dt>
<dd>
<!--[rfced] Does "The usual natural numbers algebra" refer to
a typical formula for cost? If so, should it be included, as
"usual" seems vague. Is there a word that would be more
clear than "algebra" here?
Original:
Cost:
A natural number without a unit associated with two entities. The
usual natural numbers algebra can be applied to costs.
-->
<dd>
A natural number without a unit associated with two entities. A natural number without a unit associated with two entities.
The usual natural numbers algebra can be applied to costs. A cost may be The usual natural numbers algebra can be applied to costs. A cost may be
associated with either associated with either
a single link or prefix or it may represent the sum of costs (dis tance) a single link or prefix, or it may represent the sum of costs (di stance)
of links in the path between two nodes.</dd> of links in the path between two nodes.</dd>
<dt>Crossbar:</dt> <dt>Crossbar:</dt>
<dd> <dd>
Physical arrangement of ports in a switching matrix without Physical arrangement of ports in a switching matrix without
implying any further scheduling or buffering discipl ines. implying any further scheduling or buffering discipl ines.
</dd> </dd>
<dt>Directed Acyclic Graph (DAG):</dt> <dt>Directed Acyclic Graph (DAG):</dt>
<dd>A finite directed graph with no directed cycles (loops). <dd>A finite directed graph with no directed cycles (loops).
If links in a Clos are considered as either being al l directed towards the top or vice versa, each If links in a Clos are considered as either being al l directed towards the top or vice versa, each
of such two graphs is a DAG. of two such graphs is a DAG.
</dd> </dd>
<dt>Disaggregation:</dt> <dt>Disaggregation:</dt>
<dd> <dd>
Process in which a node decides to The process in which a node decides to
advertise more specific prefixes Southwards, either advertise more specific prefixes southwards, either
positively to positively to
attract the corresponding traffic, or negatively to attract the corresponding traffic or negatively to r
repel it. epel it.
Disaggregation is performed to prevent traffic loss and suboptimal Disaggregation is performed to prevent traffic loss and suboptimal
routing to the more specific prefixes.</dd> routing to the more specific prefixes.</dd>
<dt>Distance:</dt> <dt>Distance:</dt>
<dd>The sum of costs (bound by infinite cost constant) between two nod es. A distance is primarily used <dd>The sum of costs (bound by the infinite cost constant) between two nodes. A distance is primarily used
to express separation between two entities and can be to express separation between two entities and can be
used again as cost in another context.</dd> used again as cost in another context.</dd>
<dt>East-West (E-W) Link:</dt> <dt>East-West (E-W) Link:</dt>
<dd>A link between <dd>A link between
two nodes at the same level. East-West two nodes at the same level. East-West
links are normally not part of Clos or links are normally not part of Clos or
"fat tree" topologies. Fat Tree topologies.
</dd> </dd>
<dt>Flood Repeater (FR):</dt> <dt>Flood Repeater (FR):</dt>
<dd>A node can designate one or more northbound <dd>A node can designate one or more northbound
neighbor nodes to be flood repeaters. The flood repe aters are responsible for neighbor nodes to be flood repeaters. The flood repe aters are responsible for
flooding northbound TIEs further north. The document flooding northbound TIEs further north. The document
sometimes calls them flood leaders as well. sometimes calls them flood leaders as well.
</dd> </dd>
<dt>Folded Spine-and-Leaf:</dt> <dt>Folded Spine-and-Leaf:</dt>
<dd> <dd>
In case the Clos fabric input and output stages are equivalent, the fabric can be In case the Clos fabric input and output stages are equivalent, the fabric can be
"folded" to build a "superspine" or top which is cal led the ToF "folded" to build a "superspine" or top, which is ca lled the ToF
in this document. in this document.
</dd> </dd>
<dt>Interface:</dt> <dt>Interface:</dt>
<dd>A layer 3 entity over which RIFT <dd>A layer 3 entity over which RIFT
control packets are exchanged. control packets are exchanged.
</dd> </dd>
<dt>Key Value (KV) TIE:</dt> <dt>Key Value (KV) TIE:</dt>
<dd>A TIE that is carrying a set of <dd>A TIE that is carrying a set of
key value pairs <xref target="DYNAMO" format="defaul t"/>. key value pairs <xref target="DYNAMO" format="defaul t"/>.
It can be used to distribute non topology related in formation It can be used to distribute non-topology-related in formation
within within
the protocol. the protocol.
</dd> </dd>
<dt>Leaf-to-Leaf Shortcuts (L2L):</dt> <dt>Leaf-to-Leaf (L2L) Shortcuts:</dt>
<dd>East-West links at <dd>East-West links at
leaf level leaf level
will need to be differentiated from East-West links at will need to be differentiated from East-West links at
other levels. other levels.
</dd> </dd>
<dt>Leaf:</dt> <dt>Leaf:</dt>
<dd>A node without southbound adjacencies. Level 0 implies a leaf in R IFT but a leaf does not have to be level 0. <dd>A node without southbound adjacencies. Level 0 implies a leaf in R IFT, but a leaf does not have to be level 0.
</dd> </dd>
<dt>Level:</dt> <dt>Level:</dt>
<dd>Clos and Fat Tree networks are <dd>Clos and Fat Tree networks are
topologically partially ordered graphs and 'level' d enotes the set of nodes at the topologically partially ordered graphs, and "level" denotes the set of nodes at the
same height in such a network. Nodes at the top leve l (i.e., ToF) are at the same height in such a network. Nodes at the top leve l (i.e., ToF) are at the
level with the highest value and count down to the n odes at the bottom level (i.e., leaf) with the level with the highest value and count down to the n odes at the bottom level (i.e., leaf) with the
lowest value. lowest value.
A node will have links to nodes one level down and/o r one level up. A node will have links to nodes one level down and/o r one level up.
In some circumstances, a node may have links to othe r nodes at In some circumstances, a node may have links to othe r nodes at
the same level. A leaf node may also have links to n odes multiple levels higher. the same level. A leaf node may also have links to n odes multiple levels higher.
In RIFT, Level 0 always indicates that a node is a l eaf, but does not have to be level 0. In RIFT, level 0 always indicates that a node is a l eaf but does not have to be level 0.
Level values can be configured manually or automatic Level values can be configured manually or automatic
ally derived via <xref target="ZTP" format="default"/>. ally as described in <xref target="ZTP" format="default"/>.
<!--[rfced] Should any of the following text be in the <aside> element? It is
defined as "a container for content that is semantically less important
or tangential to the content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
Section 3.1
As a final
footnote: Clos terminology often uses the concept of "stage", but
due to the folded nature of the Fat Tree, it is not used from this
point on to prevent misunderstandings.
Section 10.3.6
Note: For interface addresses, the protocol can propagate the address
part beyond the subnet mask and on reachability computation that has
to be normalized. The non-significant bits can be used for
operational purposes.
Section 10.3.11
Note: The only purpose of those values is to introduce an ordering,
whereas an implementation can internally choose any other values as
long the ordering is preserved.
Section 10.3.17
Note: This node's level is already included on the packet header.
-->
As a final footnote: Clos terminology As a final footnote: Clos terminology
often uses the concept of "stage", but due to the often uses the concept of "stage", but due to the
folded nature of the Fat Tree it is not used from th is point on folded nature of the Fat Tree, it is not used from t his point on
to prevent misunderstandings.</dd> to prevent misunderstandings.</dd>
<dt>LIE:</dt> <dt>LIE:</dt>
<dd>This is an acronym for a <dd>This is an acronym for a
"Link Information Element" exchanged on "Link Information Element" exchanged on
all the system's links running RIFT to form <em>Thre eWay</em> adjacencies and carry all the system's links running RIFT to form <em>Thre eWay</em> adjacencies and carry
information used to perform RIFT Zero Touch Provisio ning (ZTP) of levels. information used to perform RIFT Zero Touch Provisio ning (ZTP) of levels.
</dd> </dd>
<dt>Metric:</dt> <dt>Metric:</dt>
<dd>Used interchangeably with cost.</dd> <dd>Used interchangeably with "cost".</dd>
<dt>Neighbor:</dt> <dt>Neighbor:</dt>
<dd>Once a <em>ThreeWay</em> adjacency has been <dd>Once a <em>ThreeWay</em> adjacency has been
formed a neighborship relationship contains the neig hbor's formed, a neighborship relationship contains the nei ghbor's
properties. Multiple adjacencies can be formed to a remote node properties. Multiple adjacencies can be formed to a remote node
via parallel point-to-point interfaces but such adja cencies are <strong>not</strong> sharing via parallel point-to-point interfaces, but such adj acencies are <strong>not</strong> sharing
a neighbor structure. Saying "neighbor" is thus equi valent to a neighbor structure. Saying "neighbor" is thus equi valent to
saying "a <em>ThreeWay</em> adjacency".</dd> saying "a <em>ThreeWay</em> adjacency".</dd>
<dt>Node TIE:</dt> <dt>Node TIE:</dt>
<dd>This stands as acronym for a <dd>This is an acronym for a
"Node Topology Information Element", which contains all "Node Topology Information Element", which contains all
adjacencies adjacencies
the node discovered and the node discovered and
information about the node itself. Node TIE should n ot be confused with information about the node itself. Node TIE should n ot be confused with
a North TIE since "node" defines the type of TIE rat her than a North TIE since "node" defines the type of TIE rat her than
its direction. Consequently, North Node TIEs and Sou th Node TIEs exist. its direction. Consequently, North Node TIEs and Sou th Node TIEs exist.
</dd> </dd>
<dt>North SPF (N-SPF):</dt> <dt>North SPF (N-SPF):</dt>
<dd>A reachability calculation that is progressing northbound, <dd>A reachability calculation that is progressing northbound,
as example SPF that is using South Node TIEs only. N for example, SPF that is using South Node TIEs only.
ormally it progresses a single hop Normally it progresses by only a single hop
only and installs default routes. and installs default routes.
</dd> </dd>
<dt>Northbound Link:</dt> <dt>Northbound Link:</dt>
<dd> <dd>
A link to a node one level up or in other words, one A link to a node one level up or, in other words, on e
level further north. level further north.
</dd> </dd>
<dt>Northbound representation:</dt> <dt>Northbound Representation:</dt>
<dd>Subset of topology <dd>The subset of topology
information flooded information flooded
towards higher levels of the fabric. towards higher levels of the fabric.
</dd> </dd>
<dt>Overloaded:</dt> <dt>Overloaded:</dt>
<dd>Applies to a node advertising <dd>Applies to a node advertising
the <em>overload</em> attribute as set. Overload att ribute is the <em>overload</em> attribute as set. The overload attribute is
carried in the <em>NodeFlags</em> object of the enco ding schema. carried in the <em>NodeFlags</em> object of the enco ding schema.
<!-- removed due to AD review <!-- removed due to AD review
The semantics closely The semantics closely
follow the meaning of the same attribute follow the meaning of the same attribute
in <xref target="ISO10589-Second-Edition"/>. in <xref target="ISO10589-Second-Edition"/>.
--> -->
</dd> </dd>
<dt>Point of Delivery (PoD):</dt> <dt>Point of Delivery (PoD):</dt>
<dd>A self-contained <dd>A self-contained
vertical slice or subset of a Clos or Fat Tree netwo rk vertical slice or subset of a Clos or Fat Tree netwo rk
containing normally only level 0 normally containing only level 0
and level 1 nodes. A node in a PoD communicates wit h and level 1 nodes. A node in a PoD communicates wit h
nodes in other PoDs via the ToF nodes. PoDs are numb ered to nodes in other PoDs via the ToF nodes. PoDs are numb ered to
distinguish them and PoD value 0 (defined later in t he encoding schema as distinguish them, and PoD value 0 (defined later in the encoding schema as
<em>common.default_pod</em>) is used to denote "unde fined" or "any" PoD. <em>common.default_pod</em>) is used to denote "unde fined" or "any" PoD.
</dd> </dd>
<dt>Prefix TIE:</dt> <dt>Prefix TIE:</dt>
<dd>This is an acronym for a "Prefix Topology <dd>This is an acronym for a "Prefix Topology
Information Element" and it contains all prefixes Information Element", and it contains all prefixes
directly attached to directly attached to
this node in case of a North TIE and in case of Sout h TIE the necessary this node in case of a North TIE and the necessary
default routes the node advertises default routes the node advertises
southbound. southbound in case of a South TIE.
</dd> </dd>
<dt>Radix:</dt> <dt>Radix:</dt>
<dd>A radix of a switch is the number of <dd>A radix of a switch is the number of
switching ports it provides. It's sometimes called switching ports it provides. It's sometimes called
fanout as well.</dd> "fanout" as well.</dd>
<dt>Routing on the Host (RotH):</dt> <dt>Routing on the Host (RotH):</dt>
<dd>Modern data center <dd>A modern data center
architecture variant where servers/leaves are multi- architecture variant where servers/leaves are multih
homed and omed and
consequently participate in routing. consequently participate in routing.
</dd> </dd>
<dt>Security Envelope:</dt> <dt>Security Envelope:</dt>
<!--[rfced] We are having some difficulty parsing "that allows to protect"
in the sentence below. May we update it as follows?
Original:
RIFT packets are flooded within an authenticated security envelope
that allows to protect the integrity of information a node accepts
if any of the mechanisms in Section 10.2 is used.
Perhaps:
RIFT packets are flooded within an authenticated security envelope
that protects the integrity of information a node accepts
if any of the mechanisms in Section 10.2 are used.
-->
<dd>RIFT packets are flooded within an authenticated <dd>RIFT packets are flooded within an authenticated
security envelope that security envelope that
allows to protect the integrity of information a nod e accepts if any allows to protect the integrity of information a nod e accepts if any
of the mechanisms in <xref target="keys-registry"/> is used. This is further described in <xref target="security-envelope"/>. of the mechanisms in <xref target="keys-registry"/> are used. This is further described in <xref target="security-envelope"/>.
</dd> </dd>
<dt>Shortest-Path First (SPF):</dt> <dt>Shortest Path First (SPF):</dt>
<dd>A well-known graph algorithm <dd>A well-known graph algorithm
attributed to <xref target="DIJKSTRA" format="defaul t">Dijkstra</xref> that establishes a tree of shortest paths attributed to <xref target="DIJKSTRA" format="defaul t">Dijkstra</xref> that establishes a tree of shortest paths
from a source to destinations on the graph. SPF acro from a source to destinations on the graph. The SPF
nym is used due to its acronym is used due to its
familiarity as general term for the node reachabilit familiarity as a general term for the node reachabil
y calculations ity calculations
RIFT can employ to ultimately calculate routes of wh RIFT can employ to ultimately calculate routes, of w
ich Dijkstra algorithm is hich Dijkstra's algorithm is
a possible one. a possible one.
</dd> </dd>
<dt>South Reflection:</dt> <dt>South Reflection:</dt>
<dd>Often abbreviated just as <dd>Often abbreviated just as
"reflection", it defines a mechanism where South Nod e TIEs "reflection", it defines a mechanism where South Nod e TIEs
are "reflected" from the level south back up north t o allow are "reflected" from the level south back up north t o allow
nodes in the same level nodes in the same level
without E-W links to be aware of each other's node T opology without E-W links to be aware of each other's node T opology
Information Elements (TIEs).</dd> Information Elements (TIEs).</dd>
<dt>South SPF (S-SPF):</dt> <dt>South SPF (S-SPF):</dt>
<dd>A reachability calculation that is progressing southbound, <dd>A reachability calculation that is progressing southbound,
as example SPF that is using North Node TIEs only. for example, SPF that is using North Node TIEs only.
</dd> </dd>
<dt>South/Southbound and North/Northbound (Direction):</dt> <dt>South/Southbound and North/Northbound (Direction):</dt>
<dd> <dd>
When describing protocol When describing protocol
elements and procedures, elements and procedures,
in different situations the directionality in different situations, the directionality
of the compass is used. i.e., 'lower', 'south' or 's of the compass is used, i.e., "lower", "south", and
outhbound' mean "southbound" mean
moving moving
towards the bottom of the Clos or Fat Tree network towards the bottom of the Clos or Fat Tree network
and 'higher', 'north' and 'northbound' mean moving t owards and "higher", "north", and "northbound" mean moving towards
the top of the Clos or Fat Tree network. the top of the Clos or Fat Tree network.
</dd> </dd>
<dt>Southbound Link:</dt> <dt>Southbound Link:</dt>
<dd> <dd>
A link to a node one level down or in other words, o ne A link to a node one level down or, in other words, one
level further south. level further south.
</dd> </dd>
<dt>Southbound representation:</dt> <dt>Southbound Representation:</dt>
<dd>Subset of topology <dd>The subset of topology
information sent information sent
towards a lower level. towards a lower level.
</dd> </dd>
<dt>Spine:</dt> <dt>Spine:</dt>
<dd>Any nodes north of leaves and south of ToF nodes. Multiple <dd>Any nodes north of leaves and south of ToF nodes. Multiple
layers of spines in a PoD are possible. layers of spines in a PoD are possible.
</dd> </dd>
<dt>Superspine, Aggregation/Spine and Edge/Leaf Switches:"</dt> <dt>Superspine, Aggregation/Spine, and Edge/Leaf Switches:</dt>
<dd> <dd>
Traditional level names in 5-stages folded Clos for Level 2, 1 and 0 respectively (counting Traditional level names in 5 stages folded Clos for levels 2, 1, and 0, respectively (counting
up from the bottom). We up from the bottom). We
normalize this language to talk about ToF, Top-of-Po d (ToP) normalize this language to talk about ToF, Top-of-Po d (ToP),
and leaves. and leaves.
</dd> </dd>
<dt>System ID:</dt> <dt>System ID:</dt>
<dd> <dd>
RIFT nodes identify themselves with a unique network-wide number whe n trying to RIFT nodes identify themselves with a unique network-wide number whe n trying to
build adjacencies or describe their topology. RIFT System IDs can be auto-derived or configured. build adjacencies or describe their topology. RIFT System IDs can be auto-derived or configured.
</dd> </dd>
<dt>ThreeWay Adjacency:</dt> <dt>ThreeWay Adjacency:</dt>
<dd>RIFT tries to form a unique adjacency between two nodes over a poi nt-to-point <dd>RIFT tries to form a unique adjacency between two nodes over a poi nt-to-point
interface and exchange local configuration and interface and exchange local configuration and
necessary RIFT ZTP information. An adjacency is only advertised in Node TIEs and necessary RIFT ZTP information. An adjacency is only advertised in Node TIEs and
used for computations after used for computations after
it achieved <em>ThreeWay</em> state, i.e. both route it achieved <em>ThreeWay</em> state, i.e., both rout
rs reflected each other in ers reflected each other in
LIEs including relevant security information. Nevert LIEs, including relevant security information. Neve
heless, rtheless,
LIEs before <em>ThreeWay</em> state is LIEs before <em>ThreeWay</em> state is
reached may carry RIFT ZTP related information alrea dy.</dd> reached may already carry information related to RIF T ZTP.</dd>
<dt>TIDE:</dt> <dt>TIDE:</dt>
<dd>Topology Information Description Element carrying <dd>The Topology Information Description Element carries
descriptors of the TIEs stored in the node.</dd> descriptors of the TIEs stored in the node.</dd>
<dt>TIE:</dt> <dt>TIE:</dt>
<dd>This is an acronym for a "Topology <dd>This is an acronym for a "Topology
Information Element". TIEs are exchanged between RIF T nodes to Information Element". TIEs are exchanged between RIF T nodes to
describe parts of a network such as links and addres s prefixes. describe parts of a network such as links and addres s prefixes.
A TIE has always a direction and a type. A TIE always has a direction and a type.
North TIEs (sometimes abbreviated as N-TIEs) are use d when dealing with North TIEs (sometimes abbreviated as N-TIEs) are use d when dealing with
TIEs in the TIEs in the
northbound representation northbound representation,
and South-TIEs (sometimes abbreviated as S-TIEs) and South-TIEs are used (sometimes abbreviated as S-
for the southbound equivalent. TIEs have different t TIEs)
ypes such for the southbound equivalent. TIEs have different t
ypes, such
as node and prefix TIEs. as node and prefix TIEs.
</dd> </dd>
<dt>TIEDB:</dt> <dt>TIEDB:</dt>
<dd>The database holding the newest versions of all TIE headers (and t he corresponding TIE content if it is available).</dd> <dd>The database holding the newest versions of all TIE headers (and t he corresponding TIE content if it is available).</dd>
<dt>TIRE:</dt> <dt>TIRE:</dt>
<dd>Topology <dd>The Topology
Information Request Element carrying set of TIDE descrip Information Request Element carries a set of TIDE descri
tors. It ptors. It
can both can both
confirm received and request missing TIEs.</dd> confirm received and request missing TIEs.</dd>
<dt>Top of Fabric (ToF):</dt> <dt>Top of Fabric (ToF):</dt>
<dd> <dd>
The set of nodes that provide inter-PoD communicatio n and have The set of nodes that provide inter-PoD communicatio n and have
no northbound adjacencies, i.e. are at the "very top " of the fabric. no northbound adjacencies, i.e., are at the "very to p" of the fabric.
ToF nodes do not belong ToF nodes do not belong
to any PoD and are assigned <em>common.default_pod</ em> to any PoD and are assigned the <em>common.default_p od</em>
PoD value to indicate PoD value to indicate
the equivalent of "any" PoD. the equivalent of "any" PoD.
</dd> </dd>
<dt>Top of PoD (ToP):</dt> <dt>Top of PoD (ToP):</dt>
<dd> <dd>
The set of nodes that provide intra-PoD communicatio n and have The set of nodes that provide intra-PoD communicatio n and have
northbound adjacencies outside of the PoD, i.e. are at the northbound adjacencies outside of the PoD, i.e., are at the
"top" of the PoD. "top" of the PoD.
</dd> </dd>
<dt>ToF Plane or Partition:</dt> <dt>ToF Plane or Partition:</dt>
<dd>In large fabrics ToF switches may not <dd>In large fabrics, ToF switches may not
have enough ports to aggregate all switches south of have enough ports to aggregate all switches south of
them and them, and
with that, the ToF is 'split' into multiple independ with that, the ToF is "split" into multiple independ
ent planes. ent planes.
<xref target="Planes" format="default"/> explains th e concept in more detail. <xref target="Planes" format="default"/> explains th e concept in more detail.
A plane is a subset of ToF nodes that are aware of e ach other through A plane is a subset of ToF nodes that are aware of e ach other through
south reflection or E-W links. south reflection or E-W links.
</dd> </dd>
<dt>Valid LIE:</dt> <dt>Valid LIE:</dt>
<dd> <dd>
LIEs undergo different checks to determine their validity. The t erm "valid LIE" is used to describe LIEs undergo different checks to determine their validity. The t erm "valid LIE" is used to describe
a LIE that can be used to form or maintain an adjacency. The amo unt of checking itself depends a LIE that can be used to form or maintain an adjacency. The amo unt of checking itself depends
on the FSM (Finite State Machine) involved and its state. A "min imally valid LIE" is a LIE that passes checks necessary on the Finite State Machine (FSM) involved and its state. A "min imally valid LIE" is a LIE that passes checks necessary
on any FSM in any state. A "ThreeWay valid LIE" is a LIE that su ccessfully underwent further on any FSM in any state. A "ThreeWay valid LIE" is a LIE that su ccessfully underwent further
checks with a LIE FSM in <em>ThreeWay</em> state. Minimally vali d LIE is a subcategory of <em>ThreeWay</em> valid LIE. checks with a LIE FSM in <em>ThreeWay</em> state. A minimally va lid LIE is a subcategory of a <em>ThreeWay</em> valid LIE.
</dd> </dd>
<dt>RIFT Zero Touch Provisioning (abbreviated as RIFT ZTP or just ZTP) :</dt> <dt>RIFT Zero Touch Provisioning (abbreviated as RIFT ZTP or just ZTP) :</dt>
<dd> <dd>
Optional RIFT mechanism which allows the automatic derivation of An optional RIFT mechanism that allows the automatic derivation
node levels of node levels
based on minimum configuration as detailed in <xref target="ZTP" based on minimum configuration, as detailed in <xref target="ZTP
/>. "/>.
Such a mininum configuration consists solely of Such a minimum configuration consists solely of
ToFs being configured as such. RIFT ZTP contains a recommendatio n for ToFs being configured as such. RIFT ZTP contains a recommendatio n for
automatic collision-free derivation of the System ID as well. automatic collision-free derivation of the System ID as well.
</dd> </dd>
</dl> </dl>
<t> <t>
Additionally, when the specification refers to elements of packet Additionally, when the specification refers to elements of packet
encoding or constants encoding or the constants
provided in the <xref target="schema"/> a special emphasis is used provided in <xref target="schema"/>, a special emphasis is used, e
, e.g. <em>invalid_distance</em>. .g., <em>invalid_distance</em>.
The same convention is used when referring to finite state machine states or events outside The same convention is used when referring to finite state machine states or events outside
the context of the machine itself, e.g., <em>OneWay</em>. the context of the machine itself, e.g., <em>OneWay</em>.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="topology_sec"> <section numbered="true" toc="default" anchor="topology_sec">
<name>Topology</name> <name>Topology</name>
<figure anchor="pic-topo-three"> <figure anchor="pic-topo-three">
<name>A Three Level Spine-and-Leaf Topology</name> <name>A Three-Level Spine-and-Leaf Topology</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-single-plane-topology.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.ne t/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscap e" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/0 2/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http ://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://w ww.w3.org/1999/xlink" baseProfile="tiny" id="svg2384" viewBox="0 0 1116.4 836" x ml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-single-plane-topology.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.ne t/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscap e" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/0 2/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http ://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://w ww.w3.org/1999/xlink" baseProfile="tiny" id="svg2384" viewBox="0 0 1116.4 836" x ml:space="preserve">
<path id="path12779" d="M171.4,427.8v127h1.1v-127L171.4,427.8z"/ > <path id="path12779" d="M171.4,427.8v127h1.1v-127L171.4,427.8z"/ >
<path id="path12775" fill-rule="evenodd" d="M176.6,543.5l-4.7,12 .7l-4.7-12.7C170,545.5,173.8,545.5,176.6,543.5z"/> <path id="path12775" fill-rule="evenodd" d="M176.6,543.5l-4.7,12 .7l-4.7-12.7C170,545.5,173.8,545.5,176.6,543.5z"/>
<path id="path12777" fill-rule="evenodd" d="M176.6,543.1c-0.1,0- 0.1,0-0.2,0.1c-2.7,1.9-6.3,1.9-8.9,0c-0.2-0.1-0.4-0.1-0.5,0.1 c-0.1,0.1-0.1,0.2 ,0,0.3l4.7,12.7c0.1,0.2,0.3,0.3,0.5,0.2c0.1,0,0.2-0.1,0.2-0.2l4.7-12.7c0.1-0.2,0 -0.4-0.2-0.5 C176.7,543.1,176.7,543.1,176.6,543.1L176.6,543.1z M176,544.2l-4,10 .9l-4-10.9C170.4,545.7,173.4,545.6,176,544.2L176,544.2z"/> <path id="path12777" fill-rule="evenodd" d="M176.6,543.1c-0.1,0- 0.1,0-0.2,0.1c-2.7,1.9-6.3,1.9-8.9,0c-0.2-0.1-0.4-0.1-0.5,0.1 c-0.1,0.1-0.1,0.2 ,0,0.3l4.7,12.7c0.1,0.2,0.3,0.3,0.5,0.2c0.1,0,0.2-0.1,0.2-0.2l4.7-12.7c0.1-0.2,0 -0.4-0.2-0.5 C176.7,543.1,176.7,543.1,176.6,543.1L176.6,543.1z M176,544.2l-4,10 .9l-4-10.9C170.4,545.7,173.4,545.6,176,544.2L176,544.2z"/>
<path id="path11242" d="M168.8,419.7c0,1.4-0.2,2.4-0.7,3c-0.4,0. 6-1.1,1-2,1c-0.9,0-1.6-0.3-2-1c-0.4-0.7-0.6-1.7-0.6-3 c0-1.4,0.2-2.4,0.6-3c0.4- 0.7,1.1-1,2-1c0.9,0,1.6,0.3,2,1C168.6,417.4,168.8,418.4,168.8,419.7z M167.5,422c 0.1-0.3,0.2-0.6,0.2-1 c0-0.4,0.1-0.8,0.1-1.4c0-0.5,0-1-0.1-1.4c0-0.4-0.1-0.7-0. 2-1c-0.1-0.3-0.3-0.5-0.5-0.6c-0.2-0.1-0.5-0.2-0.8-0.2 c-0.3,0-0.6,0.1-0.8,0.2c- 0.2,0.1-0.4,0.3-0.5,0.6c-0.1,0.3-0.2,0.6-0.2,1c0,0.4-0.1,0.9-0.1,1.3c0,0.5,0,1,0 .1,1.3s0.1,0.7,0.2,1 c0.1,0.3,0.3,0.5,0.5,0.6c0.2,0.1,0.5,0.2,0.8,0.2c0.3,0,0.6 -0.1,0.8-0.2S167.3,422.3,167.5,422L167.5,422z"/> <path id="path11242" d="M168.8,419.7c0,1.4-0.2,2.4-0.7,3c-0.4,0. 6-1.1,1-2,1c-0.9,0-1.6-0.3-2-1c-0.4-0.7-0.6-1.7-0.6-3 c0-1.4,0.2-2.4,0.6-3c0.4- 0.7,1.1-1,2-1c0.9,0,1.6,0.3,2,1C168.6,417.4,168.8,418.4,168.8,419.7z M167.5,422c 0.1-0.3,0.2-0.6,0.2-1 c0-0.4,0.1-0.8,0.1-1.4c0-0.5,0-1-0.1-1.4c0-0.4-0.1-0.7-0. 2-1c-0.1-0.3-0.3-0.5-0.5-0.6c-0.2-0.1-0.5-0.2-0.8-0.2 c-0.3,0-0.6,0.1-0.8,0.2c- 0.2,0.1-0.4,0.3-0.5,0.6c-0.1,0.3-0.2,0.6-0.2,1c0,0.4-0.1,0.9-0.1,1.3c0,0.5,0,1,0 .1,1.3s0.1,0.7,0.2,1 c0.1,0.3,0.3,0.5,0.5,0.6c0.2,0.1,0.5,0.2,0.8,0.2c0.3,0,0.6 -0.1,0.8-0.2S167.3,422.3,167.5,422L167.5,422z"/>
<path id="path11244" d="M174,415.5l-3.7,9.6h-0.9l3.7-9.6H174z"/> <path id="path11244" d="M174,415.5l-3.7,9.6h-0.9l3.7-9.6H174z"/>
<path id="path11246" d="M180.4,419.7c0,1.4-0.2,2.4-0.7,3c-0.4,0. 6-1.1,1-2,1c-0.9,0-1.6-0.3-2-1c-0.4-0.7-0.6-1.7-0.6-3 c0-1.4,0.2-2.4,0.6-3c0.4- 0.7,1.1-1,2-1c0.9,0,1.6,0.3,2,1C180.2,417.4,180.4,418.4,180.4,419.7z M179,422c0. 1-0.3,0.2-0.6,0.2-1 c0-0.4,0.1-0.8,0.1-1.4c0-0.5,0-1-0.1-1.4c0-0.4-0.1-0.7-0.2- 1c-0.1-0.3-0.3-0.5-0.5-0.6c-0.2-0.1-0.5-0.2-0.8-0.2 c-0.3,0-0.6,0.1-0.8,0.2c-0. 2,0.1-0.4,0.3-0.5,0.6c-0.1,0.3-0.2,0.6-0.2,1c0,0.4-0.1,0.9-0.1,1.3c0,0.5,0,1,0.1 ,1.3s0.1,0.7,0.2,1 c0.1,0.3,0.3,0.5,0.5,0.6c0.2,0.1,0.5,0.2,0.8,0.2c0.3,0,0.6-0 .1,0.8-0.2S178.9,422.3,179,422L179,422z"/> <path id="path11246" d="M180.4,419.7c0,1.4-0.2,2.4-0.7,3c-0.4,0. 6-1.1,1-2,1c-0.9,0-1.6-0.3-2-1c-0.4-0.7-0.6-1.7-0.6-3 c0-1.4,0.2-2.4,0.6-3c0.4- 0.7,1.1-1,2-1c0.9,0,1.6,0.3,2,1C180.2,417.4,180.4,418.4,180.4,419.7z M179,422c0. 1-0.3,0.2-0.6,0.2-1 c0-0.4,0.1-0.8,0.1-1.4c0-0.5,0-1-0.1-1.4c0-0.4-0.1-0.7-0.2- 1c-0.1-0.3-0.3-0.5-0.5-0.6c-0.2-0.1-0.5-0.2-0.8-0.2 c-0.3,0-0.6,0.1-0.8,0.2c-0. 2,0.1-0.4,0.3-0.5,0.6c-0.1,0.3-0.2,0.6-0.2,1c0,0.4-0.1,0.9-0.1,1.3c0,0.5,0,1,0.1 ,1.3s0.1,0.7,0.2,1 c0.1,0.3,0.3,0.5,0.5,0.6c0.2,0.1,0.5,0.2,0.8,0.2c0.3,0,0.6-0 .1,0.8-0.2S178.9,422.3,179,422L179,422z"/>
<path id="path12705" d="M473,427.8v127h1.1v-127L473,427.8z"/> <path id="path12705" d="M473,427.8v127h1.1v-127L473,427.8z"/>
<path id="path12701" fill-rule="evenodd" d="M478.3,543.5l-4.7,12 .7l-4.7-12.7C471.7,545.5,475.4,545.5,478.3,543.5L478.3,543.5z"/> <path id="path12701" fill-rule="evenodd" d="M478.3,543.5l-4.7,12 .7l-4.7-12.7C471.7,545.5,475.4,545.5,478.3,543.5L478.3,543.5z"/>
skipping to change at line 1326 skipping to change at line 1360
| +---0/0---&gt;-----+ 0/0 | +----------------+ | | +---0/0---&gt;-----+ 0/0 | +----------------+ |
0/0 | | | | | | | 0/0 | | | | | | |
| +---&lt;-0/0-----+ | v | +--------------+ | | | +---&lt;-0/0-----+ | v | +--------------+ | |
v | | | | | | | v | | | | | | |
+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+ +-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+
Level 0 | | (L2L) | | | | | | Level 0 | | (L2L) | | | | | |
|Leaf111+~~~~~~~~~~+Leaf112| |Leaf121| |Leaf122| |Leaf111+~~~~~~~~~~+Leaf112| |Leaf121| |Leaf122|
+-+-----+ +-+---+-+ +--+--+-+ +-+-----+ +-+-----+ +-+---+-+ +--+--+-+ +-+-----+
+ + \ / + + + + \ / + +
Prefix111 Prefix112 \ / Prefix121 Prefix122 Prefix111 Prefix112 \ / Prefix121 Prefix122
multi-homed multihomed
Prefix Prefix
+---------- PoD 1 ---------+ +---------- PoD 2 ---------+</artwork> +---------- PoD 1 ---------+ +---------- PoD 2 ---------+</artwork>
</artset> </artset>
</figure> </figure>
<figure anchor="partitioned-spine"> <figure anchor="partitioned-spine">
<name>Topology with Multiple Planes</name> <name>Topology with Multiple Planes</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-multiplane-topology.svg"><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink=" http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="Layer_1" view Box="0 0 3593.8 4401" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-multiplane-topology.svg"><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink=" http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="Layer_1" view Box="0 0 3593.8 4401" xml:space="preserve">
<circle fill="#FFFFFF" stroke="#000000" stroke-width="1.0759" cx ="1704.7" cy="1772" r="64.6"/> <circle fill="#FFFFFF" stroke="#000000" stroke-width="1.0759" cx ="1704.7" cy="1772" r="64.6"/>
<g> <g>
skipping to change at line 1912 skipping to change at line 1946
/ | 1 | | 2 + | 3 | . . . | n |/ ^^ / | 1 | | 2 + | 3 | . . . | n |/ ^^
/ +++-+++ +-----+ +-----+ +-----+/ // / +++-+++ +-----+ +-----+ +-----+/ //
/ / PoDs / / PoDs
================================================================== //</artwork> ================================================================== //</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
The topology in <xref target="pic-topo-three" format="default "/> The topology in <xref target="pic-topo-three" format="default "/>
is referred to in all further considerations. is referred to in all further considerations.
This figure depicts This figure depicts
a generic "single plane fat tree" and the concepts explained using a generic "single plane Fat Tree" and the concepts explained using
three levels three levels
apply by induction to further levels and higher degrees apply by induction to further levels and higher degrees
of connectivity. Further, this document will deal also of connectivity. Further, this document will also deal
with designs that with designs that
provide only sparser connectivity and "partitioned spines" provide only sparser connectivity and "partitioned spines",
as shown in <xref target="partitioned-spine" format="default "/> as shown in <xref target="partitioned-spine" format="default "/>
and explained further in <xref target="Planes" format="defau lt"/>. and explained further in <xref target="Planes" format="defau lt"/>.
</t> </t>
</section> </section>
</section> </section>
<!-- based on Hardwick IAB review <!-- based on Hardwick IAB review
<section anchor="reqs" title="Requirement Considerations"> <section anchor="reqs" title="Requirement Considerations">
<t> <t>
<xref <xref
skipping to change at line 2144 skipping to change at line 2178
<!-- removed based on AD review <!-- removed based on AD review
<xref target="RFC2328"></xref><xref <xref target="RFC2328"></xref><xref
target="ISO10589-Second-Edition"></xref> target="ISO10589-Second-Edition"></xref>
--> -->
when when
distributing information northbound and distributing information northbound and
a distance vector a distance-vector
<!-- removed based on AD review <!-- removed based on AD review
<xref target="RFC4271"></xref> <xref target="RFC4271"></xref>
--> -->
protocol protocol
when distributing information southbound. when distributing information southbound.
While this is an unusual combination, While this is an unusual combination,
it does quite naturally exhibit desired properties. it does quite naturally exhibit desired properties.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="overview_sec"> <section numbered="true" toc="default" anchor="overview_sec">
<name>Overview</name> <name>Overview</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Properties</name> <name>Properties</name>
<t> <t>
The most singular property of RIFT is that it floods The most singular property of RIFT is that it only floods
link-state information northbound only so that each level obtains link-state information northbound so that each level obtains
the full topology of levels south of it. Link-State information is, the full topology of levels south of it. Link-State information is,
with some exceptions, not flooded East-West nor back South again. with some exceptions, not flooded East-West nor back south again.
Exceptions like south reflection is explained in detail in Exceptions like south reflection is explained in detail in
<xref target="posdisaggreg" format="default"/> and east-west flooding at ToF lev el <xref target="posdisaggreg" format="default"/>, and east-west flooding at the To F level
in multi-plane fabrics is outlined in <xref target="Planes" format="default"/>. in multi-plane fabrics is outlined in <xref target="Planes" format="default"/>.
In the southbound direction, the necessary routing information required (normall y just a In the southbound direction, the necessary routing information required (normall y just a
default route as per <xref target="defaultrouterules"/>) only propagates one hop south. Those nodes then generate their own default route as per <xref target="defaultrouterules"/>) only propagates one hop south. Those nodes then generate their own
routing information and flood it south to avoid the overhead of building an upda te per adjacency. routing information and flood it south to avoid the overhead of building an upda te per adjacency.
For the moment describing the East-West direction is left out until later in the
document.
</t>
<t>
<!--[rfced] May we make this sentence more concise?
Original:
For the moment
describing the East-West direction is left out until later in the
document.
Perhaps:
The East-West direction is described later in the document.
-->
For the moment, describing the East-West direction is left out until later in th
e document.
</t>
<t>
Those information flow constraints create not only an anisotropic Those information flow constraints create not only an anisotropic
protocol (i.e. the information is not distributed "evenly" or protocol (i.e., the information is not distributed "evenly" or
"clumped" but summarized along the N-S gradient) but also a "clumped" but summarized along the north-south gradient) but also a
"smooth" information propagation where nodes do not receive the "smooth" information propagation where nodes do not receive the
same information from multiple directions at the same time. same information from multiple directions at the same time.
Normally, accepting the same reachability on any link, without Normally, accepting the same reachability on any link, without
understanding its topological significance, forces tie-breaking on understanding its topological significance, forces tie-breaking on
some kind of distance function. some kind of distance function.
And such tie-breaking leads ultimately to hop-by-hop forwarding by And such tie-breaking ultimately leads to hop-by-hop forwarding by
shortest paths only. shortest paths only.
In contrast to that, RIFT, under normal conditions, In contrast to that, RIFT, under normal conditions,
does not need to tie-break the same does not need to tie-break the same
reachability information from multiple directions. Its computation reachability information from multiple directions. Its computation
principles (south forwarding direction is always preferred) leads principles (south forwarding direction is always preferred) lead
to <xref target="VFR" format="default">valley-free</xref> forwarding behavior. to <xref target="VFR" format="default">valley-free</xref> forwarding behavior.
In shortest terms, valley free paths allow reversal of In the shortest terms, valley-free paths allow reversal of
direction at most once from a packet heading direction from a packet heading
northbound to southbound while permitting northbound to southbound while permitting
traversal of horizontal links in traversal of horizontal links in
the northbound phase. the northbound phase at most once.
Those principles guarantee Those principles guarantee
loop-free forwarding and with that can take advantage of all such feasible path s on a fabric. This is another loop-free forwarding and with that can take advantage of all such feasible path s on a fabric. This is another
highly desirable property if available bandwidth should be highly desirable property if available bandwidth should be
utilized to the maximum extent possible. utilized to the maximum extent possible.
</t> </t>
<t> <t>
To account for the "northern" and the "southern" information split To account for the "northern" and the "southern" information split,
the link state database is partitioned accordingly into "north the link state database is partitioned accordingly into "north
representation" and "south representation" Topology Information Elements (TIEs). representation" and "south representation" Topology Information Elements (TIEs).
In simplest terms the North TIEs contain a link state topology In the simplest terms, the North TIEs contain a link-state topology
description of lower levels and South TIEs carry simply description of lower levels and South TIEs simply carry a
node description of the level above and default routes pointing north. node description of the level above and default routes pointing north.
This oversimplified view This oversimplified view
will be refined gradually in the following sections while introducing will be refined gradually in the following sections while introducing
protocol procedures and state machines at the same time. protocol procedures and state machines at the same time.
</t> </t>
</section> </section>
<section anchor="Planes" numbered="true" toc="default"> <section anchor="Planes" numbered="true" toc="default">
<name>Generalized Topology View</name> <name>Generalized Topology View</name>
<t> <t>
This section and resulting <xref target="negdisaggreg" format="default"/> are de dicated to multi-plane fabrics, This section and <xref target="negdisaggreg" format="default"/> are dedicated to multi-plane fabrics,
in contrast with the single plane designs where all in contrast with the single plane designs where all
ToF nodes are topologically equal and initially ToF nodes are topologically equal and initially
connected to all the switches at the level below them. connected to all the switches at the level below them.
</t> </t>
<t> <t>
Multi-plane design is The multi-plane design is
effectively a multi-dimensional switching matrix. To make that easier to visuali effectively a multidimensional switching matrix. To make that easier to visualiz
ze, e,
this document introduces a methodology depicting the this document introduces a methodology depicting the
connectivity in two-dimensional pictures. Further, connectivity in two-dimensional pictures. Further,
it can be leveraged that what is under consideration here are basically stacked crossbar it can be leveraged that what is under consideration here is basically stacked c rossbar
fabrics where ports align "on top of each other" in a regular fabrics where ports align "on top of each other" in a regular
fashion. fashion.
</t> </t>
<t> <t>
A word of caution to the reader; at this point it should be A word of caution to the reader: At this point, it should be
observed that the language used to describe Clos variations, observed that the language used to describe Clos variations,
especially in multi-plane designs, varies widely between sources. especially in multi-plane designs, varies widely between sources.
This description follows the terminology introduced in This description follows the terminology introduced in
<xref target="glossary" format="default"/>. This terminology is needed <xref target="glossary" format="default"/>. This terminology is needed
to follow the rest of this section correctly. to follow the rest of this section correctly.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Terminology and Glossary</name> <name>Terminology and Glossary</name>
<t> <t>
This section describes the terminology and abbreviations used in the This section describes the terminology and abbreviations used in the
skipping to change at line 2255 skipping to change at line 2300
</t> </t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>P:</dt> <dt>P:</dt>
<dd>Denotes the number of PoDs in a topology.</dd> <dd>Denotes the number of PoDs in a topology.</dd>
<dt>S:</dt> <dt>S:</dt>
<dd>Denotes the number of ToF nodes in a topology. <dd>Denotes the number of ToF nodes in a topology.
</dd> </dd>
<dt>K:</dt> <dt>K:</dt>
<dd> <dd>
To simplify the visual aids, notations and To simplify the visual aids, notations, and
further considerations, the assumption is made that the switches are sym metrical, further considerations, the assumption is made that the switches are sym metrical,
i.e., they have an equal number of ports pointing northbound and southbo und. i.e., they have an equal number of ports pointing northbound and southbo und.
With that simplification, K denotes half of the radix of a symmetrical With that simplification, K denotes half of the radix of a symmetrical
switch, meaning that the switch has K ports pointing switch, meaning that the switch has K ports pointing
north and K ports pointing south. north and K ports pointing south.
K_LEAF (K of a leaf) thus represents both the number of access ports in a leaf Node K_LEAF (K of a leaf) thus represents both the number of access ports in a leaf node
and the maximum number of planes in the fabric, whereas K_TOP (K of a T oP) represents the and the maximum number of planes in the fabric, whereas K_TOP (K of a T oP) represents the
number of leaves in the PoD and the number of ports pointing north in a ToP Node towards number of leaves in the PoD and the number of ports pointing north in a ToP Node towards
a higher spine level and thus the number of ToF nodes in a plane. a higher spine level and thus the number of ToF nodes in a plane.
</dd> </dd>
<dt>ToF Plane:</dt> <dt>ToF Plane:</dt>
<dd>Set of ToFs that are aware of each <dd>Set of ToFs that are aware of each
other by means of south reflection. other by means of south reflection.
Planes are designated by capital letters, e.g. Planes are designated by capital letters, e.g.,
plane A. plane A.
</dd> </dd>
<dt>N:</dt> <dt>N:</dt>
<dd>Denotes the number of independent ToF planes <dd>Denotes the number of independent ToF planes
in a topology.</dd> in a topology.</dd>
<dt>R:</dt> <dt>R:</dt>
<dd>Denotes a redundancy factor, i.e., number of <dd>Denotes a redundancy factor, i.e., the number of
connections a spine has towards a ToF plane. connections a spine has towards a ToF plane.
In single plane design K_TOP is equal to R. In a single plane design, K_TOP is equal to R.
</dd> </dd>
<dt>Fallen Leaf:</dt> <dt>Fallen Leaf:</dt>
<dd>A fallen leaf in a plane Z is a <dd>A fallen leaf in a plane Z is a
switch that lost all connectivity switch that lost all connectivity
northbound to Z.</dd> northbound to Z.</dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Clos as Crossed, Stacked Crossbars</name> <name>Clos as Crossed, Stacked Crossbars</name>
<t> <t>
The typical topology for which RIFT is defined is built of P The typical topology for which RIFT is defined is built of P
number of PoDs and connected together by S number of ToF nodes. number of PoDs and connected together by S number of ToF nodes.
A PoD node has K number of ports. From here on half of A PoD node has K number of ports. From here on, half of
them (K=Radix/2) are assumed to connect host devices from the south, and them (K=Radix/2) are assumed to connect host devices from the south, and
the other half to connect to interleaved PoD Top-Level switches to the the other half is assumed to connect to interleaved PoD top-level switches to th e
north. The K ratio can be chosen differently without loss of generality north. The K ratio can be chosen differently without loss of generality
when port speeds differ or the fabric is oversubscribed but K=Radix/2 when port speeds differ or the fabric is oversubscribed, but K=Radix/2
allows for more readable representation whereby there are as many allows for more readable representation whereby there are as many
ports facing north as south on any intermediate node. ports facing north as south on any intermediate node.
A node is hence represented in a schematic fashion with ports "sticking out" to A node is hence represented in a schematic fashion with ports "sticking out" to
its north and south rather than by the usual real-world front its north and south, rather than by the usual real-world front
faceplate designs of the day. faceplate designs of the day.
</t> </t>
<t> <t>
<xref target="leaftopview" format="default"/> provides a view of a leaf node as <xref target="leaftopview" format="default"/> provides a view of a leaf node as
seen from the north, i.e. showing ports that connect northbound. seen from the north, i.e., showing ports that connect northbound.
For lack of a better symbol, the document chooses to use the "o" as For lack of a better symbol, the document chooses to use the "o" as
ASCII visualisation of a single port. In this example, K_LEAF has ASCII visualization of a single port. In this example, K_LEAF has
6 ports. Observe that the number of PoDs is not related to Radix 6 ports. Observe that the number of PoDs is not related to the Radix
unless the ToF Nodes are constrained to be the same as the PoD unless the ToF nodes are constrained to be the same as the PoD
nodes in a particular deployment. nodes in a particular deployment.
</t> </t>
<figure anchor="leaftopview"> <figure anchor="leaftopview">
<name>A Leaf Node, K_LEAF=6</name> <name>A Leaf Node, K_LEAF=6</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-leaf-k-leaf-6.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/ sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xml ns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-r df-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http://www .w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3. org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 540.8 500" height="500" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-leaf-k-leaf-6.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/ sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xml ns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-r df-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http://www .w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3. org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 540.8 500" height="500" xml:space="preserve">
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path7526" fill-rule="evenodd" stroke="#000000" strok e-width="0.4484" stroke-miterlimit="1.7935" d="M115.8,159.9 l2.2-2.2l-7.8,2.2l7 .8,2.2L115.8,159.9z"/> <path id="path7526" fill-rule="evenodd" stroke="#000000" strok e-width="0.4484" stroke-miterlimit="1.7935" d="M115.8,159.9 l2.2-2.2l-7.8,2.2l7 .8,2.2L115.8,159.9z"/>
<path id="path8365" fill-rule="evenodd" stroke="#000000" strok e-width="0.4484" stroke-miterlimit="1.7935" d="M284.7,372.3 l-2.2-2.2l2.2,7.8l2 .2-7.8L284.7,372.3z"/> <path id="path8365" fill-rule="evenodd" stroke="#000000" strok e-width="0.4484" stroke-miterlimit="1.7935" d="M284.7,372.3 l-2.2-2.2l2.2,7.8l2 .2-7.8L284.7,372.3z"/>
<path id="path26725" fill-rule="evenodd" stroke="#000000" stro ke-width="0.8899" stroke-miterlimit="3.5597" d="M284.7,376.8"/> <path id="path26725" fill-rule="evenodd" stroke="#000000" stro ke-width="0.8899" stroke-miterlimit="3.5597" d="M284.7,376.8"/>
skipping to change at line 2409 skipping to change at line 2454
<path id="path12764" d="M250.1,153.6h-1v-3.4c0-0.3,0-0.5,0-0.8 c0-0.2-0.1-0.4-0.2-0.6c-0.1-0.2-0.2-0.3-0.4-0.3 c-0.2-0.1-0.4-0.1-0.7-0.1c-0.3, 0-0.6,0.1-0.9,0.2c-0.3,0.1-0.6,0.3-0.9,0.5v4.5h-1v-6h1v0.7c0.3-0.3,0.6-0.5,1-0.6 c0.3-0.1,0.7-0.2,1-0.2c0.6,0,1.1,0.2,1.5,0.6c0.3,0.4,0.5,1,0.5,1.7L250.1,153.6 z"/> <path id="path12764" d="M250.1,153.6h-1v-3.4c0-0.3,0-0.5,0-0.8 c0-0.2-0.1-0.4-0.2-0.6c-0.1-0.2-0.2-0.3-0.4-0.3 c-0.2-0.1-0.4-0.1-0.7-0.1c-0.3, 0-0.6,0.1-0.9,0.2c-0.3,0.1-0.6,0.3-0.9,0.5v4.5h-1v-6h1v0.7c0.3-0.3,0.6-0.5,1-0.6 c0.3-0.1,0.7-0.2,1-0.2c0.6,0,1.1,0.2,1.5,0.6c0.3,0.4,0.5,1,0.5,1.7L250.1,153.6 z"/>
<path id="path12766" d="M257.1,150.7h-4.4c0,0.4,0.1,0.7,0.2,1c 0.1,0.3,0.3,0.5,0.5,0.7c0.2,0.2,0.4,0.3,0.7,0.4 c0.3,0.1,0.5,0.1,0.8,0.1c0.4,0, 0.8-0.1,1.2-0.2c0.4-0.2,0.7-0.3,0.9-0.5h0.1v1.1c-0.3,0.1-0.7,0.3-1,0.4c-0.4,0.1- 0.7,0.1-1.1,0.1 c-1,0-1.8-0.3-2.3-0.8c-0.6-0.5-0.8-1.3-0.8-2.3c0-1,0.3-1.8,0.8- 2.3c0.5-0.6,1.2-0.9,2.1-0.9c0.8,0,1.4,0.2,1.9,0.7 c0.4,0.5,0.7,1.1,0.7,2L257.1, 150.7z M256.1,150c0-0.5-0.1-0.9-0.4-1.2c-0.3-0.3-0.7-0.4-1.2-0.4c-0.5,0-1,0.2-1. 3,0.5 c-0.3,0.3-0.5,0.7-0.5,1.2H256.1z"/> <path id="path12766" d="M257.1,150.7h-4.4c0,0.4,0.1,0.7,0.2,1c 0.1,0.3,0.3,0.5,0.5,0.7c0.2,0.2,0.4,0.3,0.7,0.4 c0.3,0.1,0.5,0.1,0.8,0.1c0.4,0, 0.8-0.1,1.2-0.2c0.4-0.2,0.7-0.3,0.9-0.5h0.1v1.1c-0.3,0.1-0.7,0.3-1,0.4c-0.4,0.1- 0.7,0.1-1.1,0.1 c-1,0-1.8-0.3-2.3-0.8c-0.6-0.5-0.8-1.3-0.8-2.3c0-1,0.3-1.8,0.8- 2.3c0.5-0.6,1.2-0.9,2.1-0.9c0.8,0,1.4,0.2,1.9,0.7 c0.4,0.5,0.7,1.1,0.7,2L257.1, 150.7z M256.1,150c0-0.5-0.1-0.9-0.4-1.2c-0.3-0.3-0.7-0.4-1.2-0.4c-0.5,0-1,0.2-1. 3,0.5 c-0.3,0.3-0.5,0.7-0.5,1.2H256.1z"/>
<path id="path12768" d="M261.7,153.6c-0.2,0.1-0.4,0.1-0.6,0.1c -0.2,0-0.4,0-0.6,0c-0.6,0-1.1-0.2-1.4-0.5c-0.3-0.3-0.5-0.9-0.5-1.6 v-3.2h-0.7v- 0.8h0.7v-1.7h1v1.7h2.1v0.8h-2.1v2.7c0,0.3,0,0.6,0,0.7c0,0.2,0.1,0.3,0.2,0.5c0.1, 0.1,0.2,0.2,0.3,0.3 c0.1,0.1,0.4,0.1,0.6,0.1c0.2,0,0.3,0,0.5-0.1c0.2-0.1,0.3-0. 1,0.4-0.1h0.1V153.6z"/> <path id="path12768" d="M261.7,153.6c-0.2,0.1-0.4,0.1-0.6,0.1c -0.2,0-0.4,0-0.6,0c-0.6,0-1.1-0.2-1.4-0.5c-0.3-0.3-0.5-0.9-0.5-1.6 v-3.2h-0.7v- 0.8h0.7v-1.7h1v1.7h2.1v0.8h-2.1v2.7c0,0.3,0,0.6,0,0.7c0,0.2,0.1,0.3,0.2,0.5c0.1, 0.1,0.2,0.2,0.3,0.3 c0.1,0.1,0.4,0.1,0.6,0.1c0.2,0,0.3,0,0.5-0.1c0.2-0.1,0.3-0. 1,0.4-0.1h0.1V153.6z"/>
<path id="path12770" d="M266,150.6c0,1.1-0.2,2-0.5,2.9c-0.4,0. 9-0.8,1.7-1.5,2.4h-1.2v-0.1c0.3-0.2,0.6-0.5,0.8-0.9 c0.3-0.4,0.5-0.8,0.7-1.2c0. 2-0.5,0.4-0.9,0.5-1.4c0.1-0.5,0.2-1.1,0.2-1.7c0-0.6-0.1-1.1-0.2-1.7c-0.1-0.5-0.3 -1-0.5-1.5 c-0.2-0.5-0.5-0.9-0.7-1.2c-0.3-0.3-0.5-0.6-0.8-0.9v-0.1h1.2c0.6,0.7, 1.1,1.5,1.5,2.4C265.8,148.5,266,149.5,266,150.6z"/> <path id="path12770" d="M266,150.6c0,1.1-0.2,2-0.5,2.9c-0.4,0. 9-0.8,1.7-1.5,2.4h-1.2v-0.1c0.3-0.2,0.6-0.5,0.8-0.9 c0.3-0.4,0.5-0.8,0.7-1.2c0. 2-0.5,0.4-0.9,0.5-1.4c0.1-0.5,0.2-1.1,0.2-1.7c0-0.6-0.1-1.1-0.2-1.7c-0.1-0.5-0.3 -1-0.5-1.5 c-0.2-0.5-0.5-0.9-0.7-1.2c-0.3-0.3-0.5-0.6-0.8-0.9v-0.1h1.2c0.6,0.7, 1.1,1.5,1.5,2.4C265.8,148.5,266,149.5,266,150.6z"/>
<path fill-rule="evenodd" stroke="#000000" stroke-width="0.448 4" stroke-miterlimit="1.7935" d="M-103.9,131.9"/> <path fill-rule="evenodd" stroke="#000000" stroke-width="0.448 4" stroke-miterlimit="1.7935" d="M-103.9,131.9"/>
<path fill-rule="evenodd" stroke="#000000" stroke-width="0.448 4" stroke-miterlimit="1.7935" d="M120.3,159.5"/> <path fill-rule="evenodd" stroke="#000000" stroke-width="0.448 4" stroke-miterlimit="1.7935" d="M120.3,159.5"/>
<path fill-rule="evenodd" stroke="#000000" stroke-miterlimit=" 1.7935" d="M284.7,159.9c0,70.7,0,141.4,0,212.2"/> <path fill-rule="evenodd" stroke="#000000" stroke-miterlimit=" 1.7935" d="M284.7,159.9c0,70.7,0,141.4,0,212.2"/>
<path fill-rule="evenodd" stroke="#000000" stroke-miterlimit=" 1.7935" d="M114.1,159.9c56.9,0,113.8,0,170.6,0"/> <path fill-rule="evenodd" stroke="#000000" stroke-miterlimit=" 1.7935" d="M114.1,159.9c56.9,0,113.8,0,170.6,0"/>
</svg> </svg>
</artwork> </artwork>
<artwork align="center" name="" type="ascii-art" originalSrc="art/ rift-rift-leaf-k-leaf-6.ascii-art">Top view <artwork align="center" name="" type="ascii-art" originalSrc="art/ rift-rift-leaf-k-leaf-6.ascii-art">Top View
+---+ +---+
| | | |
| O | e.g., Radix = 12, K_LEAF = 6 | o | e.g., Radix = 12, K_LEAF = 6
| | | |
| O | | o |
| | ------------------------- | | -------------------------
| o &lt;------ Physical Port (Ethernet) ----+ | o &lt;------ Physical Port (Ethernet) ----+
| | ------------------------- | | | ------------------------- |
| O | | | o | |
| | | | | |
| O | | | o | |
| | | | | |
| O | | | o | |
| | | | | |
+---+ v +---+ v
|| || || || || || || || || || || || || ||
+----+ +------------------------------------------------+ +----+ +------------------------------------------------+
| | | | | | | |
+----+ +------------------------------------------------+ +----+ +------------------------------------------------+
|| || || || || || || || || || || || || ||
Side views</artwork> Side Views</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
The Radix of a PoD's top node may be different than that of the The Radix of a PoD's top node may be different than that of the
leaf node. Though, more often than not, a same type of node is leaf node. Though, more often than not, a same type of node is
used for both, effectively forming a square (K*K). used for both, effectively forming a square (K*K).
In the general case, switches at the top of the PoD with K_TOP southern In the general case, switches at the top of the PoD with K_TOP southern
ports not necessarily equal to K_LEAF could be considered . ports not necessarily equal to K_LEAF could be considered .
For instance, in the representations below, we For instance, in the representations below, we
pick a 6 port K_LEAF and an 8 port K_TOP. In order to form a pick a 6-port K_LEAF and an 8-port K_TOP. In order to form a
crossbar, K_TOP Leaf Nodes are necessary as illustrated in crossbar, K_TOP leaf nodes are necessary as illustrated in
<xref target="PODSview" format="default"/>. <xref target="PODSview" format="default"/>.
</t> </t>
<figure anchor="PODSview"> <figure anchor="PODSview">
<name>Southern View of Leaf Nodes of a PoD, K_TOP=8</name> <name>Southern View of Leaf Nodes of a PoD, K_TOP=8</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-south-view-PoD-k-top-8.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge .net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inks cape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/199 9/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="h ttp://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http: //www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox=" 0 0 555.8 425" height="425" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-south-view-PoD-k-top-8.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge .net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inks cape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/199 9/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="h ttp://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http: //www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox=" 0 0 555.8 425" height="425" xml:space="preserve">
<rect id="rect26456" x="4.6" y="0.5" fill="none" stroke="#0000 00" stroke-width="1.0427" stroke-miterlimit="3.941" stroke-opacity="0.9636" widt h="41.6" height="424"/> <rect id="rect26456" x="4.6" y="0.5" fill="none" stroke="#0000 00" stroke-width="1.0427" stroke-miterlimit="3.941" stroke-opacity="0.9636" widt h="41.6" height="424"/>
<ellipse id="path26555" fill="none" stroke="#000000" stroke-wi dth="0.9256" stroke-miterlimit="3.941" stroke-opacity="0.9636" cx="25.4" cy="30. 1" rx="8.6" ry="8.8"/> <ellipse id="path26555" fill="none" stroke="#000000" stroke-wi dth="0.9256" stroke-miterlimit="3.941" stroke-opacity="0.9636" cx="25.4" cy="30. 1" rx="8.6" ry="8.8"/>
<ellipse id="path26555-4" fill="none" stroke="#000000" stroke- width="0.9256" stroke-miterlimit="3.941" stroke-opacity="0.9636" cx="25.4" cy="1 03.6" rx="8.6" ry="8.8"/> <ellipse id="path26555-4" fill="none" stroke="#000000" stroke- width="0.9256" stroke-miterlimit="3.941" stroke-opacity="0.9636" cx="25.4" cy="1 03.6" rx="8.6" ry="8.8"/>
<ellipse id="path26555-0" fill="none" stroke="#000000" stroke- width="0.9256" stroke-miterlimit="3.941" stroke-opacity="0.9636" cx="25.4" cy="1 77.1" rx="8.6" ry="8.8"/> <ellipse id="path26555-0" fill="none" stroke="#000000" stroke- width="0.9256" stroke-miterlimit="3.941" stroke-opacity="0.9636" cx="25.4" cy="1 77.1" rx="8.6" ry="8.8"/>
skipping to change at line 2525 skipping to change at line 2570
| O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O | | O |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+</artwork> +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
As further visualized in <xref target="PODNview" format="default"/> the K_TOP Le af Nodes As further visualized in <xref target="PODNview" format="default"/>, the K_TOP l eaf nodes
are fully interconnected with the K_LEAF ToP nodes, providing are fully interconnected with the K_LEAF ToP nodes, providing
connectivity that can be represented as a crossbar when "looked at" connectivity that can be represented as a crossbar when "looked at"
from the from the
north. The result is that, in the absence of a failure, a packet north. The result is that, in the absence of a failure, a packet
entering the PoD from the north on any port can be routed to any port entering the PoD from the north on any port can be routed to any port
in the south of the PoD and vice versa. And that is precisely why it makes in the south of the PoD and vice versa. And that is precisely why it makes
sense to talk about a sense to talk about a
"switching "switching
matrix". matrix".
</t> </t>
skipping to change at line 2696 skipping to change at line 2741
+--------------------------------------------------------+ | +--------------------------------------------------------+ |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ | +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ |
^ | ^ |
| | | |
| ---------- ----------------------- | | ---------- ----------------------- |
+----- Leaf Node Top-of-PoD Node (Spine) --+ +----- Leaf Node Top-of-PoD Node (Spine) --+
---------- -----------------------</artwork> ---------- -----------------------</artwork>
</artset> </artset>
</figure> </figure>
<t>Side views of this PoD is illustrated in <xref target="PODSideview" <t>Side views of this PoD is illustrated in Figures <xref
format="default"/> and target="PODSideview" format="counter"/> and <xref
<xref target="PODSideview2" format="default"/>. target="PODSideview2" format="counter"/>.</t>
</t>
<figure anchor="PODSideview"> <figure anchor="PODSideview">
<name>Side View of a PoD, K_TOP=8, K_LEAF=6</name> <name>Side View of a PoD, K_TOP=8, K_LEAF=6</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-side-view-pod-k-top-8-k-leaf-6.svg"><svg xmlns:sodipodi="http://sodipodi.sou rceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespa ces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3 .org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmln s:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlin k="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" v iewBox="0 0 500 193.3" width="500" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-side-view-pod-k-top-8-k-leaf-6.svg"><svg xmlns:sodipodi="http://sodipodi.sou rceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespa ces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3 .org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmln s:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlin k="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" v iewBox="0 0 500 193.3" width="500" xml:space="preserve">
<path id="path26727-39-9" fill="none" stroke="#000000" stroke- width="1.0716" stroke-miterlimit="3.2402" d="M442.6,119.6V74"/> <path id="path26727-39-9" fill="none" stroke="#000000" stroke- width="1.0716" stroke-miterlimit="3.2402" d="M442.6,119.6V74"/>
<path id="path26727-7-1" fill="none" stroke="#000000" stroke-w idth="1.0716" stroke-miterlimit="3.2402" d="M442.6,150.9v-31.4"/> <path id="path26727-7-1" fill="none" stroke="#000000" stroke-w idth="1.0716" stroke-miterlimit="3.2402" d="M442.6,150.9v-31.4"/>
<path id="path26727-39-7" fill="none" stroke="#000000" stroke- width="1.0716" stroke-miterlimit="3.2402" d="M442.6,74V42.7"/> <path id="path26727-39-7" fill="none" stroke="#000000" stroke- width="1.0716" stroke-miterlimit="3.2402" d="M442.6,74V42.7"/>
<path id="path26727-39" fill="none" stroke="#000000" stroke-wi dth="1.0716" stroke-miterlimit="3.2402" d="M22.7,119.6V74"/> <path id="path26727-39" fill="none" stroke="#000000" stroke-wi dth="1.0716" stroke-miterlimit="3.2402" d="M22.7,119.6V74"/>
<path id="path26727-7" fill="none" stroke="#000000" stroke-wid th="1.0716" stroke-miterlimit="3.2402" d="M22.7,150.9v-31.4"/> <path id="path26727-7" fill="none" stroke="#000000" stroke-wid th="1.0716" stroke-miterlimit="3.2402" d="M22.7,150.9v-31.4"/>
<path id="path26727-39-3" fill="none" stroke="#000000" stroke- width="1.0716" stroke-miterlimit="3.2402" d="M22.7,74V42.7"/> <path id="path26727-39-3" fill="none" stroke="#000000" stroke- width="1.0716" stroke-miterlimit="3.2402" d="M22.7,74V42.7"/>
skipping to change at line 3069 skipping to change at line 3114
+------------------------------------------------+ v +------------------------------------------------+ v
| Leaf Node (Sideways) | S | Leaf Node (Sideways) | S
+------------------------------------------------+ +------------------------------------------------+
Connecting to Client Nodes</artwork> Connecting to Client Nodes</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
As a next step, observe As a next step, observe
that a resulting PoD can be abstracted as a bigger node with that a resulting PoD can be abstracted as a bigger node with
a number K of K_POD= K_TOP * K_LEAF, and the design can recurse. a number K of K_POD = K_TOP * K_LEAF, and the design can recurse.
</t> </t>
<t> <t>
It will be critical at this point that, before progressing further, It will be critical at this point that, before progressing further,
the concept and the picture of "crossed crossbars" is understood. the concept and the picture of "crossed crossbars" is understood.
Else, the following considerations might be difficult to Else, the following considerations might be difficult to
comprehend. comprehend.
</t> </t>
<t> <t>
To continue, the PoDs are interconnected with each other through a To continue, the PoDs are interconnected with each other through a
ToF node at the very top or the north edge of the ToF node at the very top or the north edge of the
fabric. The resulting ToF is <strong>not</strong> partitioned if, and only if (I fabric. The resulting ToF is <strong>not</strong> partitioned if and only if (II
IF), F)
every PoD top level node (spine) is connected to every ToF Node. every PoD top-level node (spine) is connected to every ToF node.
This topology is also referred to as a single plane configuration This topology is also referred to as a single plane configuration
and is quite popular due to its simplicity. and is quite popular due to its simplicity. There are K_TOP
In order to reach a 1:1 connectivity ratio between the ToF and the ToF nodes and K_LEAF ToP nodes because each port of a ToP node connects
leaves, it results that there are K_TOP ToF nodes, because each to a different ToF node. Consequently, it will take at least P * K_LEAF
port of a ToP node connects to a different ToF node, and K_LEAF
ToP nodes for the same reason. Consequently, it will take at least (P * K_LEAF)
ports on a ToF node to connect to each of the K_LEAF ToP nodes of ports on a ToF node to connect to each of the K_LEAF ToP nodes of
the P PoDs. <xref target="nonpart" format="default"/> illustrates this, looking at P=3 PoDs the P PoDs. <xref target="nonpart" format="default"/> illustrates this, looking at P=3 PoDs
from above and 2 sides. The large view is the one from above, with the 8 from above and 2 sides. The large view is the one from above, with the 8
ToF of 3*6 ports each interconnecting the PoDs, every ToP Node being ToF of 3 * 6 ports each interconnecting the PoDs and every ToP Node being
connected to every ToF node. connected to every ToF node.
</t> </t>
<figure anchor="nonpart"> <figure anchor="nonpart">
<name>Fabric Spines and TOFs in Single Plane Design, 3 PoDs</name> <name>Fabric Spines and ToFs in Single Plane Design, 3 PoDs</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-fabric-spines-tof-singple-plane-3-pod.svg"><svg xmlns:sodipodi="http://sodip odi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/ namespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http:/ /www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1 /" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xml ns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg 1627" viewBox="0 0 1102 1301" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-fabric-spines-tof-singple-plane-3-pod.svg"><svg xmlns:sodipodi="http://sodip odi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/ namespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http:/ /www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1 /" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xml ns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg 1627" viewBox="0 0 1102 1301" xml:space="preserve">
<rect id="rect859" x="0.1" y="233.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/> <rect id="rect859" x="0.1" y="233.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/>
<rect id="rect861" x="0.1" y="285.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/> <rect id="rect861" x="0.1" y="285.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/>
<rect id="rect863" x="0.1" y="337.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/> <rect id="rect863" x="0.1" y="337.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/>
<rect id="rect865" x="0.1" y="389.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/> <rect id="rect865" x="0.1" y="389.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/>
<rect id="rect867" x="0.1" y="441.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/> <rect id="rect867" x="0.1" y="441.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/>
<rect id="rect869" x="0.1" y="493.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/> <rect id="rect869" x="0.1" y="493.1" fill="#FFFFFF" stroke="#0 00000" stroke-width="1.23" stroke-opacity="0.964" width="586" height="42.2"/>
<rect id="rect873" x="12.6" y="221.1" fill="#FFFFFF" stroke="# 000000" stroke-width="1.06" stroke-opacity="0.964" width="42.2" height="327"/> <rect id="rect873" x="12.6" y="221.1" fill="#FFFFFF" stroke="# 000000" stroke-width="1.06" stroke-opacity="0.964" width="42.2" height="327"/>
<rect id="rect875" x="87.1" y="221.1" fill="#FFFFFF" stroke="# 000000" stroke-width="1.06" stroke-opacity="0.964" width="42.2" height="327"/> <rect id="rect875" x="87.1" y="221.1" fill="#FFFFFF" stroke="# 000000" stroke-width="1.06" stroke-opacity="0.964" width="42.2" height="327"/>
skipping to change at line 3507 skipping to change at line 3550
| | | | | | | | | | | | | | | | -+ +- +-+ | | | | | | | | | | | | | | | | | | -+ +- +-+ | |
+-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
The top view can be collapsed into a third dimension where the The top view can be collapsed into a third dimension where the
hidden depth index is representing the PoD number. One PoD can be shown then hidden depth index is representing the PoD number. One PoD can be shown then
as a class of PoDs and hence save one dimension in as a class of PoDs and hence save one dimension in
the representation. the representation.
The Spine Node expands in the depth and the vertical dimensions, The spine node expands in the depth and the vertical dimensions,
whereas the PoD top level Nodes are constrained, in horizontal whereas the PoD top-level nodes are constrained in the horizontal
dimension. dimension.
A port in the 2-D representation represents effectively the class A port in the 2-D representation effectively represents the class
of all the ports at the same position in all the PoDs that are of all the ports at the same position in all the PoDs that are
projected in its position along the depth axis. This is shown in projected in its position along the depth axis. This is shown in
<xref target="colnonpart" format="default"/>. <xref target="colnonpart" format="default"/>.
</t> </t>
<figure anchor="colnonpart"> <figure anchor="colnonpart">
<name>Collapsed Northern View of a Fabric for Any Number of PoDs</na me> <name>Collapsed Northern View of a Fabric for Any Number of PoDs</na me>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-collapsed-northern-view-fabricn-pods.svg"><svg xmlns:sodipodi="http://sodipo di.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/n amespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http:// www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/ " xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmln s:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg1 720" viewBox="0 0 864 596" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-collapsed-northern-view-fabricn-pods.svg"><svg xmlns:sodipodi="http://sodipo di.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/n amespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http:// www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/ " xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmln s:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg1 720" viewBox="0 0 864 596" xml:space="preserve">
<path id="path844" fill="none" stroke="#000000" stroke-width=" 1.06" d="M12.7,106.7l104-106"/> <path id="path844" fill="none" stroke="#000000" stroke-width=" 1.06" d="M12.7,106.7l104-106"/>
<path id="path846" fill="none" stroke="#000000" stroke-width=" 1.06" d="M54.9,106.7l104-106"/> <path id="path846" fill="none" stroke="#000000" stroke-width=" 1.06" d="M54.9,106.7l104-106"/>
skipping to change at line 3950 skipping to change at line 3993
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
As simple as a single plane deployment is, it introduces a limit due to As simple as a single plane deployment is, it introduces a limit due to
the bound on the available radix of the ToF nodes that has to be the bound on the available radix of the ToF nodes that has to be
at least P * K_LEAF. Nevertheless, it will become clear that a distinct at least P * K_LEAF. Nevertheless, it will become clear that a distinct
advantage of a connected or non-partitioned ToF is that advantage of a connected or non-partitioned ToF is that
all failures can be resolved by simple, non-transitive, positive all failures can be resolved by simple, non-transitive, positive
disaggregation (i.e., nodes advertising more specific prefixes with disaggregation (i.e., nodes advertising more specific prefixes with
the default to the level below them that is, however, not propagated the default to the level below them that is not propagated
further down the fabric) as described in <xref target="posdisaggreg" format="def further down the fabric) as described in <xref target="posdisaggreg" format="def
ault"/> ault"/>. In other words, non-partitioned ToF nodes can always reach nodes
. In other words, non-partitioned ToF nodes can always reach nodes
below or withdraw the routes from PoDs they cannot reach below or withdraw the routes from PoDs they cannot reach
unambiguously. And with this, positive disaggregation can heal all unambiguously. And with this, positive disaggregation can heal all
failures and still allow all the ToF nodes to be aware of each other via failures and still allow all the ToF nodes to be aware of each other via
south reflection. Disaggregation will be explained in further detail in south reflection. Disaggregation will be explained in further detail in
<xref target="disaggregate" format="default"/>. <xref target="disaggregate" format="default"/>.
</t> </t>
<t> <t>
In order to scale beyond the "single plane limit", the In order to scale beyond the "single plane limit", the
ToF can be partitioned into N number of identically ToF can be partitioned into N number of identically
wired planes where N is an integer divider of K_LEAF. wired planes where N is an integer divider of K_LEAF.
The 1:1 ratio and the desired symmetry are still served, this time The 1:1 ratio and the desired symmetry are still served, this time
with (K_TOP * N) ToF nodes, each of (P * K_LEAF / N) ports. with (K_TOP*N) ToF nodes, each of (P*K_LEAF/N) ports.
N=1 represents a non-partitioned Spine and N=K_LEAF is a maximally N=1 represents a non-partitioned Spine, and N=K_LEAF is a maximally
partitioned Spine. partitioned Spine.
Further, if R is any integer divisor of K_LEAF, then N=K_LEAF/R is a Further, if R is any integer divisor of K_LEAF, then N=K_LEAF/R is a
feasible number of planes and R a redundancy factor that denotes the feasible number of planes and R is a redundancy factor that denotes the
number of independent paths between 2 leaves within a plane. number of independent paths between 2 leaves within a plane.
It proves convenient for deployments to use a radix for the leaf It proves convenient for deployments to use a radix for the leaf
nodes that is a power of 2 so they can pick a number of planes nodes that is a power of 2 so they can pick a number of planes
that is a lower power of 2. that is a lower power of 2.
The example in <xref target="partitionedin2" format="default"/> splits the Spine in The example in <xref target="partitionedin2" format="default"/> splits the Spine in
2 planes with a redundancy factor R=3, meaning that there are 3 2 planes with a redundancy factor of R=3, meaning that there are 3
non-intersecting paths between any leaf node and any ToF node. non-intersecting paths between any leaf node and any ToF node.
A ToF node must have, in this case, at least 3*P ports, and be A ToF node must have, in this case, at least 3*P ports and be
directly connected to 3 of the 6 ToP nodes (spines) in each PoD. directly connected to 3 of the 6 ToP nodes (spines) in each PoD.
The ToP nodes are represented horizontally with K_TOP=8 ports The ToP nodes are represented horizontally with K_TOP=8 ports
northwards each. northwards each.
</t> </t>
<figure anchor="partitionedin2"> <figure anchor="partitionedin2">
<name>Northern View of a Multi-Plane ToF Level, K_LEAF=6, N=2</name> <name>Northern View of a Multi-Plane ToF Level, K_LEAF=6, N=2</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-north-view-multiplane-tof-level-k-leaf-6-n-2.svg"><svg xmlns:sodipodi="http: //sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inksca pe.org/namespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf= "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/eleme nts/1.1/" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/s vg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 500 363" width="500" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-north-view-multiplane-tof-level-k-leaf-6-n-2.svg"><svg xmlns:sodipodi="http: //sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inksca pe.org/namespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf= "http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/eleme nts/1.1/" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/s vg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 500 363" width="500" xml:space="preserve">
<rect id="rect26456-5" x="0.4" y="94.2" fill="#FFFFFF" stroke= "#000000" stroke-width="0.7685" stroke-miterlimit="2.9045" stroke-opacity="0.963 6" width="426.5" height="30.7"/> <rect id="rect26456-5" x="0.4" y="94.2" fill="#FFFFFF" stroke= "#000000" stroke-width="0.7685" stroke-miterlimit="2.9045" stroke-opacity="0.963 6" width="426.5" height="30.7"/>
<rect id="rect26456-7" x="0.4" y="56.4" fill="#FFFFFF" stroke= "#000000" stroke-width="0.7685" stroke-miterlimit="2.9045" stroke-opacity="0.963 6" width="426.5" height="30.7"/> <rect id="rect26456-7" x="0.4" y="56.4" fill="#FFFFFF" stroke= "#000000" stroke-width="0.7685" stroke-miterlimit="2.9045" stroke-opacity="0.963 6" width="426.5" height="30.7"/>
skipping to change at line 4156 skipping to change at line 4198
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
^ ^
| |
| --------------------- | ---------------------
+----- ToF Node Across Depth +----- ToF Node Across Depth
--------------------- ---------------------
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
At the extreme end of the spectrum it is even possible to fully At the extreme end of the spectrum, it is even possible to fully
partition the spine with N = K_LEAF and R=1, while maintaining partition the spine with N=K_LEAF and R=1 while maintaining
connectivity between each leaf node and each ToF node. connectivity between each leaf node and each ToF node.
In that case the ToF node connects to a single Port per PoD, so it In that case, the ToF node connects to a single port per PoD, so it
appears as a single port in the projected view represented in appears as a single port in the projected view represented in
<xref target="maxpartitioned" format="default"/>. <xref target="maxpartitioned" format="default"/>.
The number of ports required on the Spine Node is more than or equal The number of ports required on the spine node is more than or equal
to P, the number of PoDs. to P, i.e., the number of PoDs.
</t> </t>
<figure anchor="maxpartitioned"> <figure anchor="maxpartitioned">
<name>Northern View of a Maximally Partitioned ToF Level, R=1</name> <name>Northern View of a Maximally Partitioned ToF Level, R=1</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-north-view-max-partitioned-tof-level.svg"><svg xmlns:sodipodi="http://sodipo di.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/n amespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http:// www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/ " xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmln s:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2 384" viewBox="0 0 525 487" width="525" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-north-view-max-partitioned-tof-level.svg"><svg xmlns:sodipodi="http://sodipo di.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/n amespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http:// www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/ " xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmln s:xlink="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2 384" viewBox="0 0 525 487" width="525" xml:space="preserve">
<rect id="rect26456-3" x="51.6" y="20.3" fill="#FFFFFF" stroke ="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity="0.96 36" width="402.7" height="29"/> <rect id="rect26456-3" x="51.6" y="20.3" fill="#FFFFFF" stroke ="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity="0.96 36" width="402.7" height="29"/>
<rect id="rect26456-6" x="60.4" y="11.9" fill="#FFFFFF" stroke ="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity="0.96 36" width="29" height="43.9"/> <rect id="rect26456-6" x="60.4" y="11.9" fill="#FFFFFF" stroke ="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity="0.96 36" width="29" height="43.9"/>
<rect id="rect26456-6-5" x="111.5" y="11.9" fill="#FFFFFF" str oke="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity="0 .9636" width="29" height="43.9"/> <rect id="rect26456-6-5" x="111.5" y="11.9" fill="#FFFFFF" str oke="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity="0 .9636" width="29" height="43.9"/>
<rect id="rect26456-6-2" x="162.7" y="11.9" fill="#FFFFFF" str oke="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity="0 .9636" width="29" height="43.9"/> <rect id="rect26456-6-2" x="162.7" y="11.9" fill="#FFFFFF" str oke="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity="0 .9636" width="29" height="43.9"/>
<rect id="rect26456-6-27" x="213.8" y="11.9" fill="#FFFFFF" st roke="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity=" 0.9636" width="29" height="43.9"/> <rect id="rect26456-6-27" x="213.8" y="11.9" fill="#FFFFFF" st roke="#000000" stroke-width="0.7256" stroke-miterlimit="2.7426" stroke-opacity=" 0.9636" width="29" height="43.9"/>
skipping to change at line 4482 skipping to change at line 4524
</artset> </artset>
</figure> </figure>
</section> </section>
<!-- "Generalized Topology View" --> <!-- "Generalized Topology View" -->
</section> </section>
<section anchor="Fallen" numbered="true" toc="default"> <section anchor="Fallen" numbered="true" toc="default">
<name>Fallen Leaf Problem</name> <name>Fallen Leaf Problem</name>
<t> <t>
As mentioned earlier, RIFT exhibits an anisotropic behavior As mentioned earlier, RIFT exhibits an anisotropic behavior
tailored for fabrics with a North / South orientation and a high tailored for fabrics with a north-south orientation and a high
level of interleaving paths. A non-partitioned fabric makes a level of interleaving paths. A non-partitioned fabric makes a
total loss of connectivity between a ToF node at the total loss of connectivity between a ToF node at the
north and a leaf node at the south a very rare but yet possible north and a leaf node at the south a very rare but possible
occasion that is fully healed by positive disaggregation as occasion that is fully healed by positive disaggregation as
described in <xref target="posdisaggreg" format="default"/>. described in <xref target="posdisaggreg" format="default"/>.
In large fabrics or fabrics built from switches with low radix, In large fabrics or fabrics built from switches with a low radix,
the ToF may often become partitioned in planes which makes the the ToF may often become partitioned in planes, which makes it
occurrence of having a given leaf being only reachable from a more likely that a given leaf is only reachable from a
subset of the ToF nodes more likely to happen. This makes some subset of the ToF nodes. This makes some
further considerations necessary. further considerations necessary.
</t> </t>
<t> <t>
A "Fallen Leaf" is a leaf that can be reached by only a A "Fallen Leaf" is a leaf that can be reached by only a
subset of ToF nodes due to missing subset of ToF nodes due to missing
connectivity. If R is the redundancy factor, then it takes at connectivity. If R is the redundancy factor, then it takes at
least R breakages to reach a "Fallen Leaf" situation. least R breakages to reach a "Fallen Leaf" situation.
</t> </t>
<t> <t>
In a maximally partitioned fabric, the redundancy factor is R=1, In a maximally partitioned fabric, the redundancy factor is R=1,
so any breakage in the fabric will cause one or more fallen leaves so any breakage in the fabric will cause one or more fallen leaves
in the affected plane. in the affected plane.
R=2 guarantees that a single breakage will not cause a fallen leaf. R=2 guarantees that a single breakage will not cause a fallen leaf.
However, not all cases require disaggregation. The following cases However, not all cases require disaggregation. The following cases
do not require particular action: do not require particular action:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>If a southern link on a node goes down, then <li>If a southern link on a node goes down, then connectivity
connectivity through that node is lost for all nodes south of it. through that node is lost for all nodes south of it. There is no
There is no need to disaggregate since the connectivity need to disaggregate since the connectivity to this node is lost for
to this node is lost for all spine nodes in a same all spine nodes in the same fashion.
fashion.
</li> </li>
<li>If a ToF Node goes down, then northern traffic towards <li>If a ToF node goes down, then northern traffic towards it is
it is routed via alternate ToF nodes in the same plane routed via alternate ToF nodes in the same plane and there is no
and there is no need to disaggregate routes. need to disaggregate routes.
</li> </li>
</ul> </ul>
<t> <t>
In a general manner, the mechanism of non-transitive positive In a general manner, the mechanism of non-transitive, positive
disaggregation is sufficient when the disaggregating ToF nodes disaggregation is sufficient when the disaggregating ToF nodes
collectively connect to all the ToP nodes in the broken plane. collectively connect to all the ToP nodes in the broken plane.
This happens in the following case: This happens in the following case:
</t> </t>
<ul empty="true" spacing="normal"> <ul spacing="normal">
<li>If the breakage is the last northern link from a ToP <li>If the breakage is the last northern link from a ToP
node to a ToF node going down, then the fallen leaf node to a ToF node going down, then the fallen leaf
problem affects only that ToF node, and the connectivity problem affects only that ToF node, and the connectivity
to all the nodes in the PoD is lost from that ToF node. to all the nodes in the PoD is lost from that ToF node.
This can be observed by other ToF nodes within the This can be observed by other ToF nodes within the
plane where the ToP node is located and positively plane where the ToP node is located and positively
disaggregated within that plane. disaggregated within that plane.
</li> </li>
</ul> </ul>
<t> <t>
skipping to change at line 4559 skipping to change at line 4600
leaf node is lost within the plane where the link is leaf node is lost within the plane where the link is
located. located.
Southern Reflection by a leaf node, e.g., between ToP Southern Reflection by a leaf node, e.g., between ToP
nodes, if the PoD has only 2 levels, happens in between nodes, if the PoD has only 2 levels, happens in between
planes, allowing the ToP nodes to detect the problem planes, allowing the ToP nodes to detect the problem
within the PoD where it occurs and positively within the PoD where it occurs and positively
disaggregate. disaggregate.
The breakage can be observed by the ToF nodes in the The breakage can be observed by the ToF nodes in the
same plane through the North flooding of TIEs from the same plane through the north flooding of TIEs from the
ToP nodes. The ToF nodes however need to be aware of ToP nodes
However, the ToF nodes need to be aware of
all the affected prefixes for the negative, possibly all the affected prefixes for the negative, possibly
transitive disaggregation to be fully effective (i.e., transitive, disaggregation to be fully effective (i.e.,
a node advertising in the control plane that it cannot a node advertising in the control plane that it cannot
reach a certain more specific prefix than default reach a certain more specific prefix than default,
whereas such disaggregation must in the extreme condition whereas such disaggregation in the extreme condition must
propagate further down southbound). be propagated further down southbound).
The problem can also be observed by the ToF nodes in The problem can also be observed by the ToF nodes in
the other planes through the flooding of North TIEs the other planes through the flooding of North TIEs
from the affected leaf nodes, together with non-node from the affected leaf nodes, together with non-node
North TIEs which indicate the affected prefixes. North TIEs, which indicate the affected prefixes.
To be effective in that case, the positive To be effective in that case, the positive
disaggregation must reach down to the nodes that make disaggregation must reach down to the nodes that make
the plane selection, which are typically the ingress the plane selection, which are typically the ingress
leaf nodes. The information is not useful for leaf nodes. The information is not useful for
routing in the intermediate levels. routing in the intermediate levels.
</li> </li>
<li>If the breakage is a ToP node in a maximally <li>If the breakage is a ToP node in a maximally
partitioned fabric (in which case it is the only ToP partitioned fabric (in which case it is the only ToP
node serving the plane in that PoD that goes down), node serving the plane in that PoD that goes down),
then the connectivity to all the nodes in the PoD is then the connectivity to all the nodes in the PoD is
skipping to change at line 4597 skipping to change at line 4639
cannot discover fallen leaves in a different plane. cannot discover fallen leaves in a different plane.
They also cannot determine beyond their local plane They also cannot determine beyond their local plane
whether a leaf node that was initially reachable has whether a leaf node that was initially reachable has
become unreachable. become unreachable.
As the breakage can be observed by the ToF As the breakage can be observed by the ToF
nodes in the plane where the breakage happened, the nodes in the plane where the breakage happened, the
ToF nodes in the plane need to be aware of all the ToF nodes in the plane need to be aware of all the
affected prefixes for the negative disaggregation to be affected prefixes for the negative disaggregation to be
fully effective. fully effective.
The problem can also be observed by the ToF nodes in the other planes through th
The problem can also be observed by the ToF nodes in e flooding of North TIEs from the affected leaf nodes if the failing ToP node is
the other planes through the flooding of North TIEs directly connected to its leaf nodes, which can detect the link going down. The
from the affected leaf nodes, if there n again, the knowledge of the failure at the ToF level can only be useful if it
are only 3 levels and the ToP nodes are directly is propagated transitively to all the leaves; it is useless above that level sin
connected to the leaf nodes, and then again it can ce the decision of placing a packet in a plane happens at the leaf that injects
only be effective if it is propagated transitively to the the packet in the fabric.
leaf, and useless above that level.
</li> </li>
</ul> </ul>
<t> <t>
These abstractions are rolled back into a simplified example These abstractions are rolled back into a simplified example
that shows that in <xref target="partitioned-spine" format="default"/> the l oss of link between spine node 3 and leaf node 3 will make leaf node 3 a fallen that shows that in <xref target="partitioned-spine" format="default"/> the l oss of the link between spine node 3 and leaf node 3 will make leaf node 3 a fal len
leaf for ToF nodes in plane C. Worse, if the cabling was never present in th e first place, plane leaf for ToF nodes in plane C. Worse, if the cabling was never present in th e first place, plane
C will not even be able to know that such a fallen leaf exists. Hence partit ioning without C will not even be able to know that such a fallen leaf exists. Hence, parti tioning without
further treatment results in two grave problems: further treatment results in two grave problems:
</t> </t>
<ul spacing="normal"> <ol spacing="normal">
<li>Leaf node 1 trying to route to leaf node 3 must not choose spine n <li>Leaf node 1 trying to route to leaf node 3 must not choose spine
ode 3 in plane C as its next hop since it will inevitably drop the packet when f node 3 in plane C as its next hop since it will inevitably drop the
orwarding using default routes or packet when forwarding using default routes or do excessive
do excessive bow-tying. This information must be in its routing bow-tying. This information must be in its routing table.
table.
</li> </li>
<li>A path computation trying to deal with the problem by distributing <li>A path computation trying to deal with the problem by
host routes may only distributing host routes may only form paths through leaves.
form paths through leaves. The flooding of information about lea The
f node 3 would have to go flooding of information about leaf node 3 would have to go up to ToF
up to ToF nodes in planes A, B, and D and then "loopback" over o nodes in planes A, B, and D and then "loopback" over other leaves to
ther leaves to ToF C leading in extreme ToF C, leading in extreme cases to traffic for leaf node 3 when
cases to traffic for leaf node 3 when presented to plane C takin presented to plane C taking an "inverted fabric" path where leaves
g an "inverted fabric" path start to serve as ToFs, at least for the duration of a protocol's
where leaves start to serve as ToFs, at least for the duration o convergence.
f a protocol's convergence.
</li> </li>
</ul> </ol>
</section> </section>
<section anchor="discFallen" numbered="true" toc="default"> <section anchor="discFallen" numbered="true" toc="default">
<name>Discovering Fallen Leaves</name> <name>Discovering Fallen Leaves</name>
<t> <t>
When aggregation is used, RIFT deals with fallen leaves by ensuring that When aggregation is used, RIFT deals with fallen leaves by ensuring that
all the ToF nodes share the same north topology database. all the ToF nodes share the same north topology database.
This happens naturally in single plane design This happens naturally in single-plane design
by the means of northbound flooding and south reflection but needs additiona l considerations in multi-plane fabrics. by the means of northbound flooding and south reflection but needs additiona l considerations in multi-plane fabrics.
To enable routing to fallen leaves in multi-plane designs, RIFT To enable routing to fallen leaves in multi-plane designs, RIFT
requires additional interconnection across planes between the ToF nodes, requires additional interconnection across planes between the ToF nodes,
e.g., using rings as illustrated in <xref target="interspine" format="defaul t"/>. e.g., using rings as illustrated in <xref target="interspine" format="defaul t"/>.
Other solutions are possible but they either need more cabling or Other solutions are possible, but they either need more cabling or
end up having much longer flooding paths and/or single points of end up having much longer flooding paths and/or single points of
failure. failure.
</t> </t>
<t> <t>
In detail, by reserving at least two ports on each ToF node In detail, by reserving at least two ports on each ToF node,
it is possible to connect them together by interplane it is possible to connect them together by interplane
bi-directional rings as illustrated in <xref target="interspine" format="def ault"/>. bidirectional rings as illustrated in <xref target="interspine" format="defa ult"/>.
The rings will be used to exchange full north topology information The rings will be used to exchange full north topology information
between planes. All ToFs having the same north topology allows by the means of between planes. All ToFs having the same north topology allows, by the means of
transitive, negative disaggregation described in transitive, negative disaggregation described in
<xref target="negdisaggreg" format="default"/> to efficiently fix any possib le <xref target="negdisaggreg" format="default"/>, to efficiently fix any possi ble
fallen leaf scenario. fallen leaf scenario.
Somewhat as a side effect, the exchange of information fulfills the Somewhat as a side effect, the exchange of information fulfills the
requirement for a full view of the fabric topology at the requirement for a full view of the fabric topology at the
ToF level, without the need to collate it from multiple ToF level without the need to collate it from multiple
points. points.
</t> </t>
<figure anchor="interspine"> <figure anchor="interspine">
<name>Using rings to bring all planes and at the ToF bind them</name> <name>Using Rings to Bring All Planes and Bind Them at the ToF</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-inter-tof-rings.svg"><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http ://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="Layer_1" viewBox= "0 0 3593.8 1750" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-inter-tof-rings.svg"><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http ://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="Layer_1" viewBox= "0 0 3593.8 1750" xml:space="preserve">
<rect x="4.8" y="11.1" fill="none" width="3590" height="1704.8"/ > <rect x="4.8" y="11.1" fill="none" width="3590" height="1704.8"/ >
<rect x="4.8" y="1715.9" fill="none" width="3590" height="24.3"/ > <rect x="4.8" y="1715.9" fill="none" width="3590" height="24.3"/ >
<path fill="#FFFFFF" stroke="#000000" stroke-width="4" stroke-op acity="0.9636" stroke-dasharray="32,32" d="M1850.7,1715.9H57.5 l-2.8-830.3L1848 .1,71.1L1850.7,1715.9z"/> <path fill="#FFFFFF" stroke="#000000" stroke-width="4" stroke-op acity="0.9636" stroke-dasharray="32,32" d="M1850.7,1715.9H57.5 l-2.8-830.3L1848 .1,71.1L1850.7,1715.9z"/>
<rect x="4.8" y="11.1" fill="none" width="3590" height="1704.8"/ > <rect x="4.8" y="11.1" fill="none" width="3590" height="1704.8"/ >
<rect x="4.8" y="1715.9" fill="none" width="3590" height="24.3"/ > <rect x="4.8" y="1715.9" fill="none" width="3590" height="24.3"/ >
<path fill="#FFFFFF" stroke="#000000" stroke-width="4" stroke-op acity="0.9636" stroke-dasharray="32,32" d="M2420.5,1715.9H641.3 l-2.5-718.5l177 9.3-808.1L2420.5,1715.9z"/> <path fill="#FFFFFF" stroke="#000000" stroke-width="4" stroke-op acity="0.9636" stroke-dasharray="32,32" d="M2420.5,1715.9H641.3 l-2.5-718.5l177 9.3-808.1L2420.5,1715.9z"/>
<rect x="4.7" y="11.1" fill="none" width="3590" height="1704.8"/ > <rect x="4.7" y="11.1" fill="none" width="3590" height="1704.8"/ >
<rect x="4.7" y="1715.9" fill="none" width="3590" height="24.3"/ > <rect x="4.7" y="1715.9" fill="none" width="3590" height="24.3"/ >
skipping to change at line 4780 skipping to change at line 4821
| || || . || || . || || . || || |</ artwork> | || || . || || . || || . || || |</ artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="FixFallen" numbered="true" toc="default"> <section anchor="FixFallen" numbered="true" toc="default">
<name>Addressing the Fallen Leaves Problem</name> <name>Addressing the Fallen Leaves Problem</name>
<t> <t>
One consequence of the "Fallen Leaf" problem is that some prefixes One consequence of the "Fallen Leaf" problem is that some prefixes
attached to the fallen leaf become unreachable from some of the attached to the fallen leaf become unreachable from some of the
ToF nodes. ToF nodes.
RIFT defines two methods to address this issue denoted as positive disaggreg ation and RIFT defines two methods to address this issue, denoted as positive disaggre gation and
negative disaggregation. Both methods flood corresponding types of negative disaggregation. Both methods flood corresponding types of
South TIEs to South TIEs to
advertise the impacted prefix(es). advertise the impacted prefix(es).
</t> </t>
<t> <t>
When used for the operation of disaggregation, a positive South When used for the operation of disaggregation, a positive South
TIE, as usual, indicates reachability to a prefix of given length TIE, as usual, indicates reachability to a prefix of given length
and all addresses subsumed by it. and all addresses subsumed by it.
In contrast, a negative route advertisement indicates that the In contrast, a negative route advertisement indicates that the
origin cannot route to the advertised prefix. origin cannot route to the advertised prefix.
</t> </t>
<t> <t>
The positive disaggregation is originated by a router that can The positive disaggregation is originated by a router that can
still reach the advertised prefix, and the operation is not still reach the advertised prefix, and the operation is not
transitive. In other words, the receiver does <strong>not</strong> generate its own transitive. In other words, the receiver does <strong>not</strong> generate its own
TIEs or flood them south as a consequence of receiving positive TIEs or flood them south as a consequence of receiving positive
disaggregation advertisements from a higher level node. disaggregation advertisements from a higher-level node.
The effect of a positive disaggregation is that the traffic to The effect of a positive disaggregation is that the traffic to
the impacted prefix will follow the longest match and will be the impacted prefix will follow the longest match and will be
limited to the northbound routers that advertised the more limited to the northbound routers that advertised the more
specific route. specific route.
</t> </t>
<t> <t>
In contrast, the negative disaggregation can be transitive, and is In contrast, the negative disaggregation can be transitive and is
propagated south when all the possible routes have been advertised propagated south when all the possible routes have been advertised
as negative exceptions. as negative exceptions.
A negative route advertisement is only actionable when the A negative route advertisement is only actionable when the
negative prefix is aggregated by a positive route advertisement negative prefix is aggregated by a positive route advertisement
for a shorter prefix. for a shorter prefix.
In such case, the negative advertisement "punches out a hole" in In such case, the negative advertisement "punches out a hole" in
the positive route in the routing table, making the positive prefix the positive route in the routing table, making the positive prefix
reachable through reachable through
the originator with the special consideration of the negative the originator with the special consideration of the negative
prefix removing certain next hop neighbors. The specific procedures prefix removing certain next-hop neighbors. The specific procedures
will be explained in detail in <xref target="neg_dis_computation_sec"/>. are explained in detail in <xref target="neg_dis_computation_sec"/>.
</t> </t>
<t> <t>
When the ToF switches are not partitioned into multiple planes, When the ToF switches are not partitioned into multiple planes,
the resulting southbound flooding the resulting southbound flooding
of the positive disaggregation by the ToF nodes that can still of the positive disaggregation by the ToF nodes that can still
reach the impacted prefix is in general enough to cover all the reach the impacted prefix is generally enough to cover all the
switches at the next level south, typically the ToP nodes. switches at the next level south, typically the ToP nodes.
If all those switches are aware of the disaggregation, they If all those switches are aware of the disaggregation, they
collectively create a ceiling that intercepts all the traffic collectively create a ceiling that intercepts all the traffic
north and forwards it to the ToF nodes that advertised the more north and forwards it to the ToF nodes that advertised the more
specific route. specific route.
In that case, the positive disaggregation alone is sufficient to In that case, the positive disaggregation alone is sufficient to
solve the fallen leaf problem. solve the fallen leaf problem.
</t> </t>
<t> <t>
On the other hand, when the fabric is partitioned in planes, the On the other hand, when the fabric is partitioned in planes, the
skipping to change at line 4850 skipping to change at line 4891
necessary. necessary.
The details on the RIFT approach to deal with fallen leaves in an The details on the RIFT approach to deal with fallen leaves in an
optimal way are specified in <xref target="negdisaggreg" format="default"/>. optimal way are specified in <xref target="negdisaggreg" format="default"/>.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default" anchor="specification_sec"> <section numbered="true" toc="default" anchor="specification_sec">
<name>Specification</name> <name>Specification</name>
<t> <t>
This section specifies the protocol in a normative fashion b y either This section specifies the protocol in a normative fashion b y either
prescriptive procedures or behavior defined by Finite State Machines (FSM). prescriptive procedures or behavior defined by Finite State Machines (FSMs).
</t> </t>
<t>The FSMs, as usual, are presented as states a neighbor can assume, <t>The FSMs, as usual, are presented as states a neighbor can assume,
events that can occur, and the corresponding actions performed when tr ansitioning events that can occur, and the corresponding actions performed when tr ansitioning
between states on event processing.</t> between states on event processing.</t>
<t>Actions are performed before the end state is assumed. <t>Actions are performed before the end state is assumed.
</t> </t>
<t>The FSMs can queue events against itself to chain actions or against ot her FSMs in the specification. <t>The FSMs can queue events against themselves to chain actions or agains t other FSMs in the specification.
Events are always processed Events are always processed
in the sequence they have been queued.</t> in the sequence they have been queued.</t>
<t>Consequently, "On Entry" actions for an FSM state are performed every t ime and right before the corresponding <t>Consequently, "On Entry" actions for an FSM state are performed every t ime and right before the corresponding
state is entered, i.e., after any transitions from previous state.</t> state is entered, i.e., after any transitions from previous state.</t>
<t>"On Exit" actions are performed every time and immediately when a state is <t>"On Exit" actions are performed every time and immediately when a state is
exited, i.e., before any transitions towards target state are performed.</t> exited, i.e., before any transitions towards the target state are performed. </t>
<t>Any attempt to transition from a state towards another on reception of <t>Any attempt to transition from a state towards another on reception of
an event where no action is specified MUST be considered an unrecoverable an event where no action is specified <bcp14>MUST</bcp14> be considered an u
error and the protocol MUST reset all adjacencies and discard all the state nrecoverable
(i.e., force the FSM error, and the protocol <bcp14>MUST</bcp14> reset all adjacencies and discar
d all the states (i.e., force the FSM
back to <em>OneWay</em> and flush all of the queues holding flooding informa tion).</t> back to <em>OneWay</em> and flush all of the queues holding flooding informa tion).</t>
<t> The data structures and FSMs described in this document are conceptual <t> The data structures and FSMs described in this document are conceptual
and do not have to be implemented precisely as described here, i.e., an and do not have to be implemented precisely as described here, i.e., an
implementation is considered conforming as long implementation is considered conforming as long
as it supports the described functionality and exhibits as it supports the described functionality and exhibits
externally observable behavior equivalent to the behavior of the st andardized FSMs.</t> externally observable behavior equivalent to the behavior of the st andardized FSMs.</t>
<t> <t>
The FSMs can use "timers" for different situations. Those timers a re started The FSMs can use "timers" for different situations. Those timers a re started
through actions and their expiration leads to queuing of correspon ding events to be processed. through actions, and their expiration leads to queuing of correspo nding events to be processed.
</t> </t>
<t> <t>
The term "holdtime" is used often as short-hand for "holddown time r" and signifies either the The term "holdtime" is used often as shorthand for "holddown timer " and signifies either the
length of the holding down period or the timer used to expire afte r such period. Such timers are used to length of the holding down period or the timer used to expire afte r such period. Such timers are used to
"hold down" state within an FSM that is cleaned if the machine tri ggers a <em>HoldtimeExpired</em> "hold down" the state within an FSM that is cleaned if the machine triggers a <em>HoldtimeExpired</em>
event. event.
</t> </t>
<!-- AD review <!-- AD review
<t>Where a FSM representation is inconvenient, i.e. the amount of proced ures and kept state <t>Where a FSM representation is inconvenient, i.e. the amount of proced ures and kept state
exceeds the amount of transitions, the specification defers to a more proced ural description of operations on exceeds the amount of transitions, the specification defers to a more proced ural description of operations on
data structures.</t> data structures.</t>
--> -->
<section numbered="true" toc="default" anchor="transportaiton_sec"> <section numbered="true" toc="default" anchor="transportaiton_sec">
<name>Transport</name> <name>Transport</name>
<t>All normative RIFT packet structures and their contents are defined <t>All normative RIFT packet structures and their contents are defined
in the <xref target="thrift" format="default">Thrift</xref> models in <xref target="schema" format="default"/>. in the <xref target="thrift" format="default">Thrift</xref> models in <xref target="schema" format="default"/>.
The packet structure itself is defined in <em>ProtocolPacket</em> which contains the packet header The packet structure itself is defined in <em>ProtocolPacket</em>, which contains the packet header
in <em>PacketHeader</em> and the packet contents in <em>PacketCont ent</em>. <em>PacketContent</em> in <em>PacketHeader</em> and the packet contents in <em>PacketCont ent</em>. <em>PacketContent</em>
is a union of the LIE, TIE, TIDE, and TIRE packets which are subse quently is a union of the LIE, TIE, TIDE, and TIRE packets, which are subs equently
defined in <em>LIEPacket</em>, <em>TIEPacket</em>, <em>TIDEPacket< /em>, defined in <em>LIEPacket</em>, <em>TIEPacket</em>, <em>TIDEPacket< /em>,
and <em>TIREPacket</em> respectively.</t> and <em>TIREPacket</em>, respectively.</t>
<t>Further, in terms of bits on the wire, it is the <em>ProtocolPacket</ em> that is serialized <t>Further, in terms of bits on the wire, it is the <em>ProtocolPacket</ em> that is serialized
and carried in an envelope defined in <xref target="secu rity-envelope"/> within and carried in an envelope defined in <xref target="secu rity-envelope"/> within
a UDP frame that provides security and allows validation/mod ification of a UDP frame that provides security and allows validation/mod ification of
several important fields without Thrift de-serialization for several important fields without Thrift deserialization for
performance and performance and
security reasons. Security model and procedures are further security reasons. Security models and procedures are further
explained explained
in <xref target="security" format="default"/>. in <xref target="security" format="default"/>.
</t> </t>
</section> </section>
<section anchor="LIE" numbered="true" toc="default"> <section anchor="LIE" numbered="true" toc="default">
<name>Link (Neighbor) Discovery (LIE Exchange)</name> <name>Link (Neighbor) Discovery (LIE Exchange)</name>
<t>RIFT LIE exchange auto-discovers neighbors, negotiates RIFT ZTP param eters and discovers <t>RIFT LIE exchange auto-discovers neighbors, negotiates RIFT ZTP param eters, and discovers
miscablings. miscablings.
<!-- removed based on AD <!-- removed based on AD
It uses a <em>ThreeWay</em> handshake mechanism It uses a <em>ThreeWay</em> handshake mechanism
which is a cleaned up version of <xref target="RFC5303"></xr ef>. which is a cleaned up version of <xref target="RFC5303"></xr ef>.
Observe that for easier comprehension Observe that for easier comprehension
the terminology of one/two and <em>ThreeWay</em> states does the terminology of one/two and <em>ThreeWay</em> states does
NOT align with OSPF or ISIS FSMs albeit they use roughly sam e mechanisms. NOT align with OSPF or ISIS FSMs albeit they use roughly sam e mechanisms.
--> -->
The formation progresses under normal conditions The formation progresses under normal conditions
from <em>OneWay</em> to <em>TwoWay</em> and then <em>Thr from <em>OneWay</em> to <em>TwoWay</em> and then <em>Thr
eeWay</em> state at which eeWay</em> state, at which
point it is ready to exchange TIEs per <xref target="tie point it is ready to exchange TIEs as described in <xref
s" format="default"/>. target="ties" format="default"/>.
The adjacency exchanges <xref target="ZTP">RIFT ZTP in formation</xref> in any of the states, The adjacency exchanges <xref target="ZTP">RIFT ZTP in formation</xref> in any of the states,
i.e. it is not necessary to reach <em>ThreeWay</em> fo r zero-touch provisioning to i.e., it is not necessary to reach <em>ThreeWay</em> f or ZTP to
operate. operate.
</t> </t>
<t> <t>
RIFT supports any combination of IPv4 and IPv6 addressing, inclu ding link-local scope, on the fabric to form adjacencies RIFT supports any combination of IPv4 and IPv6 addressing, inclu ding link-local scope, on the fabric to form adjacencies
with the additional capability with the additional capability
for forwarding paths that are capable of forwarding IPv4 packets in presence of IPv6 addressing only. for forwarding paths that are capable of forwarding IPv4 packets in the presence of IPv6 addressing only.
</t> </t>
<!--[rfced] We are having trouble parsing this sentence. Please review
and let us know how it should be updated for clarity.
Original:
IPv4 LIE exchange happens by default over well-known administratively
locally scoped and configured or otherwise well-known IPv4 multicast
address [RFC2365].
-->
<t>IPv4 LIE <t>IPv4 LIE
exchange happens by default over well-known administratively exchange happens by default over well-known administratively
locally scoped and configured or otherwise well-known locally scoped and configured or otherwise well-known
IPv4 multicast address <xref target="RFC2365" format="default"/>. IPv4 multicast address <xref target="RFC2365" format="default"/>.
For IPv6 <xref target="RFC8200" format="default"/> exchange is per For IPv6 <xref target="RFC8200" format="default"/>, exchange is pe
formed over rformed over the
link-local multicast scope <xref target="RFC4291" format="default"/> address link-local multicast scope <xref target="RFC4291" format="default"/> address,
which is configured or otherwise which is configured or otherwise
well-known. In both cases a destination UDP port defined in the sc hema <xref target="common_thrift_app" format="default"/> well-known. In both cases, a destination UDP port defined in the s chema (<xref target="common_thrift_app" format="default"/>)
is used unless configured otherwise. is used unless configured otherwise.
LIEs MUST be sent with an IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) LIEs <bcp14>MUST</bcp14> be sent with an IPv4 Time to Live (TTL) or an IPv6
of either 1 or 255 Hop Limit (HL) of either 1 or 255
to prevent RIFT information reaching beyond a single L3 next-hop in the topo to prevent RIFT information reaching beyond a single Layer 3 (L3) next hop i
logy. n the topology.
Observe that for the allocated link-local scope IP multicast addre Observe that, for the allocated link-local scope IP multicast addr
ss TTL value of 1 is a more logical choice ess, the TTL value of 1 is a more logical choice
since TTL value of 255 may in some environment lead to an early since the TTL value of 255 may, in some environments, lead to an e
drop due to suspicious TTL value for a packet addressed to such de arly
stination. drop due to the suspicious TTL value for a packet addressed to suc
LIEs SHOULD be sent with network control precedence unless an implementation h a destination.
is prevented from doing so <xref target="RFC2474" format="default"/>. LIEs <bcp14>SHOULD</bcp14> be sent with network control precedence unless an
implementation is prevented from doing so <xref target="RFC2474" format="defaul
t"/>.
</t> </t>
<t> <t>
Any LIE packet received on an address that is neither the well -known nor configured Any LIE packet received on an address that is neither the well -known nor configured
multicast or a broadcast address MUST be discarded. multicast or a broadcast address <bcp14>MUST</bcp14> be discar ded.
</t> </t>
<t> <t>
The originating port The originating port
of the LIE has no further significance other than identifying the originatio n point. of the LIE has no further significance, other than identifying the originati on point.
LIEs are LIEs are
exchanged over all links running RIFT. exchanged over all links running RIFT.
</t> </t>
<t> <t>
An implementation may listen and send LIEs on IPv4 and/or An implementation may listen and send LIEs on IPv4 and/or
IPv6 multicast addresses. A node MUST NOT originate LIEs IPv6 multicast addresses. A node <bcp14>MUST NOT</bcp14> originate LIEs
on an address family if it does not process received LIEs on that on an address family if it does not process received LIEs on that
family. LIEs on the same link are considered family. LIEs on the same link are considered
part of the same LIE FSM independent of the address family part of the same LIE FSM independent of the address family
they arrive on. The LIE source address may not identify they arrive on. The LIE source address may not identify
the peer uniquely in unnumbered or link-local address cases so the peer uniquely in unnumbered or link-local address cases so
the response transmission MUST occur over the same interface the LIEs have b een the response transmission <bcp14>MUST</bcp14> occur over the same interface the LIEs have been
received on. A node may use any of the adjacency's source addresses it received on. A node may use any of the adjacency's source addresses it
saw in saw in
LIEs on the specific interface during adjacency formation to send TIEs (<xre f target="flooding_sec"/>). LIEs on the specific interface during adjacency formation to send TIEs (<xre f target="flooding_sec"/>).
That implies that an implementation MUST be ready to accept TIEs on That implies that an implementation <bcp14>MUST</bcp14> be ready to accept T
all addresses it used as source of LIE frames. IEs on
all addresses it used as sources of LIE frames.
</t> </t>
<t>A simplified version MAY be implemented on platforms with limited mul <t>A simplified version <bcp14>MAY</bcp14> be implemented on platforms w
ticast support ith limited multicast support
(e.g. IoT devices) by sending and receiving LIE frames on IPv4 subnet (e.g., Internet of Things (IoT) devices) by sending and receiving LIE
broadcast addresses or IPv6 frames on IPv4 subnet broadcast addresses or IPv6
all routers multicast address. However, this technique is less optimal all-routers multicast addresses. However, this technique is less optim
and presents a wider al and presents a wider
attack surface from a security perspective and should hence be used on attack surface from a security perspective and should hence be used on
ly as last resort.</t> ly as a last resort.</t>
<t>A <em>ThreeWay</em> adjacency (as defined in the glossary) over any a ddress family implies support <t>A <em>ThreeWay</em> adjacency (as defined in the glossary) over any a ddress family implies support
for IPv4 forwarding if the <em>ipv4_forwarding_capable</em> flag in <em>Link Capabilities</em> for IPv4 forwarding if the <em>ipv4_forwarding_capable</em> flag in <em>Link Capabilities</em>
is set to true. In the absence of IPv4 LIEs with <em>ipv4_forwarding_capable </em> set to true, a is set to true. In the absence of IPv4 LIEs with <em>ipv4_forwarding_capable </em> set to true, a
node MUST forward IPv4 packets using gateways discovered on IPv6-only links advertising this node <bcp14>MUST</bcp14> forward IPv4 packets using gateways discovered on I Pv6-only links advertising this
capability. The mechanism to discover the corresponding IPv6 gateway is out of scope for this specification capability. The mechanism to discover the corresponding IPv6 gateway is out of scope for this specification
and may be implementation specific. It is expected that the whole fabric and may be implementation-specific. It is expected that the whole fabric
supports the same type of forwarding of address families on all the links, a supports the same type of forwarding of address families on all the links; a
ny other combination ny other combination
is outside the scope of this specification. is outside the scope of this specification.
If IPv4 forwarding is If IPv4 forwarding is
supported on an interface, <em>ipv4_forwarding_capable</em> MUST be set to supported on an interface, <em>ipv4_forwarding_capable</em> <bcp14>MUST</bcp 14> be set to
true for all LIEs advertised from that interface. If IPv4 true for all LIEs advertised from that interface. If IPv4
and IPv6 LIEs indicate contradicting information, protocol and IPv6 LIEs indicate contradicting information, protocol
behavior is unspecified. behavior is unspecified.
A node sending IPv4 LIEs MUST set the <em>ipv4_forwarding_capable</em> flag to true on all LIEs A node sending IPv4 LIEs <bcp14>MUST</bcp14> set the <em>ipv4_forwarding_cap able</em> flag to true on all LIEs
advertised from that interface. advertised from that interface.
</t> </t>
<t> <t>
Operation of a fabric where only Operation of a fabric where only
some of the links are supporting forwarding on an address family or have an address in a family and some of the links are supporting forwarding on an address family or have an address in a family and
others do not is outside the scope of this specification. others do not is outside the scope of this specification.
</t> </t>
<t>Any attempt to construct IPv6 forwarding over IPv4 only adjacencies i s outside this specification.</t> <t>Any attempt to construct IPv6 forwarding over IPv4-only adjacencies i s outside the scope of this specification.</t>
<t><xref target="af-types-cp"/> outlines protocol behavior pertaining to LIE exchange over different address <t><xref target="af-types-cp"/> outlines protocol behavior pertaining to LIE exchange over different address
family combinations. family combinations.
<xref target="af-types-f"/> outlines the way in which neighbors forward traffic <xref target="af-types-f"/> outlines the way in which neighbors forward traffic
as it pertains to the <em>ipv4_forwarding_capable</em> flag setting acro ss the same address family combinations. as it pertains to the <em>ipv4_forwarding_capable</em> flag setting acro ss the same address family combinations.
The table is symmetric, i.e. local and remote can be exchanged to construct the remaining combinations.</t> The table is symmetric, i.e., the local and remote columns can be exchanged to construct the remaining combinations.</t>
<t>The specific forwarding implementation to support the described behav ior is out of scope for this document.</t> <t>The specific forwarding implementation to support the described behav ior is out of scope for this document.</t>
<table anchor="af-types-cp" align="center"> <table anchor="af-types-cp" align="center">
<name>Control Plane Behavior for Neighbor AF Combinations</name> <name>Control Plane Behavior for Neighbor AF Combinations</name>
<thead> <thead>
<tr> <tr>
<th align="left">Local Neighbor AF</th> <th align="left">Local Neighbor AF</th>
<th align="left">Remote Neighbor AF</th> <th align="left">Remote Neighbor AF</th>
<th align="left">LIE Exchange Behavior</th> <th align="left">LIE Exchange Behavior</th>
</tr> </tr>
</thead> </thead>
skipping to change at line 5030 skipping to change at line 5081
<td align="left">LIEs and TIEs are exchanged over IPv4 only. The l ocal neighbor receives TIEs from remote neighbors on any of the LIE source addre sses.</td> <td align="left">LIEs and TIEs are exchanged over IPv4 only. The l ocal neighbor receives TIEs from remote neighbors on any of the LIE source addre sses.</td>
</tr> </tr>
<tr> <tr>
<td align="left">IPv6</td> <td align="left">IPv6</td>
<td align="left">IPv6</td> <td align="left">IPv6</td>
<td align="left">LIEs and TIEs are exchanged over IPv6 only. The l ocal neighbor receives TIEs from remote neighbors on any of the LIE source addre sses.</td> <td align="left">LIEs and TIEs are exchanged over IPv6 only. The l ocal neighbor receives TIEs from remote neighbors on any of the LIE source addre sses.</td>
</tr> </tr>
<tr> <tr>
<td align="left">IPv4, IPv6</td> <td align="left">IPv4, IPv6</td>
<td align="left">IPv6</td> <td align="left">IPv6</td>
<td align="left">The local neighbor sends LIEs for both IPv4 and I Pv6 while the remote neighbor only sends LIEs for IPv6. <td align="left">The local neighbor sends LIEs for both IPv4 and I Pv6, while the remote neighbor only sends LIEs for IPv6.
The resulting adjacency will exchange TIEs over IPv6 on any of the IPv6 LIE source addresses.</td> The resulting adjacency will exchange TIEs over IPv6 on any of the IPv6 LIE source addresses.</td>
</tr> </tr>
<tr> <tr>
<td align="left">IPv4, IPv6</td> <td align="left">IPv4, IPv6</td>
<td align="left">IPv4, IPv6</td> <td align="left">IPv4, IPv6</td>
<td align="left">LIEs and TIEs are exchanged over IPv6 and IPv4. T IEs are received on any of the IPv4 or IPv6 LIE source addresses. The local neig hbor receives TIEs from the remote neighbors on any of the IPv4 or IPv6 LIE sour ce addresses.</td> <td align="left">LIEs and TIEs are exchanged over IPv6 and IPv4. T IEs are received on any of the IPv4 or IPv6 LIE source addresses. The local neig hbor receives TIEs from the remote neighbors on any of the IPv4 or IPv6 LIE sour ce addresses.</td>
</tr> </tr>
<tr> <tr>
<td align="left">IPv4, IPv6</td> <td align="left">IPv4, IPv6</td>
<td align="left">IPv4</td> <td align="left">IPv4</td>
<td align="left">The local neighbor sends LIEs for both IPv4 and I Pv6 while the remote neighbor only sends LIEs for IPv4. <td align="left">The local neighbor sends LIEs for both IPv4 and I Pv6, while the remote neighbor only sends LIEs for IPv4.
The resulting adjacency will exchange TIEs over IPv4 on any of the IPv4 LIE source addresses.</td> The resulting adjacency will exchange TIEs over IPv4 on any of the IPv4 LIE source addresses.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<table anchor="af-types-f" align="center"> <table anchor="af-types-f" align="center">
<name>Forwarding Behavior for Neighbor AF Combinations</name> <name>Forwarding Behavior for Neighbor AF Combinations</name>
<thead> <thead>
<tr> <tr>
<th align="left">Local Neighbor AF</th> <th align="left">Local Neighbor AF</th>
<th align="left">Remote Neighbor AF</th> <th align="left">Remote Neighbor AF</th>
skipping to change at line 5085 skipping to change at line 5136
</tr> </tr>
<tr> <tr>
<td align="left">IPv4, IPv6</td> <td align="left">IPv4, IPv6</td>
<td align="left">IPv4</td> <td align="left">IPv4</td>
<td align="left">IPv4 traffic can be forwarded.</td> <td align="left">IPv4 traffic can be forwarded.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The protocol does <strong>not</strong> support selective disabling of <t>The protocol does <strong>not</strong> support selective disabling of
address families after adjacency formation, address families after adjacency formation,
disabling IPv4 forwarding capability or any local address changes disabling IPv4 forwarding capability, or any local address changes
in <em>ThreeWay</em> state, i.e. if a link has entered ThreeWay in <em>ThreeWay</em> state, i.e., if a link has entered ThreeWay
IPv4 and/or IPv6 with a IPv4 and/or IPv6 with a
neighbor on an adjacency and it wants to stop supporting one of neighbor on an adjacency and it wants to stop supporting one of
the families or change the families, change
any of its local addresses or stop IPv4 forwarding, it MUST any of its local addresses, or stop IPv4 forwarding, it <bcp14>MUST</bcp14>
tear down and rebuild the adjacency. It MUST also remove any state tear down and rebuild the adjacency. It <bcp14>MUST</bcp14> also remove any
state
it stored about the remote side of the it stored about the remote side of the
adjacency such as associated LIE source addresses. adjacency such as associated LIE source addresses.
</t> </t>
<t> <t>
Unless Unless
RIFT ZTP as described in <xref target="ZTP" format="defa RIFT ZTP
ult"/> is used as described in <xref target="ZTP" format="defau
is used, lt"/>,
each node is each node is
provisioned with the level at which it provisioned with the level at which it
is operating and advertises it in the is operating and advertises it in the
<em>level</em> of the <em>PacketHeader</em> <em>level</em> of the <em>PacketHeader</em>
schema element. schema element.
It MAY be also provisioned It <bcp14>MAY</bcp14> also be provisioned
with its PoD. with its PoD.
If level is not provisioned, it is not present If the level is not provisioned, it is not present
in the optional <em>PacketHeader</em> schema element and established in the optional <em>PacketHeader</em> schema element and established
by ZTP procedures if feasible. by ZTP procedures, if feasible.
If PoD is not provisioned, it is governed by the <em>LIE Packet</em> If PoD is not provisioned, it is governed by the <em>LIE Packet</em>
schema element assuming the <em>common.default_pod</em> value. schema element assuming the <em>common.default_pod</em> value.
This means that switches except ToF This means that switches except ToF
do not need to be configured at all. do not need to be configured at all.
Necessary information to configure all values is exchang ed Necessary information to configure all values is exchang ed
in the <em>LIEPacket</em> and <em>PacketHeader</em> in the <em>LIEPacket</em> and <em>PacketHeader</em>
or derived by the node automatically. or derived by the node automatically.
</t> </t>
<!--[rfced] We are having difficulty understanding how "given they have
implications in terms of level and adjacency forming here" fits into this
sentence. Please review and let us know how we may update this sentence
for clarity. Also, does "they" refer to "definitions" or "leaf flags"?
Original:
Further definitions of leaf flags are found in Section 6.7 given they
have implications in terms of level and adjacency forming here.
-->
<t>Further definitions of leaf flags are found in <t>Further definitions of leaf flags are found in
<xref target="ZTP"/> given they have implications in terms <xref target="ZTP"/> given they have implications in terms
of level and adjacency forming here. Leaf flags are carried of level and adjacency forming here. Leaf flags are carried
in <em>HierarchyIndications</em>. in <em>HierarchyIndications</em>.
</t> </t>
<t>A node MUST form a <em>ThreeWay</em> adjacency if at a minimum the fo <t>A node <bcp14>MUST</bcp14> form a <em>ThreeWay</em> adjacency if, at
llowing first order logic a minimum, the following first order logic conditions are satisfied on
conditions are satisfied on a LIE packet a LIE packet, as specified by the <em>LIEPacket</em> schema element and
as specified by the <em>LIEPacket</em> schema element an received on a link (such a LIE is considered a "minimally valid"
d LIE). Observe that, depending on the FSM involved and its state further,
received on a link (such a LIE is considered a conditions may be checked, and even a minimally valid LIE can be
"minimally valid" LIE). Observe that depending considered ultimately invalid if any of the additional conditions
on the FSM involved and its state further fail:
conditions may be checked and even a minimally valid LIE
can be considered ultimately invalid if any of the addit
ional conditions fail.
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<!-- removed based on AD comments
<li>the node is in the same PoD or either the node or
the neighbor
advertises "undefined/any" PoD membership (PoD# = `co
mmon.default_pod`) <strong>and</strong></li>
-->
<li>the neighboring node is
running the same major
schema version as indicated in the <em>major_version<
/em>
element in <em>PacketHeader</
em> <strong>and</strong></li>
<!-- removed based on AD comments <!-- removed based on AD comments
<li>the node is in the same PoD or either the node or the
neighbor advertises "undefined/any" PoD membership (PoD# =
'common.default_pod') <strong>and</strong></li>
-->
<li>the neighboring node is running the same major schema version as
indicated in the <em>major_version</em> element in
<em>PacketHeader</em>;</li>
<!-- removed based on AD comments
<t anchor="samepod">the neighbor is not member of some PoD
while the node has a northbound adjacency already joining
another PoD <strong>and</strong></t>
-->
<t anchor="samepod">the neighbor is not member <li>the neighboring node uses a valid System ID (i.e., a value
of some PoD while the node different from <em>IllegalSystemID</em>) in the <em>sender</em>
has a northbound adjacency already joining another element in <em>PacketHeader</em>;</li>
PoD <strong>and</strong></t>
-->
<li>the neighboring node uses a valid System ID
(i.e. value different from <em>IllegalSystemID</em>)
in the
<em>sender</em> element in <em>PacketHeader</em> <st
rong>and</strong></li>
<li>the neighboring node uses a different System ID than the node <li>the neighboring node uses a different System ID than the node
itself <strong>and</strong></li> itself;</li>
<li>(the advertised MTU values in the <em>LiePacket</em> element match
on both sides while a missing MTU in the <em>LiePacket</em> element is interpre <li>the advertised MTU values in the <em>LiePacket</em> element
ted as <em>default_mtu_size</em>) <strong>and</strong></li> match on both sides, while a missing MTU in the <em>LiePacket</em>
<li>both nodes advertise defined level values in <em>level</em> elemen element is interpreted as <em>default_mtu_size</em>;</li>
t in <em>PacketHeader</em> <strong>and</strong></li>
<li anchor="topmustHAL"> <li>both nodes advertise defined level values in the <em>level</em>
<t>[</t> element in <em>PacketHeader</em>, <strong>and</strong></li>
<ul empty="true" spacing="normal">
<li anchor="mustHAL">i) the node is at <em>leaf_level</em> value a <li anchor="topmustHAL"><t>either:</t>
nd has
no <em>ThreeWay</em> adjacencies already <ol type="a" spacing="normal">
to nodes at
Highest Adjacency <em>ThreeWay</em> (HAT as <!--[rfced] We are having difficulty parsing "already to nodes at".
defined later in <xref target="ZTPTerminology" f Please review and let us know how we may clarify this sentence.
ormat="default"/>) with level Also, does "with level different" refer to the nodes?
different than the adjacent
node <strong>or</strong> Original:
</li> i) the node is at _leaf_level_ value and has no _ThreeWay_
<li>ii) the node is not at <em>leaf_level</em> value and adjacencies already to nodes at Highest Adjacency _ThreeWay_
the neighboring node is at <em>leaf_level</em> v (HAT as defined later in Section 6.7.1) with level different
alue <strong>or</strong></li> than the adjacent node *or*
<li>iii) both nodes are at <em>leaf_level</em> values <strong>and<
/strong> both indicate Perhaps:
support for a. the node is at the _leaf_level_ value and does not already
<xref target="leaf2leaf" format="default"/> <str have any _ThreeWay_ adjacencies to nodes that are at Highest
ong>or</strong></li> Adjacency _ThreeWay_ (HAT), as defined in Section 6.7.1,
<li>iv) neither node is at <em>leaf_level</em> value and the and that have a level different than the adjacent node;
neighboring node is at most one level difference -->
away
</li> <li anchor="mustHAL">the node is at the <em>leaf_level</em> value
</ul> and has no <em>ThreeWay</em> adjacencies already to nodes at
<t>]. Highest Adjacency <em>ThreeWay</em> (HAT), as defined later in
</t> <xref target="ZTPTerminology" format="default"/>, with the level
different than the adjacent node;</li>
<li>the node is not at the <em>leaf_level</em> value and the
neighboring node is at the <em>leaf_level</em> value;</li>
<li>both nodes are at the <em>leaf_level</em> values
<strong>and</strong> both indicate support for that described in <
xref
target="leaf2leaf" format="default"/>; <strong>or</strong></li>
<li>neither node is at the <em>leaf_level</em> value and the
neighboring node is, at most, one level away.</li>
</ol>
</li> </li>
</ol> </ol>
<!-- <!--
<t>The rules checking PoD numbering MAY be optionally disreg arded <t>The rules checking PoD numbering MAY be optionally disreg arded
by a node if PoD detection is undesirable or has to be by a node if PoD detection is undesirable or has to be
ignored. This will not affect the correctness of the pro tocol ignored. This will not affect the correctness of the pro tocol
except preventing detection of certain miscabling cases. </t> except preventing detection of certain miscabling cases. </t>
<t>A node configured with "undefined" PoD membership MUST, <t>A node configured with "undefined" PoD membership MUST,
after building first northbound <em>ThreeWay</em> adjace ncies to a node after building first northbound <em>ThreeWay</em> adjace ncies to a node
being in being in
a defined PoD, advertise that PoD a defined PoD, advertise that PoD
skipping to change at line 5205 skipping to change at line 5285
from all available northbound from all available northbound
<em>ThreeWay</em> adjacencies the node with the highest System ID <em>ThreeWay</em> adjacencies the node with the highest System ID
and defined PoD is chosen. That way the northernmost def ined and defined PoD is chosen. That way the northernmost def ined
PoD value (normally the ToP nodes) can PoD value (normally the ToP nodes) can
diffuse southbound towards the leaves "forcing" diffuse southbound towards the leaves "forcing"
the PoD value on any node with "undefined" PoD. the PoD value on any node with "undefined" PoD.
</t> </t>
--> -->
<t>LIEs arriving with IPv4 Time to Live (TTL) or an IPv6 Hop <t>LIEs arriving with IPv4 Time to Live (TTL) or an IPv6 Hop Limit
Limit (HL) different than 1 or 255 (HL) different than 1 or 255 <bcp14>MUST</bcp14> be ignored.
MUST be ignored.
</t> </t>
<!-- AD review <!-- AD review
<t>A node SHOULD NOT send out LIEs without defined level val ue <t>A node <bcp14>SHOULD NOT</bcp14> send out LIEs without de fined level value
in the <em>PacketHeader</em> but in certain scenarios it may in the <em>PacketHeader</em> but in certain scenarios it may
be beneficial for troubleshooting purposes.</t> be beneficial for troubleshooting purposes.</t>
--> -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>LIE Finite State Machine</name> <name>LIE Finite State Machine</name>
<t> <t>
This section specifies the precise, normative LIE FSM which is given as well in <xref target="lie-fsm-figure"/>. Additionally, some sets of actions ofte n repeat and are hence summarized into well-known procedures. This section specifies the precise, normative LIE FSM, which is also sho wn in <xref target="lie-fsm-figure"/>. Additionally, some sets of actions often repeat and are hence summarized into well-known procedures.
</t> </t>
<t> <t>
Events generated are fairly fine grained, especially when indi cating Events generated are fairly fine grained, especially when indi cating
problems in adjacency forming conditions to simplify tracking of problems in deployment. problems in adjacency-forming conditions to simplify tracking of problems in deployment.
</t> </t>
<t>Initial state is <em>OneWay</em>.</t> <t>The initial state is <em>OneWay</em>.</t>
<t>The machine sends LIEs proactively on several transitions to accele rate adjacency <t>The machine sends LIEs proactively on several transitions to accele rate adjacency
bring-up without waiting for the corresponding timer tic.</t> bring-up without waiting for the corresponding timer tic.</t>
<figure anchor="lie-fsm-figure"> <figure anchor="lie-fsm-figure">
<name>LIE FSM</name> <name>LIE FSM</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-lie-fsm.svg"><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www .w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="Layer_1" viewBox="0 0 1 268.4 986" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-lie-fsm.svg"><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www .w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="Layer_1" viewBox="0 0 1 268.4 986" xml:space="preserve">
<polygon fill="#FFFFFF" points="0,986 0,0 1268.4,0 1268.4,986 "/> <polygon fill="#FFFFFF" points="0,986 0,0 1268.4,0 1268.4,986 "/>
<ellipse fill="none" stroke="#000000" cx="719.4" cy="71.5" rx= "55.8" ry="18"/> <ellipse fill="none" stroke="#000000" cx="719.4" cy="71.5" rx= "55.8" ry="18"/>
<text transform="matrix(1 0 0 1 690.4625 75.2)" font-size="14p x">T</text> <text transform="matrix(1 0 0 1 690.4625 75.2)" font-size="14p x">T</text>
<text transform="matrix(1 0 0 1 699.0142 75.2)" font-size="14p x">h</text> <text transform="matrix(1 0 0 1 699.0142 75.2)" font-size="14p x">h</text>
<text transform="matrix(1 0 0 1 706.0142 75.2)" font-size="14p x">r</text> <text transform="matrix(1 0 0 1 706.0142 75.2)" font-size="14p x">r</text>
<text transform="matrix(1 0 0 1 710.6763 75.2)" font-size="14p x">e</text> <text transform="matrix(1 0 0 1 710.6763 75.2)" font-size="14p x">e</text>
skipping to change at line 5708 skipping to change at line 5789
+------------+ MultipleNeighborsDone</artwork> +------------+ MultipleNeighborsDone</artwork>
</artset> </artset>
</figure> </figure>
<!-- generated LIE FSM output --> <!-- generated LIE FSM output -->
<t> <t>
The following words are used for well-known procedures: The following words are used for well-known procedures:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>PUSH Event: queues an event to be executed by the FSM upon exit of this action</li> <li>PUSH Event: queues an event to be executed by the FSM upon exit of this action</li>
<li> CLEANUP: The FSM <strong>conceptually</strong> holds a `current <li>CLEANUP: The FSM <strong>conceptually</strong> holds a "current
neighbor` variable that contains information received in the remote node's LIE neighbor" variable that contains information received in the
that is processed against LIE validation rules. In the event that the LIE is con remote node's LIE that is processed against LIE validation
sidered to be invalid, the existing state held by `current neighbor` MUST be del rules. In the event that the LIE is considered to be invalid, the
eted.</li> existing state held by a "current neighbor" <bcp14>MUST</bcp14> be
<li> deleted.</li>
<t>SEND_LIE: create and send a new LIE packet</t> <li><t>SEND_LIE: create and send a new LIE packet</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>reflecting the <em>neighbor</em> element as described in Val <li>reflecting the <em>neighbor</em> element as described in
idReflection and</li> ValidReflection,</li>
<li>setting the necessary <em>not_a_ztp_offer</em> variable if l <li>setting the necessary <em>not_a_ztp_offer</em> variable if
evel was derived from the last the level was derived from the last-known neighbor on this
known neighbor on this interface and</li> interface, and</li>
<li>setting <em>you_are_flood_repeater</em> variable to the comp <li>setting the <em>you_are_flood_repeater</em> variable to the
uted value</li> computed value.</li>
</ol> </ol>
</li> </li>
<li> <li><t>PROCESS_LIE:</t>
<t>PROCESS_LIE:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>if LIE has a major version not equal to this node's major ve <li>if LIE has a major version not equal to this node's major
rsion <strong>or</strong> System ID equal to (this node's System ID or <em>Illeg version <strong>or</strong> System ID equal to this node's
alSystemID</em>) then CLEANUP System ID or <em>IllegalSystemID</em>, then CLEANUP, else
else
</li> </li>
<li>if both sides advertise Layer 2 MTU values and the MTU in th <li>if both sides advertise Layer 2 MTU values and the MTU in
e received LIE does not match the MTU advertised by the local system <strong>or< the received LIE does not match the MTU advertised by the
/strong> at least one of the nodes does not advertise an MTU value and the adver local system <strong>or</strong> at least one of the nodes
tising node's LIE does not match the <em>default_mtu_size</em> of the system not does not advertise an MTU value and the advertising node's LIE
advertising an MTU then does not match the <em>default_mtu_size</em> of the system not
CLEANUP, advertising an MTU, then CLEANUP, PUSH UpdateZTPOffer, and PUSH
PUSH UpdateZTPOffer, MTUMismatch, else
PUSH MTUMismatch
else
</li> </li>
<li>if the LIE has an undefined level <strong>or</strong> this n <li>if the LIE has an undefined level <strong>or</strong> this
ode's level is undefined <strong>or</strong> node's level is undefined <strong>or</strong> this node is a
this node is a leaf and remote level is lower than HAT <stro leaf and the remote level is lower than HAT <strong>or</strong>
ng>or</strong> the LIE's level is not leaf <strong>and</strong> its
(the LIE's level is not leaf <strong>and</strong> its differ difference is more than one from this node's level, then
ence is more than one from this node's level) then CLEANUP, PUSH UpdateZTPOffer, and PUSH UnacceptableHeader, else
CLEANUP,
PUSH UpdateZTPOffer,
PUSH UnacceptableHeader
else
</li> </li>
<li> <li>
<t>PUSH UpdateZTPOffer, <t>PUSH UpdateZTPOffer, construct a temporary new neighbor
construct temporary new neighbor structure with values from structure with values from LIE, if no current neighbor
LIE, exists, then set current neighbor to new neighbor, PUSH
if no current neighbor exists then NewNeighbor event, CHECK_THREE_WAY, else</t>
set current neighbor to new neighbor, <ol spacing="normal" type="a">
PUSH NewNeighbor event, CHECK_THREE_WAY else</t> <li>if the current neighbor System ID differs from LIE's
<ol spacing="normal" type="1"> System ID, then PUSH MultipleNeighbors, else
<li>if current neighbor System ID differs from LIE's Sys </li>
tem ID then PUSH MultipleNeighbors <li>if the current neighbor stored level differs from LIE's
else level, then PUSH NeighborChangedLevel, else
</li> </li>
<li>if current neighbor stored level differs from LIE's leve <li>if the current neighbor stored IPv4/v6 address differs
l then PUSH NeighborChangedLevel from LIE's address, then PUSH NeighborChangedAddress, else
else </li>
</li> <li>if any of the neighbor's flood address port, name, or
<li>if current neighbor stored IPv4/v6 address differs from local LinkID changed, then PUSH
LIE's address then PUSH NeighborChangedAddress NeighborChangedMinorFields</li>
else <li>CHECK_THREE_WAY</li>
</li>
<li>if any of neighbor's flood address port, name, or local
LinkID changed then PUSH NeighborChangedMinorFields</li>
<li>CHECK_THREE_WAY</li>
</ol> </ol>
</li> </li>
</ol> </ol>
</li> </li>
<li> <li><t>CHECK_THREE_WAY: if the current state is <em>OneWay</em>, do
<t>CHECK_THREE_WAY: if current state is <em>OneWay</em> do nothing nothing, else</t>
else</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>if LIE packet does not contain neighbor then if current stat <li>if LIE packet does not contain a neighbor and if the current
e is <em>ThreeWay</em> then PUSH NeighborDroppedReflection else</li> state is <em>ThreeWay</em>, then PUSH NeighborDroppedReflection,
<li>if packet reflects this system's ID and local port and state else</li>
is <em>ThreeWay</em> then PUSH event ValidReflection else PUSH event MultipleNe <li>if the packet reflects this System ID and local port and
ighbors</li> the state is <em>ThreeWay</em>, then PUSH the ValidReflection ev
ent,
else PUSH the MultipleNeighbors event.</li>
</ol> </ol>
</li> </li>
</ul> </ul>
<t>States:</t> <t>States:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>OneWay: <li>OneWay: The initial state the FSM is starting from. In this stat
e,
initial state the FSM is starting from. In this state the router did not receive the router did not receive any valid LIEs from a neighbor.
any valid LIEs from a neighbor. </li>
</li> <li>TwoWay: This state is entered when a node has received a
<li>TwoWay: minimally valid LIE from a neighbor but not a ThreeWay valid LIE.
</li>
that state is entered when a node has received a minimally valid LIE from a neig <li>ThreeWay: This state signifies that <em>ThreeWay</em> valid
hbor but not a LIEs from a neighbor have been received. On achieving this state,
ThreeWay valid LIE. the link can be advertised in the <em>neighbors</em> element in
</li> <em>NodeTIEElement</em>.
<li>ThreeWay: </li>
<li>MultipleNeighborsWait: Occurs normally when more than two
this state signifies that <em>ThreeWay</em> valid LIEs from a neighbor have been nodes become aware of each other on the same link or a remote node
received. is quickly reconfigured or rebooted without regressing to
On achieving this state the link can be advertised in <em>neighbors</em> element <em>OneWay</em> first. Each occurrence of the event
in <em>NodeTIEElement</em>. <bcp14>SHOULD</bcp14> generate a notification to help operational
</li> deployments.</li>
<li>MultipleNeighborsWait:
occurs normally when more than two nodes become aware of each
other on the same link or a remote node is quickly reconfigured or rebooted
without regressing to <em>OneWay</em> first. Each
occurrence of the event SHOULD generate notification to help
operational deployments.</li>
</ul> </ul>
<t>Events:</t> <t>Events:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>TimerTick: <li>TimerTick: One-second timer tick, i.e., the event is provided
to the FSM once a second by an implementation-specific mechanism
one-second timer tick, i.e., the event is provided to the FSM that is outside the scope of this specification. This event is
once a second by an implementation-specific mechanism that is outside the scope quietly ignored if the relevant transition does not exist.</li>
of this specification. <li>LevelChanged: Node's level has been changed by ZTP or
This event is quietly ignored if the relevant transition does not exist. configuration. This is provided by the ZTP FSM.
</li> </li>
<li>LevelChanged: <li>HALChanged: Best HAL computed by ZTP has changed. This is
provided by the ZTP FSM.</li>
node's level has been changed by ZTP or configuration. This is provided by the Z <li>HATChanged: HAT computed by ZTP has changed. This is provided
TP FSM. by the ZTP FSM.</li>
</li> <li>HALSChanged: Set of HAL offering systems computed by ZTP has
<li>HALChanged: changed. This is provided by the ZTP FSM.</li>
best HAL computed by ZTP has changed. This is provided by the ZTP FSM.</ <li>LieRcvd: Received LIE on the interface.</li>
li> <li>NewNeighbor: New neighbor is present in the received
<li>HATChanged: LIE. </li>
HAT computed by ZTP has changed. This is provided by the ZTP FSM.</li> <li>ValidReflection: Received valid reflection of this node from the
<li>HALSChanged: neighbor, i.e., all elements in the <em>neighbor</em> element in
set of HAL offering systems computed by ZTP has changed. This is provide <em>LiePacket</em> have values corresponding to this link.</li>
d by the ZTP FSM.</li> <li>NeighborDroppedReflection: Lost previously held reflection
<li>LieRcvd: from the neighbor, i.e., the <em>neighbor</em> element in
received LIE on the interface.</li> <em>LiePacket</em> does not correspond to this node or is not
<li>NewNeighbor: present.</li>
new neighbor is present in the received LIE. </li> <li>NeighborChangedLevel: Neighbor changed the advertised level from
<li>ValidReflection: the previously held one.</li>
<li>NeighborChangedAddress: Neighbor changed the IP address, i.e., t
received valid reflection of this node from neighbor, i.e. all elements in <em>n he LIE
eighbor</em> has been received from an address different from previous LIEs.
element in <em>LiePacket</em> have values corresponding to this link.</li> Those changes will influence the sockets used to listen to TIEs,
<li>NeighborDroppedReflection: TIREs, and TIDEs.
</li>
lost previously held reflection from neighbor, i.e. <em>neighbor</em> <li>UnacceptableHeader: Unacceptable header received.</li>
element in <em>LiePacket</em> does not correspond to this node or is <li>MTUMismatch: MTU mismatched.</li>
not present.</li> <li>NeighborChangedMinorFields: Minor fields changed in the neighbor
<li>NeighborChangedLevel: 's
neighbor changed advertised level from the previously held one.</li> LIE.</li>
<li>NeighborChangedAddress: <li>HoldtimeExpired: Adjacency holddown timer expired.</li>
<li>MultipleNeighbors: More than one neighbor is present on the
neighbor changed IP address, i.e. LIE has been received from an address differen interface.</li>
t from <li>MultipleNeighborsDone: Multiple neighbors' timers expired.</li>
previous LIEs. Those changes will influence the sockets <li>FloodLeadersChanged: Node's election algorithm determined new
used to listen to TIEs, TIREs, TIDEs. set of flood leaders.
</li> </li>
<li>UnacceptableHeader: <li>SendLie: Send a LIE out.</li>
Unacceptable header received.</li> <li>UpdateZTPOffer: Update this node's ZTP offer. This is sent to
<li>MTUMismatch: the ZTP FSM.</li>
MTU mismatched.</li>
<li>NeighborChangedMinorFields:
minor fields changed in neighbor's LIE.</li>
<li>HoldtimeExpired:
adjacency holddown timer expired.</li>
<li>MultipleNeighbors:
more than one neighbor is present on interface</li>
<li>MultipleNeighborsDone:
multiple neighbors timer expired.</li>
<li>FloodLeadersChanged:
node's election algorithm determined new set of flood leaders.
</li>
<li>SendLie:
send a LIE out.</li>
<li>UpdateZTPOffer:
update this node's ZTP offer. This is sent to the ZTP FSM.</li>
</ul> </ul>
<t>Actions:</t> <t>Actions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>on HATChanged in <em>OneWay</em> finishes in OneWay: <li>on HATChanged in <em>OneWay</em> finishes in OneWay: store HAT
store HAT </li>
</li>
<li>on FloodLeadersChanged in <em>OneWay</em> finishes in OneWay: <li>on FloodLeadersChanged in <em>OneWay</em> finishes in OneWay:
update <em>you_are_flood_repeater</em> LIE elements based on flood leade update <em>you_are_flood_repeater</em> LIE elements based on the flo
r election results od
</li> leader election results
</li>
<li>on UnacceptableHeader in <em>OneWay</em> finishes in OneWay: <li>on UnacceptableHeader in <em>OneWay</em> finishes in OneWay:
no action no action
</li> </li>
<li>on NeighborChangedMinorFields in <em>OneWay</em> finishes in One <li>on NeighborChangedMinorFields in <em>OneWay</em> finishes in
Way: OneWay: no action
no action </li>
</li> <li>on SendLie in <em>OneWay</em> finishes in OneWay: SEND_LIE
<li>on SendLie in <em>OneWay</em> finishes in OneWay: </li>
SEND_LIE <li>on HALSChanged in <em>OneWay</em> finishes in OneWay: store the
</li> HALS
<li>on HALSChanged in <em>OneWay</em> finishes in OneWay: </li>
store HALS <li>on MultipleNeighbors in <em>OneWay</em> finishes in
</li> MultipleNeighborsWait: start multiple neighbors' timers with the
<li>on MultipleNeighbors in <em>OneWay</em> finishes in MultipleNeig interval <em>multiple_neighbors_lie_holdtime_multipler</em> *
hborsWait: <em>default_lie_holdtime</em>
start multiple neighbors timer with interval <em>multiple_neighbors_lie_
holdtime_multipler</em> * <em>default_lie_holdtime</em>
</li> </li>
<li>on NeighborChangedLevel in <em>OneWay</em> finishes in OneWay: <li>on NeighborChangedLevel in <em>OneWay</em> finishes in OneWay:
no action no action
</li> </li>
<li>on LieRcvd in <em>OneWay</em> finishes in OneWay: <li>on LieRcvd in <em>OneWay</em> finishes in OneWay: PROCESS_LIE
PROCESS_LIE </li>
</li> <li>on MTUMismatch in <em>OneWay</em> finishes in OneWay: no
<li>on MTUMismatch in <em>OneWay</em> finishes in OneWay: action
no action </li>
</li> <li>on ValidReflection in <em>OneWay</em> finishes in ThreeWay: no
<li>on ValidReflection in <em>OneWay</em> finishes in ThreeWay: action
no action </li>
</li> <li>on LevelChanged in <em>OneWay</em> finishes in OneWay: update th
<li>on LevelChanged in <em>OneWay</em> finishes in OneWay: e
update level with event value, PUSH SendLie event level with the event value, PUSH the SendLie event
</li> </li>
<li>on HALChanged in <em>OneWay</em> finishes in OneWay: <li>on HALChanged in <em>OneWay</em> finishes in OneWay: store the n
store new HAL ew
</li> HAL
<li>on HoldtimeExpired in <em>OneWay</em> finishes in OneWay: </li>
no action <li>on HoldtimeExpired in <em>OneWay</em> finishes in OneWay: no
</li> action
<li>on NeighborChangedAddress in <em>OneWay</em> finishes in OneWay: </li>
no action <li>on NeighborChangedAddress in <em>OneWay</em> finishes in
</li> OneWay: no action
<li>on NewNeighbor in <em>OneWay</em> finishes in TwoWay: </li>
PUSH SendLie event <li>on NewNeighbor in <em>OneWay</em> finishes in TwoWay: PUSH the
</li> SendLie event
<li>on UpdateZTPOffer in <em>OneWay</em> finishes in OneWay: </li>
send offer to ZTP FSM <li>on UpdateZTPOffer in <em>OneWay</em> finishes in OneWay: send th
</li> e
<li>on NeighborDroppedReflection in <em>OneWay</em> finishes in OneW offer to the ZTP FSM
ay: </li>
no action <li>on NeighborDroppedReflection in <em>OneWay</em> finishes in
</li> OneWay: no action
<li>on TimerTick in <em>OneWay</em> finishes in OneWay: </li>
PUSH SendLie event <li>on TimerTick in <em>OneWay</em> finishes in OneWay: PUSH
</li> SendLie event
</li>
<li>on FloodLeadersChanged in <em>TwoWay</em> finishes in TwoWay: <li>on FloodLeadersChanged in <em>TwoWay</em> finishes in TwoWay:
update <em>you_are_flood_repeater</em> LIE elements based on flood leade update <em>you_are_flood_repeater</em> LIE elements based on the flo
r election results od
</li> leader election results
<li>on UpdateZTPOffer in <em>TwoWay</em> finishes in TwoWay: </li>
send offer to ZTP FSM <li>on UpdateZTPOffer in <em>TwoWay</em> finishes in TwoWay: send th
</li> e
<li>on NewNeighbor in <em>TwoWay</em> finishes in MultipleNeighborsW offer to the ZTP FSM
ait: </li>
PUSH SendLie event <li>on NewNeighbor in <em>TwoWay</em> finishes in
</li> MultipleNeighborsWait: PUSH the SendLie event
<li>on ValidReflection in <em>TwoWay</em> finishes in ThreeWay: </li>
no action <li>on ValidReflection in <em>TwoWay</em> finishes in ThreeWay: no
</li> action
<li>on LieRcvd in <em>TwoWay</em> finishes in TwoWay: </li>
PROCESS_LIE <li>on LieRcvd in <em>TwoWay</em> finishes in TwoWay: PROCESS_LIE
</li> </li>
<li>on UnacceptableHeader in <em>TwoWay</em> finishes in OneWay: <li>on UnacceptableHeader in <em>TwoWay</em> finishes in OneWay:
no action no action
</li> </li>
<li>on HALChanged in <em>TwoWay</em> finishes in TwoWay: <li>on HALChanged in <em>TwoWay</em> finishes in TwoWay: store the n
store new HAL ew
</li> HAL
<li>on HoldtimeExpired in <em>TwoWay</em> finishes in OneWay: </li>
no action <li>on HoldtimeExpired in <em>TwoWay</em> finishes in OneWay: no
</li> action
<li>on LevelChanged in <em>TwoWay</em> finishes in TwoWay: </li>
update level with event value <li>on LevelChanged in <em>TwoWay</em> finishes in TwoWay: update th
</li> e
<li>on TimerTick in <em>TwoWay</em> finishes in TwoWay: level with the event value
PUSH SendLie event, if last valid LIE was received more than <em>holdtim </li>
e</em> ago as advertised by neighbor then PUSH HoldtimeExpired event <li>on TimerTick in <em>TwoWay</em> finishes in TwoWay: PUSH
</li> SendLie event, if last valid LIE was received more than
<li>on HATChanged in <em>TwoWay</em> finishes in TwoWay: <em>holdtime</em> ago as advertised by the neighbor, then PUSH the
store HAT HoldtimeExpired event
</li> </li>
<li>on HATChanged in <em>TwoWay</em> finishes in TwoWay: store HAT
</li>
<li>on NeighborChangedLevel in <em>TwoWay</em> finishes in OneWay: <li>on NeighborChangedLevel in <em>TwoWay</em> finishes in OneWay:
no action no action
</li> </li>
<li>on HALSChanged in <em>TwoWay</em> finishes in TwoWay: <li>on HALSChanged in <em>TwoWay</em> finishes in TwoWay: store the
store HALS HALS
</li> </li>
<li>on MTUMismatch in <em>TwoWay</em> finishes in OneWay: <li>on MTUMismatch in <em>TwoWay</em> finishes in OneWay: no
no action action
</li> </li>
<li>on NeighborChangedAddress in <em>TwoWay</em> finishes in OneWay: <li>on NeighborChangedAddress in <em>TwoWay</em> finishes in
no action OneWay: no action
</li> </li>
<li>on SendLie in <em>TwoWay</em> finishes in TwoWay: <li>on SendLie in <em>TwoWay</em> finishes in TwoWay: SEND_LIE
SEND_LIE </li>
</li> <li>on MultipleNeighbors in <em>TwoWay</em> finishes in
<li>on MultipleNeighbors in <em>TwoWay</em> finishes in MultipleNeig MultipleNeighborsWait: start multiple neighbors' timers with the
hborsWait: interval <em>multiple_neighbors_lie_holdtime_multipler</em> *
start multiple neighbors timer with interval <em>multiple_neighbors_lie_ <em>default_lie_holdtime</em>
holdtime_multipler</em> * <em>default_lie_holdtime</em> </li>
<li>on TimerTick in <em>ThreeWay</em> finishes in ThreeWay: PUSH the
SendLie event, if the last valid LIE was received more than
<em>holdtime</em> ago as advertised by the neighbor, then PUSH the
HoldtimeExpired event
</li> </li>
<li>on TimerTick in <em>ThreeWay</em> finishes in ThreeWay:
PUSH SendLie event, if last valid LIE was received more than <em>holdtim
e</em> ago as advertised by neighbor then PUSH HoldtimeExpired event
</li>
<li>on LevelChanged in <em>ThreeWay</em> finishes in OneWay: <li>on LevelChanged in <em>ThreeWay</em> finishes in OneWay:
update level with event value update the level with the event value
</li> </li>
<li>on HATChanged in <em>ThreeWay</em> finishes in ThreeWay: <li>on HATChanged in <em>ThreeWay</em> finishes in ThreeWay: store
store HAT HAT
</li> </li>
<li>on MTUMismatch in <em>ThreeWay</em> finishes in OneWay: <li>on MTUMismatch in <em>ThreeWay</em> finishes in OneWay: no
no action action
</li> </li>
<li>on UnacceptableHeader in <em>ThreeWay</em> finishes in OneWay: <li>on UnacceptableHeader in <em>ThreeWay</em> finishes in OneWay:
no action no action
</li> </li>
<li>on MultipleNeighbors in <em>ThreeWay</em> finishes in MultipleNe <li>on MultipleNeighbors in <em>ThreeWay</em> finishes in
ighborsWait: MultipleNeighborsWait: start multiple neighbors' timers with the
start multiple neighbors timer with interval <em>multiple_neighbors_lie_ interval <em>multiple_neighbors_lie_holdtime_multipler</em> *
holdtime_multipler</em> * <em>default_lie_holdtime</em> <em>default_lie_holdtime</em>
</li>
<li>on NeighborChangedLevel in <em>ThreeWay</em> finishes in
OneWay: no action
</li> </li>
<li>on NeighborChangedLevel in <em>ThreeWay</em> finishes in OneWay:
no action
</li>
<li>on HALSChanged in <em>ThreeWay</em> finishes in ThreeWay: <li>on HALSChanged in <em>ThreeWay</em> finishes in ThreeWay:
store HALS store the HALS
</li> </li>
<li>on LieRcvd in <em>ThreeWay</em> finishes in ThreeWay: <li>on LieRcvd in <em>ThreeWay</em> finishes in ThreeWay:
PROCESS_LIE PROCESS_LIE
</li> </li>
<li>on FloodLeadersChanged in <em>ThreeWay</em> finishes in ThreeWay <li>on FloodLeadersChanged in <em>ThreeWay</em> finishes in
: ThreeWay: update <em>you_are_flood_repeater</em> LIE elements
update <em>you_are_flood_repeater</em> LIE elements based on flood leade based on the flood leader election results, PUSH the SendLie event
r election results, PUSH SendLie </li>
</li> <li>on NeighborDroppedReflection in <em>ThreeWay</em> finishes in
<li>on NeighborDroppedReflection in <em>ThreeWay</em> finishes in Tw TwoWay: no action
oWay: </li>
no action <li>on HoldtimeExpired in <em>ThreeWay</em> finishes in OneWay: no
</li> action
<li>on HoldtimeExpired in <em>ThreeWay</em> finishes in OneWay: </li>
no action
</li>
<li>on ValidReflection in <em>ThreeWay</em> finishes in ThreeWay: <li>on ValidReflection in <em>ThreeWay</em> finishes in ThreeWay:
no action no action
</li> </li>
<li>on UpdateZTPOffer in <em>ThreeWay</em> finishes in ThreeWay: <li>on UpdateZTPOffer in <em>ThreeWay</em> finishes in ThreeWay:
send offer to ZTP FSM send the offer to the ZTP FSM
</li> </li>
<li>on NeighborChangedAddress in <em>ThreeWay</em> finishes in OneWa <li>on NeighborChangedAddress in <em>ThreeWay</em> finishes in
y: OneWay: no action
no action </li>
</li> <li>on HALChanged in <em>ThreeWay</em> finishes in ThreeWay: store t
<li>on HALChanged in <em>ThreeWay</em> finishes in ThreeWay: he
store new HAL new HAL
</li> </li>
<li>on SendLie in <em>ThreeWay</em> finishes in ThreeWay: <li>on SendLie in <em>ThreeWay</em> finishes in ThreeWay: SEND_LIE
SEND_LIE </li>
</li> <li>on MultipleNeighbors in MultipleNeighborsWait finishes in
<li>on MultipleNeighbors in MultipleNeighborsWait finishes in Multip MultipleNeighborsWait: start multiple neighbors' timers with the
leNeighborsWait: interval <em>multiple_neighbors_lie_holdtime_multipler</em> *
start multiple neighbors timer with interval <em>multiple_neighbors_lie_ <em>default_lie_holdtime</em>
holdtime_multipler</em> * <em>default_lie_holdtime</em> </li>
<li>on FloodLeadersChanged in MultipleNeighborsWait finishes in
MultipleNeighborsWait: update <em>you_are_flood_repeater</em> LIE
elements based on the flood leader election results
</li>
<li>on TimerTick in MultipleNeighborsWait finishes in
MultipleNeighborsWait: check MultipleNeighbors timer, if the timer
expired, PUSH MultipleNeighborsDone
</li>
<li>on ValidReflection in MultipleNeighborsWait finishes in
MultipleNeighborsWait: no action
</li>
<li>on UpdateZTPOffer in MultipleNeighborsWait finishes in
MultipleNeighborsWait: send the offer to the ZTP FSM
</li>
<li>on NeighborDroppedReflection in MultipleNeighborsWait finishes
in MultipleNeighborsWait: no action
</li>
<li>on LieRcvd in MultipleNeighborsWait finishes in
MultipleNeighborsWait: no action
</li>
<li>on UnacceptableHeader in MultipleNeighborsWait finishes in
MultipleNeighborsWait: no action
</li>
<li>on NeighborChangedAddress in MultipleNeighborsWait finishes in
MultipleNeighborsWait: no action
</li> </li>
<li>on FloodLeadersChanged in MultipleNeighborsWait finishes in Mult
ipleNeighborsWait:
update <em>you_are_flood_repeater</em> LIE elements based on flood lead
er election results
</li>
<li>on TimerTick in MultipleNeighborsWait finishes in MultipleNeighb
orsWait:
check MultipleNeighbors timer, if timer expired PUSH MultipleNeighborsDo
ne
</li>
<li>on ValidReflection in MultipleNeighborsWait finishes in Multiple
NeighborsWait:
no action
</li>
<li>on UpdateZTPOffer in MultipleNeighborsWait finishes in MultipleN
eighborsWait:
send offer to ZTP FSM
</li>
<li>on NeighborDroppedReflection in MultipleNeighborsWait finishes i
n MultipleNeighborsWait:
no action
</li>
<li>on LieRcvd in MultipleNeighborsWait finishes in MultipleNeighbor
sWait:
no action
</li>
<li>on UnacceptableHeader in MultipleNeighborsWait finishes in Multi
pleNeighborsWait:
no action
</li>
<li>on NeighborChangedAddress in MultipleNeighborsWait finishes in M
ultipleNeighborsWait:
no action
</li>
<li>on LevelChanged in MultipleNeighborsWait finishes in OneWay: <li>on LevelChanged in MultipleNeighborsWait finishes in OneWay:
update level with event value update the level with the event value
</li> </li>
<li>on HATChanged in MultipleNeighborsWait finishes in MultipleNeigh <li>on HATChanged in MultipleNeighborsWait finishes in
borsWait: MultipleNeighborsWait: store HAT
store HAT </li>
</li> <li>on MTUMismatch in MultipleNeighborsWait finishes in
<li>on MTUMismatch in MultipleNeighborsWait finishes in MultipleNeig MultipleNeighborsWait: no action
hborsWait: </li>
no action <li>on HALSChanged in MultipleNeighborsWait finishes in
</li> MultipleNeighborsWait: store the HALS
<li>on HALSChanged in MultipleNeighborsWait finishes in MultipleNeig </li>
hborsWait: <li>on HALChanged in MultipleNeighborsWait finishes in
store HALS MultipleNeighborsWait: store the new HAL
</li> </li>
<li>on HALChanged in MultipleNeighborsWait finishes in MultipleNeigh <li>on HoldtimeExpired in MultipleNeighborsWait finishes in
borsWait: MultipleNeighborsWait: no action
store new HAL </li>
</li> <li>on SendLie in MultipleNeighborsWait finishes in
<li>on HoldtimeExpired in MultipleNeighborsWait finishes in Multiple MultipleNeighborsWait: no action
NeighborsWait: </li>
no action <li>on MultipleNeighborsDone in MultipleNeighborsWait finishes in
</li> OneWay: no action
<li>on SendLie in MultipleNeighborsWait finishes in MultipleNeighbor </li>
sWait: <li>on Entry into OneWay: CLEANUP
no action </li>
</li>
<li>on MultipleNeighborsDone in MultipleNeighborsWait finishes in On
eWay:
no action
</li>
<li>on Entry into OneWay:
CLEANUP
</li>
</ul> </ul>
<!-- end generated output --> <!-- end generated output -->
</section> </section>
</section> </section>
<section anchor="ties" numbered="true" toc="default"> <section anchor="ties" numbered="true" toc="default">
<name>Topology Exchange (TIE Exchange)</name> <name>Topology Exchange (TIE Exchange)</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Topology Information Elements</name> <name>Topology Information Elements</name>
<t>Topology and reachability information in RIFT is <t>Topology and reachability information in RIFT is
skipping to change at line 6090 skipping to change at line 6179
which have good which have good
amount of commonalities with LSAs in OSPF. amount of commonalities with LSAs in OSPF.
--> -->
</t> </t>
<t>The TIE exchange <t>The TIE exchange
mechanism uses mechanism uses
the port indicated by each node in the LIE the port indicated by each node in the LIE
exchange as <em>flood_port</em> in <em>LIEPacket</em > and the interface exchange as <em>flood_port</em> in <em>LIEPacket</em > and the interface
on which the adjacency has been on which the adjacency has been
formed as destination. TIEs MUST be sent with an IPv formed as the destination. TIEs <bcp14>MUST</bcp14>
4 Time to Live (TTL) or an IPv6 Hop Limit (HL) of either 1 or 255 and also be sent with an IPv4 Time to Live (TTL) or an IPv6 Hop Limit (HL) of either 1 or
MUST be ignored if received with values different th 255 and also
an 1 or 255. This helps to protect RIFT information from being accepted <bcp14>MUST</bcp14> be ignored if received with valu
beyond a single L3 next-hop in the topology. es different than 1 or 255. This helps to protect RIFT information from being ac
TIEs SHOULD be sent with network control precedence cepted
unless an implementation is prevented beyond a single L3 next hop in the topology.
TIEs <bcp14>SHOULD</bcp14> be sent with network cont
rol precedence unless an implementation is prevented
from doing so <xref target="RFC2474" format="default "/>. from doing so <xref target="RFC2474" format="default "/>.
</t> </t>
<t>TIEs <t>TIEs
contain sequence numbers, lifetimes, and a type. contain sequence numbers, lifetimes, and a type.
Each type has ample identifying number space Each type has ample identifying number space,
and information is spread across multiple TIEs with the same TIEElement type (this is true for all TIE types). and information is spread across multiple TIEs with the same TIEElement type (this is true for all TIE types).
</t> </t>
<t>More information about the TIE structure can be <t>More information about the TIE structure can be
found in the schema in <xref target="schema" format= "default"/> found in the schema in <xref target="schema" format= "default"/>,
starting with <em>TIEPacket</em> root. starting with <em>TIEPacket</em> root.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="n_and_s_rep_sec"> <section numbered="true" toc="default" anchor="n_and_s_rep_sec">
<name>Southbound and Northbound TIE Representation</name> <name>Southbound and Northbound TIE Representation</name>
<t>A central concept of RIFT is that each node represents <t>A central concept of RIFT is that each node represents
itself differently depending on the direction in itself differently, depending on the direction i n
which it is advertising information. which it is advertising information.
More precisely, More precisely,
a spine node represents two different databases a spine node represents two different databases
over its adjacencies over its adjacencies,
depending on whether it advertises TIEs to the depending on whether it advertises TIEs to the
north or to the south/east-west. north or to the south/east-west.
Those differing TIE databases Those differing TIE databases
are called either south- or are called either southbound or
northbound (South TIEs and North TIEs) northbound (South TIEs and North TIEs),
depending on the direction of distribution. depending on the direction of distribution.
</t> </t>
<t>The North TIEs hold all of the node's adjacencies and local <t>The North TIEs hold all of the node's adjacencies and local
prefixes while the South TIEs hold only all of the node's adjacencies, the prefixes, while the South TIEs hold all of the node's adjacencies, the
default prefix with necessary disaggregated prefixes and local prefixes. default prefix with necessary disaggregated prefixes, and local prefixes.
<xref target="disaggregate" format="default"/> explains further details. <xref target="disaggregate" format="default"/> explains further details.
</t> </t>
<t>All TIE types are mostly symmetrical in both directions. <t>All TIE types are mostly symmetrical in both directions.
The (<xref target="encoding_thrift_app" format="default"/>) define s the TIE types (i.e., the TIETypeType element) <xref target="encoding_thrift_app" format="default"/> defines the TIE types (i.e., the TIETypeType element)
and their directionality (i.e., <em>direction</em> within the <em> TIEID</em> element). and their directionality (i.e., <em>direction</em> within the <em> TIEID</em> element).
</t> </t>
<t>As an example illustrating a database holding both <t>As an example illustrating a database holding both
representations, the representations, the topology in <xref target="pic-topo-three"
topology in <xref target="pic-topo-three" format="default"/> with the option format="default"/> with the optional link between spine 111 and
al spine 112 (so that the flooding on an East-West link can be shown)
link between spine 111 and spine 112 (so that the flooding on an is shown below. Unnumbered interfaces are implicitly assumed and, for
East-West link can be shown) is shown below. Unnumbered simplicity, the key value elements, which may be included in their
interfaces are implicitly assumed and for simplicity, the key value elements South TIEs or North TIEs, are not shown. First, <xref
which may be included target="ties-topo-three"/> shows the TIEs generated by some
in their South TIEs or North TIEs are not shown. First, in <xre nodes. </t>
f target="ties-topo-three"/> are the TIEs generated by some
nodes. </t>
<figure anchor="ties-topo-three"> <figure anchor="ties-topo-three">
<name>Example TIEs Generated in a 2 Level Spine-and-Leaf Topology</n <name>Example TIEs Generated in a 2-Level Spine-and-Leaf Topology</n
ame> ame>
<artset> <sourcecode type=""><![CDATA[
<artwork align="center" name="" type="ascii-art" originalSrc="art/ ToF 21 South TIEs:
rift-rift-example-ties-2-level-spine-leaf-topo.ascii-art"> ToF 21 South T Node South TIE:
IEs: NodeTIEElement(level=2,
Node South TIE: neighbors(
NodeTIEElement(level=2, (Spine 111, level 1, cost 1, links(...)),
neighbors( (Spine 112, level 1, cost 1, links(...)),
(Spine 111, level 1, cost 1, links(...)), (Spine 121, level 1, cost 1, links(...)),
(Spine 112, level 1, cost 1, links(...)), (Spine 122, level 1, cost 1, links(...))
(Spine 121, level 1, cost 1, links(...)), )
(Spine 122, level 1, cost 1, links(...)) )
) Prefix South TIE:
) PrefixTIEElement(prefixes(0/0, metric 1), (::/0, metric 1))
Prefix South TIE:
PrefixTIEElement(prefixes(0/0, metric 1), (::/0, metric 1))
Spine 111 South TIEs: Spine 111 South TIEs:
Node South TIE: Node South TIE:
NodeTIEElement(level=1, NodeTIEElement(level=1,
neighbors( neighbors(
(ToF 21, level 2, cost 1, links(...)), (ToF 21, level 2, cost 1, links(...)),
(ToF 22, level 2, cost 1, links(...)), (ToF 22, level 2, cost 1, links(...)),
(Spine 112, level 1, cost 1, links(...)), (Spine 112, level 1, cost 1, links(...)),
(Leaf111, level 0, cost 1, links(...)), (Leaf111, level 0, cost 1, links(...)),
(Leaf112, level 0, cost 1, links(...)) (Leaf112, level 0, cost 1, links(...))
) )
) )
Prefix South TIE: Prefix South TIE:
PrefixTIEElement(prefixes(0/0, metric 1), (::/0, metric 1)) PrefixTIEElement(prefixes(0/0, metric 1), (::/0, metric 1))
Spine 111 North TIEs: Spine 111 North TIEs:
Node North TIE: Node North TIE:
NodeTIEElement(level=1, NodeTIEElement(level=1,
neighbors( neighbors(
(ToF 21, level 2, cost 1, links(...)), (ToF 21, level 2, cost 1, links(...)),
(ToF 22, level 2, cost 1, links(...)), (ToF 22, level 2, cost 1, links(...)),
(Spine 112, level 1, cost 1, links(...)), (Spine 112, level 1, cost 1, links(...)),
(Leaf111, level 0, cost 1, links(...)), (Leaf111, level 0, cost 1, links(...)),
(Leaf112, level 0, cost 1, links(...)) (Leaf112, level 0, cost 1, links(...))
) )
) )
Prefix North TIE: Prefix North TIE:
PrefixTIEElement(prefixes(Spine 111.loopback) PrefixTIEElement(prefixes(Spine 111.loopback)
Spine 121 South TIEs: Spine 121 South TIEs:
Node South TIE: Node South TIE:
NodeTIEElement(level=1, NodeTIEElement(level=1,
neighbors( neighbors(
(ToF 21, level 2, cost 1, links(...)), (ToF 21, level 2, cost 1, links(...)),
(ToF 22, level 2, cost 1, links(...)), (ToF 22, level 2, cost 1, links(...)),
(Leaf121, level 0, cost 1, links(...)), (Leaf121, level 0, cost 1, links(...)),
(Leaf122, level 0, cost 1, links(...)) (Leaf122, level 0, cost 1, links(...))
) )
) )
Prefix South TIE: Prefix South TIE:
PrefixTIEElement(prefixes(0/0, metric 1), (::/0, metric 1)) PrefixTIEElement(prefixes(0/0, metric 1), (::/0, metric 1))
Spine 121 North TIEs: Spine 121 North TIEs:
Node North TIE: Node North TIE:
NodeTIEElement(level=1, NodeTIEElement(level=1,
neighbors( neighbors(
(ToF 21, level 2, cost 1, links(...)), (ToF 21, level 2, cost 1, links(...)),
(ToF 22, level 2, cost 1, links(...)), (ToF 22, level 2, cost 1, links(...)),
(Leaf121, level 0, cost 1, links(...)), (Leaf121, level 0, cost 1, links(...)),
(Leaf122, level 0, cost 1, links(...)) (Leaf122, level 0, cost 1, links(...))
) )
) )
Prefix North TIE: Prefix North TIE:
PrefixTIEElement(prefixes(Spine 121.loopback) PrefixTIEElement(prefixes(Spine 121.loopback)
Leaf112 North TIEs: Leaf112 North TIEs:
Node North TIE: Node North TIE:
NodeTIEElement(level=0, NodeTIEElement(level=0,
neighbors( neighbors(
(Spine 111, level 1, cost 1, links(...)), (Spine 111, level 1, cost 1, links(...)),
(Spine 112, level 1, cost 1, links(...)) (Spine 112, level 1, cost 1, links(...))
) )
) )
Prefix North TIE: Prefix North TIE:
PrefixTIEElement(prefixes(Leaf112.loopback, Prefix112, Prefix_MH))</ar PrefixTIEElement(prefixes(Leaf112.loopback, Prefix112, Prefix_MH))]]></sourcec
twork> ode>
</artset>
</figure> </figure>
<t> <t>
It may not be obvious here as to why the Node South TIEs contain all the It may not be obvious here as to why the Node South TIEs contain all the
adjacencies of the corresponding node. adjacencies of the corresponding node.
This will be necessary for algorithms further elaborated on in <xref target= This will be necessary for algorithms further elaborated on in Sections <xre
"mpr" format="default"/> f target="mpr" format="counter"/>
and <xref target="bwb" format="default"/>. and <xref target="bwb" format="counter"/>.
</t> </t>
<t> <t>
For Node TIEs to carry more adjacencies than fit into an MTU-s ized packet, the element <em>neighbors</em> For Node TIEs to carry more adjacencies than fit into an MTU-s ized packet, the <em>neighbors</em> element
may contain a different set of neighbors in each TIE. Those di sjointed sets of neighbors may contain a different set of neighbors in each TIE. Those di sjointed sets of neighbors
MUST be joined during corresponding computation. However, if t he following occurs across multiple Node TIEs <bcp14>MUST</bcp14> be joined during corresponding computation . However, if the following occurs across multiple Node TIEs:
</t> </t>
<ol spacing="normal"> <ol spacing="normal">
<li> <li>
<em>capabilities</em> do not match <strong>or</strong></li> <em>capabilities</em> do not match,</li>
<li> <li>
<em>flags</em> values do not match <strong>or</strong></li> <em>flags</em> values do not match, <strong>or</strong></li>
<li>same neighbor repeats in multiple TIEs with different values</li <li>the same neighbor repeats in multiple TIEs with different values
> .</li>
</ol> </ol>
<t>The implementation is expected to use the value of any of the valid TIEs it received as it cannot control the arrival order of those TIEs.</t> <t>The implementation is expected to use the value of any of the valid TIEs it received, as it cannot control the arrival order of those TIEs.</t>
<t> <t>
The <em>miscabled_links</em> element SHOULD be included in eve The <em>miscabled_links</em> element <bcp14>SHOULD</bcp14> be
ry included in every
Node TIE, otherwise the behavior is undefined. Node TIE; otherwise, the behavior is undefined.
</t> </t>
<t>A ToF node MUST include information on all other ToFs it is aware o <t>A ToF node <bcp14>MUST</bcp14> include information on all other ToF
f through reflection. The <em>same_plane_tofs</em> element is used to carry this s it is aware of through reflection. The <em>same_plane_tofs</em> element is use
information. To prevent MTU overrun problems, d to carry this information. To prevent MTU overrun problems,
multiple Node TIEs can carry disjointed sets of ToFs which MUS multiple Node TIEs can carry disjointed sets of ToFs, which <b
T be joined to form a single set. cp14>MUST</bcp14> be joined to form a single set.
</t> </t>
<t> <t>
Different TIE types are carried in <em>TIEElement</em>. Schem a enum Different TIE types are carried in <em>TIEElement</em>. Schem a enum
`common.TIETypeType` 'common.TIETypeType'
in <em>TIEID</em> indicates which elements MUST be present in <em>TIEID</em> indicates which elements <bcp14>MUST</bcp14>
in the <em>TIEElement</em>. In case of a mismatch between the be present
<em>TIETypeType</em> in the <em>TIEID</em> and the present element, in <em>TIEElement</em>. In case of a mismatch between <em>TIET
the unexpected elements MUST be ignored. In case of lack of ex ypeType</em> in the <em>TIEID</em> and the present element,
pected the unexpected elements <bcp14>MUST</bcp14> be ignored. In cas
element in the TIE an error MUST be reported and the TIE e of the lack of an expected
MUST be ignored. element in the TIE, an error <bcp14>MUST</bcp14> be reported a
nd the TIE
<bcp14>MUST</bcp14> be ignored.
The element <em>positive_disaggregation_prefixes</em> and <em> The <em>positive_disaggregation_prefixes</em> and <em>positive
positive_external_disaggregation_prefixes</em> _external_disaggregation_prefixes</em> elements
MUST be advertised <bcp14>MUST</bcp14> be advertised
southbound only and ignored in North TIEs. southbound only and ignored in North TIEs.
The element <em>negative_disaggregation_prefixes</em> MUST be The <em>negative_disaggregation_prefixes</em> element <bcp14>M
propagated UST</bcp14> be propagated,
according to <xref target="negdisaggreg"/> according to <xref target="negdisaggreg"/>,
southwards towards lower levels to heal southwards towards lower levels to heal
pathological upper-level partitioning, otherwise pathological upper-level partitioning; otherwise,
traffic loss may occur in multiplane fabrics. traffic loss may occur in multi-plane fabrics.
It MUST NOT be advertised within a North TIE and MUST be ignor It <bcp14>MUST NOT</bcp14> be advertised within a North TIE an
ed otherwise. d <bcp14>MUST</bcp14> be ignored otherwise.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="flooding_sec"> <section numbered="true" toc="default" anchor="flooding_sec">
<name>Flooding</name> <name>Flooding</name>
<!-- <t> <!-- <t>
The mechanism used to distribute TIEs is the well-known (albeit The mechanism used to distribute TIEs is the well-known (albeit
modified in several respects to take advantage of Fat Tree topology) flooding me chanism used modified in several respects to take advantage of Fat Tree topology) flooding me chanism used
in link-state protocols. Although flooding is initially more demanding to implem ent, it avoids many in link-state protocols. Although flooding is initially more demanding to implem ent, it avoids many
problems with update style used in diffused computation by distance vector proto cols. problems with update style used in diffused computation by distance vector proto cols.
However, since flooding tends to present a significant burden in large, densely meshed However, since flooding tends to present a significant burden in large, densely meshed
topologies (Fat Trees being unfortunately such a topology). topologies (Fat Trees being unfortunately such a topology).
RIFT provides as solution a close to optimal global flood reduction and load bal ancing RIFT provides as solution a close to optimal global flood reduction and load bal ancing
optimization in <xref target="mpr" format="default"/>. optimization in <xref target="mpr" format="default"/>.
</t> --> </t> -->
<t> <t>
As described before, TIEs themselves are transported over UDP with the As described before, TIEs themselves are transported over UDP with the
ports indicated in the LIE ports indicated in the LIE
exchanges and using the destination address exchanges and use the destination address
on which the LIE adjacency on which the LIE adjacency
has been formed.</t> has been formed.</t>
<t>TIEs are uniquely identified by the <em>TIEID</em> schema element. <t>TIEs are uniquely identified by the <em>TIEID</em> schema element.
The <em>TIEID</em> induces a total order achieved by comparing <em>TIEID</em> induces a total order achieved by comparing
the elements in sequence defined in the element and comparing each the elements in sequence defined in the element and comparing each
value as an unsigned integer of corresponding length. The <em> TIEHeader</em> element contains a value as an unsigned integer of corresponding length. The <em> TIEHeader</em> element contains a
<em>seq_nr</em> element to distinguish newer versions of same <em>seq_nr</em> element to distinguish newer versions of the s
TIE.</t> ame TIE.</t>
<t>The <em>TIEHeader</em> can also carry an <em>origination_time</em> <t><em>TIEHeader</em> can also carry an <em>origination_time</em> sche
schema element ma element
(for fabrics that utilize precision timing) which contains (for fabrics that utilize precision timing) that contains
the the
absolute timestamp of when the TIE was generated and an <em>or igination_lifetime</em> absolute timestamp of when the TIE was generated and an <em>or igination_lifetime</em>
to indicate the original lifetime when the TIE was generated. When carried, they to indicate the original lifetime when the TIE was generated. When carried, they
can be used for debugging or security purposes (e.g. to preven t lifetime modification attacks). can be used for debugging or security purposes (e.g., to preve nt lifetime modification attacks).
Clock synchronization is considered in more detail in <xre f target="mobility"/>. Clock synchronization is considered in more detail in <xre f target="mobility"/>.
</t> </t>
<t> <t>
<em>remaining_lifetime</em> counts down to 0 from <em>originat ion_lifetime</em>. <em>remaining_lifetime</em> counts down to 0 from <em>originat ion_lifetime</em>.
TIEs with lifetimes differing by less than TIEs with lifetimes differing by less than
<em>lifetime_diff2ignore</em> MUST be considered EQUAL (if all other fields are equal). <em>lifetime_diff2ignore</em> <bcp14>MUST</bcp14> be considere d EQUAL (if all other fields are equal).
This This
constant MUST be larger than <em>purge_lifetime</em> to avoid constant <bcp14>MUST</bcp14> be larger than <em>purge_lifetime </em> to avoid
retransmissions. retransmissions.
</t> </t>
<t>This normative ordering methodology is <t>This normative ordering methodology is
described in <xref target="tie-ordering"/> and MUST be used by all implementations.</t> described in <xref target="tie-ordering"/> and <bcp14>MUST</bc p14> be used by all implementations.</t>
<figure anchor="tie-ordering"> <figure anchor="tie-ordering">
<name>TIEHeader Comparison Function</name> <name>TIEHeader Comparison Function</name>
<artset> <sourcecode type=""><![CDATA[
<artwork align="center" name="" type="ascii-art" originalSrc="art/ function Compare(X: TIEHeader, Y: TIEHeader) returns Ordering:
rift-rift-tie-ordering.ascii-art">function Compare(X: TIEHeader, Y: TIEHeader) r
eturns Ordering:
seq_nr of a TIEHeader = TIEHeader.seq_nr seq_nr of a TIEHeader = TIEHeader.seq_nr
TIEID of a TIEHeader = TIEHeader.TIEID TIEID of a TIEHeader = TIEHeader.TIEID
direction of a TIEID = TIEID.direction direction of a TIEID = TIEID.direction
# System ID # System ID
originator of a TIEID = TIEID.originator originator of a TIEID = TIEID.originator
# is of type TIETypeType # is of type TIETypeType
tietype of a TIEID = TIEID.tietype tietype of a TIEID = TIEID.tietype
tie_nr of a TIEID = TIEID.tie_nr tie_nr of a TIEID = TIEID.tie_nr
if X.direction &gt; Y.direction: if X.direction > Y.direction:
return X is larger return X is larger
else if X.direction &lt; Y.direction: else if X.direction < Y.direction:
return Y is larger return Y is larger
else if X.originator &gt; Y.originator: else if X.originator > Y.originator:
return X is larger return X is larger
else if X.originator &lt; Y.originator: else if X.originator < Y.originator:
return Y is larger return Y is larger
else: else:
if X.tietype == Y.tietype: if X.tietype == Y.tietype:
if X.tie_nr == Y.tie_nr: if X.tie_nr == Y.tie_nr:
if X.seq_nr == Y.seq_nr: if X.seq_nr == Y.seq_nr:
X.lifetime_left = X.remaining_lifetime - time since TIE was X.lifetime_left = X.remaining_lifetime
received - time since TIE was received
Y.lifetime_left = Y.remaining_lifetime - time since TIE was Y.lifetime_left = Y.remaining_lifetime
received - time since TIE was received
if absolute_value_of(X.lifetime_left - Y.lifetime_left) &lt; if absolute_value_of(X.lifetime_left -
= common.lifetime_diff2ignore: Y.lifetime_left) <= common.lifetime_diff2ignore:
return Both are Equal return Both are Equal
else: else:
return TIEHeader with larger lifetime_left is larger return TIEHeader with larger lifetime_left is
else: larger
return return TIEHeader with larger seq_nr is larger else:
else: return TIEHeader with larger seq_nr is larger
return TIEHeader with larger tie_nr is larger else:
else: return TIEHeader with larger tie_nr is larger
return TIEHeader with larger TIEType is larger</artwork> else:
</artset> return TIEHeader with larger TIEType is larger]]></sourcecode>
</figure> </figure>
<t> <t>
All valid TIE types are defined in <em>TIETypeType</em>. All valid TIE types are defined in <em>TIETypeType</em>.
This enum indicates what TIE type the TIE is carrying. This enum indicates what TIE type the TIE is carrying.
In case the value is not known to the receiver, In case the value is not known to the receiver,
the TIE MUST be re-flooded with scope identical to the scope o the TIE <bcp14>MUST</bcp14> be reflooded with the scope identi
f cal to the scope of
a prefix TIE. This allows for a prefix TIE.
<!--[rfced] To improve the readability of this sentence, may we clarify it
as follows?
Original:
This allows for future
extensions of the protocol within the same major schema with types
opaque to some nodes with some restrictions defined in Section 7.
Perhaps:
This allows for future
extensions of the protocol that are within the same major schema
and that have types that are opaque to some nodes; some restrictions
are defined in Section 7.
-->
This allows for
future extensions of the protocol within the same major schema future extensions of the protocol within the same major schema
with types opaque to some nodes with some restrictions defined in with types opaque to some nodes with some restrictions defined in
<xref target="schema" format="default"/>. <xref target="schema" format="default"/>.
</t> </t>
<section anchor="floodproc" numbered="true" toc="default"> <section anchor="floodproc" numbered="true" toc="default">
<name>Normative Flooding Procedures</name> <name>Normative Flooding Procedures</name>
<t>On reception of a TIE with an undefined level value in the packet <t>On reception of a TIE with an undefined level value in the packet
header header,
the node MUST issue a warning and discard the packet. the node <bcp14>MUST</bcp14> issue a warning and discard the packet.
</t> </t>
<t>This section specifies the precise, normative flooding mechanism and can be omitted unless the <t>This section specifies the precise, normative flooding mechanism and can be omitted unless the
reader is pursuing an implementation of the protocol or looks for a deep understanding of reader is pursuing an implementation of the protocol or looks for a deep understanding of
underlying information distribution mechanism. underlying information distribution mechanism.
</t> </t>
<t> <t>
Flooding Procedures are described in terms of the flooding s Flooding procedures are described in terms of the flooding s
tate of an adjacency tate of an adjacency,
and resulting operations on it driven by packet arrivals. Im and resulting operations on it are driven by packet arrivals
plementations MUST implement a behavior . Implementations <bcp14>MUST</bcp14> implement a behavior
that is externally indistinguishable from the FSMs and norma tive procedures given here. that is externally indistinguishable from the FSMs and norma tive procedures given here.
</t> </t>
<t> <t>
RIFT does not specify any kind of flood rate limiting. To he RIFT does not specify any kind of flood rate limiting. To he
lp with adjustment of flooding speeds the encoded packets provide hints to react lp with adjustment of flooding speeds, the encoded packets provide hints to reac
accordingly to t accordingly to
losses or overruns via <em>you_are_sending_too_quickly</em> losses or overruns via <em>you_are_sending_too_quickly</em>
in the <em>LIEPacket</em> and `Packet Number` in the in the <em>LIEPacket</em> and "Packet Number" in the
security envelope described in <xref target="security-envelo pe"/>. security envelope described in <xref target="security-envelo pe"/>.
Flooding of all corresponding topology exchange elements SHOULD Flooding of all corresponding topology exchange elements <bcp14>
be performed at the SHOULD</bcp14> be performed at the
highest feasible rate but the rate of transmission MUST be t highest feasible rate, but the rate of transmission <bcp14>M
hrottled by UST</bcp14> be throttled by
reacting to packet elements and features of the system such reacting to packet elements and features of the system, such
as e.g. queue lengths or as queue lengths or
congestion indications in the protocol packets. congestion indications in the protocol packets.
</t> </t>
<t> <t>
A node SHOULD NOT send out any topology information elements A node <bcp14>SHOULD NOT</bcp14> send out any topology infor
if the adjacency is not in a mation elements if the adjacency is not in a
"ThreeWay" state. No further tightening of this rule is poss <em>ThreeWay</em> state. No further tightening of this rule
ible. For example, link buffering may cause both LIEs and TIEs/TIDEs/TIREs to be is possible. For example, link buffering may cause both LIEs and TIEs/TIDEs/TIRE
re-ordered. s to be reordered.
</t> </t>
<t> <t>
A node MUST drop any received TIEs/TIDEs/TIREs unless it is in <em>ThreeWay</em> state. A node <bcp14>MUST</bcp14> drop any received TIEs/TIDEs/TIR Es unless it is in the <em>ThreeWay</em> state.
</t> </t>
<t> <t>
TIEs generated by other nodes MUST be re-flooded. TIDEs and TIREs MUST NOT be re-flooded. TIEs generated by other nodes <bcp14>MUST</bcp14> be reflood ed. TIDEs and TIREs <bcp14>MUST NOT</bcp14> be reflooded.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>FloodState Structure per Adjacency</name> <name>FloodState Structure per Adjacency</name>
<t>The structure contains conceptually for each adjacency the foll owing elements. <t>For each adjacency, the structure conceptually contains the fol lowing elements.
The word "collection" The word "collection"
or "queue" indicates a set of elements that can be itera ted over: or "queue" indicates a set of elements that can be itera ted over the following:
</t> </t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>TIES_TX:</dt> <dt>TIES_TX:</dt>
<dd>Collection containing all the TIEs to <dd>Collection containing all the TIEs to
transmit on the adjacency.</dd> transmit on the adjacency.</dd>
<dt>TIES_ACK:</dt> <dt>TIES_ACK:</dt>
<dd>Collection containing all the TIEs that <dd>Collection containing all the TIEs that
have to be acknowledged on the adjacency.</dd> have to be acknowledged on the adjacency.</dd>
<dt>TIES_REQ:</dt> <dt>TIES_REQ:</dt>
<dd>Collection containing all the TIE headers <dd>Collection containing all the TIE headers
that have to be requested on the adjacency.</dd> that have to be requested on the adjacency.</dd>
<dt>TIES_RTX:</dt> <dt>TIES_RTX:</dt>
<dd>Collection containing all TIEs that need <dd>Collection containing all TIEs that need
retransmission with the corresponding time to re transmit.</dd> retransmission with the corresponding time to re transmit.</dd>
<dt>FILTERED_TIEDB:</dt> <dt>FILTERED_TIEDB:</dt>
<dd>A filtered view of TIEDB, which retains for consideration on ly those headers <dd>A filtered view of TIEDB, which retains for consideration on ly those headers
permitted by is_tide_entry_filtered and which either have a lifetime left &gt; 0 permitted by is_tide_entry_filtered and which either have a lifetime left &gt; 0
or have no content.</dd> or have no content.</dd>
</dl> </dl>
<t>Following words are used for well-known elements and procedures operating on this structure: <t>The following words are used for well-known elements and proced ures operating on this structure:
</t> </t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>TIE:</dt> <dt>TIE:</dt>
<dd>Describes either a full RIFT TIE or <dd>describes either a full RIFT TIE or
just the <em>TIEHeader</em> or <em>TIEID</em> eq just the <em>TIEHeader</em> or <em>TIEID</em> eq
uivalent as defined in uivalent, as defined in
<xref target="encoding_thrift_app"/>. The corresponding me aning is <xref target="encoding_thrift_app"/>. The corresponding me aning is
unambiguously contained in the context of each a lgorithm. </dd> unambiguously contained in the context of each a lgorithm. </dd>
<dt>is_flood_reduced(TIE):</dt> <dt>is_flood_reduced(TIE):</dt>
<dd>returns whether a TIE can be <dd>returns whether a TIE can be
flood reduced or not.</dd> flood-reduced or not.</dd>
<dt>is_tide_entry_filtered(TIE):</dt> <dt>is_tide_entry_filtered(TIE):</dt>
<dd>returns whether a header <dd>returns whether a header
should be propagated in TIDE according to floodi ng scopes.</dd> should be propagated in TIDE according to floodi ng scopes.</dd>
<dt>is_request_filtered(TIE):</dt> <dt>is_request_filtered(TIE):</dt>
<dd>returns whether a TIE request <dd>returns whether a TIE request
should be propagated to neighbor or not accordin g to flooding scopes.</dd> should be propagated to the neighbor or not, acc ording to flooding scopes.</dd>
<dt>is_flood_filtered(TIE):</dt> <dt>is_flood_filtered(TIE):</dt>
<dd>returns whether a TIE requested be <dd>returns whether a TIE requested be
flooded to neighbor or not according to flooding scopes.</dd> flooded to the neighbor or not, according to flo oding scopes.</dd>
<dt>try_to_transmit_tie(TIE):</dt> <dt>try_to_transmit_tie(TIE):</dt>
<dd> <dd><t>if not is_flood_filtered(TIE), then</t>
<ol spacing="normal" type="A">
<li>if not is_flood_filtered(TIE) then</li>
<li>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>remove TIE from TIES_RTX if present </li> <li>remove the TIE from TIES_RTX if present </li>
<li> <li>
<t>if TIE with same key is found on TIES_ACK then <t>if the TIE with same key is found on TIES_ACK, then
</t> </t>
<ol spacing="normal" type="a"> <ol spacing="normal" type="a">
<li>if TIE is same or newer than TIE do nothing el <li>if the TIE is the same as or newer than TIE, d
se </li> o nothing, else </li>
<li>remove TIE from TIES_ACK and add TIE to TIES_TX< <li>remove the TIE from TIES_ACK and add TIE to TIES
/li> _TX</li>
</ol> </ol>
</li> </li>
<li>else insert TIE into TIES_TX</li> <li>else insert the TIE into TIES_TX.</li>
</ol> </ol>
</li>
</ol>
</dd> </dd>
<dt>ack_tie(TIE):</dt> <dt>ack_tie(TIE):</dt>
<dd>remove TIE from all collections and then <dd>remove the TIE from all collections and then
insert TIE into TIES_ACK.</dd> insert the TIE into TIES_ACK.</dd>
<dt>tie_been_acked(TIE):</dt> <dt>tie_been_acked(TIE):</dt>
<dd>remove TIE from all collections.</dd> <dd>remove the TIE from all collections.</dd>
<dt>remove_from_all_queues(TIE):</dt> <dt>remove_from_all_queues(TIE):</dt>
<dd>same as <em>tie_been_acked</em>.</dd> <dd>same as <em>tie_been_acked</em>.</dd>
<dt>request_tie(TIE):</dt> <dt>request_tie(TIE):</dt>
<dd>if not is_request_filtered(TIE) then <dd>if not is_request_filtered(TIE), then
remove_from_all_queues(TIE) and add to TIES_REQ. </dd> remove_from_all_queues(TIE) and add to TIES_REQ. </dd>
<dt>move_to_rtx_list(TIE):</dt> <dt>move_to_rtx_list(TIE):</dt>
<dd>remove TIE from TIES_TX and then <dd>remove the TIE from TIES_TX and then
add to TIES_RTX using TIE retransmission interva add to TIES_RTX, using the TIE retransmission in
l.</dd> terval.</dd>
<dt>clear_requests(TIEs):</dt> <dt>clear_requests(TIEs):</dt>
<dd>remove all TIEs from TIES_REQ.</dd> <dd>remove all TIEs from TIES_REQ.</dd>
<dt>bump_own_tie(TIE):</dt> <dt>bump_own_tie(TIE):</dt>
<dd>for self-originated TIE <dd>for a self-originated TIE,
originate an empty or re-generate with originate an empty or regenerate with the
version number higher than the one in TIE.</dd> version number higher than the one in the TIE.</
dd>
</dl> </dl>
<t> <t>
The collection SHOULD be served with the following prior ities if the system The collection <bcp14>SHOULD</bcp14> be served with the following priorities if the system
cannot process all the collections in real time: cannot process all the collections in real time:
</t> </t>
<ol> <ol>
<li>Elements on TIES_ACK should be processed with highest prio rity</li> <li>Elements on TIES_ACK should be processed with highest prio rity</li>
<li>TIES_TX</li> <li>TIES_TX</li>
<li>TIES_REQ and TIES_RTX should be processed with lowest priori ty</li> <li>TIES_REQ and TIES_RTX should be processed with lowest priori ty</li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>TIDEs</name> <name>TIDEs</name>
<t> <t>
<em>TIEID</em> and <em>TIEHeader</em> space forms a stri ct total order (modulo <em>TIEID</em> and <em>TIEHeader</em> spaces form a stri ct total order (modulo
incomparable incomparable
sequence numbers (found in `TIEHeader.seq_nr`) as explai sequence numbers (found in "TIEHeader.seq_nr"), as expla
ned in <xref target="arithmetic"/> in the very unlikely event that ined in <xref target="arithmetic"/>, in the very unlikely event that
can occur if a TIE is "stuck" in a part of a network whi a TIE is "stuck" in a part of a network while the origin
le the originator ator
reboots and reissues TIEs many times reboots and reissues TIEs many times
to the point its sequence# rolls over and forms incompar to the point its sequence number rolls over and forms an
able distance incomparable distance
to the "stuck" copy) which implies that to the "stuck" copy), which implies that
a comparison relation is possible between two elements. a comparison relation is possible between two elements.
With that it is With that, it is
implicitly implicitly
possible to compare TIEs, TIEHeaders and TIEIDs to each other whereas the possible to compare TIEs, TIEHeaders, and TIEIDs to each other, whereas the
shortest shortest
viable key is always implied. viable key is always implied.
</t> </t>
<!-- <!--
<t>When generating and sending TIDEs an implementation SHOUL D ensure that <t>When generating and sending TIDEs an implementation <bcp1 4>SHOULD</bcp14> ensure that
enough bandwidth is left to send elements from other que ues of <em>Floodstate</em> structure. enough bandwidth is left to send elements from other que ues of <em>Floodstate</em> structure.
</t> --> </t> -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>TIDE Generation</name> <name>TIDE Generation</name>
<t>As given by timer constant, periodically generate TIDEs by:</ <t>As given by the timer constant, periodically generate TIDEs b
t> y:</t>
<ul empty="true" spacing="normal">
<li>NEXT_TIDE_ID: ID of next TIE to be sent in TIDE.</li> <dl newline="false" spacing="normal">
</ul> <dt>NEXT_TIDE_ID:</dt> <dd>ID of the next TIE to be sent in th
<ol spacing="normal" type="a"> e TIDE.</dd>
<li>NEXT_TIDE_ID = MIN_TIEID</li> </dl>
<ol spacing="normal" type="1">
<li>NEXT_TIDE_ID = MIN_TIEID</li>
<li> <li>
<t>while NEXT_TIDE_ID not equal to MAX_TIEID do <t>while NEXT_TIDE_ID is not equal to MAX_TIEID, do the foll owing:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="a">
<li>HEADERS = Exactly TIRDEs_PER_PKT headers from FILTER <li>HEADERS = Exactly TIRDEs_PER_PKT headers from
ED_TIEDB starting at NEXT_TIDE_ID, FILTERED_TIEDB starting at NEXT_TIDE_ID, unless fewer
unless fewer than TIRDEs_PER_PKT remain, in which ca than TIRDEs_PER_PKT remain, in which case all
se all remaining headers.</li> remaining headers.</li>
<li>if HEADERS is empty then START = MIN_TIEID else START <li>if HEADERS is empty, then START = MIN_TIEID, else
= START = first element in HEADERS</li>
first <li>if HEADERS' size is less than TIRDEs_PER_PKT, then EN
element in HEADERS D
</li> = MAX_TIEID, else END = last element in HEADERS</li>
<li>if HEADERS' size less than TIRDEs_PER_PKT then END = <li>send <strong>sorted</strong> HEADERS the as TIDE,
MAX_TIEID setting START and END as its range</li>
else END = last element in HEADERS <li>NEXT_TIDE_ID = END</li>
</li>
<li>send <strong>sorted</strong> HEADERS as TIDE setting S
TART and END as
its range
</li>
<li>NEXT_TIDE_ID = END</li>
</ol> </ol>
</li> </li>
</ol> </ol>
<t>The constant <em>TIRDEs_PER_PKT</em> SHOULD be computed per i <!--[rfced] What does "TIRDE" refer to in "TIRDEs_PER_PKT"?
nterface and used by the Is this sufficiently clear to the reader from the text? We note
implementation to "TIDE" and "TIRE" are defined in Section 3.1.
limit the amount of TIE headers per TIDE so the
sent TIDE PDU Current:
does not exceed interface MTU. The constant _TIRDEs_PER_PKT_ SHOULD be computed per interface and
used by the implementation to limit the amount of TIE headers per
TIDE so the sent TIDE PDU does not exceed the interface of MTU.
-->
<t>The constant <em>TIRDEs_PER_PKT</em> <bcp14>SHOULD</bcp14>
be computed per interface and used by the implementation to
limit the amount of TIE headers per TIDE so the sent TIDE PDU
does not exceed the interface of MTU.
</t> </t>
<t>
TIDE PDUs SHOULD be spaced on sending to prevent <!--[rfced] Is "spaced" the correct term to use here? If so, it is unclear how
packet drops. TIDE PDUs should be spaced. Please review and let us know if/how this sentence
may be updated for clarity.
Original:
TIDE PDUs SHOULD be spaced on sending to prevent packet drops.
-->
<t>TIDE PDUs <bcp14>SHOULD</bcp14> be spaced on sending to
prevent packet drops.
</t> </t>
<t> <t>The algorithm will intentionally enter the loop once and
The algorithm will intentionally enter the loop send a single TIDE, even when the database is empty; otherwise,
once and send a single TIDE even when the database no TIDEs would be sent for in case of an empty database and brea
is empty, otherwise no TIDEs would be sent for i k the
n case of empty database and break intended synchronization.
intended synchronization.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>TIDE Processing</name> <name>TIDE Processing</name>
<t>On reception of TIDEs the following processing is performed:
</t> <!--[rfced] Should the terms defined in Sections 6.3.3.1.2.1, 6.3.3.1.2.2,
<ul empty="true" spacing="normal"> and 6.3.3.1.3.2 be prefaced with introductory text? The current text
<li>TXKEYS: Collection of TIE Headers to be sent after process introduces the steps of a process, but then is followed directly by
ing of the packet</li> definitions. May we rearrange the order of the text so that the definitions
<li>REQKEYS: Collection of TIEIDs to be requested after proces come before the current lead-in text?
sing of the packet</li>
<li>CLEARKEYS: Collection of TIEIDs to be removed from flood s For example:
tate queues</li> Original:
<li>LASTPROCESSED: Last processed TIEID in TIDE</li> On reception of TIDEs the following processing is performed:
<li>DBTIE: TIE in the Link State Database (LSDB) if found</li>
</ul> TXKEYS: Collection of TIE Headers to be sent after processing of
<ol spacing="normal" type="a"> the packet
<li>LASTPROCESSED = TIDE.start_range</li>
REQKEYS: Collection of TIEIDs to be requested after processing of
the packet
CLEARKEYS: Collection of TIEIDs to be removed from flood state
queues
LASTPROCESSED: Last processed TIEID in TIDE
DBTIE: TIE in the Link State Database (LSDB) if found
a. LASTPROCESSED = TIDE.start_range
b. for every HEADER in TIDE do
Perhaps:
TXKEYS: Collection of TIE Headers to be sent after processing of
the packet
REQKEYS: Collection of TIEIDs to be requested after processing of
the packet
CLEARKEYS: Collection of TIEIDs to be removed from flood state
queues
LASTPROCESSED: Last processed TIEID in TIDE
DBTIE: TIE in the Link State Database (LSDB) if found
On reception of TIDEs, the following processing is performed:
a. LASTPROCESSED = TIDE.start_range
b. for every HEADER in TIDE do
-->
<t>On reception of TIDEs, the following processing is performed:
</t>
<dl newline="false" spacing="normal">
<dt>TXKEYS:</dt> <dd>Collection of TIE headers to be sent afte
r processing of the packet</dd>
<dt>REQKEYS:</dt> <dd>Collection of TIEIDs to be requested aft
er processing of the packet</dd>
<dt>CLEARKEYS:</dt> <dd>Collection of TIEIDs to be removed fro
m flood state queues</dd>
<dt>LASTPROCESSED:</dt> <dd>Last processed TIEID in the TIDE</
dd>
<dt>DBTIE:</dt> <dd>TIE in the Link State Database (LSDB), if
found</dd>
</dl>
<ol spacing="normal" type="1">
<li>LASTPROCESSED = TIDE.start_range</li>
<li> <li>
<t>for every HEADER in TIDE do <t>For every HEADER in the TIDE, do the following:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="a">
<li>DBTIE = find HEADER in current LSDB </li> <li>DBTIE = find HEADER in the current LSDB </li>
<li>if HEADER &lt; LASTPROCESSED then report error and res <li>if HEADER &lt; LASTPROCESSED, then report the error an
et adjacency and return</li> d reset the adjacency and return</li>
<li>put all TIEs in LSDB where (TIE.HEADER &gt; LASTPROCES <li>put all TIEs in LSDB, where TIE.HEADER &gt; LASTPROCES
SED and SED and
TIE.HEADER &lt; HEADER) into TXKEYS</li> TIE.HEADER &lt; HEADER, into TXKEYS</li>
<li>LASTPROCESSED = HEADER</li> <li>LASTPROCESSED = HEADER</li>
<li> <li>
<t>if DBTIE not found then <t>if DBTIE is not found, then
</t> </t>
<ol spacing="normal" type="%I)"> <ol spacing="normal" type="i">
<li>if originator is this node, then bump_own_tie</l <li>if originator is this node, then bump_own_tie</li>
i>
<li>else put HEADER into REQKEYS</li> <li>else put HEADER into REQKEYS</li>
</ol> </ol>
</li> </li>
<li> <li>
<t>if DBTIE.HEADER &lt; HEADER then <t>if DBTIE.HEADER &lt; HEADER, then
</t> </t>
<ol spacing="normal" type="%I)"> <ol spacing="normal" type="i">
<li> <li>
<t>if originator is this node then bump_own_tie <t>if the originator is this node, then bump_own_tie
else ,
</t> else</t>
<ol spacing="normal" type="%i."> <ol spacing="normal" type="1">
<li>if this is a North TIE header from a northbo <li>if this is a North TIE header from a northbo
und neighbor then und neighbor, then
override DBTIE in LS DB with HEADER</li> override DBTIE in LS DB with HEADER</li>
<li>else put HEADER into REQKEYS</li> <li>else put HEADER into REQKEYS</li>
</ol> </ol>
</li> </li>
</ol> </ol>
</li> </li>
<li>if DBTIE.HEADER &gt; HEADER then put DBTIE.HEADER into TXKEYS </li> <li>if DBTIE.HEADER &gt; HEADER, then put DBTIE.HEADER int o TXKEYS </li>
<li> <li>
<t>if DBTIE.HEADER = HEADER then <t>if DBTIE.HEADER = HEADER, then
</t> </t>
<ol spacing="normal" type="%I)"> <ol spacing="normal" type="i">
<li>if DBTIE has content already then put DBTIE.HEAD <li>if DBTIE has content already, then put DBTIE.HEA
ER into CLEARKEYS</li> DER into CLEARKEYS, else</li>
<li>else put HEADER into REQKEYS</li> <li>put HEADER into REQKEYS</li>
</ol> </ol>
</li> </li>
</ol> </ol>
</li> </li>
<li>put all TIEs in LSDB where (TIE.HEADER &gt; LASTPROCESSED <li>put all TIEs in LSDB, where TIE.HEADER &gt;
and LASTPROCESSED and TIE.HEADER &lt;= TIDE.end_range, into
TIE.HEADER &lt;= TIDE.end_range) into TXKEYS </l TXKEYS </li>
i> <li>for all TIEs in TXKEYS, try_to_transmit_tie(TIE) </li>
<li>for all TIEs in TXKEYS try_to_transmit_tie(TIE) </li> <li>for all TIEs in REQKEYS, request_tie(TIE) </li>
<li>for all TIEs in REQKEYS request_tie(TIE) </li> <li>for all TIEs in CLEARKEYS, remove_from_all_queues(TIE)</li
<li>for all TIEs in CLEARKEYS remove_from_all_queues(TIE)</li> >
</ol> </ol>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>TIREs</name> <name>TIREs</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>TIRE Generation</name> <name>TIRE Generation</name>
<t> <t> Elements from both TIES_REQ and TIES_ACK
Elements from both TIES_REQ and TIES_ACK <bcp14>MUST</bcp14> be collected and sent out as fast as
MUST be collected feasible as TIREs. When sending TIREs with elements from
and sent out as fast as feasible as TIREs. When sending TIES_REQ, the <em>remaining_lifetime</em> field in
TIREs <em>TIEHeaderWithLifeTime</em> <bcp14>MUST</bcp14> be set to 0
with elements from TIES_REQ the <em>remaining_lifeti to force reflooding from the neighbor even if the TIEs seem to
me</em> field in <em>TIEHeaderWithLifeTime</em> be the same.
MUST be set to 0
to force reflooding from the neighbor even if the TI
Es seem to be
same.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>TIRE Processing</name> <name>TIRE Processing</name>
<t>On reception of TIREs the following processing is performed: <t>On reception of TIREs, the following processing is
performed: </t>
</t> <dl newline="false" spacing="normal">
<ul empty="true" spacing="normal"> <dt>TXKEYS:</dt><dd>Collection of TIE headers to be sent after
<li>TXKEYS: Collection of TIE Headers to be sent after process processing of the packet</dd>
ing of the packet</li> <dt>REQKEYS:</dt><dd> Collection of TIEIDs to be requested aft
<li>REQKEYS: Collection of TIEIDs to be requested after proces er processing of the packet</dd>
sing of the packet</li> <dt>ACKKEYS:</dt><dd> Collection of TIEIDs that have been ackn
<li>ACKKEYS: Collection of TIEIDs that have been acked</li> owledged</dd>
<li>DBTIE: TIE in the LSDB if found</li> <dt>DBTIE:</dt><dd> TIE in the LSDB, if found</dd>
</ul> </dl>
<ol spacing="normal" type="a"> <ol spacing="normal" type="1">
<li> <li>
<t>for every HEADER in TIRE do <t>for every HEADER in TIRE, do the following:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="a">
<li>DBTIE = find HEADER in current LSDB </li> <li>DBTIE = find HEADER in the current LSDB </li>
<li>if DBTIE not found then do nothing </li> <li>if DBTIE is not found, then do nothing </li>
<li>if DBTIE.HEADER &lt; HEADER then put HEADER into REQKE <li>if DBTIE.HEADER &lt; HEADER, then put HEADER into REQK
YS </li> EYS </li>
<li>if DBTIE.HEADER &gt; HEADER then put DBTIE.HEADER into <li>if DBTIE.HEADER &gt; HEADER, then put DBTIE.HEADER int
TXKEYS </li> o TXKEYS </li>
<li>if DBTIE.HEADER = HEADER then put DBTIE.HEADER into AC <li>if DBTIE.HEADER = HEADER, then put DBTIE.HEADER into A
KKEYS</li> CKKEYS</li>
</ol> </ol>
</li> </li>
<li>for all TIEs in TXKEYS try_to_transmit_tie(TIE) </li> <li>for all TIEs in TXKEYS, try_to_transmit_tie(TIE) </li>
<li>for all TIEs in REQKEYS request_tie(TIE) </li> <li>for all TIEs in REQKEYS, request_tie(TIE) </li>
<li>for all TIEs in ACKKEYS tie_been_acked(TIE) </li> <li>for all TIEs in ACKKEYS, tie_been_acked(TIE) </li>
</ol> </ol>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>TIEs Processing on Flood State Adjacency</name> <name>TIEs Processing on Flood State Adjacency</name>
<t>On reception of TIEs the following processing is performed: <t>On reception of TIEs, the following processing is performed:
</t> </t>
<ul empty="true" spacing="normal"> <dl newline="false" spacing="normal">
<li>ACKTIE: TIE to acknowledge</li> <dt>ACKTIE:</dt><dd>TIE to acknowledge</dd>
<li>TXTIE: TIE to transmit</li> <dt>TXTIE:</dt><dd>TIE to transmit</dd>
<li>DBTIE: TIE in the LSDB if found</li> <dt>DBTIE:</dt><dd>TIE in the LSDB, if found</dd>
</ul> </dl>
<ol spacing="normal" type="a"> <ol spacing="normal" type="1">
<li>DBTIE = find TIE in current LSDB </li> <li>DBTIE = find TIE in the current LSDB </li>
<li> <li>
<t>if DBTIE not found then <t>if DBTIE is not found, then</t>
</t> <ol spacing="normal" type="a">
<ol spacing="normal" type="1"> <li>if the originator is this node, then bump_own_tie with a
<li>if originator is this node then bump_own_tie with short remaining lifetime, else</li>
a short remaining lifetime</li> <li>insert TIE into LSDB and ACKTIE = TIE</li>
<li>else insert TIE into LSDB and ACKTIE = TIE</li>
</ol> </ol>
<t> <t>else</t>
else <ol spacing="normal" type="a">
</t>
<ol spacing="normal" type="1">
<li> <li>
<t>if DBTIE.HEADER = TIE.HEADER then <t>if DBTIE.HEADER = TIE.HEADER, then
</t> </t>
<ol spacing="normal" type="%i."> <ol spacing="normal" type="i">
<li>if DBTIE has content already then ACKTIE = TIE </l <li>if DBTIE has content already, then ACKTIE = TIE, e
i> lse </li>
<li>else process like the "DBTIE.HEADER &lt; TIE.HEADER" <li>process like the "DBTIE.HEADER &lt; TIE.HEADER" case
case</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t>if DBTIE.HEADER &lt; TIE.HEADER then <t>if DBTIE.HEADER &lt; TIE.HEADER, then
</t> </t>
<ol spacing="normal" type="%i."> <ol spacing="normal" type="i">
<li>if originator is this node then bump_own_tie</li> <li>if the originator is this node, then bump_own_tie,
<li>else insert TIE into LSDB and ACKTIE = TIE</li> else</li>
<li>insert TIE into LSDB and ACKTIE = TIE</li>
</ol> </ol>
</li> </li>
<li> <li>
<t>if DBTIE.HEADER &gt; TIE.HEADER then <t>if DBTIE.HEADER &gt; TIE.HEADER, then
</t> </t>
<ol spacing="normal" type="%i."> <ol spacing="normal" type="i">
<li>if DBTIE has content already then TXTIE = DBTIE</l <li>if DBTIE has content already, then TXTIE = DBTIE,
i> else</li>
<li>else ACKTIE = DBTIE </li> <li>ACKTIE = DBTIE </li>
</ol> </ol>
</li> </li>
</ol> </ol>
</li> </li>
<li>if TXTIE is set then try_to_transmit_tie(TXTIE) </li> <li>if TXTIE is set, then try_to_transmit_tie(TXTIE) </li>
<li>if ACKTIE is set then ack_tie(TIE)</li> <li>if ACKTIE is set, then ack_tie(TIE)</li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Sending TIEs</name> <name>Sending TIEs</name>
<t> <t>
On a periodic basis all TIEs with lifetime left &gt; 0 M On a periodic basis, all TIEs with a lifetime of &gt; 0
UST be sent out left <bcp14>MUST</bcp14> be sent out
on the adjacency, removed from TIES_TX list and requeued on the adjacency, removed from the TIES_TX list, and req
onto TIES_RTX list. The ueued onto TIES_RTX list. The
specific period is out of scope for this document. specific period is out of scope for this document.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>TIEs Processing In LSDB</name> <name>TIEs Processing in LSDB</name>
<t> <t>
The Link State Database (LSDB) holds the most recent cop y of TIEs received via flooding from The Link State Database (LSDB) holds the most recent cop y of TIEs received via flooding from
according peers. Consecutively, after version tie-breaki ng by LSDB, according peers. Consecutively, after version tie-breaki ng by LSDB,
a peer receives from the LSDB the newest versions of TIE s a peer receives from the LSDB the newest versions of TIE s
received by other peers and processes them (without any filtering) just like received by other peers and processes them (without any filtering) just like
receiving TIEs from its remote peer. Such a publisher mo del can be implemented in receiving TIEs from its remote peer. Such a publisher mo del can be implemented in
several ways, either in a single thread of execution or in multiple parallel threads. several ways, either in a single thread of execution or in multiple parallel threads.
</t> </t>
<t> <t>
LSDB can be logically considered as the entity aging out TIEs, i.e. being LSDB can be logically considered as the entity aging out TIEs, i.e., being
responsible to discard TIEs that are stored longer than <em>remaining_lifetime</em> responsible to discard TIEs that are stored longer than <em>remaining_lifetime</em>
on their reception. on their reception.
</t> </t>
<t> LSDB is also expected to periodically re-originate the node's <t> LSDB is also expected to periodically reoriginate the node's o
own TIEs. Originating wn TIEs. Originating
at an interval significantly shorter than <em>default_li at an interval significantly shorter than <em>default_li
fetime</em> is RECOMMENDED fetime</em> is <bcp14>RECOMMENDED</bcp14>
to prevent TIE expiration by other nodes in the network to prevent TIE expiration by other nodes in the network,
which can lead to which can lead to
instabilities. instabilities.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="tiescopes" numbered="true" toc="default"> <section anchor="tiescopes" numbered="true" toc="default">
<name>TIE Flooding Scopes</name> <name>TIE Flooding Scopes</name>
<t>In a somewhat analogous fashion to link-local, area and domain floo <t>In a somewhat analogous fashion to link-local, area, and domain flo
ding scopes, oding scopes,
RIFT defines several complex "flooding scopes" depending on the direction and ty RIFT defines several complex "flooding scopes", depending on the direction and t
pe of TIE ype of TIE
propagated.</t> propagated.</t>
<t>Every North TIE is flooded northbound, providing a node at a given level with the <t>Every North TIE is flooded northbound, providing a node at a given level with the
complete topology of complete topology of
the Clos or Fat Tree network that is reachable southwards of it, including a ll specific prefixes. the Clos or Fat Tree network that is reachable southwards of it, including a ll specific prefixes.
This means that a packet This means that a packet
received from a node at the same or lower level whose destination is covered received from a node at the same or lower level whose destination is covered
by one of those specific by one of those specific
prefixes will be routed directly towards the node advertising that prefix prefixes will be routed directly towards the node advertising that prefix,
rather than sending rather than sending
the packet to a node at a higher level.</t> the packet to a node at a higher level.</t>
<t>A node's Node South TIEs, consisting of all node's adjacencies and <t>A node's Node South TIEs, consisting of all node's adjacencies and
prefix South TIEs limited to those related to default IP prefix and disaggregate d prefixes, prefix South TIEs limited to those related to default IP prefix and disaggregate d prefixes,
are flooded southbound in order to inform nodes one level down of connectivi ty of the higher level as well are flooded southbound in order to inform nodes one level down of connectivi ty of the higher level as well
as reachability to the rest of the fabric. In as reachability to the rest of the fabric. In
order to allow an E-W disconnected node in order to allow an E-W disconnected node in
a given level to receive the South TIEs of other nodes at its level, every <stro ng>NODE</strong> a given level to receive the South TIEs of other nodes at its level, every Node
South TIE is "reflected" northbound to the level from which it was South TIE is "reflected" northbound to the level from which it was
received. It should be noted that East-West links are included in received. It should be noted that East-West links are included in
South TIE flooding (except at the ToF level); South TIE flooding (except at the ToF level);
those TIEs need to be flooded to satisfy algorithms in <xref target="calculate" those TIEs need to be flooded to satisfy the algorithms described in <xref targe
format="default"/>. t="calculate" format="default"/>.
In that way nodes at same level can learn about each other In that way, nodes at same level can learn about each other
using without a lower level except in case of leaf level. without using a lower level except in case of leaf level.
The precise, normative flooding scopes are given in <xref target="tie-tire-tide- scopes" format="default"/>. The precise, normative flooding scopes are given in <xref target="tie-tire-tide- scopes" format="default"/>.
Those rules also govern what SHOULD be included in TIDEs on the adjacency. Those rules also govern what <bcp14>SHOULD</bcp14> be included in TIDEs on the a djacency.
Again, East-West flooding scopes are Again, East-West flooding scopes are
identical to South flooding scopes except in case of ToF East-West links (rings) which identical to southern flooding scopes, except in case of ToF East-West links (ri ngs), which
are basically performing northbound flooding. are basically performing northbound flooding.
</t> </t>
<t>Node South TIE "south reflection" enables support of positive disag <t>Node South TIE "south reflection" enables support of positive disag
gregation on failures as described gregation on failures, as described
in <xref target="disaggregate" format="default"/> and flooding reduction in in <xref target="disaggregate" format="default"/>, and flooding reduction, a
<xref target="mpr" format="default"/>. s described in <xref target="mpr" format="default"/>.
</t> </t>
<table anchor="tie-tire-tide-scopes" align="center"> <table anchor="tie-tire-tide-scopes" align="center">
<name>Normative Flooding Scopes</name> <name>Normative Flooding Scopes</name>
<thead> <thead>
<tr> <tr>
<th align="left">Type / Direction</th> <th align="left">Type / Direction</th>
<th align="left">South</th> <th align="left">South</th>
<th align="left">North</th> <th align="left">North</th>
<th align="left">East-West</th> <th align="left">East-West</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Node South TIE</td> <td align="left">Node South TIE</td>
<td align="left">flood if level of originator is equal to this n <td align="left">flood if the level of the originator is equal t
ode</td> o this node</td>
<td align="left">flood if level of originator is higher than thi <td align="left">flood if the level of the originator is higher
s node</td> than this node</td>
<td align="left">flood only if this node <td align="left">flood only if this node
is not ToF</td> is not ToF</td>
</tr> </tr>
<tr> <tr>
<td align="left">non-Node South TIE</td> <td align="left">non-Node South TIE</td>
<td align="left">flood self-originated only</td> <td align="left">flood self-originated only</td>
<td align="left">flood only if neighbor is originator of TIE</td <td align="left">flood only if the neighbor is the originator of
> TIE</td>
<td align="left">flood only if self-originated and this node is <td align="left">flood only if it is self-originated and this no
not ToF</td> de is not ToF</td>
</tr> </tr>
<tr> <tr>
<td align="left">all North TIEs</td> <td align="left">all North TIEs</td>
<td align="left">never flood</td> <td align="left">never flood</td>
<td align="left">flood always</td> <td align="left">flood always</td>
<td align="left">flood only if this node is ToF</td> <td align="left">flood only if this node is ToF</td>
</tr> </tr>
<tr> <tr>
<td align="left">TIDE</td> <td align="left">TIDE</td>
<td align="left">include at least all non-self <td align="left">include at least all non-self-originated
originated North TIE headers and North TIE headers and
self-originated South TIE headers and self-originated South TIE headers and
Node South TIEs of nodes at same Node South TIEs of nodes at same
level</td> level</td>
<td align="left">include at least all Node South TIEs and <td align="left">include at least all Node South TIEs and
all South TIEs originated by peer and all South TIEs originated by a peer and
all North TIEs</td> all North TIEs</td>
<td align="left">if this node is ToF then <td align="left">if this node is ToF, then
include all North TIEs, otherwise include all North TIEs; otherwise
only self-originated , only include self-originated
TIEs</td> TIEs</td>
</tr> </tr>
<tr> <tr>
<td align="left">TIRE as Request</td> <td align="left">TIRE as Request</td>
<td align="left">request all North TIEs and all peer's <td align="left">request all North TIEs and all peer's
self-originated TIEs and self-originated TIEs and
all Node South TIEs</td> all Node South TIEs</td>
<td align="left">request all South TIEs</td> <td align="left">request all South TIEs</td>
<td align="left">if this node is ToF then apply North scope rule s, otherwise South scope rules</td> <td align="left">if this node is ToF, then apply north scope rul es; otherwise, apply south scope rules</td>
</tr> </tr>
<tr> <tr>
<td align="left">TIRE as Ack</td> <td align="left">TIRE as Ack</td>
<td align="left">Ack all received TIEs</td> <td align="left">Ack all received TIEs</td>
<td align="left">Ack all received TIEs</td> <td align="left">Ack all received TIEs</td>
<td align="left">Ack all received TIEs</td> <td align="left">Ack all received TIEs</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
If the TIDE includes additional TIE If the TIDE includes additional TIE
headers beside the ones specified, the receiving neighbor must apply headers beside the ones specified, the receiving neighbor must apply
the corresponding filter to the received TIDE strictly and MUST NOT requ est the corresponding filter to the received TIDE strictly and <bcp14>MUST N OT</bcp14> request
the extra TIE headers that were not allowed by the flooding scope rules in the extra TIE headers that were not allowed by the flooding scope rules in
its direction. its direction.
</t> </t>
<t>To illustrate these rules, consider using <t>To illustrate these rules, consider using
the topology in <xref target="pic-topo-three" format="default"/>, with the the topology in <xref target="pic-topo-three" format="default"/>, with the
optional link between spine 111 and spine 112, and the optional link between spine 111 and spine 112, and the
associated TIEs given in <xref target="ties-topo-three" format="default"/>. The flooding from particular associated TIEs given in <xref target="ties-topo-three" format="default"/>. The flooding from particular
nodes of the TIEs is given in <xref target="flooding-topo-three" format="def ault"/>.</t> nodes of the TIEs is given in <xref target="flooding-topo-three" format="def ault"/>.</t>
<table anchor="flooding-topo-three" align="center"> <table anchor="flooding-topo-three" align="center">
<name>Flooding some TIEs from example topology</name> <name>Flooding Some TIEs from Example Topology</name>
<thead> <thead>
<tr> <tr>
<th align="left">Local Node</th> <th align="left">Local Node</th>
<th align="left">Neighbor Node</th> <th align="left">Neighbor Node</th>
<th align="left">TIEs Flooded from Local to Neighbor Node</th> <th align="left">TIEs Flooded from Local to Neighbor Node</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Leaf111</td> <td align="left">Leaf111</td>
skipping to change at line 6975 skipping to change at line 7140
nodes in a level. nodes in a level.
leaves do not need to follow this rule leaves do not need to follow this rule
and can freely flood and can freely flood
TIEs of other leaves northbound.</t> TIEs of other leaves northbound.</t>
<t > <t >
Southbound links are where the really Southbound links are where the really
interesting changes interesting changes
happen since here the link-state becomes happen since here the link-state becomes
de-facto a de facto a
"one-hop distance vector" protocol. A "one-hop distance vector" protocol. A
spine node starts to spine node starts to
send on this link different TIEs than send on this link different TIEs than
it uses on it uses on
north- north-
or Eastbound links, namely its South TIE s. or Eastbound links, namely its South TIE s.
They form an independent They form an independent
database that represents ONLY the database that represents ONLY the
node's neighbors node's neighbors
and a default IP prefix. Node's South TI Es and a default IP prefix. Node's South TI Es
skipping to change at line 7004 skipping to change at line 7169
--> -->
</section> </section>
<section anchor="onlynodeties" numbered="true" toc="default"> <section anchor="onlynodeties" numbered="true" toc="default">
<name>RAIN: RIFT Adjacency Inrush Notification</name> <name>RAIN: RIFT Adjacency Inrush Notification</name>
<t> <t>
The optional RIFT Adjacency Inrush Notification (RAI N) The optional RIFT Adjacency Inrush Notification (RAI N)
mechanism helps to prevent adjacencies from being ov erwhelmed by flooding mechanism helps to prevent adjacencies from being ov erwhelmed by flooding
on restart or bring-up with many southbound neighbor s. on restart or bring-up with many southbound neighbor s.
A node MAY set in its In its
LIEs the corresponding <em>you_are_sending_too_quick LIEs, a node <bcp14>MAY</bcp14> set the correspondin
ly</em> flag g <em>you_are_sending_too_quickly</em> flag
to indicate to the neighbor that it SHOULD to indicate to the neighbor that it <bcp14>SHOULD</b
cp14>
flood Node TIEs with normal speed and significantly slow down the flood Node TIEs with normal speed and significantly slow down the
flooding of any other TIEs. The flag SHOULD be set o flooding of any other TIEs. The flag <bcp14>SHOULD</
nly bcp14> be set only
in the southbound direction. The receiving node SHOU in the southbound direction. The receiving node <bcp
LD 14>SHOULD</bcp14>
accommodate the request to lessen the flooding load on the affected accommodate the request to lessen the flooding load on the affected
node if south of the sender and should ignore the in dication if node if it is south of the sender and should ignore the indication if it is
north of the sender. north of the sender.
</t> </t>
<t>The distribution of Node TIEs at normal speed even at high load gua rantees correct <t>The distribution of Node TIEs at normal speed, even at high load, g uarantees correct
behavior of algorithms like disaggregation or defaul t route behavior of algorithms like disaggregation or defaul t route
origination. origination.
Furthermore though, the use of this bit presents an inherent trade-off Furthermore though, the use of this bit presents an inherent trade-off
between processing load and convergence speed since significantly slowing down between processing load and convergence speed since significantly slowing down
flooding of northbound prefixes from neighbors for a n extended time will lead to flooding of northbound prefixes from neighbors for a n extended time will lead to
traffic losses. traffic losses.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="lsdb_sync_sec"> <section numbered="true" toc="default" anchor="lsdb_sync_sec">
<name>Initial and Periodic Database Synchronization</name> <name>Initial and Periodic Database Synchronization</name>
<t>The initial exchange of RIFT includes periodic TIDE <t>The initial exchange of RIFT includes periodic TIDE
exchanges that contain description of the exchanges that contain descriptions of the
link state database and TIREs which perform link state database and TIREs, which perform
the function of requesting unknown TIEs the function of requesting unknown TIEs
as well as confirming reception of flooded TIEs. as well as confirming the reception of flooded T IEs.
<!-- removed on AD comment <!-- removed on AD comment
ISIS with TIDE being equivalent to CSNP and ISIS with TIDE being equivalent to CSNP and
TIRE playing the role of PSNP. TIRE playing the role of PSNP.
--> -->
The content of The content of
TIDEs and TIREs is governed TIDEs and TIREs is governed
by <xref target="tie-tire-tide-scopes" format="d efault"/>. by <xref target="tie-tire-tide-scopes" format="d efault"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="lsdb_purge_sec"> <section numbered="true" toc="default" anchor="lsdb_purge_sec">
<name>Purging and Roll-Overs</name> <name>Purging and Rollovers</name>
<t> <t>
When a node exits the network, if "unpurged", residual stale TIEs may exist in the network until their lifetimes expire When a node exits in the network, if "unpurged", residual stale TIEs may exi st in the network until their lifetimes expire
(which in case of RIFT is by default a rather long period (which in case of RIFT is by default a rather long period
to prevent ongoing re-origination of TIEs in very large topologies). to prevent ongoing reorigination of TIEs in very large topologies).
RIFT does not have a "purging mechanism" based on RIFT does not have a "purging mechanism" based on
sending specialized "purge" packets. sending specialized "purge" packets.
In other routing protocols such a mechanism has proven In other routing protocols, such a mechanism has proven
to be complex and fragile based on many years of experience. RIFT simply issues a new, i.e., higher sequence number, empty version of the TIE to be complex and fragile based on many years of experience. RIFT simply issues a new, i.e., higher sequence number, empty version of the TIE
with a short with a short
lifetime given by the <em>purge_lifetime</em> constant and relies on each no de to age out and delete each TIE copy independently. lifetime given by the <em>purge_lifetime</em> constant and relies on each no de to age out and delete each TIE copy independently.
Abundant amounts of memory are Abundant amounts of memory are
available available
today even on low-end platforms and hence keepin g those relatively short-lived today, even on low-end platforms, and hence, kee ping those relatively short-lived
extra copies for a while extra copies for a while
is acceptable. The is acceptable. The
information will age out and in the meantime all computations information will age out and, in the meantime, a ll computations
will deliver correct results if a node will deliver correct results if a node
leaves the network due leaves the network due
to the new information distributed by its adjace nt to the new information distributed by its adjace nt
nodes breaking bi-directional connectivity check s in nodes breaking bidirectional connectivity checks in
different computations. different computations.
</t> </t>
<t>Once a RIFT node issues a TIE with an ID, it SHOULD <t>Once a RIFT node issues a TIE with an ID, it <bcp14>SHOULD</bcp14>
preserve the ID as long as feasible (also when preserve the ID as long as feasible (also when
the protocol restarts), even if the TIE the protocol restarts), even if the TIE
looses looses
all content. The re-advertisement of an empty TI E all content. The re-advertisement of an empty TI E
fulfills the purpose of purging any information fulfills the purpose of purging any information
advertised in previous versions. The originator advertised in previous versions. The originator
is free to not re-originate the corresponding em is free to not reoriginate the corresponding emp
pty TIE ty TIE
again or originate an empty TIE with relatively again or originate an empty TIE with a relativel
short lifetime to prevent large number of long-l y
ived short lifetime to prevent a large number of long
-lived
empty empty
stubs polluting the network. stubs polluting the network.
Each node Each node
MUST time out and clean up the corresponding emp ty TIEs <bcp14>MUST</bcp14> time out and clean up the co rresponding empty TIEs
independently. independently.
</t> </t>
<t>Upon restart a node MUST be prepared to receive <t>Upon restart, a node <bcp14>MUST</bcp14> be prepared to receive
TIEs with its own System ID and supersede them TIEs with its own System ID and supersede them
with equivalent, newly generated, empty TIEs wit h with equivalent, newly generated, empty TIEs wit h
a higher sequence number. As above, the lifetime a higher sequence number. As above, the lifetime
can be relatively short since it only needs to can be relatively short since it only needs to
exceed the necessary propagation and processing exceed the necessary propagation and processing
delay by all the nodes that are within the delay by all the nodes that are within the
TIE's flooding scope. TIE's flooding scope.
</t> </t>
<t>TIE sequence numbers are rolled over using the method <t>TIE sequence numbers are rolled over using the method
described in described in
<xref target="arithmetic" format="default"/> . <xref target="arithmetic" format="default"/> .
First sequence number of any spontaneously The first sequence number of any spontaneously
originated TIE (i.e. not originated originated TIE (i.e., not originated
to override a detected older copy in to override a detected older copy in
the network) MUST be the network) <bcp14>MUST</bcp14> be
a reasonably unpredictable random number (for ex a reasonably unpredictable random number (for ex
ample <xref target="RFC4086"/>) in the ample, <xref target="RFC4086"/>) in the
interval [0, 2^30-1] which will prevent otherwis interval [0, 2<sup>30</sup>-1], which will preve
e nt otherwise
identical TIE headers to remain "stuck" in the n etwork identical TIE headers to remain "stuck" in the n etwork
with content different from TIE originated after reboot. with content different from the TIE originated a fter reboot.
In traditional In traditional
link-state protocols this is delegated to a 16-b link-state protocols, this is delegated to a 16-
it bit
checksum on packet content. RIFT avoids this des checksum on packet content.
ign due RIFT avoids this design due
to the CPU burden presented by computation of su ch to the CPU burden presented by computation of su ch
checksums and additional complications tied to t he checksums and additional complications tied to t he
fact that the checksum must be "patched" into th e fact that the checksum must be "patched" into th e
packet after the generation of the content, a di packet after the generation of the content, whic
fficult proposition h is a difficult proposition
in binary hand-crafted formats already and highl in binary, hand-crafted formats already and high
y ly
incompatible with model-based, serialized format s. incompatible with model-based, serialized format s.
The sequence number space is hence consciously c hosen The sequence number space is hence consciously c hosen
to be 64-bits wide to make the occurrence of a to be 64-bits wide to make the occurrence of a
TIE with same sequence number but different TIE with the same sequence number but different
content as much or even more unlikely than the content as much or even more unlikely than the
checksum method. checksum method.
To emulate the "checksum behavior" an implementa tion To emulate the "checksum behavior", an implement ation
could choose to compute a 64-bit checksum or has h function over the could choose to compute a 64-bit checksum or has h function over the
TIE content and use that as part of the TIE content and use that as part of the
first sequence number first sequence number
after reboot. after reboot.
</t> </t>
</section> </section>
<section anchor="defaultrouterules" numbered="true" toc="default"> <section anchor="defaultrouterules" numbered="true" toc="default">
<name>Southbound Default Route Origination</name> <name>Southbound Default Route Origination</name>
<t>Under certain conditions nodes issue a default route in their South Prefix TIEs with <t>Under certain conditions, nodes issue a default route in their Sout h Prefix TIEs with
costs as computed in <xref target="varydefault" format="default"/>.</t> costs as computed in <xref target="varydefault" format="default"/>.</t>
<t>A node X that <t>A node X that
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> is <strong>not</strong> overloaded <strong>and</strong></li> <li> is <strong>not</strong> overloaded <strong>and</strong></li>
<li>has southbound or East-West adjacencies</li> <li>has southbound or East-West adjacencies</li>
</ol> </ol>
<t> <t>
SHOULD originate in its south prefix TIE such a default <bcp14>SHOULD</bcp14> originate such a default
route if and only if route in its south prefix TIE if and only if
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>all other nodes at X's' level are overloaded <strong>or</stron g></li> <li>all other nodes at X's' level are overloaded,</li>
<li>all other nodes at X's' level have NO northbound <li>all other nodes at X's' level have NO northbound
adjacencies adjacencies,
<strong>or</strong></li> <strong>or</strong></li>
<li>X has computed reachability to a default <li>X has computed reachability to a default
route during N-SPF.</li> route during N-SPF.</li>
</ol> </ol>
<t>The term "all other nodes at X's' level" describes obviously <t>The term "all other nodes at X's' level " obviously describes
just the nodes at the same level in the PoD with a viable lower level just the nodes at the same level in the PoD with a viable lower level
(otherwise the Node South TIEs cannot be reflected. The nodes in (otherwise, the Node South TIEs cannot be reflected; the nodes in
PoD 1 and PoD 2 are "invisible" to each other). PoD 1 and PoD 2 are "invisible" to each other).
</t> </t>
<t>A node originating a southbound <t>A node originating a southbound
default route SHOULD install a default discard route default route <bcp14>SHOULD</bcp14> install a default discard route
if it did not compute a default route during N-SPF. This basically means that if it did not compute a default route during N-SPF. This basically means that
the top of the fabric will drop traffic for unreachable the top of the fabric will drop traffic for unreachable
addresses. addresses.
</t> </t>
</section> </section>
<section anchor="mpr" numbered="true" toc="default"> <section anchor="mpr" numbered="true" toc="default">
<name>Northbound TIE Flooding Reduction</name> <name>Northbound TIE Flooding Reduction</name>
<t> <t>
RIFT chooses only a subset of northbound nodes to propagate flooding RIFT chooses only a subset of northbound nodes to propagate flooding
and with that both balances it (to prevent 'hot' flooding links) and, with that, both balances it (to prevent "hot" flooding links)
across the fabric as well as reduces across the fabric as well as reduces
its volume. The solution is based on several principles: its volume. The solution is based on several principles:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>a node MUST flood self-originated North TIEs to all the reacha <li>a node <bcp14>MUST</bcp14> flood self-originated North TIEs to
ble nodes at all the reachable nodes at
the level above which is called the node's "parents"; the level above, which is called the node's "parents";
</li> </li>
<li> <li>
it is typically not necessary that all parents reflood the North TIEs to ach ieve it is typically not necessary that all parents reflood the North TIEs to ach ieve
a complete flooding of all the reachable nodes two levels above which we cal l the node's "grandparents"; a complete flooding of all the reachable nodes two levels above, which we ca ll the node's "grandparents";
</li> </li>
<li> <li>
to control the volume of its flooding two hops North and yet keep it robust to control the volume of its flooding two hops north and yet keep it robust
enough, it is advantageous for a node to select a subset of its parents as enough, it is advantageous for a node to select a subset of its parents as
"Flood Repeaters" (FRs), which when combined, deliver two or more copies "Flood Repeaters" (FRs), which when combined, deliver two or more copies
of its flooding to all of its parents, i.e. the originating node's of its flooding to all of its parents, i.e., the originating node's
grandparents; grandparents;
</li> </li>
<li> <li>
nodes at the same level do <strong>not</strong> have to agree on nodes at the same level do <strong>not</strong> have to agree on
a specific algorithm to select the FRs, a specific algorithm to select the FRs,
but overall load balancing should be achieved so that different but overall load balancing should be achieved so that different
nodes at the same level should tend to select different parents as FRs nodes at the same level should tend to select different parents as FRs
(consideration of possible strategies in an unrelated but (consideration of possible strategies in an unrelated but
similar field can be found in <xref target="RFC2991"/>); similar field can be found in <xref target="RFC2991"/>);
</li> </li>
<li> <li>
there are usually many solutions to the problem of finding a set of FRs for there are usually many solutions to the problem of finding a set of FRs for
a given node; the problem of finding the minimal set is (similar to) a a given node; the problem of finding the minimal set is (similar to) an
NP-Complete problem and a globally optimal set may not be the minimal one if NP-Complete problem, and a globally optimal set may not be the minimal one i
load-balancing with other nodes is an important consideration; f
load balancing with other nodes is an important consideration;
</li> </li>
<li> <li>
it is expected that there will often exist sets of equivalent nodes at a it is expected that sets of equivalent nodes at a
level L, defined as having a common set of parents at L+1. level L will often exist, defined as having a common set of parents at L+1.
Applying this observation at both L and L+1, an algorithm may attempt to Applying this observation at both L and L+1, an algorithm may attempt to
split the larger problem in a sum of smaller separate problems; split the larger problem in a sum of smaller, separate problems; and
</li> </li>
<li> <li>
it is expected that there will be from time to time a broken it is expected that there will be a broken
link between a parent and a grandparent, and in that case the parent is link between a parent and a grandparent from time to time, and in that case
, the parent is
probably a poor FR due to its lower reliability. probably a poor FR due to its lower reliability.
An algorithm may attempt to eliminate parents with An algorithm may attempt to eliminate parents with
broken northbound adjacencies first in order to reduce the number of FRs. broken northbound adjacencies first in order to reduce the number of FRs.
Albeit it could be argued that relying on higher fanout FRs will slow Albeit it could be argued that relying on higher fanout FRs will slow
flooding due to higher replication, load reliability of FR's links is likely flooding due to higher replication, load reliability of FR's links is likely
a more pressing concern. a more pressing concern.
</li> </li>
</ol> </ol>
<t> <t>
In a fully connected Clos Network, this means that a node selects one In a fully connected Clos network, this means that a node selects one
arbitrary parent as FR and then a second one for redundancy. The computation arbitrary parent as the FR and then a second one for redundancy. The computa
tion
can be relatively simple and completely distributed without any need can be relatively simple and completely distributed without any need
for synchronization among nodes. In a "PoD" structure, where the Level L+2 for synchronization among nodes. In a "PoD" structure, where the level L+2
is partitioned into silos of equivalent grandparents that are only reachable is partitioned into silos of equivalent grandparents that are only reachable
from respective parents, this means treating each silo as a fully connected from respective parents, this means treating each silo as a fully connected
Clos Network and solving the problem within the silo. Clos network and solving the problem within the silo.
</t> </t>
<t> <t>
In terms of signaling, a node has enough information to select its set of In terms of signaling, a node has enough information to select its set of
FRs; this information is derived from the node's parents' Node South TIEs, w hich FRs; this information is derived from the node's parents' Node South TIEs, w hich
indicate the parent's reachable northbound adjacencies to its own parents (t he node's grandparents). indicate the parent's reachable northbound adjacencies to its own parents (t he node's grandparents).
A node may send a LIE to a northbound neighbor with the optional boolean fie ld A node may send a LIE to a northbound neighbor with the optional boolean fie ld
<em>you_are_flood_repeater</em> set to false, to indicate that the northboun <em>you_are_flood_repeater</em> set to false to indicate that the northbound
d neighbor is neighbor is
not a flood repeater for the node that sent the LIE. In that case the northb not a flood repeater for the node that sent the LIE. In that case, the north
ound bound
neighbor SHOULD NOT reflood northbound TIEs received from the node that sent neighbor <bcp14>SHOULD NOT</bcp14> reflood northbound TIEs received from the
the LIE. node that sent the LIE.
If the <em>you_are_flood_repeater</em> is absent or if <em>you_are_flood_rep If <em>you_are_flood_repeater</em> is absent or <em>you_are_flood_repeater<
eater</em> is set to true, /em> is set to true,
then the northbound neighbor is a flood repeater for the node that sent the then the northbound neighbor is a flood repeater for the node that sent the
LIE and MUST LIE and <bcp14>MUST</bcp14>
reflood northbound TIEs received from that node. reflood northbound TIEs received from that node.
The element <em>you_are_flood_repeater</em> MUST be ignored if rec eived The element <em>you_are_flood_repeater</em> <bcp14>MUST</bcp14> be ignored if received
from a northbound adjacency. from a northbound adjacency.
</t> </t>
<t>This specification provides a simple default algorithm that SHOULD be <t>This specification provides a simple default algorithm that <bcp14> SHOULD</bcp14> be
implemented and used by default on every RIFT node. implemented and used by default on every RIFT node.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>let |NA(Node) be the set of Northbound adjacencies of node Node <li>let |NA(Node) be the set of northbound adjacencies of node Node
and CN(Node) be the cardinality of |NA(Node);</li> and CN(Node) be the cardinality of |NA(Node);</li>
<li>let |SA(Node) be the set of Southbound adjacencies of node Node <li>let |SA(Node) be the set of southbound adjacencies of node Node
and CS(Node) be the cardinality of |SA(Node);</li> and CS(Node) be the cardinality of |SA(Node);</li>
<li>let |P(Node) be the set of node Node's parents; </li> <li>let |P(Node) be the set of node Node's parents; </li>
<li>let |G(Node) be the set of node Node's grandparents. Observe tha t |G(Node) = |P(|P(Node));</li> <li>let |G(Node) be the set of node Node's grandparents. Observe tha t |G(Node) = |P(|P(Node));</li>
<li>let N be the child node at level L computing a set of FR;</li> <li>let N be the child node at level L computing a set of FRs;</li>
<li>let P be a node at level L+1 and a parent node of N, i.e. bi-dir <li>let P be a node at level L+1 and a parent node of N, i.e., bidir
ectionally reachable over adjacency ADJ(N, P);</li> ectionally reachable over adjacency ADJ(N, P);</li>
<li>let G be a grandparent node of N, reachable transitively via a p arent P over adjacencies ADJ(N, P) and ADJ(P, G). Observe <li>let G be a grandparent node of N, reachable transitively via a p arent P over adjacencies ADJ(N, P) and ADJ(P, G). Observe
that N does not have enough information to check bidirectional reach ability of ADJ(P, G);</li> that N does not have enough information to check bidirectional reach ability of ADJ(P, G);</li>
<li>let R be a redundancy constant integer; a value of 2 or higher f <li>let R be a redundancy constant integer; a value of 2 or higher f
or R is RECOMMENDED;</li> or R is <bcp14>RECOMMENDED</bcp14>;</li>
<li>let S be a similarity constant integer; a value in range 0 .. 2 <li>let S be a similarly constant integer; a value in range 0 .. 2 f
for S is RECOMMENDED, the value of 1 SHOULD be used. or S is <bcp14>RECOMMENDED</bcp14>, and the value of 1 <bcp14>SHOULD</bcp14> be
Two cardinalities are considered as equivalent if their absolute dif used.
ference is less than or equal to S, i.e. Two cardinalities are considered as equivalent if their absolute dif
ference is less than or equal to S, i.e.,
<!-- a ~ b => | a div (S+1) | == | b div (S+1) |. --> <!-- a ~ b => | a div (S+1) | == | b div (S+1) |. -->
|a-b|&lt;=S. |a-b|&lt;=S; and
</li> </li>
<li>let RND be a 64-bit random number (for example <xref target="RFC 4086"/>) generated by the system once on startup.</li> <li>let RND be a 64-bit random number (for example, as described in <xref target="RFC4086"/>) generated by the system once on startup.</li>
</ul> </ul>
<t> <t>The algorithm consists of the following steps:</t>
The algorithm consists of the following steps:
</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Derive a 64-bits number by XOR'ing 'N's System ID with RND. <li>Derive a 64-bit number by XORing N's System ID with RND.</li>
</li> <li>
<li> <t>Derive a 16-bit pseudo-random unsigned integer PR(N) from
<t> the resulting 64-bit number by splitting it into 16-bit-long
Derive a 16-bits pseudo-random unsigned integer PR(N) from the resulting 64- words W1, W2, W3, W4 (where W1 are the least significant 16
bits bits of the 64-bit number, and W4 are the most significant 16
number bits) and then XORing the circularly shifted resulting words
by splitting it in 16-bits-long words W1, W2, W3, W4 (where W1 are the least together:
significant 16 </t>
bits of the 64-bits number, and W4 are the most significant 16 bits) and the <t>(W1&lt;&lt;1) xor (W2&lt;&lt;2) xor
n XOR'ing the (W3&lt;&lt;3) xor (W4&lt;&lt;4); where &lt;&lt; is the
circularly shifted resulting words together: circular shift operator.</t>
</t> </li>
<ol spacing="normal" type="A">
<li>
<t>
(W1&lt;&lt;1) xor (W2&lt;&lt;2) xor (W3&lt;&lt;3) xor (W4&lt;&lt;4);
</t>
<t>where &lt;&lt; is the circular shift operator.</t>
</li>
</ol>
</li>
<li> <li>
Sort the parents by decreasing number of northbound adjacencies Sort the parents by decreasing number of northbound adjacencies
(using decreasing System ID of the parent as tie-breaker): (using decreasing System ID of the parent as a tie-breaker):
sort |P(N) by decreasing CN(P), for all P in |P(N), as ordered array |A(N) sort |P(N) by decreasing CN(P), for all P in |P(N), as the ordered array |A(
N)
</li> </li>
<li> <li>
<t> <t>
Partition |A(N) in subarrays |A_k(N) of parents with equivalent cardinality Partition |A(N) in subarrays |A_k(N) of parents with equivalent cardinality
of northbound adjacencies (in other words with equivalent number of of northbound adjacencies (in other words, with equivalent number of
grandparents they can reach): grandparents they can reach):
</t> </t>
<ol spacing="normal" type="A"> <ol spacing="normal" type="a">
<li>set k=0; // k is the ID of the subarrray</li> <li>set k=0; // k is the ID of the subarray</li>
<li>set i=0; </li> <li>set i=0; </li>
<li> <li>
<t>while i &lt; CN(N) do <t>while i &lt; CN(N) do the following:
</t> </t>
<ol spacing="normal" type="%i)"> <ol spacing="normal" type="i">
<li>set j=i; </li> <li>set j=i; </li>
<li> <li>
<t>while i &lt; CN(N) and CN(|A(N)[j]) - CN(|A(N)[i]) &lt; = S <t>while i &lt; CN(N) and CN(|A(N)[j]) - CN(|A(N)[i]) &lt; = S:
</t> </t>
<ol spacing="normal" type="%c."> <ol spacing="normal" type="1">
<li>place |A(N)[i] in |A_k(N) // abstract action, mayb e noop </li> <li>place |A(N)[i] in |A_k(N) // abstract action, mayb e noop </li>
<li>set i=i+1;</li> <li>set i=i+1;</li>
</ol> </ol>
</li> </li>
<li> <li>
<t>/* At this point j is the index in |A(N) of the first m <t>/* At this point, j is the index in |A(N) of the first
ember of member of
|A_k(N) and (i-j) is C_k(N) defined as the cardinality of |A_k(N |A_k(N) and (i-j) is C_k(N) defined as the cardinality of |A_k(N
) */ ). */
</t> </t>
<t> <t>
set k=k+1; set k=k+1.
</t> </t>
</li> </li>
</ol> </ol>
</li> </li>
</ol> </ol>
<t> <t>
/* At this point k is the total number of subarrays, initialized for the /* At this point, k is the total number of subarrays, initialized for the
shuffling operation below */ shuffling operation below. */
</t> </t>
</li> </li>
<li> <li>
<t> <t>
shuffle individually each subarrays |A_k(N) of cardinality C_k(N) within Shuffle each subarrays |A_k(N) of cardinality C_k(N) within
|A(N) using the Durstenfeld variation of Fisher-Yates algorithm that depends |A(N) individually using the Durstenfeld variation of the Fisher-Yates algor
on N's System ID: ithm that depends on N's System ID:
</t> </t>
<ol spacing="normal" type="A"> <ol spacing="normal" type="a">
<li> <li>
<t>while k &gt; 0 do <t>while k &gt; 0 do the following:
</t> </t>
<ol spacing="normal" type="%i)"> <ol spacing="normal" type="i">
<li> <li>
<t>for i from C_k(N)-1 to 1 decrementing by 1 do <t>for i from C_k(N)-1 to 1 decrementing by 1, do the foll owing:
</t> </t>
<ol spacing="normal" type="%c."> <ol spacing="normal" type="1">
<li>set j to PR(N) modulo i;</li> <li>set j to PR(N) modulo i;</li>
<li>exchange |A_k[j] and |A_k[i];</li> <li>exchange |A_k[j] and |A_k[i];</li>
</ol> </ol>
</li> </li>
<li>set k=k-1;</li> <li>set k=k-1.</li>
</ol> </ol>
</li> </li>
</ol> </ol>
</li> </li>
<li> <li>
<t> <t>
For each grandparent G, initialize a counter c(G) with the number of its sou For each grandparent G, initialize a counter c(G) with the number of its sou
th-bound adjacencies thbound adjacencies
to elected flood repeaters (which is initially zero): to elected flood repeaters (which is initially zero):</t>
</t> <ol spacing="normal" type="a">
<ol spacing="normal" type="A"> <li><t>for each G in |G(N), set c(G) = 0.</t></li>
<li>for each G in |G(N) set c(G) = 0;</li> </ol>
</ol>
</li> </li>
<li> <li>
<t> <t>
Finally keep as FRs only parents that are needed to maintain the number of Finally, only keep FRs as parents that are needed to maintain the number of
adjacencies between the FRs and any grandparent G equal or above the adjacencies between the FRs and any grandparent G equal or above the
redundancy constant R: redundancy constant R:
</t> </t>
<ol spacing="normal" type="A"> <ol spacing="normal" type="a">
<li> <li><t>for each P in reshuffled |A(N):</t>
<t>for each P in reshuffled |A(N); <ol spacing="normal" type="i">
</t> <li><t>if there
<ol spacing="normal" type="%i)"> exists an adjacency ADJ(P, G) in |NA(P) such that c(G) &lt;
<li> R, then</t>
<t>if there exists an adjacency ADJ(P, G) in |NA(P) such t <ol spacing="normal" type="1">
hat c(G) &lt; R then
</t>
<ol spacing="normal" type="%c.">
<li>place P in FR set;</li> <li>place P in FR set;</li>
<li>for all adjacencies ADJ(P, G') in |NA(P) increment c (G')</li> <li>for all adjacencies ADJ(P, G') in |NA(P) increment c (G')</li>
</ol> </ol>
</li> </li></ol>
</ol> </li>
</li> </ol>
</li>
<li>If any c(G) is still &lt; R, it was not possible to elect <li>If any c(G) is still &lt; R, it was not possible to elect
a set of FRs that covers all grandparents with redundancy R</li> a set of FRs that covers all grandparents with redundancy R</li>
</ol> </ol>
</li>
</ol>
<t>Additional rules for flooding reduction: <t>Additional rules for flooding reduction:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The algorithm MUST be re-evaluated by a node on every change o f local <li>The algorithm <bcp14>MUST</bcp14> be re-evaluated by a node on every change of local
adjacencies or reception of a parent South TIE with changed adja cencies. adjacencies or reception of a parent South TIE with changed adja cencies.
A node MAY apply a hysteresis to prevent excessive amount of A node <bcp14>MAY</bcp14> apply a hysteresis to prevent an exces sive amount of
computation during periods of network instability just like in t he case computation during periods of network instability just like in t he case
of reachability computation.</li> of reachability computation.</li>
<li> <li>
Upon a change of the flood repeater set, a node SHOULD send out LIEs Upon a change of the flood repeater set, a node <bcp14>SHOULD</b cp14> send out LIEs
that grant flood repeater status to newly promoted nodes before it sends LIEs that grant flood repeater status to newly promoted nodes before it sends LIEs
that revoke the status to the nodes that have been newly demoted . that revoke the status to the nodes that have been newly demoted .
This is done to prevent transient behavior where the full covera ge of This is done to prevent transient behavior where the full covera ge of
grandparents is not guaranteed. Such a condition is sometimes un avoidable grandparents is not guaranteed. Such a condition is sometimes un avoidable
in case of lost LIEs but it will in case of lost LIEs, but it will
correct itself though at possible transient reduction in floodin correct itself at possible transient reduction in flooding propa
g propagation speeds. gation speeds.
The election can use the LIE FSM <em>FloodLeadersChanged</em> event to notify LIE The election can use the LIE FSM <em>FloodLeadersChanged</em> event to notify LIE
FSMs of necessity to update the sent LIEs. FSMs of the necessity to update the sent LIEs.
</li> </li>
<li>A node MUST always flood its self-originated TIEs to all its nei ghbors. <li>A node <bcp14>MUST</bcp14> always flood its self-originated TIEs to all its neighbors.
</li> </li>
<li>A node receiving a TIE originated by <li>A node receiving a TIE originated by
a node for which it is not a flood a node for which it is not a flood
repeater SHOULD NOT reflood such TIEs to its neighbors repeater <bcp14>SHOULD NOT</bcp14> reflood such TIEs to its neig
except for rules in <xref target="rule2" format="default"/>. hbors,
except for the rules described in <xref target="rule2" format="d
efault"/>.
</li> </li>
<li>The indication of flood reduction capability <li>The indication of flood reduction capability
MUST be carried in the Node TIEs in the <em>flood_reduction</em> <bcp14>MUST</bcp14> be carried in the Node TIEs in the <em>flood
element _reduction</em> element
and MAY be used to optimize the and <bcp14>MAY</bcp14> be used to optimize the
algorithm to account for nodes that will flood regardless. algorithm to account for nodes that will flood regardless.
</li> </li>
<li anchor="rule2">A node generates TIDEs as usual but when
<!--[rfced] May "on first and only first request" be updated to
"on only the first request" for clarity?
Original:
...when receiving TIREs or TIDEs
resulting in requests for a TIE of which the newest received copy
came on an adjacency where the node was not flood repeater it
SHOULD ignore such requests on first and only first request.
Perhaps:
...when receiving TIREs or TIDEs
resulting in requests for a TIE of which the newest received copy
came on an adjacency where the node was not a flood repeater, it
SHOULD ignore such requests on only the first request.
-->
<li anchor="rule2">A node generates TIDEs as usual, but when
receiving TIREs or TIDEs resulting in requests for a receiving TIREs or TIDEs resulting in requests for a
TIE of which the newest received copy came on TIE of which the newest received copy came on
an adjacency where the node was not flood repeater it an adjacency where the node was not a flood repeater, it
SHOULD ignore such requests on first and only first <bcp14>SHOULD</bcp14> ignore such requests on first and only fir
st
request. Normally, the nodes that received request. Normally, the nodes that received
the TIEs as flooding repeaters should satisfy the requesting nod e the TIEs as flooding repeaters should satisfy the requesting nod e
and with that no and, with that, no
further TIREs for such TIEs will be further TIREs for such TIEs will be
generated. Otherwise, the next set generated. Otherwise, the next set
of TIDEs and TIREs MUST lead to flooding of TIDEs and TIREs <bcp14>MUST</bcp14> lead to flooding
independent of the independent of the
flood repeater status. This solves a very difficult flood repeater status. This solves a very difficult
incast problem on nodes restarting with a very wide fanout, espe "incast" problem on nodes restarting with a very wide fanout, es
cially pecially
northbound. To retrieve the full database they often northbound. To retrieve the full database, they often
end up processing many in-rushing copies whereas this end up processing many inrushing copies, whereas this
approach load-balances the incoming database approach load balances the incoming database
between adjacent nodes and flood repeaters and should between adjacent nodes and flood repeaters and should
guarantee that two copies are sent by different nodes guarantee that two copies are sent by different nodes
to ensure against any losses. to ensure against any losses.
</li> </li>
<!-- belongs into PGP draft <!-- belongs into PGP draft
<t>Obviously flooding reduction does NOT apply to <t>Obviously flooding reduction does NOT apply to
self originated TIEs and since self originated TIEs and since
all policy-guided information consists of all policy-guided information consists of
self-originated TIEs those are unaffected. self-originated TIEs those are unaffected.
skipping to change at line 7452 skipping to change at line 7624
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Special Considerations</name> <name>Special Considerations</name>
<t> <t>
First, due to the distributed, asynchronous nature of First, due to the distributed, asynchronous nature of
ZTP, it can create temporary convergence anomalies where nodes at hi gher levels ZTP, it can create temporary convergence anomalies where nodes at hi gher levels
of the fabric temporarily become lower than where they ultimately be long. Since flooding of the fabric temporarily become lower than where they ultimately be long. Since flooding
can begin before ZTP is "finished" and in fact must do so given ther e is no global can begin before ZTP is "finished" and in fact must do so given ther e is no global
termination criteria for the unsychronized ZTP algorithm, informatio n may end up temporarily termination criteria for the unsynchronized ZTP algorithm, informati on may temporarily end up
in wrong layers. in wrong layers.
A special clause A special clause
when changing level takes care of that. when changing level takes care of that.
</t> </t>
<!--[rfced] Should "TIE north" be "North TIE" to match other instances
throughout the document?
Original:
More difficult is a condition where a node (e.g. a leaf) floods a TIE
north towards its grandparent, then its parent reboots, partitioning
the grandparent from leaf directly and then the leaf itself reboots.
-->
<t> <t>
More difficult is a condition where a node (e.g. a leaf) floods a TI More difficult is a condition where a node (e.g., a leaf) floods a T
E north towards its IE north towards its
grandparent, then its parent reboots, partitioning the grandparent f grandparent, then its parent reboots, partitioning the grandparent f
rom rom the
leaf directly and then the leaf itself reboots. That can leave the leaf directly, and then the leaf itself reboots. That can leave the
grandparent holding the "primary copy" of the leaf's TIE. Normally t grandparent holding the "primary copy" of the leaf's TIE. Normally,
his condition this condition
is resolved easily by the leaf re-originating its TIE with a higher is resolved easily by the leaf reoriginating its TIE with a higher s
sequence equence
number than it notices in the northbound TIEs, here however, when th number than it notices in the northbound TIEs; here however, when th
e parent comes back it won't e parent comes back, it won't
be able to obtain leaf's North TIE from the grandparent easily and w be able to obtain the leaf's North TIE from the grandparent easily,
ith that the leaf and with that, the leaf
may not issue the TIE with a higher sequence number that can reach t he grandparent for a long may not issue the TIE with a higher sequence number that can reach t he grandparent for a long
time. Flooding time. Flooding
procedures are extended to deal with the problem by the means of spe cial clauses procedures are extended to deal with the problem by the means of spe cial clauses
that override the database of a lower level with headers of newer TI Es received in that override the database of a lower level with headers of newer TI Es received in
TIDEs coming from the north. Those headers are then propagated south bound towards the leaf TIDEs coming from the north. Those headers are then propagated south bound towards the leaf
to cause it to originate a higher sequence number of the TIE effecti vely refreshing it to cause it to originate a higher sequence number of the TIE, effect ively refreshing it
all the way up to ToF. all the way up to ToF.
</t> </t>
</section> </section>
</section> </section>
<!-- flooding --> <!-- flooding -->
<section anchor="calculate" numbered="true" toc="default"> <section anchor="calculate" numbered="true" toc="default">
<name>Reachability Computation</name> <name>Reachability Computation</name>
<t>A node has three possible sources of relevant information for reachab ility computation. <t>A node has three possible sources of relevant information for reachab ility computation.
A node knows A node knows
the full topology south of it from the received North Node TIEs or alter nately the full topology south of it from the received North Node TIEs or alter nately
north of it from the South Node TIEs. A node has the north of it from the South Node TIEs. A node has the
set of prefixes with their associated distances and bandwidths from set of prefixes with their associated distances and bandwidths from
corresponding prefix TIEs.</t> corresponding prefix TIEs.</t>
<t>To compute prefix reachability, a node runs conceptually a northbound <t>To compute prefix reachability, a node conceptually runs a northbound
and a southbound and a southbound
SPF. SPF.
N-SPF and S-SPF notation denotes here the direction in which the computa tion Here, N-SPF and S-SPF notation denotes the direction in which the comput ation
front is progressing. front is progressing.
</t> </t>
<t>Since neither computation can "loop", it is <t>Since neither computation can "loop", it is
possible to compute non-equal-cost or even possible to compute non-equal costs or even
<xref target="EPPSTEIN" format="default">k-shortest paths</xref> <xref target="EPPSTEIN" format="default">k-shortest paths</xref>
and "saturate" the fabric and "saturate" the fabric
to the extent desired. This specification however uses simple, familiar SPF algorithms and to the extent desired. This specification however uses simple, familiar SPF algorithms and
concepts as example due to their prevalence in today's routing. concepts as examples due to their prevalence in today's routing.
</t> </t>
<t> <t>
For reachability computation purposes, RIFT considers all parallel For reachability computation purposes, RIFT considers all parallel
links between two nodes to be of the same cost advertised in the <em>cos t</em> element links between two nodes to be of the same cost advertised in the <em>cos t</em> element
of <em>NodeNeighborsTIEElement</em>. In case the neighbor has multiple of <em>NodeNeighborsTIEElement</em>. In case the neighbor has multiple
parallel links at different cost, the largest distance parallel links at different costs, the largest distance
(highest numerical value) MUST be advertised. Given the range of (highest numerical value) <bcp14>MUST</bcp14> be advertised.
thrift encodings, <em>infinite_distance</em> is defined as the largest n Given the range of
on-negative Thrift encodings, <em>infinite_distance</em> is defined as the largest n
<em>MetricType</em>. Any link with metric larger than that (i.e. negativ on-negative
e <em>MetricType</em>. Any link with a metric larger than that (i.e., the
MetricType) MUST be ignored negative
in computations. Any link with metric set to <em>invalid_distance</em> M MetricType) <bcp14>MUST</bcp14> be ignored
UST also be ignored in in computations. Any link with the metric set to <em>invalid_distance</
em> <bcp14>MUST</bcp14> also be ignored in
computation. computation.
In case of a In case of a
negatively distributed prefix the metric attribute negatively distributed prefix, the metric attribute
MUST be set to <em>infinite_distance</em> <bcp14>MUST</bcp14> be set to <em>infinite_distance</em>
by the originator and it MUST be ignored by all nodes by the originator, and it <bcp14>MUST</bcp14> be ignored by all nodes
during computation except for the purpose of determining during computation, except for the purpose of determining
transitive propagation and building the corresponding routing table. transitive propagation and building the corresponding routing table.
</t> </t>
<t> <t>
A prefix can carry the <em>directly_attached</em> attribute to indicate that the prefix is directly attached, i.e., should be A prefix can carry the <em>directly_attached</em> attribute to indicate that the prefix is directly attached, i.e., should be
routed to even if the node is in overload. In case of a routed to even if the node is in overload. In case of a
negatively distributed prefix this attribute MUST NOT negatively distributed prefix, this attribute <bcp14>MUST NOT</bcp14>
be included by the originator and it MUST be ignored be included by the originator, and it <bcp14>MUST</bcp14> be ignored
by all nodes during SPF computation. If a prefix is locally originated by all nodes during SPF computation. If a prefix is locally originated,
the attribute <em>from_link</em> can indicate the interface the attribute <em>from_link</em> can indicate the interface
to which the address to which the address
belongs to. In case of a negatively distributed prefix belongs to. In case of a negatively distributed prefix,
this attribute MUST NOT be included by the originator this attribute <bcp14>MUST NOT</bcp14> be included by the originator,
and it MUST be ignored by all nodes during computation. and it <bcp14>MUST</bcp14> be ignored by all nodes during computation.
A prefix can also carry the <em>loopback</em> attribute to indicate the said property. A prefix can also carry the <em>loopback</em> attribute to indicate the said property.
</t> </t>
<t> <t>
Prefixes are carried in different types of TIEs indicating their type. Prefixes are carried in different types of TIEs indicating their type.
For same prefix being included in different TIE types tie-breaking For the same prefix being included in different TIE types, tie-breaking
is performed according to <xref target="prefs"/>. is performed according to <xref target="prefs"/>.
If the same prefix is included multiple times in multiple TIEs of the sa me type originating at the If the same prefix is included multiple times in multiple TIEs of the sa me type originating at the
same node the resulting same node, the resulting
behavior is unspecified. behavior is unspecified.
</t> </t>
<section anchor="nspf" numbered="true" toc="default"> <section anchor="nspf" numbered="true" toc="default">
<name>Northbound Reachability SPF</name> <name>Northbound Reachability SPF</name>
<t> N-SPF MUST use exclusively northbound and East-West adjacencies in <t> N-SPF <bcp14>MUST</bcp14> use exclusively northbound and East-West
the computing adjacencies in the computing
node's node North TIEs (since if the node is a leaf it may not have node's node North TIEs (since if the node is a leaf, it may not have
generated a Node South TIE) generated a Node South TIE)
when starting SPF. Observe that N-SPF is really just when starting SPF. Observe that N-SPF is really just
a one hop variety since Node South TIEs are not re-flooded southboun d a one-hop variety since Node South TIEs are not reflooded southbound
beyond beyond
a single level (or East-West) and a single level (or East-West), and
with that the computation cannot progress beyond adjacent nodes. with that, the computation cannot progress beyond adjacent nodes.
</t> </t>
<t>Once progressing, the computation uses the next higher level's Node South TIEs to <t>Once progressing, the computation uses the next higher level's Node South TIEs to
find corresponding adjacencies to verify backlink connectivity. find corresponding adjacencies to verify backlink connectivity.
Two unidirectional links MUST be Two unidirectional links <bcp14>MUST</bcp14> be
associated to confirm bidirectional connectivity, a process often known associated to confirm bidirectional connectivity, a process often known
as `backlink check`. As part of the check, both Node TIEs as "backlink check". As part of the check, both Node TIEs
MUST contain the correct System IDs <strong>and</strong> expected levels. <bcp14>MUST</bcp14> contain the correct System IDs <strong>and</strong> expe
cted levels.
</t> </t>
<t>The default route found when crossing an E-W link SHOULD be used if and only if <t>The default route found when crossing an E-W link <bcp14>SHOULD</bc p14> be used if and only if:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>the node itself does <strong>not</strong> have any northbound adjacencies <strong>and</strong></li> <li>the node itself does <strong>not</strong> have any northbound adjacencies <strong>and</strong></li>
<li>the adjacent node has one or more northbound adjacencies</li> <li>the adjacent node has one or more northbound adjacencies</li>
</ol> </ol>
<t> <t>
This rule forms This rule forms
a "one-hop default route split-horizon" and prevents looping a "one-hop default route split-horizon" and prevents looping
over default routes over default routes
while allowing for "one-hop protection" of nodes that lost while allowing for "one-hop protection" of nodes that lost
all northbound all northbound
adjacencies except at the ToF where the links are used adjacencies, except at the ToF where the links are used
exclusively to flood topology information in multi-plane designs. exclusively to flood topology information in multi-plane designs.
</t> </t>
<t>Other south prefixes found when crossing E-W link MAY be used if an d only if <t>Other south prefixes found when crossing E-W links <bcp14>MAY</bcp1 4> be used if and only if
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>no <li>no
north neighbors are advertising same or a supersuming non-default north neighbors are advertising the same or a supersuming non-defaul t
prefix <strong>and</strong> </li> prefix <strong>and</strong> </li>
<li>the node does not originate a non-default supersuming prefix <li>the node does not originate a non-default supersuming prefix
itself.</li> itself.</li>
</ol> </ol>
<t> <t>
I.e., the That is, the
E-W link can be used as a gateway of last resort for a specific prefix only. E-W link can be used as a gateway of last resort for a specific prefix only.
Using south prefixes across E-W link can be beneficial e.g., Using south prefixes across an E-W link can be beneficial, e.g.,
on automatic disaggregation on automatic disaggregation
in pathological fabric partitioning scenarios. in pathological fabric partitioning scenarios.
</t> </t>
<t> <t>
A detailed example can be found in <xref target="onastickexample" fo rmat="default"/>. A detailed example can be found in <xref target="onastickexample" fo rmat="default"/>.
</t> </t>
</section> </section>
<section anchor="sspf" numbered="true" toc="default"> <section anchor="sspf" numbered="true" toc="default">
<name>Southbound Reachability SPF</name> <name>Southbound Reachability SPF</name>
<t> S-SPF MUST use the <t> S-SPF <bcp14>MUST</bcp14> use the
southbound adjacencies in the Node South TIEs exclusively, southbound adjacencies in the Node South TIEs exclusively,
i.e. progresses towards nodes at lower levels. Observe that i.e., progresses towards nodes at lower levels. Observe that
E-W adjacencies are NEVER used in this computation. This enforces th e E-W adjacencies are NEVER used in this computation. This enforces th e
requirement that a packet traversing in a southbound direction must requirement that a packet traversing in a southbound direction must
never change its direction.</t> never change its direction.</t>
<t>S-SPF MUST use northbound adjacencies in node North TIEs to verify <t>S-SPF <bcp14>MUST</bcp14> use northbound adjacencies in node North
backlink TIEs to verify backlink
connectivity by checking for presence of the link beside correct Sys connectivity by checking for the presence of the link beside the cor
tem ID and rect System ID and
level. </t> level. </t>
</section> </section>
<section anchor="ringspf" numbered="true" toc="default"> <section anchor="ringspf" numbered="true" toc="default">
<name>East-West Forwarding Within a non-ToF Level</name> <name>East-West Forwarding Within a Non-ToF Level</name>
<t>Using south prefixes over horizontal links MAY occur <t>Using south prefixes over horizontal links <bcp14>MAY</bcp14> occur
if the N-SPF includes East-West adjacencies in computation. if the N-SPF includes East-West adjacencies in computation.
It can It can
protect against pathological fabric partitioning cases that protect against pathological fabric partitioning cases that
leave only paths to destinations that would necessitate multiple leave only paths to destinations that would necessitate multiple
changes of forwarding direction between north and south. changes of the forwarding direction between north and south.
</t> </t>
</section> </section>
<section anchor="tofew" numbered="true" toc="default"> <section anchor="tofew" numbered="true" toc="default">
<name>East-West Links Within ToF Level</name> <name>East-West Links Within a ToF Level</name>
<t>E-W ToF links behave in terms of flooding scopes defined in <t>E-W ToF links behave in terms of flooding scopes defined in
<xref target="tiescopes" format="default"/> like northbound link s and MUST be used exclusively for control plane <xref target="tiescopes" format="default"/> like northbound link s and <bcp14>MUST</bcp14> be used exclusively for control plane
information flooding. Even though a ToF node could be tempted information flooding. Even though a ToF node could be tempted
to use those links during southbound SPF and carry traffic over to use those links during southbound SPF and carry traffic over
them this them, this
MUST NOT be attempted since it may, in anycast cases, lead to ro <bcp14>MUST NOT</bcp14> be attempted since it may, in anycast ca
uting loops. ses, lead to routing loops.
An implementation MAY try to resolve the looping problem by foll An implementation <bcp14>MAY</bcp14> try to resolve the looping
owing on the ring strictly problem by following on the ring strictly
tie-broken tie-broken
shortest-paths only but the details are outside this specificati on. And even then, shortest-paths only, but the details are outside this specificat ion. And even then,
the problem of proper capacity provisioning of such links when t hey become traffic-bearing in the problem of proper capacity provisioning of such links when t hey become traffic-bearing in
case of failures is vexing and when used for forwarding purposes , they defeat statistical non-blocking case of failures is vexing, and when used for forwarding purpose s, they defeat statistical non-blocking
guarantees that Clos is providing normally.</t> guarantees that Clos is providing normally.</t>
</section> </section>
</section> </section>
<section anchor="disaggregate" numbered="true" toc="default"> <section anchor="disaggregate" numbered="true" toc="default">
<name>Automatic Disaggregation on Link &amp; Node Failures</name> <name>Automatic Disaggregation on Link &amp; Node Failures</name>
<section anchor="posdisaggreg" numbered="true" toc="default"> <section anchor="posdisaggreg" numbered="true" toc="default">
<name>Positive, Non-transitive Disaggregation</name> <name>Positive, Non-Transitive Disaggregation</name>
<t>Under normal circumstances, a node's South TIEs contain <t>Under normal circumstances, a node's South TIEs contain
just the adjacencies and a default route. just the adjacencies and a default route.
However, if a node detects that its default IP However, if a node detects that its default IP
prefix covers one or more prefixes that are reachable prefix covers one or more prefixes that are reachable
through it but not through one or through it but not through one or
more other nodes at the same level, then it MUST more other nodes at the same level, then it <bcp14>MUST</bcp14>
explicitly advertise those prefixes in a explicitly advertise those prefixes in a
South TIE. Otherwise, some percentage of the northbound South TIE. Otherwise, some percentage of the northbound
traffic for those prefixes would traffic for those prefixes would
be sent to nodes without corresponding reachability, be sent to nodes without corresponding reachability,
causing it to be dropped. causing it to be dropped.
Even when traffic is not being dropped, the resulting forwarding Even when traffic is not being dropped, the resulting forwarding
could could
'backhaul' packets through the higher level spines, "backhaul" packets through the higher-level spines,
clearly an undesirable condition affecting clearly an undesirable condition affecting
the blocking probabilities of the fabric. the blocking probabilities of the fabric.
</t> </t>
<t>This specification refers to the process of advertising additional prefixes southbound <t>This specification refers to the process of advertising additional prefixes southbound
as 'positive disaggregation'. Such disaggregation as "positive disaggregation". Such disaggregation
is non-transitive, i.e., its effects are always constrained to a single level of is non-transitive, i.e., its effects are always constrained to a single level of
the fabric. Naturally, multiple node or link failures can lead to severa l the fabric. Naturally, multiple node or link failures can lead to severa l
independent instances of positive disaggregation necessary to prevent independent instances of positive disaggregation necessary to prevent
looping or bow-tying the fabric. looping or bow-tying the fabric.
</t> </t>
<t> <t>
A node determines the set of prefixes needing disaggregation A node determines the set of prefixes needing disaggregation
using the following steps: using the following steps:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>A DAG computation in the southern <li>A DAG computation in the southern
direction is performed first. The direction is performed first. The
North TIEs are used to find all of the prefixes North TIEs are used to find all of the prefixes
it can reach and the set of next-hops in it can reach and the set of next hops in
the lower level the lower level
for each of them. for each of them.
Such a computation can be Such a computation can be
easily performed on a Fat Tree by easily performed on a Fat Tree by
setting all link costs in the setting all link costs in the
southern direction to 1 and all southern direction to 1 and all
northern directions to infinity. We northern directions to infinity.
term set of those prefixes |R, and for each prefix, r,
in |R, The set of those prefixes is referred to as |R; for each prefix
its set of next-hops is defined to be |H(r). r in |R, its set of next hops is |H(r).
</li> </li>
<li> The node uses reflected South TIEs to find all nodes <li> The node uses reflected South TIEs to find all nodes
at the same level in the same PoD and the set of southbound at the same level in the same PoD and the set of southbound
adjacencies adjacencies
for each. The set of nodes at the same level is termed |N and f or each for each. The set of nodes at the same level is termed |N, and for each
node, n, in |N, node, n, in |N,
its set of southbound adjacencies is defined to be |A(n). its set of southbound adjacencies is defined to be |A(n).
</li> </li>
<li>For a given r, if the intersection <li>For a given r, if the intersection
of |H(r) and |A(n), for any n, is empty of |H(r) and |A(n), for any n, is empty,
then that prefix r must be then that prefix r must be
explicitly advertised by the node explicitly advertised by the node
in a South TIE. in a South TIE.
<!-- The set of reachable prefixes <!-- The set of reachable prefixes
advertised in North TIEs for which the set advertised in North TIEs for which the set
of possible next-hops is disjoint with of possible next-hops is disjoint with
any of the sets of adjacencies reachable by any of the sets of adjacencies reachable by
the other nodes are the disaggregated the other nodes are the disaggregated
prefixes. More formally, the set prefixes. More formally, the set
consists of all r in |R such that |H consists of all r in |R such that |H
of r is disjoint to |A for any N. --> of r is disjoint to |A for any N. -->
</li> </li>
<li>Identical set of disaggregated prefixes is flooded on each of th e <li>An identical set of disaggregated prefixes is flooded on each of the
node's southbound node's southbound
adjacencies. In accordance with the normal flooding rules for a South TIE, adjacencies. In accordance with the normal flooding rules for a South TIE,
a node at the lower level that a node at the lower level that
receives this South TIE SHOULD NOT propagate it south-bound or receives this South TIE <bcp14>SHOULD NOT</bcp14> propagate it s outhbound or
reflect the disaggregated prefixes reflect the disaggregated prefixes
back over its adjacencies to nodes at the level from which back over its adjacencies to nodes at the level from which
it was received. it was received.
</li> </li>
</ol> </ol>
<t>To summarize the above in simplest terms: if a node detects that it s <t>To summarize the above in simplest terms: If a node detects that it s
default route encompasses default route encompasses
prefixes for which one of the other nodes in its level has no prefixes for which one of the other nodes in its level has no
possible next-hops in the level below, possible next hops in the level below,
it has to disaggregate it to prevent traffic loss or suboptimal it has to disaggregate it to prevent traffic loss or suboptimal
routing through such nodes. Hence, routing through such nodes. Hence,
a node X needs to determine if it can a node X needs to determine if it can
reach a different set of south neighbors than other nodes at the reach a different set of south neighbors than other nodes at the
same level, which are connected to it via at least one common same level, which are connected to it via at least one common
south south
neighbor. If it can, then prefix disaggregation may be required. neighbor. If it can, then prefix disaggregation may be required.
If it can't, then no prefix disaggregation is needed. If it can't, then no prefix disaggregation is needed.
An example of disaggregation is provided in An example of disaggregation is provided in
<xref target="fabriccut" format="default"/>. <xref target="fabriccut" format="default"/>.
</t> </t>
<t>Finally, a possible <t>Finally, a possible
algorithm is described here:</t> algorithm is described here:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Create partial_neighbors = (empty), a set of neighbors with <li>Create partial_neighbors = (empty), a set of neighbors with
partial connectivity to the node X's level from X's perspective. partial connectivity to the node X's level from X's perspective.
Each entry in the set is a south neighbor of X and a list of nod es Each entry in the set is a south neighbor of X and a list of nod es
of X.level that can't reach that neighbor.</li> of X.level that can't reach that neighbor.</li>
<li>A node X determines its set of southbound neighbors <li>A node X determines its set of southbound neighbors
X.south_neighbors.</li> X.south_neighbors.</li>
<li>For each South TIE originated from a node Y that X has which is <li>For each South TIE originated from a node Y that X has, which is
at X.level, if Y.south_neighbors is not the same as at X.level, if Y.south_neighbors is not the same as
X.south_neighbors but the nodes share at least one X.south_neighbors but the nodes share at least one
southern neighbor, for each neighbor N in X.south_neighbors but southern neighbor, for each neighbor N in X.south_neighbors but
not in Y.south_neighbors, add (N, (Y)) to partial_neighbors if N not in Y.south_neighbors, add (N, (Y)) to partial_neighbors if N
isn't there or add Y to the list for N.</li> isn't there or add Y to the list for N.</li>
<li>If partial_neighbors is empty, then node X does not <li>If partial_neighbors is empty, then node X does not
disaggregate any prefixes. If node X is advertising disaggregat ed disaggregate any prefixes. If node X is advertising disaggregat ed
prefixes in its South TIE, X SHOULD remove them and re-advertise its prefixes in its South TIE, X <bcp14>SHOULD</bcp14> remove them a nd re-advertise its
South TIEs.</li> South TIEs.</li>
</ol> </ol>
<t>A node X computes reachability to all nodes below it <t>A node X computes reachability to all nodes below it
based upon the received North TIEs first. This based upon the received North TIEs first. This
results in a set of routes, each categorized by (prefix, results in a set of routes, each categorized by (prefix,
path_distance, next-hop set). Alternately, for clarity in the path_distance, next-hop set). Alternately, for clarity in the
following procedure, these can be organized by next-hop following procedure, these can be organized by a next-hop
set as ((next-hops), {(prefix, path_distance)}). If partial_neighbors i sn't set as ((next-hops), {(prefix, path_distance)}). If partial_neighbors i sn't
empty, then the procedure in <xref target="algo-disaggregated-prefixes"/ > describes how to identify empty, then the procedure in <xref target="algo-disaggregated-prefixes"/ > describes how to identify
prefixes to disaggregate.</t> prefixes to disaggregate.</t>
<!-- <!--
<t>It is worth to observe here that <t>It is worth to observe here that
this procedure only disaggregates prefixes when there this procedure only disaggregates prefixes when there
is a same-level node with no connectivity to any of the next-hop south is a same-level node with no connectivity to any of the next-hop south
neighbors. This obviously ignores concerns about load-balancing; one neighbors. This obviously ignores concerns about load-balancing; one
could also decide to advertise a disaggregated prefixes whenever a could also decide to advertise a disaggregated prefixes whenever a
same-level node lacks connectivity to at least one next-hop. To do same-level node lacks connectivity to at least one next-hop. To do
skipping to change at line 7780 skipping to change at line 7963
indicated. This has a trade-off of adding more flooding - prefixes indicated. This has a trade-off of adding more flooding - prefixes
would be disaggregated based on a single failure instead of when would be disaggregated based on a single failure instead of when
connectivity is lost - but should give better load-balancing. Of connectivity is lost - but should give better load-balancing. Of
course, instead of aggregate link bandwidth, one could use link count, course, instead of aggregate link bandwidth, one could use link count,
assuming all links in the fabric have the same bandwidth.</t> assuming all links in the fabric have the same bandwidth.</t>
--> -->
<figure anchor="algo-disaggregated-prefixes"> <figure anchor="algo-disaggregated-prefixes">
<name>Computation of Disaggregated Prefixes</name> <name>Computation of Disaggregated Prefixes</name>
<artset> <sourcecode type=""><![CDATA[
<artwork align="center" name="" type="ascii-art" originalSrc="art/ disaggregated_prefixes = { empty }
rift-rift-computation-disagg-pfx.ascii.art"> disaggregated_prefixes = nodes_same_level = { empty }
{ empty } for each South TIE
nodes_same_level = { empty } if (South TIE.level == X.level and
for each South TIE X shares at least one S-neighbor with X)
if (South TIE.level == X.level and add South TIE.originator to nodes_same_level
X shares at least one S-neighbor with X) end if
add South TIE.originator to nodes_same_level end for
end if
end for
for each next-hop-set NHS for each next-hop-set NHS
isolated_nodes = nodes_same_level isolated_nodes = nodes_same_level
for each NH in NHS for each NH in NHS
if NH in partial_neighbors if NH in partial_neighbors
isolated_nodes = isolated_nodes =
intersection(isolated_nodes, intersection(isolated_nodes,
partial_neighbors[NH].nodes) partial_neighbors[NH].nodes)
end if end if
end for end for
if isolated_nodes is not empty if isolated_nodes is not empty
for each prefix using NHS for each prefix using NHS
add (prefix, distance) to disaggregated_prefixes add (prefix, distance) to disaggregated_prefixes
end for end for
end if end if
end for end for
copy disaggregated_prefixes to X's South TIE copy disaggregated_prefixes to X's South TIE
if X's South TIE is different if X's South TIE is different
schedule South TIE for flooding schedule South TIE for flooding
end if</artwork> end if]]></sourcecode>
</artset>
</figure> </figure>
<t>Each disaggregated prefix is sent with the corresponding path_dista nce. <t>Each disaggregated prefix is sent with the corresponding path_dista nce.
This allows a node to send the same South TIE to each south neighbor. This allows a node to send the same South TIE to each south neighbor.
The south neighbor which is connected to that prefix will thus have a The south neighbor that is connected to that prefix will thus have a
shorter path.</t> shorter path.</t>
<t>Finally, to summarize the less obvious points partially omitted in the <t>Finally, to summarize the less obvious points partially omitted in the
algorithms to keep them more tractable: algorithms to keep them more tractable:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>all neighbor relationships MUST perform backlink checks. <li>All neighbor relationships <bcp14>MUST</bcp14> perform backlin k checks.
</li> </li>
<li>overload flag <li>The overload flag
as introduced in <xref target="overload" format="default"/> as introduced in <xref target="overload" format="default"/>
and carried in the <em>overload</em> schema element and carried in the <em>overload</em> schema element
have to has to
be respected during the computation. Nodes advertising be respected during the computation. Nodes advertising
themselves as overloaded MUST NOT be transited in reachability themselves as overloaded <bcp14>MUST NOT</bcp14> be transited in
computation but MUST be used as terminal nodes with reachability
computation but <bcp14>MUST</bcp14> be used as terminal nodes wi
th
prefixes they advertise being reachable. prefixes they advertise being reachable.
</li> </li>
<li>all the lower-level nodes are flooded the same disaggregated <li>All the lower-level nodes are flooded to the same disaggregated
prefixes since RIFT does not build a South TIE per node which wo prefixes since RIFT does not build a South TIE per node, which w
uld ould
complicate things unnecessarily. The lower-level node complicate things unnecessarily. The lower-level node
that can compute a southbound route to the prefix that can compute a southbound route to the prefix
will prefer it to the disaggregated route anyway based on will prefer it to the disaggregated route anyway based on
route preference rules.</li> route preference rules.</li>
<li>positively disaggregated prefixes <li>Positively disaggregated prefixes
do <strong>not</strong> have to propagate to lower levels. With do <strong>not</strong> have to propagate to lower levels. With
that the that, the
disturbance in terms of new flooding is contained to a single disturbance in terms of new flooding is contained to a single
level experiencing failures.</li> level experiencing failures.</li>
<li>disaggregated Prefix South TIEs are not "reflected" by the <li>Disaggregated Prefix South TIEs are not "reflected" by the
lower level. lower level.
Nodes within same level do <strong>not</strong> need to be aware which node Nodes within the same level do <strong>not</strong> need to be a ware of which node
computed the need for disaggregation. computed the need for disaggregation.
</li> </li>
<li>The fabric is still <li>The fabric is still
supporting maximum load balancing properties while not trying supporting maximum load balancing properties while not trying
to send traffic northbound unless to send traffic northbound unless
necessary. </li> necessary. </li>
</ol> </ol>
<t>In case positive disaggregation is triggered and due to the very st able but <t>In case positive disaggregation is triggered and due to the very st able but
un-synchronized nature of the algorithm the nodes may issue the necessar y unsynchronized nature of the algorithm, the nodes may issue the necessar y
disaggregated disaggregated
prefixes at different points in time. This can lead for a short prefixes at different points in time. For a short
time to an "incast" behavior where the first advertising router based on time, this can lead to an "incast" behavior where the first advertising
the router based on the
nature of longest prefix match will attract all the traffic. Different i nature of the longest prefix match will attract all the traffic. Differe
mplementation nt implementation
strategies can be used to lessen that effect, but those are outside strategies can be used to lessen that effect, but those are outside
the scope of this specification. the scope of this specification.
</t> </t>
<t> <t>
It is worth observing that, in a single plane ToF, It is worth observing that, in a single plane ToF,
this disaggregation prevents traffic loss up to (K_LEAF * P) link failur es in terms of this disaggregation prevents traffic loss up to (K_LEAF * P) link failur es in terms of
<xref target="Planes" format="default"/> or, in other terms, it takes at minimum that many <xref target="Planes" format="default"/> or, in other terms, it takes at minimum that many
link failures to partition the ToF into multiple planes. link failures to partition the ToF into multiple planes.
</t> </t>
</section> </section>
<!-- positive disaggregation --> <!-- positive disaggregation -->
<section anchor="negdisaggreg" numbered="true" toc="default"> <section anchor="negdisaggreg" numbered="true" toc="default">
<name>Negative, Transitive Disaggregation for Fallen Leaves</name> <name>Negative, Transitive Disaggregation for Fallen Leaves</name>
<t>As explained in <xref target="Fallen" format="default"/> failures i n multi-plane ToF or <t>As explained in <xref target="Fallen" format="default"/>, failures in multi-plane ToF or
more than (K_LEAF * P) links failing in single plane design can generate fallen leaves. more than (K_LEAF * P) links failing in single plane design can generate fallen leaves.
Such scenario cannot be addressed by positive disaggregation Such scenario cannot be addressed by positive disaggregation
only and needs a further mechanism. only and needs a further mechanism.
</t> </t>
<section numbered="true" toc="default" anchor="cable_tof_sec"> <section numbered="true" toc="default" anchor="cable_tof_sec">
<name>Cabling of Multiple ToF Planes</name> <name>Cabling of Multiple ToF Planes</name>
<t>Returning in this section to designs with multiple planes as show n originally in <t>Returning in this section to designs with multiple planes as show n originally in
<xref target="partitioned-spine" format="default"/>, <xref target="partition -one-area-cabling" format="default"/> highlights <xref target="partitioned-spine" format="default"/>, <xref target="partition -one-area-cabling" format="default"/> highlights
how the ToF is cabled in case of two planes how the ToF is cabled in case of two planes
by the means of dual-rings to distribute all the North TIEs within both planes. by the means of dual-rings to distribute all the North TIEs within both planes.
skipping to change at line 8018 skipping to change at line 8201
| || || . || || . || || . || || | | || || . || || . || || . || || |
| || || . || || . || || . || || |</ artwork> | || || . || || . || || . || || |</ artwork>
</artset> </artset>
</figure> </figure>
<!-- describe the negative disaggregation computation [i.e. all node s <!-- describe the negative disaggregation computation [i.e. all node s
not on SPF & having some kind of southbound from other nodes in TDB ] --> not on SPF & having some kind of southbound from other nodes in TDB ] -->
<t> <t>
<xref target="Fallen" format="default"/> already describes how failures in m ulti-plane fabrics <xref target="Fallen" format="default"/> already describes how failures in m ulti-plane fabrics
can lead to traffic loss that normal positive disaggregation cannot fix. can lead to traffic loss that normal positive disaggregation cannot fix.
The mechanism of negative, transitive disaggregation incorporated in RIFT The mechanism of negative, transitive disaggregation incorporated in RIFT
provides the corresponding solution and next section explains the involv ed provides the corresponding solution, and the next section explains the i nvolved
mechanisms in more detail. mechanisms in more detail.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="neg_advertise_sec"> <section numbered="true" toc="default" anchor="neg_advertise_sec">
<name>Transitive Advertisement of Negative Disaggregates</name> <name>Transitive Advertisement of Negative Disaggregates</name>
<!-- describe the negative disaggregation transitive behavior, i.e. <!-- describe the negative disaggregation transitive behavior, i.e.
suppression until one northbound provided a negative --> suppression until one northbound provided a negative -->
<t> <t>
A ToF node discovering that it cannot reach a fallen leaf SHOULD disaggregat e A ToF node discovering that it cannot reach a fallen leaf <bcp14>SHOULD</bcp 14> disaggregate
all the prefixes of that leaf. all the prefixes of that leaf.
It uses for that purpose negative prefix South TIEs that are, as usual, For that purpose, it uses negative prefix South TIEs that are, as usual,
flooded southwards with the flooded southwards with the
scope defined in <xref target="tiescopes" format="default"/>. scope defined in <xref target="tiescopes" format="default"/>.
</t> </t>
<t> <t>
Transitively, a node explicitly loses connectivity to a prefix when Transitively, a node explicitly loses connectivity to a prefix when
none of its children advertises it none of its children advertises it
and when the prefix is negatively disaggregated by all of its parents. When and when the prefix is negatively disaggregated by all of its parents. When
that happens, the node originates the negative prefix further down south. that happens, the node originates the negative prefix further down south.
Since the mechanism applies recursively south Since the mechanism applies recursively south,
the negative prefix may propagate transitively all the way down to the leaf. This is necessary the negative prefix may propagate transitively all the way down to the leaf. This is necessary
since leaves connected to multiple planes by means of disjointed paths m ay have to choose since leaves connected to multiple planes by means of disjointed paths m ay have to choose
the correct plane at the very bottom of the fabric to make sure that the y the correct plane at the very bottom of the fabric to make sure that the y
don't send traffic towards another leaf using a plane where it is "falle n" which would don't send traffic towards another leaf using a plane where it is "falle n", which would
make traffic loss unavoidable. make traffic loss unavoidable.
</t> </t>
<t> <t>
When connectivity is restored, a node that disaggregated a prefix When connectivity is restored, a node that disaggregated a prefix
withdraws the negative disaggregation by the usual mechanism of withdraws the negative disaggregation by the usual mechanism of
re-advertising TIEs omitting the negative prefix. re-advertising TIEs omitting the negative prefix.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="neg_dis_computation_sec "> <section numbered="true" toc="default" anchor="neg_dis_computation_sec ">
<name>Computation of Negative Disaggregates</name> <name>Computation of Negative Disaggregates</name>
<t> <t>
Negative prefixes can in fact be advertised due Negative prefixes can in fact be advertised due
to two different triggers. This will be described consecutively. to two different triggers. This will be described consecutively.
</t> </t>
<t>The first origination reason is a computation that uses all the n ode North TIEs to build <t>The first origination reason is a computation that uses all the n ode North TIEs to build
the set of all reachable nodes by reachability computation over the comp the set of all reachable nodes by reachability computation over the comp
lete graph lete graph,
and including horizontal ToF links. The including horizontal ToF links. The
computation uses the node itself as root. This is compared with the resu computation uses the node itself as the root. This is compared with the
lt of the normal result of the normal
southbound SPF as described in <xref target="sspf" format="default"/ southbound SPF as described in <xref target="sspf" format="default"/
>. The difference are the fallen >. The differences are the fallen
leaves and all their attached prefixes are advertised as negative pr efixes southbound leaves and all their attached prefixes are advertised as negative pr efixes southbound
if the node does not consider the prefix to be reachable within the southbound SPF. if the node does not consider the prefix to be reachable within the southbound SPF.
</t> </t>
<t> <t>
The second origination reason hinges on the understanding how the ne gative prefixes are used The second origination reason hinges on the understanding of how the negative prefixes are used
within the computation as described in <xref target="algo-attach-s-t ie-prefixes" format="default"/>. within the computation as described in <xref target="algo-attach-s-t ie-prefixes" format="default"/>.
When attaching the negative prefixes at a certain point in time the When attaching the negative prefixes at a certain point in time, the
negative prefix negative prefix
may find itself with all the viable nodes from the shorter match nex may find itself with all the viable nodes from the shorter match nex
thop being t hop being
pruned. In other words, all its northbound neighbors provided a nega tive prefix pruned. In other words, all its northbound neighbors provided a nega tive prefix
advertisement. This is the trigger to advertise this negative prefix transitively advertisement. This is the trigger to advertise this negative prefix transitively
south and is normally caused by the node being in a plane where the prefix south and is normally caused by the node being in a plane where the prefix
belongs to a fabric leaf that has "fallen" in this plane. Obviously, when one of belongs to a fabric leaf that has "fallen" in this plane. Obviously, when one of
the northbound switches withdraws its negative advertisement, the no de has to the northbound switches withdraws its negative advertisement, the no de has to
withdraw its transitively provided negative prefix as well. withdraw its transitively provided negative prefix as well.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<!-- disaggregation --> <!-- disaggregation -->
<section anchor="sec_attaching_prefixes" numbered="true" toc="default"> <section anchor="sec_attaching_prefixes" numbered="true" toc="default">
<name>Attaching Prefixes</name> <name>Attaching Prefixes</name>
<t>After an SPF is run, it is necessary to attach the resulting reachabi lity information <t>After an SPF is run, it is necessary to attach the resulting reachabi lity information
in form of prefixes. in the form of prefixes.
For S-SPF, prefixes from a North TIE are attached to the originating nod e with For S-SPF, prefixes from a North TIE are attached to the originating nod e with
that node's next-hop set and a distance equal to the prefix's cost that node's next-hop set and a distance equal to the prefix's cost
plus the node's minimized path distance. The RIFT route database, a plus the node's minimized path distance. The RIFT route database, a
set of (prefix, prefix-type, attributes, path_distance, next-hop set), a ccumulates set of (prefix, prefix-type, attributes, path_distance, next-hop set), a ccumulates
these results.</t> these results.</t>
<t>N-SPF prefixes from each South TIE need to also be added to the RIFT <t>N-SPF prefixes from each South TIE need to also be added to the RIFT
route database. The N-SPF is really just a stub so the route database. The N-SPF is really just a stub so the
computing node needs simply to determine, for each prefix in a South TIE computing node simply needs to determine, for each prefix in a South TIE
that originated from adjacent node, what next-hops to use to reach that originated from adjacent node, what next hops to use to reach
that node. Since there may be parallel links, the next-hops to that node. Since there may be parallel links, the next hops to
use can be a set; presence of the computing node in the associated use can be a set; the presence of the computing node in the associated
Node South TIE is sufficient to verify that at least one link has Node South TIE is sufficient to verify that at least one link has
bidirectional connectivity. The set of minimum cost next-hops bidirectional connectivity. The set of minimum cost next hops
from the computing node X to the originating adjacent node is determined. </ t> from the computing node X to the originating adjacent node is determined. </ t>
<t>Each prefix has its cost adjusted before being added into the <t>Each prefix has its cost adjusted before being added into the
RIFT route database. The cost of the prefix is set to the cost RIFT route database. The cost of the prefix is set to the cost
received plus the cost of the minimum distance next-hop to that received plus the cost of the minimum distance next hop to that
neighbor while considering its attributes such as mobility neighbor while considering its attributes such as mobility
per <xref target="mobility" format="default"/>. Then each prefix can be add ed into the RIFT route per <xref target="mobility" format="default"/>. Then each prefix can be add ed into the RIFT route
database with the next-hop set; ties are broken based upon database with the next-hop set; ties are broken based upon
type first and then distance and further on <em>PrefixAttributes</em>. Only the best type first and then distance and further on <em>PrefixAttributes</em>. Only the best
combination is used for forwarding. combination is used for forwarding.
RIFT route preferences are normalized RIFT route preferences are normalized
by the enum <em>RouteType</em> in <xref target="thrift" format="default">Thr ift</xref> model by the enum <em>RouteType</em> in the <xref target="thrift" format="default" >Thrift</xref> model
given in <xref target="schema"/>.</t> given in <xref target="schema"/>.</t>
<t>An example implementation for node X follows: <t>An example implementation for node X follows:
</t> </t>
<figure anchor="algo-attach-s-tie-prefixes"> <figure anchor="algo-attach-s-tie-prefixes">
<name>Adding Routes from South TIE Positive and Negative Prefixes</nam e> <name>Adding Routes from South TIE Positive and Negative Prefixes</nam e>
<artset> <sourcecode type=""><![CDATA[
<artwork align="center" name="" type="ascii-art" originalSrc="art/ri for each South TIE
ft-rift-add-routes-s-tie-pos-neg-pfx.ascii-art"> for each South TIE if South TIE.level > X.level
if South TIE.level &gt; X.level
next_hop_set = set of minimum cost links to the next_hop_set = set of minimum cost links to the
South TIE.originator South TIE.originator
next_hop_cost = minimum cost link to next_hop_cost = minimum cost link to
South TIE.originator South TIE.originator
end if end if
for each prefix P in the South TIE for each prefix P in the South TIE
P.cost = P.cost + next_hop_cost P.cost = P.cost + next_hop_cost
if P not in route_database: if P not in route_database:
add (P, P.cost, P.type, add (P, P.cost, P.type,
P.attributes, next_hop_set) to route_database P.attributes, next_hop_set) to route_database
end if end if
if (P in route_database): if (P in route_database):
if route_database[P].cost &gt; P.cost or if route_database[P].cost > P.cost or
route_database[P].type &gt; P.type: route_database[P].type > P.type:
update route_database[P] with (P, P.type, P.cost, update route_database[P] with (P, P.type, P.cost,
P.attributes, P.attributes,
next_hop_set) next_hop_set)
else if route_database[P].cost == P.cost and else if route_database[P].cost == P.cost and
route_database[P].type == P.type: route_database[P].type == P.type:
update route_database[P] with (P, P.type, update route_database[P] with (P, P.type,
P.cost, P.attributes, P.cost, P.attributes,
merge(next_hop_set, route_database[P].next_hop_set)) merge(next_hop_set, route_database[P].next_hop_set))
else else
// Not preferred route so ignore // Not preferred route so ignore
end if end if
end if end if
end for end for
end for</artwork> end for]]></sourcecode>
</artset>
</figure> </figure>
<t> <t>
After the positive prefixes are attached and tie-broken, negative prefix es are attached and After the positive prefixes are attached and tie-broken, negative prefix es are attached and
used in case of northbound computation, ideally from the shortest length to the longest. used in case of northbound computation, ideally from the shortest length to the longest.
The nexthop adjacencies for a negative prefix are inherited from the lon
gest positive prefix that <!--[rfced] We are having difficulty understanding "subsequently adjacencies
to nodes that advertised..." How may we update for clarity?
Original:
The nexthop
adjacencies for a negative prefix are inherited from the longest
positive prefix that aggregates it, and subsequently adjacencies to
nodes that advertised negative for this prefix are removed.
Option A:
The next-hop
adjacencies for a negative prefix are inherited from the longest
positive prefix that aggregates it; subsequently, adjacencies to
nodes that negatively advertised for this prefix are removed.
Option B: [if the intended meaning is 'as a result' rather than 'afterward']
The next-hop
adjacencies for a negative prefix are inherited from the longest
positive prefix that aggregates it; as a result, adjacencies to
nodes that negatively advertised for this prefix are removed.
-->
The next-hop adjacencies for a negative prefix are inherited from the lo
ngest positive prefix that
aggregates it, and subsequently adjacencies to nodes that advertised neg ative for aggregates it, and subsequently adjacencies to nodes that advertised neg ative for
this prefix are removed. this prefix are removed.
<!-- <!--
As an example, if a As an example, if a
hypothetical RIFT routing table contains A.1/16 @ [A,B], A.1.1/24 @ [C,D ] it will hypothetical RIFT routing table contains A.1/16 @ [A,B], A.1.1/24 @ [C,D ] it will
on reception of negative A.1.1.1/32 on reception of negative A.1.1.1/32
from D from D
include the entry A.1.1.1/32 @ [C] resulting from computation inheriting A.1.1/24 include the entry A.1.1.1/32 @ [C] resulting from computation inheriting A.1.1/24
nexthops (C and D) and pruning all nexthops (C and D) and pruning all
the nodes that advertised this negative prefix (which is D in this case) . the nodes that advertised this negative prefix (which is D in this case) .
--> -->
</t> </t>
<t>The rule of inheritance MUST be maintained when the nexthop list for a prefix is <t>The rule of inheritance <bcp14>MUST</bcp14> be maintained when the ne xt-hop list for a prefix is
modified, as the modified, as the
modification may affect the entries for matching negative prefixes of imm ediate modification may affect the entries for matching negative prefixes of imm ediate
longer prefix length. longer prefix length.
For instance, if a nexthop is added, then by inheritance it must be added to all For instance, if a next hop is added, then by inheritance, it must be add ed to all
the negative routes the negative routes
of immediate longer prefixes length unless it is pruned due to a negative of immediate longer prefixes length unless it is pruned due to a negative
advertisement for the same advertisement for the same
next hop. Similarly, if a nexthop is deleted for a given prefix, then it is next hop. Similarly, if a next hop is deleted for a given prefix, then it is
deleted for all the deleted for all the
immediately aggregated negative routes. This will recurse in the case of immediately aggregated negative routes. This will recurse in the case of
nested negative prefix nested negative prefix
aggregations. aggregations.
</t> </t>
<t> <t>
The rule of inheritance MUST also be maintained when a new prefix of inte rmediate length is inserted, The rule of inheritance <bcp14>MUST</bcp14> also be maintained when a new prefix of intermediate length is inserted
or when the immediately aggregating prefix is deleted from the routing ta ble, making an even shorter or when the immediately aggregating prefix is deleted from the routing ta ble, making an even shorter
aggregating prefix the one from which the negative routes now inherit the ir adjacencies. As the aggregating prefix the one from which the negative routes now inherit the ir adjacencies. As the
aggregating prefix changes, all the negative routes MUST be recomputed, a nd then again the process aggregating prefix changes, all the negative routes <bcp14>MUST</bcp14> b e recomputed, and then again, the process
may recurse in case of nested negative prefix aggregations. may recurse in case of nested negative prefix aggregations.
</t> </t>
<t> <t>
Although these operations can be computationally expensive, the overall Although these operations can be computationally expensive, the overall
load on devices in the network is low because these computations are not run load on devices in the network is low because these computations are not run
very often, as positive route advertisements are always preferred over n egative ones. very often, as positive route advertisements are always preferred over n egative ones.
This prevents recursion in most cases because positive reachability info rmation never This prevents recursion in most cases because positive reachability info rmation never
inherits next hops.</t> inherits next hops.</t>
<t>To make the negative disaggregation less abstract and provide an exam ple <t>To make the negative disaggregation less abstract and provide an exam ple
ToP node T1 with 4 ToF parents S1..S4 as ToP node, T1 with 4 ToF parents S1..S4 as
represented in <xref target="negdis1" format="default"/> are considered furt her: represented in <xref target="negdis1" format="default"/> are considered furt her:
</t> </t>
<figure anchor="negdis1"> <figure anchor="negdis1">
<name>A ToP Node with 4 Parents</name> <name>A ToP Node with 4 Parents</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-top-node-4-parents.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net/D TD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/2 2-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http:// www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www. w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 14 44.2 387.2" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-top-node-4-parents.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net/D TD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/2 2-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http:// www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www. w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 14 44.2 387.2" xml:space="preserve">
<line fill="#FFFFFF" stroke="#000000" stroke-miterlimit="10" x1= "57.5" y1="113.8" x2="313.2" y2="286.6"/> <line fill="#FFFFFF" stroke="#000000" stroke-miterlimit="10" x1= "57.5" y1="113.8" x2="313.2" y2="286.6"/>
<line fill="#FFFFFF" stroke="#000000" stroke-miterlimit="10" x1= "227.6" y1="113.8" x2="313.2" y2="286.6"/> <line fill="#FFFFFF" stroke="#000000" stroke-miterlimit="10" x1= "227.6" y1="113.8" x2="313.2" y2="286.6"/>
<line fill="#FFFFFF" stroke="#000000" stroke-miterlimit="10" x1= "398.1" y1="113.8" x2="313.2" y2="286.6"/> <line fill="#FFFFFF" stroke="#000000" stroke-miterlimit="10" x1= "398.1" y1="113.8" x2="313.2" y2="286.6"/>
<line fill="#FFFFFF" stroke="#000000" stroke-miterlimit="10" x1= "570.9" y1="113.8" x2="313.2" y2="286.6"/> <line fill="#FFFFFF" stroke="#000000" stroke-miterlimit="10" x1= "570.9" y1="113.8" x2="313.2" y2="286.6"/>
skipping to change at line 8251 skipping to change at line 8456
| | | | v | | | | v
|+--------+ | | S |+--------+ | | S
||+-----------------+ | ||+-----------------+ |
|||+----------------+---------+ |||+----------------+---------+
|||| ||||
+----+ +----+
| T1 | | T1 |
+----+</artwork> +----+</artwork>
</artset> </artset>
</figure> </figure>
<t>If all ToF nodes can reach all the prefixes in the network; with <t>If all ToF nodes can reach all the prefixes in the network, with
RIFT, they will normally advertise a default route south. RIFT, they will normally advertise a default route south.
An abstract Routing Information Base (RIB), more commonly known as a routing table, An abstract Routing Information Base (RIB), more commonly known as a routing table,
stores all types of maintained routes stores all types of maintained routes,
including the negative ones and "tie-breaks" for the best one, including the negative ones and "tie-breaks" for the best one,
whereas an abstract Forwarding table (FIB) whereas an abstract forwarding table (FIB)
retains only the ultimately computed "positive" routing instructions. retains only the ultimately computed "positive" routing instructions.
In T1, those tables would look as illustrated in <xref target="rib1" format= "default"/>: In T1, those tables would look as illustrated in <xref target="rib1" format= "default"/>:
</t> </t>
<figure anchor="rib1"> <figure anchor="rib1">
<name>Abstract RIB</name> <name>Abstract RIB</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-rib.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sod ipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns: cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf- syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http://www.w3 .org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org /1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 1444.2 7 79.7" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-rib.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sod ipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xmlns: cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf- syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http://www.w3 .org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org /1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 1444.2 7 79.7" xml:space="preserve">
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path1759" fill-rule="evenodd" stroke="#000000" stroke- width="0.5966" stroke-linejoin="round" stroke-miterlimit="3.8185" d=" M183.9,20 7.7l10.4,3.8l-10.4,3.8C185.6,213.1,185.6,210,183.9,207.7z"/> <path id="path1759" fill-rule="evenodd" stroke="#000000" stroke- width="0.5966" stroke-linejoin="round" stroke-miterlimit="3.8185" d=" M183.9,20 7.7l10.4,3.8l-10.4,3.8C185.6,213.1,185.6,210,183.9,207.7z"/>
<path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M178.7,859.8"/> <path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M178.7,859.8"/>
skipping to change at line 8338 skipping to change at line 8543
+---&gt; | Via S3 | +---&gt; | Via S3 |
| +--------+ | +--------+
| |
| +--------+ | +--------+
+---&gt; | Via S4 | +---&gt; | Via S4 |
+--------+</artwork> +--------+</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
In case T1 receives a negative advertisement for prefix 2001:db8::/32 from In case T1 receives a negative advertisement for prefix 2001:db8::/32 from
S1 a negative route is stored in the RIB (indicated by a ~ sign), while the S1, a negative route is stored in the RIB (indicated by a "~" sign), while t he
more specific routes to the complementing ToF nodes are installed in FIB. more specific routes to the complementing ToF nodes are installed in FIB.
RIB and FIB in T1 now look as illustrated in <xref target="rib1.1" format="d RIB and FIB in T1 now look as illustrated in Figures <xref target="rib1.1" f
efault"/> and ormat="counter"/> and
<xref target="fib1.1" format="default"/>, respectively: <xref target="fib1.1" format="counter"/>, respectively:
</t> </t>
<figure anchor="rib1.1"> <figure anchor="rib1.1">
<name>Abstract RIB after Negative 2001:db8::/32 from S1</name> <name>Abstract RIB After Negative 2001:db8::/32 from S1</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-rib-negative-s1.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge .net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inks cape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/199 9/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="h ttp://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http: //www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox=" 0 0 1444.2 779.7" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-rib-negative-s1.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge .net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inks cape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/199 9/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="h ttp://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http: //www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox=" 0 0 1444.2 779.7" xml:space="preserve">
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path2323" fill-rule="evenodd" stroke="#000000" stroke- width="0.5966" stroke-linejoin="round" stroke-miterlimit="3.8185" d=" M183.9,20 7.7l10.4,3.8l-10.4,3.8C185.6,213.1,185.6,210,183.9,207.7z"/> <path id="path2323" fill-rule="evenodd" stroke="#000000" stroke- width="0.5966" stroke-linejoin="round" stroke-miterlimit="3.8185" d=" M183.9,20 7.7l10.4,3.8l-10.4,3.8C185.6,213.1,185.6,210,183.9,207.7z"/>
<path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M178.7,859.8"/> <path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M178.7,859.8"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path1589" fill-rule="evenodd" stroke="#000000" stroke- width="0.6017" stroke-linejoin="round" stroke-miterlimit="3.8511" d=" M183.8,37 8.1l10.5,3.9l-10.5,3.9C185.5,383.6,185.5,380.4,183.8,378.1z"/> <path id="path1589" fill-rule="evenodd" stroke="#000000" stroke- width="0.6017" stroke-linejoin="round" stroke-miterlimit="3.8511" d=" M183.8,37 8.1l10.5,3.9l-10.5,3.9C185.5,383.6,185.5,380.4,183.8,378.1z"/>
<path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M178.7,689.4"/> <path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M178.7,689.4"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path1824" fill-rule="evenodd" stroke="#000000" stroke- width="0.6074" stroke-linejoin="round" stroke-miterlimit="3.8873" d=" M183.8,54 8.5l10.6,3.9l-10.6,3.9C185.5,554,185.5,550.9,183.8,548.5z"/> <path id="path1824" fill-rule="evenodd" stroke="#000000" stroke- width="0.6074" stroke-linejoin="round" stroke-miterlimit="3.8873" d=" M183.8,54 8.5l10.6,3.9l-10.6,3.9C185.5,554,185.5,550.9,183.8,548.5z"/>
skipping to change at line 8450 skipping to change at line 8655
| +--------+ | +--------+
+---&gt; | Via S3 | +---&gt; | Via S3 |
| +--------+ | +--------+
| |
| +--------+ | +--------+
+---&gt; | Via S4 | +---&gt; | Via S4 |
+--------+</artwork> +--------+</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
The negative 2001:db8::/32 prefix entry inherits from ::/0, so the positive The negative 2001:db8::/32 prefix entry inherits from ::/0, so the positive
more specific , more specific
routes are the complements to S1 in the set of next-hops for the default routes are the complements to S1 in the set of next hops for the default
route. That entry is composed of S2, S3, and S4, or, in other words, it use route. That entry is composed of S2, S3, and S4, or in other words, it uses
s
all entries in all entries in
the default route with a "hole punched" for S1 into them. the default route with a "hole punched" for S1 into them.
These are the next hops that are still available to reach 2001:db8::/32, These are the next hops that are still available to reach 2001:db8::/32
now that S1 advertised that it will not forward 2001:db8::/32 anymore. now that S1 advertised that it will not forward 2001:db8::/32 anymore.
Ultimately, those resulting next-hops are installed in Ultimately, those resulting next hops are installed in
FIB for the more specific route to 2001:db8::/32 as illustrated below: FIB for the more specific route to 2001:db8::/32 as illustrated below:
</t> </t>
<figure anchor="fib1.1"> <figure anchor="fib1.1">
<name>Abstract FIB after Negative 2001:db8::/32 from S1</name> <name>Abstract FIB After Negative 2001:db8::/32 from S1</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-fib-negative-s1.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge .net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inks cape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/199 9/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="h ttp://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http: //www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox=" 0 0 1444.2 734.1" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-fib-negative-s1.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge .net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inks cape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/199 9/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="h ttp://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http: //www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox=" 0 0 1444.2 734.1" xml:space="preserve">
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path2821" fill-rule="evenodd" stroke="#000000" stroke- width="0.5617" stroke-linejoin="round" stroke-miterlimit="3.5949" d=" M173.2,19 5.6l9.8,3.6l-9.8,3.6C174.7,200.6,174.7,197.7,173.2,195.6z"/> <path id="path2821" fill-rule="evenodd" stroke="#000000" stroke- width="0.5617" stroke-linejoin="round" stroke-miterlimit="3.5949" d=" M173.2,19 5.6l9.8,3.6l-9.8,3.6C174.7,200.6,174.7,197.7,173.2,195.6z"/>
<path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,872.2"/> <path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,872.2"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path2831" fill-rule="evenodd" stroke="#000000" stroke- width="0.5665" stroke-linejoin="round" stroke-miterlimit="3.6256" d=" M173.1,35 6l9.9,3.6l-9.9,3.6C174.6,361.1,174.6,358.2,173.1,356z"/> <path id="path2831" fill-rule="evenodd" stroke="#000000" stroke- width="0.5665" stroke-linejoin="round" stroke-miterlimit="3.6256" d=" M173.1,35 6l9.9,3.6l-9.9,3.6C174.6,361.1,174.6,358.2,173.1,356z"/>
<path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,711.8"/> <path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,711.8"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path1466" fill-rule="evenodd" stroke="#000000" stroke- width="0.5718" stroke-linejoin="round" stroke-miterlimit="3.6597" d=" M173,516. 4l10,3.7l-10,3.7C174.6,521.6,174.6,518.6,173,516.4z"/> <path id="path1466" fill-rule="evenodd" stroke="#000000" stroke- width="0.5718" stroke-linejoin="round" stroke-miterlimit="3.6597" d=" M173,516. 4l10,3.7l-10,3.7C174.6,521.6,174.6,518.6,173,516.4z"/>
skipping to change at line 8582 skipping to change at line 8787
| +--------+ | +--------+ | +--------+ | +--------+
+---&gt; | Via S3 | +---&gt; | Via S3 | +---&gt; | Via S3 | +---&gt; | Via S3 |
| +--------+ | +--------+ | +--------+ | +--------+
| | | |
| +--------+ | +--------+ | +--------+ | +--------+
+---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 |
+--------+ +--------+</artwork> +--------+ +--------+</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
To illustrate matters further consider T1 receiving a negative advertisement To illustrate matters further, consider T1 receiving a negative advertisemen t
for prefix 2001:db8:1::/48 for prefix 2001:db8:1::/48
from S2, which is stored in RIB again. After the update, the RIB in T1 is from S2, which is stored in RIB again. After the update, the RIB in T1 is
illustrated in <xref target="rib1.2" format="default"/>: illustrated in <xref target="rib1.2" format="default"/>:
</t> </t>
<figure anchor="rib1.2"> <figure anchor="rib1.2">
<name>Abstract RIB after Negative 2001:db8:1::/48 from S2</name> <name>Abstract RIB After Negative 2001:db8:1::/48 from S2</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-rib-negative-s1-s2.svg"><svg xmlns:sodipodi="http://sodipodi.sourcefo rge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/i nkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/ 1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg ="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="ht tp://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBo x="0 0 1444.2 734.1" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-rib-negative-s1-s2.svg"><svg xmlns:sodipodi="http://sodipodi.sourcefo rge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/i nkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/ 1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg ="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="ht tp://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBo x="0 0 1444.2 734.1" xml:space="preserve">
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path2466" fill-rule="evenodd" stroke="#000000" stroke- width="0.561" stroke-linejoin="round" stroke-miterlimit="3.5902" d=" M172.9,195 .3l9.8,3.6l-9.8,3.6C174.5,200.4,174.5,197.5,172.9,195.3z"/> <path id="path2466" fill-rule="evenodd" stroke="#000000" stroke- width="0.561" stroke-linejoin="round" stroke-miterlimit="3.5902" d=" M172.9,195 .3l9.8,3.6l-9.8,3.6C174.5,200.4,174.5,197.5,172.9,195.3z"/>
<path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.2,872.5"/> <path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.2,872.5"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path2725" fill-rule="evenodd" stroke="#000000" stroke- width="0.5658" stroke-linejoin="round" stroke-miterlimit="3.6208" d=" M172.8,35 5.5l9.9,3.6l-9.9,3.6C174.4,360.6,174.4,357.7,172.8,355.5z"/> <path id="path2725" fill-rule="evenodd" stroke="#000000" stroke- width="0.5658" stroke-linejoin="round" stroke-miterlimit="3.6208" d=" M172.8,35 5.5l9.9,3.6l-9.9,3.6C174.4,360.6,174.4,357.7,172.8,355.5z"/>
<path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.1,712.3"/> <path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.1,712.3"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path2990" fill-rule="evenodd" stroke="#000000" stroke- width="0.5711" stroke-linejoin="round" stroke-miterlimit="3.6549" d=" M172.8,51 5.7l10,3.7l-10,3.7C174.4,520.9,174.4,518,172.8,515.7z"/> <path id="path2990" fill-rule="evenodd" stroke="#000000" stroke- width="0.5711" stroke-linejoin="round" stroke-miterlimit="3.6549" d=" M172.8,51 5.7l10,3.7l-10,3.7C174.4,520.9,174.4,518,172.8,515.7z"/>
skipping to change at line 8725 skipping to change at line 8930
| +--------+ | +--------+
+---&gt; | Via S3 | +---&gt; | Via S3 |
| +--------+ | +--------+
| |
| +--------+ | +--------+
+---&gt; | Via S4 | +---&gt; | Via S4 |
+--------+</artwork> +--------+</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
Negative 2001:db8:1::/48 inherits from 2001:db8::/32 now, so the positive mo re Negative 2001:db8:1::/48 inherits from 2001:db8::/32 now, so the positive, m ore
specific routes are the complements to S2 in the set of next hops for specific routes are the complements to S2 in the set of next hops for
2001:db8::/32, which are S3 and S4, or, in other words, all entries of 2001:db8::/32, which are S3 and S4, or in other words, all entries of
the parent with the negative holes "punched in" again. the parent with the negative holes "punched in" again.
After the update, the FIB in T1 shows as illustrated After the update, the FIB in T1 shows as illustrated
in <xref target="fib1.2" format="default"/>: in <xref target="fib1.2" format="default"/>:
</t> </t>
<figure anchor="fib1.2"> <figure anchor="fib1.2">
<name>Abstract FIB after Negative 2001:db8:1::/48 from S2</name> <name>Abstract FIB After Negative 2001:db8:1::/48 from S2</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-fib-negative-s1-s2.svg"><svg xmlns:sodipodi="http://sodipodi.sourcefo rge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/i nkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/ 1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg ="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="ht tp://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBo x="0 0 1444.2 734.1" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-fib-negative-s1-s2.svg"><svg xmlns:sodipodi="http://sodipodi.sourcefo rge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/i nkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/ 1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg ="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="ht tp://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBo x="0 0 1444.2 734.1" xml:space="preserve">
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path7308" fill-rule="evenodd" stroke="#000000" stroke- width="0.5617" stroke-linejoin="round" stroke-miterlimit="3.5951" d=" M173.2,19 5.6l9.8,3.6l-9.8,3.6C174.8,200.7,174.7,197.7,173.2,195.6z"/> <path id="path7308" fill-rule="evenodd" stroke="#000000" stroke- width="0.5617" stroke-linejoin="round" stroke-miterlimit="3.5951" d=" M173.2,19 5.6l9.8,3.6l-9.8,3.6C174.8,200.7,174.7,197.7,173.2,195.6z"/>
<path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,872.2"/> <path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,872.2"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path7318" fill-rule="evenodd" stroke="#000000" stroke- width="0.5665" stroke-linejoin="round" stroke-miterlimit="3.6258" d=" M173.1,35 6l9.9,3.6l-9.9,3.6C174.7,361.1,174.6,358.2,173.1,356z"/> <path id="path7318" fill-rule="evenodd" stroke="#000000" stroke- width="0.5665" stroke-linejoin="round" stroke-miterlimit="3.6258" d=" M173.1,35 6l9.9,3.6l-9.9,3.6C174.7,361.1,174.6,358.2,173.1,356z"/>
<path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,711.8"/> <path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,711.8"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path5243" fill-rule="evenodd" stroke="#000000" stroke- width="0.5719" stroke-linejoin="round" stroke-miterlimit="3.6599" d=" M173,516. 4l10,3.7l-10,3.7C174.6,521.6,174.6,518.7,173,516.4z"/> <path id="path5243" fill-rule="evenodd" stroke="#000000" stroke- width="0.5719" stroke-linejoin="round" stroke-miterlimit="3.6599" d=" M173,516. 4l10,3.7l-10,3.7C174.6,521.6,174.6,518.7,173,516.4z"/>
skipping to change at line 8892 skipping to change at line 9097
| +--------+ | +--------+ | +--------+ | +--------+ | +--------+ | +--------+
+---&gt; | Via S3 | +---&gt; | Via S3 | +---&gt; | Via S3 | +---&gt; | Via S3 | +---&gt; | Via S3 | +---&gt; | Via S3 |
| +--------+ | +--------+ | +--------+ | +--------+ | +--------+ | +--------+
| | | | | |
| +--------+ | +--------+ | +--------+ | +--------+ | +--------+ | +--------+
+---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 |
+--------+ +--------+ +--------+</artwor k> +--------+ +--------+ +--------+</artwor k>
</artset> </artset>
</figure> </figure>
<t> <t>
Further, assume that S3 stops advertising its service as default gateway. Further, assume that S3 stops advertising its service as a default gateway.
The entry is removed from RIB as usual. In order to update the FIB, it is The entry is removed from RIB as usual. In order to update the FIB, it is
necessary to eliminate the FIB entry for the default route, as well as all necessary to eliminate the FIB entry for the default route, as well as all
the FIB entries that were created for negative routes pointing to the the FIB entries that were created for negative routes pointing to the
RIB entry being removed (::/0). This is done recursively for 2001:db8::/32 RIB entry being removed (::/0). This is done recursively for 2001:db8::/32
and then for, 2001:db8:1::/48. The related FIB entries via S3 are removed, and then for 2001:db8:1::/48. The related FIB entries via S3 are removed
as illustrated in <xref target="fib1.3" format="default"/>. as illustrated in <xref target="fib1.3" format="default"/>.
</t> </t>
<figure anchor="fib1.3"> <figure anchor="fib1.3">
<name>Abstract FIB after Loss of S3</name> <name>Abstract FIB After Loss of S3</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-fib-negative-s1-s2-loss-s3.svg"><svg xmlns:sodipodi="http://sodipodi. sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/name spaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www .w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" x mlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:x link="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384 " viewBox="0 0 1444.2 734.1" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-fib-negative-s1-s2-loss-s3.svg"><svg xmlns:sodipodi="http://sodipodi. sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/name spaces/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www .w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" x mlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:x link="http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384 " viewBox="0 0 1444.2 734.1" xml:space="preserve">
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path2603" fill-rule="evenodd" stroke="#000000" stroke- width="0.5617" stroke-linejoin="round" stroke-miterlimit="3.5951" d=" M173.2,19 5.6l9.8,3.6l-9.8,3.6C174.8,200.7,174.7,197.7,173.2,195.6z"/> <path id="path2603" fill-rule="evenodd" stroke="#000000" stroke- width="0.5617" stroke-linejoin="round" stroke-miterlimit="3.5951" d=" M173.2,19 5.6l9.8,3.6l-9.8,3.6C174.8,200.7,174.7,197.7,173.2,195.6z"/>
<path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,872.2"/> <path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,872.2"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path2613" fill-rule="evenodd" stroke="#000000" stroke- width="0.5665" stroke-linejoin="round" stroke-miterlimit="3.6258" d=" M173.1,35 6l9.9,3.6l-9.9,3.6C174.7,361.1,174.6,358.2,173.1,356z"/> <path id="path2613" fill-rule="evenodd" stroke="#000000" stroke- width="0.5665" stroke-linejoin="round" stroke-miterlimit="3.6258" d=" M173.1,35 6l9.9,3.6l-9.9,3.6C174.7,361.1,174.6,358.2,173.1,356z"/>
<path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,711.8"/> <path id="path1257" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M167.4,711.8"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path1459" fill-rule="evenodd" stroke="#000000" stroke- width="0.5778" stroke-linejoin="round" stroke-miterlimit="3.6981" d=" M173.3,67 6.9l10.1,3.7l-10.1,3.7C174.9,682.1,174.9,679.1,173.3,676.9z"/> <path id="path1459" fill-rule="evenodd" stroke="#000000" stroke- width="0.5778" stroke-linejoin="round" stroke-miterlimit="3.6981" d=" M173.3,67 6.9l10.1,3.7l-10.1,3.7C174.9,682.1,174.9,679.1,173.3,676.9z"/>
skipping to change at line 9038 skipping to change at line 9243
Say that at that time, S4 would also disaggregate prefix 2001:db8:1::/48. Say that at that time, S4 would also disaggregate prefix 2001:db8:1::/48.
This would mean that the FIB entry for 2001:db8:1::/48 becomes a discard This would mean that the FIB entry for 2001:db8:1::/48 becomes a discard
route, and that would be the signal for T1 to disaggregate prefix route, and that would be the signal for T1 to disaggregate prefix
2001:db8:1::/48 negatively in a transitive fashion with its own children. 2001:db8:1::/48 negatively in a transitive fashion with its own children.
</t> </t>
<t> <t>
Finally, the case occurs where S3 becomes available again as a default gatew ay, and a negative Finally, the case occurs where S3 becomes available again as a default gatew ay, and a negative
advertisement is received from S4 about prefix 2001:db8:2::/48 as opposed to advertisement is received from S4 about prefix 2001:db8:2::/48 as opposed to
2001:db8:1::/48. 2001:db8:1::/48.
Again, a negative route is stored in the RIB, and the more specific route Again, a negative route is stored in the RIB, and the more specific route
to the complementing ToF nodes are installed in FIB. to the complementing ToF nodes is installed in FIB.
Since 2001:db8:2::/48 inherits from 2001:db8::/32, the positive FIB routes Since 2001:db8:2::/48 inherits from 2001:db8::/32, the positive FIB routes
are chosen by removing S4 from S2, S3, S4. The abstract FIB in T1 now shows are chosen by removing S4 from S2, S3, S4. The abstract FIB in T1 now shows
as illustrated in <xref target="fib1.4" format="default"/>: as illustrated in <xref target="fib1.4" format="default"/>:
</t> </t>
<figure anchor="fib1.4"> <figure anchor="fib1.4">
<name>Abstract FIB after Negative 2001:db8:2::/48 from S4</name> <name>Abstract FIB After Negative 2001:db8:2::/48 from S4</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-fib-negative-s1-s2-s4.svg"><svg xmlns:sodipodi="http://sodipodi.sourc eforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespace s/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.o rg/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns: svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink= "http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" vie wBox="0 0 1444.2 734.1" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-abstract-fib-negative-s1-s2-s4.svg"><svg xmlns:sodipodi="http://sodipodi.sourc eforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespace s/inkscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.o rg/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns: svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink= "http://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" vie wBox="0 0 1444.2 734.1" xml:space="preserve">
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path2995-8" fill-rule="evenodd" stroke="#000000" strok e-width="0.564" stroke-linejoin="round" stroke-miterlimit="3.6097" d=" M1315.3, 355.7l9.9,3.6l-9.9,3.6C1316.9,360.8,1316.9,357.8,1315.3,355.7z"/> <path id="path2995-8" fill-rule="evenodd" stroke="#000000" strok e-width="0.564" stroke-linejoin="round" stroke-miterlimit="3.6097" d=" M1315.3, 355.7l9.9,3.6l-9.9,3.6C1316.9,360.8,1316.9,357.8,1315.3,355.7z"/>
<path id="path1257-0-3" fill-rule="evenodd" stroke="#000000" str oke-width="0.625" stroke-linejoin="round" d=" M1309.6,388.5"/> <path id="path1257-0-3" fill-rule="evenodd" stroke="#000000" str oke-width="0.625" stroke-linejoin="round" d=" M1309.6,388.5"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path4620" fill-rule="evenodd" stroke="#000000" stroke- width="0.5592" stroke-linejoin="round" stroke-miterlimit="3.5791" d=" M172.4,19 4.7l9.8,3.6l-9.8,3.6C174,199.8,174,196.9,172.4,194.7z"/> <path id="path4620" fill-rule="evenodd" stroke="#000000" stroke- width="0.5592" stroke-linejoin="round" stroke-miterlimit="3.5791" d=" M172.4,19 4.7l9.8,3.6l-9.8,3.6C174,199.8,174,196.9,172.4,194.7z"/>
<path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M166.6,873.1"/> <path id="path1253" fill-rule="evenodd" stroke="#000000" stroke- width="0.625" stroke-linejoin="round" d=" M166.6,873.1"/>
<path fill="none" d=""/> <path fill="none" d=""/>
<path id="path4630" fill-rule="evenodd" stroke="#000000" stroke- width="0.564" stroke-linejoin="round" stroke-miterlimit="3.6097" d=" M172.3,354 .4l9.9,3.6l-9.9,3.6C173.9,359.5,173.9,356.6,172.3,354.4z"/> <path id="path4630" fill-rule="evenodd" stroke="#000000" stroke- width="0.564" stroke-linejoin="round" stroke-miterlimit="3.6097" d=" M172.3,354 .4l9.9,3.6l-9.9,3.6C173.9,359.5,173.9,356.6,172.3,354.4z"/>
skipping to change at line 9246 skipping to change at line 9451
+---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 | +---&gt; | Via S4 |
+--------+ +--------+ +--------+</artwork> +--------+ +--------+ +--------+</artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<!-- attaching prefixes --> <!-- attaching prefixes -->
<section anchor="ZTP" numbered="true" toc="default"> <section anchor="ZTP" numbered="true" toc="default">
<name>Optional Zero Touch Provisioning (RIFT ZTP)</name> <name>Optional Zero Touch Provisioning (RIFT ZTP)</name>
<t> <t>
Each RIFT node can operate in zero touch Each RIFT node can operate in Zero Touch
provisioning (ZTP) Provisioning (ZTP)
mode, i.e. it has no RIFT specific configuration (unless it is a ToF mode, i.e., it has no RIFT-specific configuration (unless it is a ToF
or it is explicitly configured to operate in the overall topology or it is explicitly configured to operate in the overall topology
as leaf and/or support leaf-2-leaf procedures) as a leaf and/or support leaf-to-leaf procedures),
and it will fully automatically derive necessary RIFT and it will fully, automatically derive necessary RIFT
parameters itself after being parameters itself after being
attached to the attached to the
topology. Manually configured nodes and nodes operating using RIFT ZTP c an be topology. Manually configured nodes and nodes operating using RIFT ZTP c an be
mixed freely and will form a valid topology if achievable. mixed freely and will form a valid topology if achievable.
</t> </t>
<t>The derivation of the level of each node happens based on offers <t>The derivation of the level of each node happens based on offers
received from its neighbors whereas each node (with the possible excepti on of nodes configured as leaves) received from its neighbors, whereas each node (with the possible except ion of nodes configured as leaves)
tries to attach at the highest possible point in tries to attach at the highest possible point in
the fabric. This guarantees that even if the diffusion front of offers r eaches the fabric. This guarantees that even if the diffusion front of offers r eaches
a node from "below" faster than from "above", it will greedily abandon a node from "below" faster than from "above", it will greedily abandon a n
already negotiated level derived from nodes topologically below it and already negotiated level derived from nodes topologically below it and
properly peer with nodes above. properly peer with nodes above.
</t> </t>
<t>The fabric is very consciously numbered from the top down to allow fo r PoDs <t>The fabric is very consciously numbered from the top down to allow fo r PoDs
of different heights and to minimize the number of configuration necessa of different heights and to minimize the number of configurations necess
ry, ary,
in this case just a TOP_OF_FABRIC flag on every node at the top of the f in this case, just a TOP_OF_FABRIC flag on every node at the top of the
abric. fabric.
</t> </t>
<t> <t>
This section describes the necessary concepts and procedures of RIFT ZTP This section describes the necessary concepts and procedures of the RIFT ZTP
operation. operation.
</t> </t>
<section anchor="ZTPTerminology" numbered="true" toc="default"> <section anchor="ZTPTerminology" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The interdependencies between the different flags and the configure d <t>The interdependencies between the different flags and the configure d
level can be somewhat vexing at first and it may take multiple reads of level can be somewhat vexing at first, and it may take multiple read s of
the glossary to comprehend them. the glossary to comprehend them.
</t> </t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>Automatic Level Derivation:</dt> <dt>Automatic Level Derivation:</dt>
<dd>Procedures which <dd>Procedures that
allow nodes without level configured to derive it allow nodes without a level configured to derive it
automatically. Only applied if CONFIGURED_LEVEL is automatically. Only applied if CONFIGURED_LEVEL is
undefined.</dd> undefined.</dd>
<dt>UNDEFINED_LEVEL:</dt> <dt>UNDEFINED_LEVEL:</dt>
<dd>A "null" value that <dd>A "null" value that
indicates that the level has not been determined and has indicates that the level has not been determined and has
not been configured. Schemas normally indicate that not been configured. Schemas normally indicate that
by a missing optional value without an by a missing optional value without an
available defined default.</dd> available defined default.</dd>
<dt>LEAF_ONLY:</dt> <dt>LEAF_ONLY:</dt>
<dd>An optional configuration <dd>An optional configuration
flag that can flag that can
be configured on a node to make sure it never leaves the be configured on a node to make sure it never leaves the
"bottom of the hierarchy". TOP_OF_FABRIC flag and "bottom of the hierarchy". The TOP_OF_FABRIC flag and
CONFIGURED_LEVEL CONFIGURED_LEVEL
cannot be defined at the same time as this flag. cannot be defined at the same time as this flag.
It implies It implies a
CONFIGURED_LEVEL value of <em>leaf_level</em>. It is indicat ed in the CONFIGURED_LEVEL value of <em>leaf_level</em>. It is indicat ed in the
<em>leaf_only</em> schema element. <em>leaf_only</em> schema element.
</dd> </dd>
<dt>TOP_OF_FABRIC:</dt> <dt>TOP_OF_FABRIC:</dt>
<dd>A configuration flag that MUST be <dd>A configuration flag that <bcp14>MUST</bcp14> be
provided on provided on
all ToF nodes. LEAF_FLAG and CONFIGURED_LEVEL all ToF nodes. LEAF_FLAG and CONFIGURED_LEVEL
cannot be defined at the same time as this flag. cannot be defined at the same time as this flag.
It implies It implies
a CONFIGURED_LEVEL value. In fact, it is basically a a CONFIGURED_LEVEL value. In fact, it is basically a
shortcut for configuring same level at all ToF shortcut for configuring the same level at all ToF
nodes which is unavoidable since an initial 'seed' is nodes, which is unavoidable since an initial "seed" is
needed for needed for
other ZTP nodes to derive their level in the topology. The f lag other ZTP nodes to derive their level in the topology. The f lag
plays an important role in fabrics with multiple planes to plays an important role in fabrics with multiple planes to
enable successful <xref target="negdisaggreg" format="defaul t">negative disaggregation</xref>. enable successful <xref target="negdisaggreg" format="defaul t">negative disaggregation</xref>.
It is carried in the <em>top_of_fabric</em> schema element. It is carried in the <em>top_of_fabric</em> schema element.
A standards conforming RIFT implementation implies A standards-conforming RIFT implementation implies
a CONFIGURED_LEVEL value of <em>top_of_fabric_level</em> in ca se of TOP_OF_FABRIC. a CONFIGURED_LEVEL value of <em>top_of_fabric_level</em> in ca se of TOP_OF_FABRIC.
This value is kept reasonably low to allow for fast ZTP re-con vergence on This value is kept reasonably low to allow for fast ZTP reconv ergence on
failures. failures.
</dd> </dd>
<dt>CONFIGURED_LEVEL:</dt> <dt>CONFIGURED_LEVEL:</dt>
<dd>A level value <dd>A level value
provided manually. When this is defined (i.e. it is not provided manually. When this is defined (i.e., it is not
an UNDEFINED_LEVEL) an UNDEFINED_LEVEL),
the node is the node is
not participating in ZTP in the sense of deriving its own not participating in ZTP in the sense of deriving its own
level based on other nodes' information. TOP_OF_FABRIC flag level based on other nodes' information. The TOP_OF_FABRIC fla g
is ignored when this value is defined. LEAF_ONLY is ignored when this value is defined. LEAF_ONLY
can be set only if this value is undefined or set to <em>lea f_level</em>.</dd> can be set only if this value is undefined or set to <em>lea f_level</em>.</dd>
<dt>DERIVED_LEVEL:</dt> <dt>DERIVED_LEVEL:</dt>
<dd>Level value computed via <dd>Level value computed via
automatic level derivation when automatic level derivation when
CONFIGURED_LEVEL is equal to CONFIGURED_LEVEL is equal to
UNDEFINED_LEVEL. UNDEFINED_LEVEL.
</dd> </dd>
<dt>LEAF_2_LEAF:</dt> <dt>LEAF_2_LEAF:</dt>
<dd>An optional flag that <dd>An optional flag that
can can
be configured on a node to make sure it supports procedures be configured on a node to make sure it supports procedures
defined in defined in
<xref target="leaf2leaf" format="default"/>. It is a <xref target="leaf2leaf" format="default"/>. It is a
capability that implies LEAF_ONLY and the corresponding capability that implies LEAF_ONLY and the corresponding
restrictions. TOP_OF_FABRIC flag is ignored restrictions. The TOP_OF_FABRIC flag is ignored
when set at the same time when set at the same time
as this flag. as this flag.
It is carried in the <em>leaf_only_and_leaf_2_leaf_procedure s</em> schema flag. It is carried in the <em>leaf_only_and_leaf_2_leaf_procedure s</em> schema flag.
</dd> </dd>
<dt>LEVEL_VALUE:</dt> <dt>LEVEL_VALUE:</dt>
<dd>With ZTP, the original <dd>With ZTP, the original
definition of definition of
"level" in <xref target="glossary" format="default"/> is "level" in <xref target="glossary" format="default"/> is
both extended and relaxed. First, level is defined both extended and relaxed. First, the level is defined
now as LEVEL_VALUE and is the first defined value of now as LEVEL_VALUE and is the first defined value of
CONFIGURED_LEVEL followed by DERIVED_LEVEL. Second, CONFIGURED_LEVEL followed by DERIVED_LEVEL. Second,
it is possible for nodes to be more it is possible for nodes to be more
than one level apart to form adjacencies if any of the than one level apart to form adjacencies if any of the
nodes is at least LEAF_ONLY.</dd> nodes is at least LEAF_ONLY.</dd>
<dt>Valid Offered Level (VOL):</dt> <dt>Valid Offered Level (VOL):</dt>
<dd>A neighbor's level <dd>A neighbor's level
received received
in a valid LIE (i.e. passing all checks for adjacency in a valid LIE (i.e., passing all checks for adjacency
formation while disregarding all clauses involving level formation while disregarding all clauses involving level
values) values)
persisting for the duration of the holdtime interval on the persisting for the duration of the holdtime interval on the
LIE. Observe that offers from nodes offering level value LIE. Observe that offers from nodes offering the level value
of <em>leaf_level</em> do not constitute VOLs (since no valid DERIVED_LEVEL of <em>leaf_level</em> do not constitute VOLs (since no valid DERIVED_LEVEL
can be obtained from those and consequently <em>not_a_ztp_off can be obtained from those and consequently the <em>not_a_ztp
er</em> flag _offer</em> flag
MUST be ignored). Offers from LIEs with <bcp14>MUST</bcp14> be ignored). Offers from LIEs with
<em>not_a_ztp_offer</em> being true are not VOLs either. If a node <em>not_a_ztp_offer</em> being true are not VOLs either. If a node
maintains parallel adjacencies to the neighbor, VOL on each maintains parallel adjacencies to the neighbor, VOL on each
adjacency is considered as equivalent, i.e. the newest VOL adjacency is considered as equivalent, i.e., the newest VOL
from any such adjacency updates the VOL received from the from any such adjacency updates the VOL received from the
same node. same node.
</dd> </dd>
<dt>Highest Available Level (HAL):</dt> <dt>Highest Available Level (HAL):</dt>
<dd>Highest defined <dd>Highest-defined
level value received from all VOLs received. level value received from all VOLs received.
</dd> </dd>
<dt>Highest Available Level Systems (HALS):</dt> <dt>Highest Available Level Systems (HALS):</dt>
<dd>Set of <dd>Set of
nodes offering nodes offering
HAL VOLs. HAL VOLs.
</dd> </dd>
<dt>Highest Adjacency ThreeWay (HAT):</dt> <dt>Highest Adjacency ThreeWay (HAT):</dt>
<dd>Highest <dd>Highest
neighbor level of all the formed <em>ThreeWay</em> adjacenci es neighbor level of all the formed <em>ThreeWay</em> adjacenci es
for the node.</dd> for the node.</dd>
</dl> </dl>
</section> </section>
<!-- ZTPTerminology --> <!-- ZTPTerminology -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Automatic System ID Selection</name> <name>Automatic System ID Selection</name>
<t>RIFT nodes require a 64-bit System ID which SHOULD be derived as <t>RIFT nodes require a 64-bit System ID that <bcp14>SHOULD</bcp14> be
EUI-64 MA-L derive according to <xref target="EUI64" format="default"/>. derived as
The EUI-64 MAC Address Block Large (MA-L) according to <xref target="EUI64"
format="default"/>. The
organizationally governed portion of organizationally governed portion of
this ID (24 bits) can be used to generate multiple IDs if required to this ID (24 bits) can be used to generate multiple IDs if required to
indicate more than one RIFT instance. indicate more than one RIFT instance.
</t> </t>
<t> <t>
As matter of operational concern, the router MUST As matter of operational concern, the router <bcp14>MUST</bcp14>
ensure that such ensure that such
identifier is not changing very frequently (or at least not without identifier is not changing very frequently (or at least not without
sending all its TIEs with fairly short lifetimes, i.e. purging them) sin sending all its TIEs with fairly short lifetimes, i.e., purging them) si
ce nce the
otherwise the network may otherwise be left with large amounts of stale TIEs in other
network may be left with large amounts of stale TIEs in other nodes nodes
(though this is not necessarily a serious problem if the procedures (though this is not necessarily a serious problem if the procedures
described described
in <xref target="security" format="default"/> are implemented). in <xref target="security" format="default"/> are implemented).
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Generic Fabric Example</name> <name>Generic Fabric Example</name>
<t>ZTP forces considerations of an incorrectly or unusually cabled fab ric and <t>ZTP forces considerations of an incorrectly or unusually cabled fab ric and
how such a topology can be forced into a "lattice" structure which how such a topology can be forced into a "lattice" structure that
a fabric a fabric
represents (with further restrictions). A necessary and represents (with further restrictions). A necessary and
sufficient physical cabling is shown in sufficient physical cabling is shown in
<xref target="pic-ztp-generic" format="default"/>. The assumption here is that <xref target="pic-ztp-generic" format="default"/>. The assumption here is that
all nodes are in all nodes are in
the same PoD.</t> the same PoD.</t>
<figure anchor="pic-ztp-generic"> <figure anchor="pic-ztp-generic">
<name>Generic ZTP Cabling Considerations</name> <name>Generic ZTP Cabling Considerations</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-generic-ztp-fabric.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net /DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape " xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02 /22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http: //www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://ww w.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 666.4 500" height="500" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-generic-ztp-fabric.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net /DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape " xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02 /22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http: //www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://ww w.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 666.4 500" height="500" xml:space="preserve">
skipping to change at line 9540 skipping to change at line 9744
+-----------------+ | | +-----------------+ | |
| | | | | | | | | |
++-++ ++-++ | ++-++ ++-++ |
| X +-----+ Y +-+ | X +-----+ Y +-+
|L2L| | L | |L2L| | L |
+---+ +---+ +---+ +---+
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t>First, RIFT must anchor the "top" of the cabling and that's what <t>First, RIFT must anchor the "top" of the cabling and that's what
the TOP_OF_FABRIC flag at node A is for. Then things look smooth until the TOP_OF_FABRIC flag at node A is for. Then, things look smooth until
the protocol has to decide whether node Y is at the same level as I, J the protocol has to decide whether node Y is at the same level as I, J
(and as consequence, X is south of it) or at (and as consequence, X is south of it), or X. This is
the same level as X. This is
unresolvable here until we unresolvable here until we
"nail down the bottom" of the topology. To achieve that the protocol chooses "nail down the bottom" of the topology. To achieve that, the protocol choose
to s to
use in this use the leaf flags in X and Y in this
example the leaf flags in X and Y. In case where Y would not have a leaf example. In the case where Y does not have a leaf
flag it will try to elect highest level offered and end up being flag, it will try to elect the highest level offered and end up being
in same level as I and J. in same level as I and J.
</t> </t>
</section> </section>
<section anchor="LDP" numbered="true" toc="default"> <section anchor="LDP" numbered="true" toc="default">
<name>Level Determination Procedure</name> <name>Level Determination Procedure</name>
<t>A node starting up with UNDEFINED_VALUE (i.e. without a <t>A node starting up with UNDEFINED_VALUE (i.e., without a
CONFIGURED_LEVEL or any leaf or TOP_OF_FABRIC flag) MUST follow those CONFIGURED_LEVEL or any leaf or TOP_OF_FABRIC flag) <bcp14>MUST</bcp14>
follow these
additional procedures:</t> additional procedures:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>It advertises its LEVEL_VALUE on all LIEs (observe that this <li>It advertises its LEVEL_VALUE on all LIEs (observe that this
can be can be
UNDEFINED_LEVEL which in terms of the schema is simply an UNDEFINED_LEVEL, which in terms of the schema, is simply an
omitted optional value). omitted optional value).
</li> </li>
<li>It computes HAL as numerically highest available level in <li>It computes HAL as the numerically highest available level in
all VOLs. all VOLs.
</li> </li>
<li>It chooses then MAX(HAL-1,0) as its DERIVED_LEVEL. <li>Then, it chooses MAX(HAL-1,0) as its DERIVED_LEVEL.
The node then starts The node then starts
to advertise to advertise
this derived level. this derived level.
</li> </li>
<li>A node that lost all adjacencies with HAL value <li>A node that lost all adjacencies with the HAL value
MUST hold <bcp14>MUST</bcp14> hold
down computation of new DERIVED_LEVEL for at least one second down computation of the new DERIVED_LEVEL for at least one secon
d
unless it has no VOLs from southbound adjacencies. unless it has no VOLs from southbound adjacencies.
After the holddown timer expired, it MUST discard After the holddown timer expired, it <bcp14>MUST</bcp14> discard
all received offers, recompute DERIVED_LEVEL and announce all received offers, recompute DERIVED_LEVEL, and announce
it to all neighbors.</li> it to all neighbors.</li>
<li>A node MUST reset any adjacency that has changed the level it <li>A node <bcp14>MUST</bcp14> reset any adjacency that has changed the level it
is offering and is in is offering and is in
<em>ThreeWay</em> state.</li> <em>ThreeWay</em> state.</li>
<li>A node that changed its defined level value MUST <li>A node that changed its defined level value <bcp14>MUST</bcp14>
readvertise its own TIEs (since the new <em>PacketHeader</em> wi re-advertise its own TIEs (since the new <em>PacketHeader</em> w
ll ill
contain a different level than before). The sequence number of e ach contain a different level than before). The sequence number of e ach
TIE MUST be increased. TIE <bcp14>MUST</bcp14> be increased.
</li> </li>
<li>After a level has been derived the node MUST set <li>After a level has been derived, the node <bcp14>MUST</bcp14> set
the <em>not_a_ztp_offer</em> on LIEs towards all systems the <em>not_a_ztp_offer</em> on LIEs towards all systems
offering a VOL for HAL. offering a VOL for HAL.
</li> </li>
<li>A node that changed its level SHOULD flush from its <li>A node that changed its level <bcp14>SHOULD</bcp14> flush TIEs
link state database TIEs of all other nodes, otherwise of all other nodes from its
link state database; otherwise,
stale information may persist on "direction reversal", i.e., stale information may persist on "direction reversal", i.e.,
nodes that seemed south are now north or east-west. nodes that seemed south are now north or east-west.
This will not prevent the correct operation of the This will not prevent the correct operation of the
protocol but could be slightly confusing operationally.</li> protocol but could be slightly confusing operationally.</li>
</ol> </ol>
<t>A node starting with LEVEL_VALUE being 0 (i.e., it assumes a leaf <t>A node starting with LEVEL_VALUE being 0 (i.e., it assumes a leaf
function by being configured with the appropriate flags function by being configured with the appropriate flags
or has a CONFIGURED_LEVEL of 0) MUST follow those or has a CONFIGURED_LEVEL of 0) <bcp14>MUST</bcp14> follow this
additional procedures:</t> additional procedure:</t>
<ol spacing="normal" type="1"> <ol spacing="normal">
<li>It computes HAT per procedures above but does <strong>not</str <li>It computes HAT per the procedures above but does <strong>not<
ong> /strong>
use it to compute DERIVED_LEVEL. HAT is used to limit use it to compute DERIVED_LEVEL. HAT is used to limit
adjacency formation per <xref target="LIE" format="default"/>.</ li> adjacency formation per <xref target="LIE" format="default"/>.</ li>
</ol> </ol>
<t>It MAY also follow modified procedures: <t>It <bcp14>MAY</bcp14> also follow this modified procedure:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal">
<li>It may pick a different strategy to choose VOL, e.g. <li>It may pick a different strategy to choose VOL, e.g.,
use the VOL value with highest number of VOLs. Such strategies use the VOL value with highest number of VOLs. Such strategies
are only possible since the node always remains "at the bottom are only possible since the node always remains "at the bottom
of the fabric" while another layer could "invert" the fabric by of the fabric", while another layer could "invert" the fabric by
picking its preferred VOL in a different fashion rather than alw ays picking its preferred VOL in a different fashion rather than alw ays
trying to achieve the highest viable level. trying to achieve the highest viable level.
</li> </li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>RIFT ZTP FSM</name> <name>RIFT ZTP FSM</name>
<t> <t>
This section specifies the precise, normative ZTP FSM and This section specifies the precise, normative ZTP FSM and
can be omitted unless the reader is pursuing an implementation of can be omitted unless the reader is pursuing an implementation of
the protocol. For additional clarity a graphical representation of the ZTP FS M the protocol. For additional clarity, a graphical representation of the ZTP F SM
is depicted in <xref target="normative-ztp-fsm"/>. It may also be helpful to refer is depicted in <xref target="normative-ztp-fsm"/>. It may also be helpful to refer
to the normative schema in <xref target="schema"/>. to the normative schema in <xref target="schema"/>.
</t> </t>
<t>Initial state is ComputeBestOffer. <t>The initial state is ComputeBestOffer.
</t> </t>
<figure anchor="normative-ztp-fsm"> <figure anchor="normative-ztp-fsm">
<name>RIFT ZTP FSM</name> <name>RIFT ZTP FSM</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-ztp-fsm.svg"><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www .w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="Layer_1" viewBox="0 0 7 89 477" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-r ift-ztp-fsm.svg"><svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www .w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="Layer_1" viewBox="0 0 7 89 477" xml:space="preserve">
<polygon fill="#FFFFFF" points="0,477 0,0 789,0 789,477 "/> <polygon fill="#FFFFFF" points="0,477 0,0 789,0 789,477 "/>
<ellipse fill="none" stroke="#000000" cx="342" cy="108.5" rx=" 94.8" ry="18"/> <ellipse fill="none" stroke="#000000" cx="342" cy="108.5" rx=" 94.8" ry="18"/>
<text transform="matrix(1 0 0 1 288.8574 112.2)" font-size="14 px">C</text> <text transform="matrix(1 0 0 1 288.8574 112.2)" font-size="14 px">C</text>
<text transform="matrix(1 0 0 1 298.1953 112.2)" font-size="14 px">o</text> <text transform="matrix(1 0 0 1 298.1953 112.2)" font-size="14 px">o</text>
<text transform="matrix(1 0 0 1 305.1953 112.2)" font-size="14 px">m</text> <text transform="matrix(1 0 0 1 305.1953 112.2)" font-size="14 px">m</text>
skipping to change at line 9891 skipping to change at line 10094
+------------------+ +------------------+
| |
| LostHAL | LostHAL
V V
(HoldingDown)</artwork> (HoldingDown)</artwork>
</artset> </artset>
</figure> </figure>
<!-- begin generated output --> <!-- begin generated output -->
<t> <t>
The following words are used for well-known procedures: The following terms are used for well-known procedures:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>PUSH Event: queues an event to be executed by the FSM upon exit of this action</li> <li>PUSH Event: queues an event to be executed by the FSM upon exit of this action</li>
<li>COMPARE_OFFERS: checks whether based on current offers and held last results, the events <li>COMPARE_OFFERS: checks whether, based on current offers and held last results, the events
BetterHAL/LostHAL/BetterHAT/LostHAT are necessary and retu rns them</li> BetterHAL/LostHAL/BetterHAT/LostHAT are necessary and retu rns them</li>
<li>UPDATE_OFFER: store current offer with adjacency holdtime as lif etime and <li>UPDATE_OFFER: store current offer with adjacency holdtime as lif etime and
COMPARE_OFFERS, then PUSH corresponding events</li> COMPARE_OFFERS, then PUSH corresponding events</li>
<li>LEVEL_COMPUTE: compute best offered or configured level and HAL/ HAT, if anything changed <li>LEVEL_COMPUTE: compute best offered or configured level and HAL/ HAT, if anything changed,
PUSH ComputationDone</li> PUSH ComputationDone</li>
<li>REMOVE_OFFER: remove the corresponding offer and COMPARE_OFFERS, PUSH corresponding events</li> <li>REMOVE_OFFER: remove the corresponding offer and COMPARE_OFFERS, PUSH corresponding events</li>
<li>PURGE_OFFERS: REMOVE_OFFER for all held offers, COMPARE OFFERS, PUSH corresponding events</li> <li>PURGE_OFFERS: REMOVE_OFFER for all held offers, COMPARE OFFERS, PUSH corresponding events</li>
<li> <li>
<t>PROCESS_OFFER:</t> <t>PROCESS_OFFER:</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>if no level offered then REMOVE_OFFER</li> <li>if no level is offered, then REMOVE_OFFER</li>
<li> <li>
<t>else</t> <t>else</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="a">
<li>if offered level &gt; leaf then UPDATE_OFF <li>if offered level &gt; leaf, then UPDATE_OF
ER</li> FER</li>
<li>else REMOVE_OFFER</li> <li>else REMOVE_OFFER</li>
</ol> </ol>
</li> </li>
</ol> </ol>
</li> </li>
</ul> </ul>
<t>States:</t> <t>States:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>ComputeBestOffer: <li>ComputeBestOffer:
processes received offers to derive ZTP variables</li> Processes received offers to derive ZTP variables.</li>
<li>HoldingDown: <li>HoldingDown:
holding down while receiving updates</li> Holding down while receiving updates.</li>
<li>UpdatingClients: <li>UpdatingClients:
updates other FSMs on the same node with computation resul ts</li> Updates other FSMs on the same node with computation resul ts.</li>
</ul> </ul>
<t>Events:</t> <t>Events:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>ChangeLocalHierarchyIndications: <li>ChangeLocalHierarchyIndications:
node locally configured with new leaf flags.</li> Node locally configured with new leaf flags.</li>
<li>ChangeLocalConfiguredLevel: <li>ChangeLocalConfiguredLevel:
node locally configured with a defined level</li> Node locally configured with a defined level.</li>
<li>NeighborOffer: <li>NeighborOffer:
a new neighbor offer with optional level and neighbor stat e.</li> A new neighbor offer with optional level and neighbor stat e.</li>
<li>BetterHAL: <li>BetterHAL:
better HAL computed internally.</li> Better HAL computed internally.</li>
<li>BetterHAT: <li>BetterHAT:
better HAT computed internally.</li> Better HAT computed internally.</li>
<li>LostHAL: <li>LostHAL:
lost last HAL in computation.</li> Lost last HAL in computation.</li>
<li>LostHAT: <li>LostHAT:
lost HAT in computation.</li> Lost HAT in computation.</li>
<li>ComputationDone: <li>ComputationDone:
computation performed.</li> Computation performed.</li>
<li>HoldDownExpired: <li>HoldDownExpired:
holddown timer expired.</li> Holddown timer expired.</li>
<li>ShortTic: <li>ShortTic:
one-second timer tick. This event is provided to the FSM One-second timer tick. This event is provided to the FSM
once a second by an implementation-specific mechanism that is outside the scope of this specification. This event is quietly once a second by an implementation-specific mechanism that is outside the scope of this specification. This event is quietly
ignored if the relevant transition does not exist.</li> ignored if the relevant transition does not exist.</li>
</ul> </ul>
<t>Actions:</t> <t>Actions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>on ChangeLocalConfiguredLevel in HoldingDown finishes in Compute BestOffer: <li>on ChangeLocalConfiguredLevel in HoldingDown finishes in Compute BestOffer:
store configured level store configured level
</li> </li>
<li>on BetterHAT in HoldingDown finishes in HoldingDown: <li>on BetterHAT in HoldingDown finishes in HoldingDown:
no action no action
</li> </li>
<li>on ShortTic in HoldingDown finishes in HoldingDown: <li>on ShortTic in HoldingDown finishes in HoldingDown:
remove expired offers and if holddown timer expired PUSH_E VENT HoldDownExpired remove expired offers, and if holddown timer expired, PUSH _EVENT HoldDownExpired
</li> </li>
<li>on NeighborOffer in HoldingDown finishes in HoldingDown: <li>on NeighborOffer in HoldingDown finishes in HoldingDown:
PROCESS_OFFER PROCESS_OFFER
</li> </li>
<li>on ComputationDone in HoldingDown finishes in HoldingDown: <li>on ComputationDone in HoldingDown finishes in HoldingDown:
no action no action
</li> </li>
<li>on BetterHAL in HoldingDown finishes in HoldingDown: <li>on BetterHAL in HoldingDown finishes in HoldingDown:
no action no action
</li> </li>
skipping to change at line 9996 skipping to change at line 10199
<li>on NeighborOffer in ComputeBestOffer finishes in ComputeBestOffe r: <li>on NeighborOffer in ComputeBestOffer finishes in ComputeBestOffe r:
PROCESS_OFFER PROCESS_OFFER
</li> </li>
<li>on BetterHAT in ComputeBestOffer finishes in ComputeBestOffer: <li>on BetterHAT in ComputeBestOffer finishes in ComputeBestOffer:
LEVEL_COMPUTE LEVEL_COMPUTE
</li> </li>
<li>on ChangeLocalHierarchyIndications in ComputeBestOffer finishes in ComputeBestOffer: <li>on ChangeLocalHierarchyIndications in ComputeBestOffer finishes in ComputeBestOffer:
store leaf flags and LEVEL_COMPUTE store leaf flags and LEVEL_COMPUTE
</li> </li>
<li>on LostHAL in ComputeBestOffer finishes in HoldingDown: <li>on LostHAL in ComputeBestOffer finishes in HoldingDown:
if any southbound adjacencies present then update holddown timer to normal duration else fire holddown timer immediately if any southbound adjacencies present, then update holddow n timer to normal duration, else fire holddown timer immediately
</li> </li>
<li>on ShortTic in ComputeBestOffer finishes in ComputeBestOffer: <li>on ShortTic in ComputeBestOffer finishes in ComputeBestOffer:
remove expired offers remove expired offers
</li> </li>
<li>on ComputationDone in ComputeBestOffer finishes in UpdatingClien ts: <li>on ComputationDone in ComputeBestOffer finishes in UpdatingClien ts:
no action no action
</li> </li>
<li>on ChangeLocalConfiguredLevel in ComputeBestOffer finishes in Co mputeBestOffer: <li>on ChangeLocalConfiguredLevel in ComputeBestOffer finishes in Co mputeBestOffer:
store configured level and LEVEL_COMPUTE store configured level and LEVEL_COMPUTE
</li> </li>
<li>on BetterHAL in ComputeBestOffer finishes in ComputeBestOffer: <li>on BetterHAL in ComputeBestOffer finishes in ComputeBestOffer:
LEVEL_COMPUTE LEVEL_COMPUTE
</li> </li>
<li>on ShortTic in UpdatingClients finishes in UpdatingClients: <li>on ShortTic in UpdatingClients finishes in UpdatingClients:
remove expired offers remove expired offers
</li> </li>
<li>on LostHAL in UpdatingClients finishes in HoldingDown: <li>on LostHAL in UpdatingClients finishes in HoldingDown:
if any southbound adjacencies are present then update hold down timer to normal duration else fire holddown timer immediately if any southbound adjacencies are present, then update hol ddown timer to normal duration, else fire holddown timer immediately
</li> </li>
<li>on BetterHAT in UpdatingClients finishes in ComputeBestOffer: <li>on BetterHAT in UpdatingClients finishes in ComputeBestOffer:
no action no action
</li> </li>
<li>on BetterHAL in UpdatingClients finishes in ComputeBestOffer: <li>on BetterHAL in UpdatingClients finishes in ComputeBestOffer:
no action no action
</li> </li>
<li>on ChangeLocalConfiguredLevel in UpdatingClients finishes in Com puteBestOffer: <li>on ChangeLocalConfiguredLevel in UpdatingClients finishes in Com puteBestOffer:
store configured level store configured level
</li> </li>
skipping to change at line 10120 skipping to change at line 10323
+---------+ | | +---------+ | |
| | | | | |
++-++ +---+ | ++-++ +---+ |
| X | | Y +-+ | X | | Y +-+
| 0 | | 0 | | 0 | | 0 |
+---+ +---+ +---+ +---+
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
In case where the LEAF_ONLY restriction on Y is removed the outcome In the case where the LEAF_ONLY restriction on Y is removed, the outcome
would be very different however and result in <xref target="pic-ztp-ldped-nol" f ormat="default"/>. would be very different however and result in <xref target="pic-ztp-ldped-nol" f ormat="default"/>.
This demonstrates basically that auto configuration makes miscabling This basically demonstrates that autoconfiguration makes miscabling
detection hard and with that can lead to undesirable effects in cases where detection hard and, with that, can lead to undesirable effects in cases where
leaves are not "nailed" by the appropriately configured flags and arbitrarily ca bled. leaves are not "nailed" by the appropriately configured flags and arbitrarily ca bled.
</t> </t>
<!-- <t>A node MAY analyze the outstanding level offers on its interfa ces and <!-- <t>A node MAY analyze the outstanding level offers on its interfa ces and
generate warnings when its internal ruleset flags a possible miscabling. generate warnings when its internal ruleset flags a possible miscabling.
As an example, when a node's receives ZTP level offers that differ by more t han As an example, when a node's receives ZTP level offers that differ by more t han
one level from its chosen level (with proper accounting for leaf's being one level from its chosen level (with proper accounting for leaf's being
at level <em>leaf_level</em>) this can indicate miscabling. at level <em>leaf_level</em>) this can indicate miscabling.
</t> --> </t> -->
<figure anchor="pic-ztp-ldped-nol"> <figure anchor="pic-ztp-ldped-nol">
skipping to change at line 10221 skipping to change at line 10424
</figure> </figure>
</section> </section>
</section> </section>
<!-- ZTP --> <!-- ZTP -->
<section numbered="true" toc="default" anchor="further_mech_sec"> <section numbered="true" toc="default" anchor="further_mech_sec">
<name>Further Mechanisms</name> <name>Further Mechanisms</name>
<section anchor="prefs" numbered="true" toc="default"> <section anchor="prefs" numbered="true" toc="default">
<name>Route Preferences</name> <name>Route Preferences</name>
<t> <t>
Since RIFT distinguishes between different route types such as Since RIFT distinguishes between different route types, such a
e.g. external routes from s external routes from
other protocols and other protocols, and
additionally advertises special types of routes on disaggregat ion, additionally advertises special types of routes on disaggregat ion,
the protocol MUST tie-break internally different types on a cl ear preference the protocol <bcp14>MUST</bcp14> tie-break internally differen t types on a clear preference
scale to prevent traffic loss or loops. The preferences are gi ven in the schema scale to prevent traffic loss or loops. The preferences are gi ven in the schema
type <em>RouteType</em>. type <em>RouteType</em>.
</t> </t>
<t> <t>
<xref target="route-types"/> contains the route type as derived from the TIE type carrying it. Entries <xref target="route-types"/> contains the route type as derived from the TIE type carrying it. Entries
are sorted from the most preferred route type to the least pre ferred route type. are sorted from the most preferred route type to the least pre ferred route type.
</t> </t>
<table anchor="route-types" align="center"> <table anchor="route-types" align="center">
<name>TIEs and Contained Route Types</name> <name>TIEs and Contained Route Types</name>
<thead> <thead>
skipping to change at line 10283 skipping to change at line 10486
<tr> <tr>
<td align="left">South Negative Prefix</td> <td align="left">South Negative Prefix</td>
<td align="left">NegativeSouthPrefix</td> <td align="left">NegativeSouthPrefix</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="overload" numbered="true" toc="default"> <section anchor="overload" numbered="true" toc="default">
<name>Overload Bit</name> <name>Overload Bit</name>
<t> <t>
Overload attribute is specified in the <xref target="schema" >packet encoding schema</xref> The overload attribute is specified in the <xref target="sch ema">packet encoding schema</xref>
in the <em>overload</em> flag. in the <em>overload</em> flag.
</t> </t>
<t> <t>
The overload flag MUST be respected by all necessary The overload flag <bcp14>MUST</bcp14> be respected by all ne cessary
SPF computations. A node with the overload flag SPF computations. A node with the overload flag
set SHOULD advertise all locally hosted prefixes set <bcp14>SHOULD</bcp14> advertise all locally hosted prefi
both northbound and southbound, all other southbound xes,
prefixes SHOULD NOT be advertised. both northbound and southbound; all other southbound
prefixes <bcp14>SHOULD NOT</bcp14> be advertised.
</t> </t>
<t> <t>
Leaf nodes SHOULD set the overload attribute on all originat ed Leaf nodes <bcp14>SHOULD</bcp14> set the overload attribute on all originated
Node TIEs. If spine nodes were to forward traffic Node TIEs. If spine nodes were to forward traffic
not intended for the local node, the leaf not intended for the local node, the leaf
node would not be able to prevent node would not be able to prevent
routing/forwarding loops as it does not have the routing/forwarding loops as it does not have the
necessary topology information to do so. necessary topology information to do so.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Optimized Route Computation on Leaves</name> <name>Optimized Route Computation on Leaves</name>
<t> <t>
Leaf nodes only have visibility to directly connected nodes Leaf nodes only have visibility to directly connected nodes
and therefore are not required to run "full" SPF computation s. and therefore are not required to run "full" SPF computation s.
Instead, prefixes from neighboring nodes can be gathered to run Instead, prefixes from neighboring nodes can be gathered to run
a "partial" SPF computation in order to build the routing ta ble. a "partial" SPF computation in order to build the routing ta ble.
</t> </t>
<t> <t>
Leaf nodes SHOULD only hold their own N-TIEs, and Leaf nodes <bcp14>SHOULD</bcp14> only hold their own N-TIEs and,
in cases of L2L implementations, the N-TIEs of their in cases of L2L implementations, the N-TIEs of their
East/West neighbors. Leaf nodes MUST hold East-West neighbors. Leaf nodes <bcp14>MUST</bcp14> hold
all S-TIEs from their neighbors. all S-TIEs from their neighbors.
</t> </t>
<t>Normally, a full network graph is created based on local N-TIEs and <t>Normally, a full network graph is created based on local N-TIEs and
remote S-TIEs that it receives from neighbors, at which time , remote S-TIEs that it receives from neighbors, at which time ,
necessary SPF computations are performed. Instead, leaf nod es necessary SPF computations are performed. Instead, leaf nod es
can simply compute the minimum cost and next-hop set of each can simply compute the minimum cost and next-hop set of each
leaf neighbor by examining its local adjacencies. Associate d leaf neighbor by examining its local adjacencies. Associate d
N-TIEs are used to determine bi-directionality and derive th N-TIEs are used to determine bidirectionality and derive the
e next-hop set. The cost is then derived from the minimum cos
next-hop set. Cost is then derived from the minimum cost of t of
the local adjacency to the neighbor and the prefix cost. the local adjacency to the neighbor and the prefix cost.
</t> </t>
<t>Leaf nodes would then attach necessary prefixes as described in <x ref target="sec_attaching_prefixes" format="default"/>.</t> <t>Leaf nodes would then attach necessary prefixes as described in <x ref target="sec_attaching_prefixes" format="default"/>.</t>
</section> </section>
<!-- <section title="Optimized Route Computation on leaves"> --> <!-- <section title="Optimized Route Computation on leaves"> -->
<section anchor="mobility" numbered="true" toc="default"> <section anchor="mobility" numbered="true" toc="default">
<name>Mobility</name> <name>Mobility</name>
<t> <t>
The RIFT control plane MUST maintain the real time The RIFT control plane <bcp14>MUST</bcp14> maintain the real time
status of every prefix, to which port it is attached, status of every prefix, to which port it is attached,
and to which leaf node that port belongs. This is still and to which leaf node that port belongs. This is still
true in cases of IP mobility where the point of attachment true in cases of IP mobility where the point of attachment
may change several times a second. may change several times a second.
</t> </t>
<t>There are two classic approaches to explicitly maintain this inform ation, <t>There are two classic approaches to explicitly maintain this inform ation,
"timestamp" and "sequence counter" as follows: "timestamp" and "sequence counter", which are defined as follows:
</t> </t>
<dl newline="true" spacing="normal"> <dl newline="true" spacing="normal">
<dt>timestamp:</dt> <dt>timestamp:</dt>
<dd> <dd>
With this method, the infrastructure SHOULD record the precise time at With this method, the infrastructure <bcp14>SHOULD</bcp14> record the pr ecise time at
which the movement is observed. One key advantage of this technique is which the movement is observed. One key advantage of this technique is
that it has no dependency on the mobile device. that it has no dependency on the mobile device.
One drawback is that the infrastructure MUST be precisely One drawback is that the infrastructure <bcp14>MUST</bcp14> be preci sely
synchronized in order to be able to compare timestamps as synchronized in order to be able to compare timestamps as
the points of attachment change. This could be accomplished by the points of attachment change. This could be accomplished by
utilizing Precision Time Protocol (PTP) IEEE Std. 1588 utilizing the Precision Time Protocol (PTP) (IEEE Std. 1588
<xref target="IEEEstd1588" format="default"/> <xref target="IEEEstd1588" format="default"/>
or 802.1AS <xref target="IEEEstd8021AS" format="default"/> or 802.1AS <xref target="IEEEstd8021AS" format="default"/>),
which is designed for bridged LANs. which is designed for bridged LANs.
Both the precision of the synchronization protocol and the resolution of Both the precision of the synchronization protocol and the resolution of
the timestamp must beat the shortest possible roaming time on the fabric . the timestamp must beat the shortest possible roaming time on the fabric .
Another drawback is that the presence of a mobile device may Another drawback is that the presence of a mobile device may
only be observed asynchronously, such as when it starts using an only be observed asynchronously, such as when it starts using an
IP protocol like ARP <xref target="RFC0826" format="default"/>, IP protocol like ARP <xref target="RFC0826" format="default"/>,
IPv6 Neighbor Discovery <xref target="RFC4861" format="default"/>, IPv6 Neighbor Discovery <xref target="RFC4861" format="default"/>,
IPv6 Stateless Address Configuration <xref target="RFC4862" format= "default"/>, IPv6 Stateless Address Configuration <xref target="RFC4862" format= "default"/>,
skipping to change at line 10383 skipping to change at line 10586
<dt>sequence counter:</dt> <dt>sequence counter:</dt>
<dd> With this method, a mobile device <dd> With this method, a mobile device
notifies its point of attachment on arrival with a sequence counter that notifies its point of attachment on arrival with a sequence counter that
is incremented upon each movement. On the positive side, this method do es is incremented upon each movement. On the positive side, this method do es
not have a dependency on a precise sense of time, since the sequence of not have a dependency on a precise sense of time, since the sequence of
movements is kept in order by the mobile device. movements is kept in order by the mobile device.
The disadvantage of this approach is the need for support for protocols The disadvantage of this approach is the need for support for protocols
that may be used by the mobile device to register its presence to the le af that may be used by the mobile device to register its presence to the le af
node with the capability to provide a sequence counter. node with the capability to provide a sequence counter.
Well-known issues with sequence counters such as wrapping and compar Well-known issues with sequence counters, such as wrapping and compa
ison rison
rules MUST be addressed properly. rules, <bcp14>MUST</bcp14> be addressed properly.
Sequence numbers MUST be compared by a single homogenous source to m ake Sequence numbers <bcp14>MUST</bcp14> be compared by a single homogen ous source to make
operation feasible. Sequence number comparison from multiple operation feasible. Sequence number comparison from multiple
heterogeneous sources would be extremely difficult to implement. heterogeneous sources would be extremely difficult to implement.
</dd> </dd>
</dl> </dl>
<t> <t>
RIFT supports a hybrid approach by using an optional 'PrefixSequenceType ' RIFT supports a hybrid approach by using an optional 'PrefixSequenceType '
attribute (that is also called a <em>monotonic_clock</em> in the schema) that consists of a timestamp attribute (which is also called a <em>monotonic_clock</em> in the schema ) that consists of a timestamp
and optional sequence number field. and optional sequence number field.
In case of a In case of a
negatively distributed prefix this attribute MUST NOT negatively distributed prefix, this attribute <bcp14>MUST NOT</bcp14>
be included by the originator and it MUST be ignored be included by the originator and it <bcp14>MUST</bcp14> be ignored
by all nodes during computation. by all nodes during computation.
When this attribute is present (observe When this attribute is present (observe
that per data schema that per data schema,
the attribute itself is optional but in case it is included the 'timesta the attribute itself is optional, but in case it is included, the "times
mp' field tamp" field
is required): is required):
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
The leaf node MAY advertise a timestamp of the latest sighting of a pref ix, The leaf node <bcp14>MAY</bcp14> advertise a timestamp of the latest sig hting of a prefix,
e.g., by snooping IP protocols or the node using the time at which it e.g., by snooping IP protocols or the node using the time at which it
advertised the prefix. RIFT transports the timestamp within the desired advertised the prefix. RIFT transports the timestamp within the desired
Prefix North TIEs as <xref target="IEEEstd1588"/> timestamp. Prefix North TIEs as the <xref target="IEEEstd1588"/> timestamp.
</li> </li>
<li> <li>
RIFT MAY interoperate with "Registration Extensions for 6LoWPAN RIFT <bcp14>MAY</bcp14> interoperate with "Registration Extensions f or 6LoWPAN
Neighbor Discovery" <xref target="RFC8505" format="default"/>, which provides a method for registering Neighbor Discovery" <xref target="RFC8505" format="default"/>, which provides a method for registering
a prefix with a sequence number called a Transaction ID (TID). a prefix with a sequence number called a Transaction ID (TID).
In such cases, RIFT SHOULD transport the derived TID without modific ation. In such cases, RIFT <bcp14>SHOULD</bcp14> transport the derived TID without modification.
</li> </li>
<li> <li>
RIFT also defines an abstract negative clock (ASNC) (also RIFT also defines an abstract negative clock (ASNC) (also
called an 'undefined' clock). The ASNC MUST be considered called an "undefined" clock). The ASNC <bcp14>MUST</bcp14> be considere d
older than any other defined clock. By default, when a node receives a older than any other defined clock. By default, when a node receives a
Prefix North TIE that does not contain a 'PrefixSequenceType' attribute, Prefix North TIE that does not contain a 'PrefixSequenceType' attribute,
it MUST interpret the absence as the ASNC. it <bcp14>MUST</bcp14> interpret the absence as the ASNC.
</li> </li>
<li>Any prefix present on the fabric in multiple nodes that have the <li>Any prefix present on the fabric in multiple nodes that have the
<strong>same</strong> clock is considered as anycast. </li> <strong>same</strong> clock is considered as anycast. </li>
<li> <li>
RIFT specification assumes that all nodes are being synchronized wit hin at The RIFT specification assumes that all nodes are being synchronized within at
least 200 milliseconds or less. This is achievable through the least 200 milliseconds or less. This is achievable through the
use of NTP <xref target="RFC5905" format="default"/>. An implementa use of NTP <xref target="RFC5905" format="default"/>. An implementa
tion MAY provide a way to reconfigure a tion <bcp14>MAY</bcp14> provide a way to reconfigure a
domain to a different value, and provides for this purpose a variabl domain to a different value and provides a variable called MAXIMUM_C
e called MAXIMUM_CLOCK_DELTA. LOCK_DELTA for this purpose.
</li> </li>
</ul> </ul>
<section anchor="clock_compare" numbered="true" toc="default"> <section anchor="clock_compare" numbered="true" toc="default">
<name>Clock Comparison</name> <name>Clock Comparison</name>
<t> <t>
All monotonic clock values MUST be compared to each other using the f ollowing rules: All monotonic clock values <bcp14>MUST</bcp14> be compared to each ot her using the following rules:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>The ASNC is older than any other value except ASNC <strong>and <li>The ASNC is older than any other value except ASNC,</li>
</strong></li> <li>Clocks with timestamps differing by more than MAXIMUM_CLOCK_DE
<li>Clocks with timestamp differing by more than MAXIMUM_CLOCK_DEL LTA are
TA are comparable by using the timestamps only,</li>
comparable by using the timestamps only <strong>and</strong>
</li>
<li>Clocks with timestamps differing by less than MAXIMUM_CLOCK_DE LTA are <li>Clocks with timestamps differing by less than MAXIMUM_CLOCK_DE LTA are
comparable by using their TIDs only <strong>and</strong></li comparable by using their TIDs only, <strong>and</strong></l
> i>
<li>An undefined TID is always older than any other TID <strong>an <li>An undefined TID is always older than any other TID, <strong>a
d</strong></li> nd</strong></li>
<li>TIDs are compared using rules of <li>TIDs are compared using rules of
<xref target="RFC8505" format="default"/>. <xref target="RFC8505" format="default"/>.
</li> </li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Interaction between Time Stamps and Sequence Counters</name> <name>Interaction Between Timestamps and Sequence Counters</name>
<t> <t>
For attachment changes that occur less frequently (e.g., once per second ), For attachment changes that occur less frequently (e.g., once per second ),
the timestamp that the RIFT infrastructure captures should be enough to determine the timestamp that the RIFT infrastructure captures should be enough to determine
the most current discovery. If the point of attachment changes faster t han the most current discovery. If the point of attachment changes faster t han
the maximum drift of the time stamping mechanism (i.e., MAXIMUM_CLOCK_DE the maximum drift of the timestamping mechanism (i.e., MAXIMUM_CLOCK_DEL
LTA), TA),
then a sequence number SHOULD be used to enable necessary precision to d then a sequence number <bcp14>SHOULD</bcp14> be used to enable necessary
etermine currency. precision to determine currency.
</t> </t>
<!--[rfced] To clarify the content of Appendix A, may we update this
sentence as follows?
Original:
The sequence counter in [RFC8505] is encoded as one octet and wraps
around using Appendix A.
Perhaps:
The sequence counter in [RFC8505] is encoded as one octet and wraps
around using the arithmetic defined in Appendix A.
-->
<t> <t>
The sequence counter in <xref target="RFC8505" format="default"/> is The sequence counter in <xref target="RFC8505" format="default"/> is
encoded as one octet and wraps around using <xref target="arithmetic" format ="default"/>. encoded as one octet and wraps around using <xref target="arithmetic" format ="default"/>.
</t> </t>
<t> <t>
Within the resolution of MAXIMUM_CLOCK_DELTA, sequence counter values Within the resolution of MAXIMUM_CLOCK_DELTA, sequence counter values
captured during 2 sequential iterations of the same timestamp SHOULD be captured during 2 sequential iterations of the same timestamp <bcp14>SHO ULD</bcp14> be
comparable. This means that with default values, a node may move up to comparable. This means that with default values, a node may move up to
127 times in a 200-millisecond period and the clocks will remain 127 times in a 200-millisecond period and the clocks will remain
comparable. This allows the RIFT infrastructure to explicitly assert comparable. This allows the RIFT infrastructure to explicitly assert
the most up-to-date advertisement. the most up-to-date advertisement.
</t> </t>
</section> </section>
<!-- Interaction between Time Stamps and Sequence Counters --> <!-- Interaction between Time Stamps and Sequence Counters -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Anycast vs. Unicast</name> <name>Anycast vs. Unicast</name>
<t> <t>
A unicast prefix can be attached to at most one leaf, whereas an A unicast prefix can be attached to one leaf at most, whereas an
anycast prefix may be reachable via more anycast prefix may be reachable via more
than one leaf. than one leaf.
</t> </t>
<t> <t>
If a monotonic clock attribute is provided on the prefix, then the prefix If a monotonic clock attribute is provided on the prefix, then the prefix
with the <strong>newest</strong> with the <strong>newest</strong>
clock value is strictly preferred. An anycast clock value is strictly preferred. An anycast
prefix does not carry a clock or all clock attributes MUST be the same under prefix does not carry a clock, or all clock attributes <bcp14>MUST</bcp14> b e the same under
the rules of <xref target="clock_compare" format="default"/>. the rules of <xref target="clock_compare" format="default"/>.
</t> </t>
<t>It is important that in mobility events the leaf is re-flooding <t>In mobility events, it is important that the leaf is reflooding
as quickly as possible to communicate the absence of as quickly as possible to communicate the absence of
the prefix that moved. the prefix that moved.
</t> </t>
<t>Without support for <xref target="RFC8505" format="default"/> <t>Without support for <xref target="RFC8505" format="default"/>,
movements on the fabric within intervals smaller than 100msec will be interp movements on the fabric within intervals smaller than 100 msec will be inter
reted preted
as anycast.</t> as anycast.</t>
</section> </section>
<!-- Anycast vs. Unicast --> <!-- Anycast vs. Unicast -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Overlays and Signaling</name> <name>Overlays and Signaling</name>
<t> <t>
RIFT is agnostic to any overlay technologies and their associated RIFT is agnostic to any overlay technologies and their associated
control and transports control and transports
that run on top of it (e.g. VXLAN). that run on top of it (e.g., Virtual eXtensible Local Area Network (VXLA N)).
It is expected that leaf nodes and possibly ToF nodes It is expected that leaf nodes and possibly ToF nodes
can perform necessary data plane encapsulation. can perform necessary data plane encapsulation.
</t> </t>
<t> <t>
In the context of mobility, overlays provide another possible solution to In the context of mobility, overlays provide another possible solution to
avoid injecting mobile prefixes into the fabric as well as improving avoid injecting mobile prefixes into the fabric as well as improving
scalability of the deployment. It makes sense to consider overlays scalability of the deployment. It makes sense to consider overlays
for mobility solutions in IP fabrics. As an example, a mobility for mobility solutions in IP fabrics. As an example, a mobility
protocol such as LISP <xref target="RFC9300" format="default"/> <xref tar get="RFC9301" format="default"/> protocol such as the Locator/ID Separation Protocol (LISP) <xref target=" RFC9300" format="default"/> <xref target="RFC9301" format="default"/>
may inform the ingress leaf of the location of the egress leaf in real ti me. may inform the ingress leaf of the location of the egress leaf in real ti me.
</t> </t>
<t> <t>
Another possibility is to consider that mobility as an underlay service and Another possibility is to consider that mobility is an underlay service and
support it in RIFT to an extent. The load on the support it in RIFT to an extent. The load on the
fabric increases with the amount of mobility obviously since a move forces fabric increases with the amount of mobility since a move forces
flooding and computation on all nodes in the scope of the move so tunneling flooding and computation on all nodes in the scope of the move so tunneling
from leaf to the ToF may be desired to speed up convergence from the leaf to the ToF may be desired to speed up convergence
times. </t> times. </t>
<!-- PRZ: TBD <!-- PRZ: TBD
<t> <t>
The overhead and performance limitations can be alleviated with an hybrid The overhead and performance limitations can be alleviated with an hybrid
approach whereby mobile North TIEs related to mobile prefixes are not flooded approach whereby mobile North TIEs related to mobile prefixes are not flooded
throughout but unicast to a limited set of Spine Nodes, which act as anchor throughout but unicast to a limited set of Spine Nodes, which act as anchor
points and tunnel the traffic back to the leaf where the mobile prefix is points and tunnel the traffic back to the leaf where the mobile prefix is
attached. This approach hides the mobility to the end nodes by having the attached. This approach hides the mobility to the end nodes by having the
encapsulation done at the spine or superspine as opposed to the ingress leaf. encapsulation done at the spine or superspine as opposed to the ingress leaf.
skipping to change at line 10559 skipping to change at line 10775
<t>the mobile device registers to the visited leaf, e.g., using IPv6 ND <t>the mobile device registers to the visited leaf, e.g., using IPv6 ND
<xref target="I-D.ietf-6lo-rfc6775-update"/>; <xref target="I-D.ietf-6lo-rfc6775-update"/>;
</t> </t>
<t>RIFT in the leaf is configured with a mobility protocol and refrains from <t>RIFT in the leaf is configured with a mobility protocol and refrains from
injecting the mobile prefix in the fabric. Instead, the RIFT notifies the injecting the mobile prefix in the fabric. Instead, the RIFT notifies the
mobility protocol that handles the signaling; mobility protocol that handles the signaling;
</t> </t>
<t>The mobility protocol informs the anchor point, e.g., duplicated in a <t>The mobility protocol informs the anchor point, e.g., duplicated in a
pair of spine nodes for redundancy, that the mobile device showed up. At pair of spine nodes for redundancy, that the mobile device showed up. At
that point the anchor points may encapsulate traffic to the leaf, which that point the anchor points may encapsulate traffic to the leaf, which
decapsulates and forward to the attached mobile node, as illustrated in decapsulates and forward to the attached mobile node as illustrated in
<xref target="mobreg"/>; <xref target="mobreg"/>;
</t> </t>
<t> <t>
If a superspine is deployed then it makes sense to flood the superspine so If a superspine is deployed then it makes sense to flood the superspine so
all superspine nodes can perform the encapsulation, as illustrated in all superspine nodes can perform the encapsulation as illustrated in
<xref target="mobtunnel"/>. The alternative is either for the anchor points <xref target="mobtunnel"/>. The alternative is either for the anchor points
to flood the spine so any spine node can perform the encapsulation, or to to flood the spine so any spine node can perform the encapsulation, or to
disaggregate the mobile prefix. disaggregate the mobile prefix.
</t> </t>
</list> </list>
</t> </t>
--> -->
skipping to change at line 10661 skipping to change at line 10877
</section> </section>
<!-- <section title="Fast Mobility"> --> <!-- <section title="Fast Mobility"> -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Key/Value (KV) Store</name> <name>Key/Value (KV) Store</name>
<section numbered="true" toc="default" anchor="kv"> <section numbered="true" toc="default" anchor="kv">
<name>Southbound</name> <name>Southbound</name>
<t> <t>
RIFT supports the southbound distribution of key-value pairs that RIFT supports the southbound distribution of key-value pairs that
can be used to distribute information to facilitate higher levels can be used to distribute information to facilitate higher levels
of functionality (e.g. distribution of configuration information). of functionality (e.g., distribution of configuration information).
KV South TIEs may arrive from multiple nodes and therefore MUST exec KV South TIEs may arrive from multiple nodes and therefore <bcp14>MU
ute ST</bcp14> execute
the following tie-breaking rules for each key: the following tie-breaking rules for each key:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Only KV TIEs received from nodes to which a bi-directional adj <li>Only KV TIEs received from nodes to which a bidirectional adja
acency cency
exists MUST be considered.</li> exists <bcp14>MUST</bcp14> be considered.</li>
<li> <li>
For each valid KV South TIEs that contains the same key, the value For each valid KV South TIEs that contains the same key, the value
within the South TIE with the highest level will be preferre d. within the South TIE with the highest level will be preferre d.
If the levels are identical, the highest originating System ID If the levels are identical, the highest originating System ID
will be preferred. In the case of overlapping keys in the will be preferred. In the case of overlapping keys in the
winning South TIE, the behavior is undefined. winning South TIE, the behavior is undefined.
</li> </li>
</ol> </ol>
<t> <t>
Consider that if a node goes down, nodes south of it will lose assoc iated Consider that if a node goes down, nodes south of it will lose assoc iated
adjacencies causing them to disregard corresponding KVs. adjacencies, causing them to disregard corresponding KVs.
New KV South TIEs are advertised to prevent stale information being New KV South TIEs are advertised to prevent stale information being
used by nodes that are further south. used by nodes that are further south.
KV advertisements southbound are not a result of independent KV advertisements southbound are not a result of independent
computation by every node over the same set of South TIEs, computation by every node over the same set of South TIEs
but a diffused computation. but a diffused computation.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Northbound</name> <name>Northbound</name>
<t>Certain use cases necessitate distribution of essential KV inform ation that <t>Certain use cases necessitate distribution of essential KV inform ation that
is generated by the leaves in the northbound direction. Such inform ation is generated by the leaves in the northbound direction. Such inform ation
is flooded in KV North TIEs. Since the originator of the KV North T IEs is is flooded in KV North TIEs. Since the originator of the KV North T IEs is
preserved during flooding, the corresponding mechanism will define, if necessary, tie-breaking rules depending on the semantics of the information. preserved during flooding, the corresponding mechanism will define, if necessary, tie-breaking rules depending on the semantics of the information.
</t> </t>
<t> <t>
Only KV TIEs from nodes that are reachable via multiplane reac Only KV TIEs from nodes that are reachable via multi-plane rea
hability chability
computation mentioned in <xref target="neg_dis_computation_sec computation mentioned in <xref target="neg_dis_computation_sec
"/> SHOULD be considered. "/> <bcp14>SHOULD</bcp14> be considered.
</t> </t>
</section> </section>
</section> </section>
<section anchor="bfd" numbered="true" toc="default"> <section anchor="bfd" numbered="true" toc="default">
<name>Interactions with BFD</name> <name>Interactions with BFD</name>
<t>RIFT MAY incorporate <xref target="RFC5881" format="default">BFD</x ref> to react quickly <t>RIFT <bcp14>MAY</bcp14> incorporate <xref target="RFC5881" format=" default">Bidirectional Forwarding Detection (BFD)</xref> to react quickly
to link failures. In such case, the following procedures to link failures. In such case, the following procedures
are introduced: </t> are introduced: </t>
<ul empty="true" spacing="normal"> <ol type="1" spacing="normal">
<li>After RIFT <em>ThreeWay</em> hello adjacency convergence <li>After RIFT <em>ThreeWay</em> hello adjacency convergence, a BFD
a BFD session MAY be formed automatically session <bcp14>MAY</bcp14> be formed automatically between the
between the RIFT endpoints without further configuration RIFT endpoints without further configuration using the exchanged
using the exchanged discriminators that are equal to the <em>loc discriminators that are equal to the <em>local_id</em> in the
al_id</em> in the <em>LIEPacket</em>. The capability of the <em>LIEPacket</em>. The capability of the remote side to support
remote side to support BFD is carried in the LIEs in <em>LinkCap BFD is carried in the LIEs in <em>LinkCapabilities</em>.</li>
abilities</em>.</li>
<li>In case an established BFD session goes Down after it was Up, RI <!--[rfced] May we update "Init" to "Initial state"?
FT
adjacency SHOULD be re-initialized and subsequently started from Original:
Init after In case an established BFD session goes Down after it was Up, RIFT
it receives a consecutive BFD Up.</li> adjacency SHOULD be re-initialized and subsequently started from
<li>In case of parallel Init after it receives a consecutive BFD Up.
links between nodes each link MAY run its own independent BFD se
ssion Perhaps:
or they MAY share a session. The specific manner in which this i In case an established BFD session goes Down after it was Up, RIFT
s implemented is outside the scope of this document. adjacency SHOULD be re-initialized and subsequently started from
the Initial state after it receives a consecutive BFD Up.
-->
<li>In case an established BFD session goes down after it was up,
RIFT adjacency <bcp14>SHOULD</bcp14> be re-initialized and
subsequently started from Init after it receives a consecutive BFD
Up.</li>
<li>In case of parallel links between nodes, each link
<bcp14>MAY</bcp14> run its own independent BFD session or they
<bcp14>MAY</bcp14> share a session. The specific manner in which
this is implemented is outside the scope of this document.
</li> </li>
<li> If link identifiers or BFD capabilities change, both the LIE an <li> If link identifiers or BFD capabilities change, both the LIE
d and any BFD sessions <bcp14>SHOULD</bcp14> be brought down and
any BFD sessions SHOULD be brought down and back up again. back up again. In case only the advertised capabilities change,
In case only the advertised capabilities change, the node MAY the node <bcp14>MAY</bcp14> choose to persist the BFD session.
choose to persist the BFD session.
</li> </li>
<li>Multiple RIFT instances MAY choose to share a single BFD session <li>Multiple RIFT instances <bcp14>MAY</bcp14> choose to share a
, single BFD session; in such cases, the behavior for which
in such cases the behavior for which discriminators are used is discriminators are used is undefined. However, RIFT
undefined. <bcp14>MAY</bcp14> advertise the same link ID for the same
However, RIFT MAY advertise the same link ID for the same interf interface in multiple instances to "share" discriminators.</li>
ace in multiple
instances to "share" discriminators.</li>
<li>The BFD TTL follows <xref target="RFC5082" format="default"/>.</ li> <li>The BFD TTL follows <xref target="RFC5082" format="default"/>.</ li>
</ul> </ol>
</section> </section>
<section anchor="bwb" numbered="true" toc="default"> <section anchor="bwb" numbered="true" toc="default">
<name>Fabric Bandwidth Balancing</name> <name>Fabric Bandwidth Balancing</name>
<t>A well understood problem in fabrics is that, in case of link failu res, <t>A well understood problem in fabrics is that, in case of link failu res,
it would be ideal to rebalance how much traffic is sent to switches in t he it would be ideal to rebalance how much traffic is sent to switches in t he
next level based on available ingress and egress bandwidth. next level based on the available ingress and egress bandwidth.
</t> </t>
<t>RIFT supports a light-weight mechanism that can deal with the probl em <t>RIFT supports a light-weight mechanism that can deal with the probl em
based on the fact that RIFT is loop-free. based on the fact that RIFT is loop-free.
</t> </t>
<section anchor="varydefault" numbered="true" toc="default"> <section anchor="varydefault" numbered="true" toc="default">
<name>Northbound Direction</name> <name>Northbound Direction</name>
<t> <t>
Every RIFT node SHOULD compute the Every RIFT node <bcp14>SHOULD</bcp14> compute the
amount of northbound bandwidth available through neighbors at a high er level amount of northbound bandwidth available through neighbors at a high er level
and modify the and modify the
distance received on default route from these neighbors. distance received on the default route from these neighbors.
The bandwidth is advertised in <em>NodeNeighborsTIEElement</em> elem The bandwidth is advertised in the <em>NodeNeighborsTIEElement</em>
ent element,
which represents the sum of the which represents the sum of the
bandwidths of all the parallel links to a neighbor. bandwidths of all the parallel links to a neighbor.
Default routes with differing distances SHOULD be used to Default routes with differing distances <bcp14>SHOULD</bcp14> be use d to
support weighted ECMP forwarding. support weighted ECMP forwarding.
Such a distance is called Bandwidth Adjusted Distance Such a distance is called Bandwidth Adjusted Distance
(BAD). This is best illustrated by a simple example. (BAD). This is best illustrated by a simple example.
</t> </t>
<figure anchor="pic-default-modify"> <figure anchor="pic-default-modify">
<name>Balancing Bandwidth</name> <name>Balancing Bandwidth</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift -rift-example-load-balancing.svg"><svg xmlns:sodipodi="http://sodipodi.sourcefor ge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/in kscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1 999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg= "http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="htt p://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox ="0 0 414.7 375" xml:space="preserve" height="375"> <artwork align="center" name="" type="svg" originalSrc="art/rift -rift-example-load-balancing.svg"><svg xmlns:sodipodi="http://sodipodi.sourcefor ge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/in kscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1 999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg= "http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="htt p://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox ="0 0 414.7 375" xml:space="preserve" height="375">
<path id="path1701-0" fill="none" stroke="#000000" stroke-wi dth="0.9122" stroke-miterlimit="3.4476" d="M70.1,0L70,87.8"/> <path id="path1701-0" fill="none" stroke="#000000" stroke-wi dth="0.9122" stroke-miterlimit="3.4476" d="M70.1,0L70,87.8"/>
skipping to change at line 10865 skipping to change at line 11099
<ellipse id="path531-9-5-8-94-1-7-6-06-4-8-5-08-4-4" fill="# FFFFFF" stroke="#000000" stroke-width="0.8092" stroke-miterlimit="3.4476" cx="33 7.8" cy="325.3" rx="47.8" ry="49.3"/> <ellipse id="path531-9-5-8-94-1-7-6-06-4-8-5-08-4-4" fill="# FFFFFF" stroke="#000000" stroke-width="0.8092" stroke-miterlimit="3.4476" cx="33 7.8" cy="325.3" rx="47.8" ry="49.3"/>
<path id="path1294" d="M307.1,333.4h-9.6v-15.7h2v13.9h7.6V33 3.4z"/> <path id="path1294" d="M307.1,333.4h-9.6v-15.7h2v13.9h7.6V33 3.4z"/>
<path id="path1296" d="M318.5,327.7h-8.4c0,0.7,0.1,1.4,0.3,1 .9c0.2,0.5,0.5,1,0.9,1.3c0.4,0.3,0.8,0.6,1.3,0.8 c0.5,0.2,1,0.3,1.6,0.3c0.8,0,1 .6-0.2,2.3-0.5c0.8-0.3,1.4-0.6,1.7-0.9h0.1v2.2c-0.6,0.3-1.3,0.5-2,0.7c-0.7,0.2-1 .4,0.3-2.1,0.3 c-1.9,0-3.4-0.5-4.4-1.6c-1.1-1.1-1.6-2.6-1.6-4.5c0-1.9,0.5-3.5,1 .5-4.6c1-1.1,2.4-1.7,4-1.7c1.5,0,2.7,0.5,3.6,1.4 c0.8,0.9,1.3,2.2,1.3,4L318.5,3 27.7z M316.6,326.2c0-1-0.3-1.8-0.8-2.4c-0.5-0.6-1.3-0.9-2.3-0.9c-1,0-1.9,0.3-2.5 ,0.9 c-0.6,0.6-1,1.4-1,2.3H316.6z"/> <path id="path1296" d="M318.5,327.7h-8.4c0,0.7,0.1,1.4,0.3,1 .9c0.2,0.5,0.5,1,0.9,1.3c0.4,0.3,0.8,0.6,1.3,0.8 c0.5,0.2,1,0.3,1.6,0.3c0.8,0,1 .6-0.2,2.3-0.5c0.8-0.3,1.4-0.6,1.7-0.9h0.1v2.2c-0.6,0.3-1.3,0.5-2,0.7c-0.7,0.2-1 .4,0.3-2.1,0.3 c-1.9,0-3.4-0.5-4.4-1.6c-1.1-1.1-1.6-2.6-1.6-4.5c0-1.9,0.5-3.5,1 .5-4.6c1-1.1,2.4-1.7,4-1.7c1.5,0,2.7,0.5,3.6,1.4 c0.8,0.9,1.3,2.2,1.3,4L318.5,3 27.7z M316.6,326.2c0-1-0.3-1.8-0.8-2.4c-0.5-0.6-1.3-0.9-2.3-0.9c-1,0-1.9,0.3-2.5 ,0.9 c-0.6,0.6-1,1.4-1,2.3H316.6z"/>
<path id="path1298" d="M330.3,333.4h-1.9v-1.3c-0.2,0.1-0.4,0 .3-0.7,0.5c-0.3,0.2-0.6,0.4-0.8,0.5c-0.3,0.2-0.7,0.3-1.1,0.4 c-0.4,0.1-0.9,0.2- 1.5,0.2c-1,0-1.9-0.4-2.6-1.1c-0.7-0.7-1.1-1.6-1.1-2.7c0-0.9,0.2-1.6,0.6-2.2c0.4- 0.6,0.9-1,1.6-1.3 c0.7-0.3,1.5-0.5,2.5-0.6s2-0.2,3.1-0.3v-0.3c0-0.5-0.1-0.8-0.2 -1.1c-0.2-0.3-0.4-0.5-0.7-0.7c-0.3-0.2-0.6-0.3-1-0.3 c-0.4-0.1-0.8-0.1-1.2-0.1c -0.5,0-1.1,0.1-1.7,0.2c-0.6,0.1-1.3,0.3-1.9,0.6h-0.1v-2c0.4-0.1,0.9-0.2,1.6-0.3 c0.7-0.1,1.4-0.2,2.1-0.2c0.8,0,1.5,0.1,2.1,0.2c0.6,0.1,1.1,0.4,1.6,0.7c0.4,0.3, 0.8,0.7,1,1.3s0.3,1.2,0.3,1.9L330.3,333.4z M328.4,330.5v-3.3c-0.6,0-1.3,0.1-2. 1,0.2c-0.8,0.1-1.4,0.2-1.9,0.3c-0.6,0.2-1,0.4-1.3,0.8c-0.3,0.3-0.5,0.8-0.5,1.4 c0,0.7,0.2,1.2,0.6,1.5c0.4,0.3,1,0.5,1.8,0.5c0.7,0,1.3-0.1,1.9-0.4C327.4,331.2,3 27.9,330.9,328.4,330.5z"/> <path id="path1298" d="M330.3,333.4h-1.9v-1.3c-0.2,0.1-0.4,0 .3-0.7,0.5c-0.3,0.2-0.6,0.4-0.8,0.5c-0.3,0.2-0.7,0.3-1.1,0.4 c-0.4,0.1-0.9,0.2- 1.5,0.2c-1,0-1.9-0.4-2.6-1.1c-0.7-0.7-1.1-1.6-1.1-2.7c0-0.9,0.2-1.6,0.6-2.2c0.4- 0.6,0.9-1,1.6-1.3 c0.7-0.3,1.5-0.5,2.5-0.6s2-0.2,3.1-0.3v-0.3c0-0.5-0.1-0.8-0.2 -1.1c-0.2-0.3-0.4-0.5-0.7-0.7c-0.3-0.2-0.6-0.3-1-0.3 c-0.4-0.1-0.8-0.1-1.2-0.1c -0.5,0-1.1,0.1-1.7,0.2c-0.6,0.1-1.3,0.3-1.9,0.6h-0.1v-2c0.4-0.1,0.9-0.2,1.6-0.3 c0.7-0.1,1.4-0.2,2.1-0.2c0.8,0,1.5,0.1,2.1,0.2c0.6,0.1,1.1,0.4,1.6,0.7c0.4,0.3, 0.8,0.7,1,1.3s0.3,1.2,0.3,1.9L330.3,333.4z M328.4,330.5v-3.3c-0.6,0-1.3,0.1-2. 1,0.2c-0.8,0.1-1.4,0.2-1.9,0.3c-0.6,0.2-1,0.4-1.3,0.8c-0.3,0.3-0.5,0.8-0.5,1.4 c0,0.7,0.2,1.2,0.6,1.5c0.4,0.3,1,0.5,1.8,0.5c0.7,0,1.3-0.1,1.9-0.4C327.4,331.2,3 27.9,330.9,328.4,330.5z"/>
<path id="path1300" d="M340.2,318.9h-0.1c-0.2-0.1-0.5-0.1-0. 8-0.2c-0.3-0.1-0.6-0.1-0.9-0.1c-0.8,0-1.4,0.2-1.8,0.6 c-0.4,0.4-0.6,1.1-0.6,2v0 .4h3.5v1.7h-3.4v10.1h-1.9v-10.1h-1.3v-1.7h1.3v-0.4c0-1.4,0.3-2.5,1-3.2c0.7-0.8,1 .7-1.1,2.9-1.1 c0.4,0,0.8,0,1.2,0.1c0.3,0,0.7,0.1,1,0.1L340.2,318.9z"/> <path id="path1300" d="M340.2,318.9h-0.1c-0.2-0.1-0.5-0.1-0. 8-0.2c-0.3-0.1-0.6-0.1-0.9-0.1c-0.8,0-1.4,0.2-1.8,0.6 c-0.4,0.4-0.6,1.1-0.6,2v0 .4h3.5v1.7h-3.4v10.1h-1.9v-10.1h-1.3v-1.7h1.3v-0.4c0-1.4,0.3-2.5,1-3.2c0.7-0.8,1 .7-1.1,2.9-1.1 c0.4,0,0.8,0,1.2,0.1c0.3,0,0.7,0.1,1,0.1L340.2,318.9z"/>
<path id="path1302" d="M350.6,333.4h-8.3v-1.6h3.2v-10.5h-3.2 v-1.4c0.4,0,0.9,0,1.4-0.1c0.5-0.1,0.9-0.2,1.1-0.3 c0.3-0.2,0.6-0.4,0.7-0.7c0.2- 0.3,0.3-0.6,0.3-1.1h1.6v14.2h3.1V333.4z"/> <path id="path1302" d="M350.6,333.4h-8.3v-1.6h3.2v-10.5h-3.2 v-1.4c0.4,0,0.9,0,1.4-0.1c0.5-0.1,0.9-0.2,1.1-0.3 c0.3-0.2,0.6-0.4,0.7-0.7c0.2- 0.3,0.3-0.6,0.3-1.1h1.6v14.2h3.1V333.4z"/>
<path id="path1304" d="M364,333.4h-8.3v-1.6h3.2v-10.5h-3.2v- 1.4c0.4,0,0.9,0,1.4-0.1c0.5-0.1,0.9-0.2,1.1-0.3 c0.3-0.2,0.6-0.4,0.7-0.7c0.2-0. 3,0.3-0.6,0.3-1.1h1.6v14.2h3.1V333.4z"/> <path id="path1304" d="M364,333.4h-8.3v-1.6h3.2v-10.5h-3.2v- 1.4c0.4,0,0.9,0,1.4-0.1c0.5-0.1,0.9-0.2,1.1-0.3 c0.3-0.2,0.6-0.4,0.7-0.7c0.2-0. 3,0.3-0.6,0.3-1.1h1.6v14.2h3.1V333.4z"/>
<path id="path1306" d="M378.2,333.4h-10.3v-2.2c0.7-0.6,1.4-1 .3,2.1-1.9c0.7-0.6,1.4-1.3,2-1.9c1.3-1.3,2.2-2.3,2.7-3.1 c0.5-0.8,0.7-1.6,0.7-2 .5c0-0.8-0.3-1.5-0.8-1.9c-0.5-0.5-1.2-0.7-2.2-0.7c-0.6,0-1.3,0.1-2,0.3c-0.7,0.2- 1.4,0.6-2.1,1h-0.1v-2.2 c0.5-0.2,1.1-0.5,1.9-0.7c0.8-0.2,1.6-0.3,2.4-0.3c1.6,0, 2.8,0.4,3.7,1.2c0.9,0.8,1.3,1.8,1.3,3.2c0,0.6-0.1,1.2-0.2,1.7 c-0.1,0.5-0.4,1-0 .6,1.5c-0.3,0.4-0.6,0.9-0.9,1.3c-0.4,0.4-0.8,0.9-1.3,1.4c-0.7,0.7-1.5,1.5-2.3,2. 2c-0.8,0.7-1.5,1.3-2.2,1.9h8.2 L378.2,333.4z"/> <path id="path1306" d="M378.2,333.4h-10.3v-2.2c0.7-0.6,1.4-1 .3,2.1-1.9c0.7-0.6,1.4-1.3,2-1.9c1.3-1.3,2.2-2.3,2.7-3.1 c0.5-0.8,0.7-1.6,0.7-2 .5c0-0.8-0.3-1.5-0.8-1.9c-0.5-0.5-1.2-0.7-2.2-0.7c-0.6,0-1.3,0.1-2,0.3c-0.7,0.2- 1.4,0.6-2.1,1h-0.1v-2.2 c0.5-0.2,1.1-0.5,1.9-0.7c0.8-0.2,1.6-0.3,2.4-0.3c1.6,0, 2.8,0.4,3.7,1.2c0.9,0.8,1.3,1.8,1.3,3.2c0,0.6-0.1,1.2-0.2,1.7 c-0.1,0.5-0.4,1-0 .6,1.5c-0.3,0.4-0.6,0.9-0.9,1.3c-0.4,0.4-0.8,0.9-1.3,1.4c-0.7,0.7-1.5,1.5-2.3,2. 2c-0.8,0.7-1.5,1.3-2.2,1.9h8.2 L378.2,333.4z"/>
</svg> </svg>
</artwork> </artwork>
<artwork align="center" name="" type="ascii-art" originalSrc="ar t/rift-rift-example-load-balancing.ascii-art"> 100 x 100 100 MBit s <artwork align="center" name="" type="ascii-art" originalSrc="ar t/rift-rift-example-load-balancing.ascii-art"> 100 x 100 100 Mbit /s
| x | | | x | |
+-+---+-+ +-+---+-+ +-+---+-+ +-+---+-+
| | | | | | | |
|Spin111| |Spin112| |Spin111| |Spin112|
+-+---+++ ++----+++ +-+---+++ ++----+++
|x || || || |x || || ||
|| |+---------------+ || || |+---------------+ ||
|| +---------------+| || || +---------------+| ||
|| || || || || || || ||
|| || || || || || || ||
-----All Links 10 MBit------- -----All Links 10 Mbit/s-----
|| || || || || || || ||
|| || || || || || || ||
|| +------------+| || || || +------------+| || ||
|| |+------------+ || || || |+------------+ || ||
|x || || || |x || || ||
+-+---+++ +--++-+++ +-+---+++ +--++-+++
| | | | | | | |
|Leaf111| |Leaf112| |Leaf111| |Leaf112|
+-------+ +-------+</artwork> +-------+ +-------+</artwork>
</artset> </artset>
skipping to change at line 10917 skipping to change at line 11151
The range [<em>normalized_bw_metric_max</em>, <em>normalized_bw_metric_ min</em>] The range [<em>normalized_bw_metric_max</em>, <em>normalized_bw_metric_ min</em>]
leaves intentionally enough space to allow for local configuration leaves intentionally enough space to allow for local configuration
that forces either a lower or higher distance than any automatically that forces either a lower or higher distance than any automatically
computed BAD. computed BAD.
--> -->
<t> <t>
<xref target="pic-default-modify" format="default"/> depicts an exam ple topology where links between <xref target="pic-default-modify" format="default"/> depicts an exam ple topology where links between
leaf and spine nodes leaf and spine nodes
are 10 MBit/s and links from spine nodes northbound are 100 MBit/s. are 10 Mbit/s and links from spine nodes northbound are 100 Mbit/s.
It includes It includes
parallel link failure between Leaf 111 and Spine 111 and as a result parallel link failure between Leaf 111 and Spine 111, and as a resul
, Leaf 111 wants t, Leaf 111 wants
to forward more traffic toward Spine 112. Additionally, it includes to forward more traffic towards Spine 112. Additionally, it include
as well an uplink s an uplink
failure on Spine 111. failure on Spine 111.
</t> </t>
<t> <t>
The local modification of the received default route distance from u pper level The local modification of the received default route distance from t he upper level
is achieved by is achieved by
running a relatively simple algorithm where the bandwidth is weighte d running a relatively simple algorithm where the bandwidth is weighte d
exponentially, while the distance on the default route represents a multiplier exponentially, while the distance on the default route represents a multiplier
for the bandwidth weight for easy operational adjustments. for the bandwidth weight for easy operational adjustments.
</t> </t>
<!--[rfced] To avoid the repetition of "to compute", should this sentence
be updated as follows?
Original:
On a node, L, use Node TIEs to compute from each non-overloaded
northbound neighbor N to compute 3 values:
Perhaps:
On a node, L, use Node TIEs to compute 3 values from each non-overloaded
northbound neighbor, N:
-->
<t>On a node, L, use Node TIEs to <t>On a node, L, use Node TIEs to
compute from each non-overloaded northbound neighbor N to compute 3 values: compute from each non-overloaded northbound neighbor N to compute 3 values:
</t> </t>
<ul empty="true" spacing="normal"> <ol type="1" spacing="normal">
<li>L_N_u: sum of the bandwidth available from L to N (to account for parallel links)</li> <li>L_N_u: sum of the bandwidth available from L to N (to account for parallel links)</li>
<li>N_u: sum of the uplink bandwidth available on N</li> <li>N_u: sum of the uplink bandwidth available on N</li>
<li>T_N_u: L_N_u * OVERSUBSCRIPTION_CONSTANT + N_u</li> <li>T_N_u: L_N_u * OVERSUBSCRIPTION_CONSTANT + N_u</li>
</ul> </ol>
<t>For all T_N_u determine the corresponding M_N_u as log_2(next_pow <t>For all T_N_u, determine the corresponding M_N_u as log_2(next_po
er_2(T_N_u)) and wer_2(T_N_u)) and
determine MAX_M_N_u as maximum value of all such M_N_u values. determine MAX_M_N_u as the maximum value of all such M_N_u values.
</t> </t>
<t>For each advertised default route from a node N modify the advert ised distance D <t>For each advertised default route from a node N, modify the adver tised distance D
to BAD = D * (1 + MAX_M_N_u - M_N_u) and use BAD instead of distance D to BAD = D * (1 + MAX_M_N_u - M_N_u) and use BAD instead of distance D
to weight balance default forwarding towards N.</t> to balance the weight of the default forwarding towards N.</t>
<t>For the example above, a simple table of values will help in unde rstanding <t>For the example above, a simple table of values will help in unde rstanding
of the concept. the concept.
The implicit assumption here is that all default route distances are The implicit assumption here is that all default route distances are
advertised with D=1 and that OVERSUBSCRIPTION_CONSTANT = 1.</t> advertised with D=1 and that OVERSUBSCRIPTION_CONSTANT=1.</t>
<table anchor="BADTable" align="center"> <table anchor="BADTable" align="center">
<name>BAD Computation</name> <name>BAD Computation</name>
<thead> <thead>
<tr> <tr>
<th align="left">Node</th> <th align="left">Node</th>
<th align="left">N</th> <th align="left">N</th>
<th align="left">T_N_u</th> <th align="left">T_N_u</th>
<th align="left">M_N_u</th> <th align="left">M_N_u</th>
<th align="left">BAD</th> <th align="left">BAD</th>
</tr> </tr>
skipping to change at line 10990 skipping to change at line 11237
</tr> </tr>
<tr> <tr>
<td align="left">Leaf112</td> <td align="left">Leaf112</td>
<td align="left">Spine 112</td> <td align="left">Spine 112</td>
<td align="left">220</td> <td align="left">220</td>
<td align="left">8</td> <td align="left">8</td>
<td align="left">1</td> <td align="left">1</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>If a calculation produces a result exceeding the range of the typ e, e.g. bandwidth, <t>If a calculation produces a result exceeding the range of the typ e, e.g., bandwidth,
the result is set to the highest possible value for that type. the result is set to the highest possible value for that type.
</t> </t>
<t>BAD SHOULD only be computed for default routes. A node MAY comput e and use BAD for <t>BAD <bcp14>SHOULD</bcp14> only be computed for default routes. A node <bcp14>MAY</bcp14> compute and use BAD for
any disaggregated any disaggregated
prefixes or other RIFT routes. prefixes or other RIFT routes.
A node MAY use a different algorithm to weight northbound A node <bcp14>MAY</bcp14> use a different algorithm to weight northb
traffic based on bandwidth. If a different algorithm is used, ound
its successful behavior MUST NOT depend on uniformity of algorithm o traffic based on the bandwidth. If a different algorithm is used,
r its successful behavior <bcp14>MUST NOT</bcp14> depend on uniformity
of the algorithm or
synchronization of BAD computations across the fabric. synchronization of BAD computations across the fabric.
E.g. it is For example, it is
conceivable that leaves could use real time link loads gathered by analy tics conceivable that leaves could use real time link loads gathered by analy tics
to change the amount of traffic assigned to each default route next hop.</t> to change the amount of traffic assigned to each default route next hop.</t>
<t> <t>
A change in available bandwidth will only affect, at most, two A change in available bandwidth will only affect, at most, two
levels down in the fabric, i.e., the blast radius of bandwidth adjus tments is levels down in the fabric, i.e., the blast radius of bandwidth adjus tments is
constrained no matter the fabric's height. constrained no matter the fabric's height.
</t> </t>
</section> </section>
<section anchor="varysouthbandwidth" numbered="true" toc="default"> <section anchor="varysouthbandwidth" numbered="true" toc="default">
<name>Southbound Direction</name> <name>Southbound Direction</name>
<t> <t>
Due to its loop free nature, during South SPF, a node MAY account fo r maximum Due to its loop-free nature, during South SPF, a node <bcp14>MAY</bc p14> account for the maximum
available bandwidth on nodes in lower levels and modify the amount o f traffic available bandwidth on nodes in lower levels and modify the amount o f traffic
offered to the next level's southbound nodes. It is worth consideri ng offered to the next level's southbound nodes. It is worth consideri ng
that such computations may be more effective if standardized, but do not that such computations may be more effective if they are standardize d, but they do not
have to be. As long as a packet continues to flow southbound, have to be. As long as a packet continues to flow southbound,
it will take some viable, loop-free path to reach its destination. it will take some viable, loop-free path to reach its destination.
</t> </t>
</section> </section>
</section> </section>
<section anchor="downstreamlabels" numbered="true" toc="default"> <section anchor="downstreamlabels" numbered="true" toc="default">
<name>Label Binding</name> <name>Label Binding</name>
<t> <t>
A node MAY advertise in its LIEs, a locally significant, downstream In its LIEs, a node <bcp14>MAY</bcp14> advertise a locally significa
assigned, interface specific label. One use of such a label is a nt, downstream-assigned, interface-specific label. One use of such a label is a
hop-by-hop encapsulation allowing forwarding planes to be hop-by-hop encapsulation allowing forwarding planes to be
easily distinguished among multiple RIFT instances. easily distinguished among multiple RIFT instances.
</t> </t>
</section> </section>
<section anchor="leaf2leaf" numbered="true" toc="default"> <section anchor="leaf2leaf" numbered="true" toc="default">
<name>Leaf to Leaf Procedures</name> <name>Leaf-to-Leaf Procedures</name>
<t> <t>
RIFT implementations <bcp14>SHOULD</bcp14> support special East-West adj
RIFT implementations SHOULD support special East-West adjacencies acencies
between leaf nodes. Leaf nodes supporting these procedures MUST: between leaf nodes. Leaf nodes supporting these procedures <bcp14>MUST<
/bcp14>:
</t> </t>
<ul empty="true" spacing="normal"> <ol type="1" spacing="normal">
<li>advertise the <li>advertise the LEAF_2_LEAF flag in its node capabilities,</li>
LEAF_2_LEAF flag in its node capabilities <strong>and</strong></ <li> set the overload flag on all leaf's Node TIEs,</li>
li> <li>flood only a node's own North and South TIEs over E-W leaf
<li> adjacencies,</li>
set the overload flag on all leaf's Node TIEs <strong>and</stron <li>always use E-W leaf adjacency in all SPF computations,</li>
g></li> <li>install a discard route for any advertised aggregate routes in
<li>flood only a node's own north and south TIEs over E-W leaf adjac a leaf's TIE, <strong>and</strong></li>
encies <strong>and</strong> </li>
<li>always use E-W leaf adjacency in all SPF computations <strong>an
d</strong></li>
<li>install a discard route for any advertised aggregate routes in a
leaf's TIE <strong>and</strong></li>
<li>never form southbound adjacencies.</li> <li>never form southbound adjacencies.</li>
</ul> </ol>
<t>This will allow the E-W leaf nodes to exchange traffic strictly for the prefixes <t>This will allow the E-W leaf nodes to exchange traffic strictly for the prefixes
advertised in each other's north prefix TIEs since the southbound comput ation will advertised in each other's north prefix TIEs since the southbound comput ation will
find the reverse direction in the other node's TIE and install its north prefixes. find the reverse direction in the other node's TIE and install its north prefixes.
</t> </t>
</section> </section>
<!-- leaf-to-leaf --> <!-- leaf-to-leaf -->
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Address Family and Multi Topology Considerations</name> <name>Address Family and Multi-Topology Considerations</name>
<t>Multi-Topology (MT)<xref target="RFC5120" format="default"/> <t>Multi-Topology (MT) <xref target="RFC5120" format="default"/>
and Multi-Instance (MI)<xref target="RFC8202" format="default"/> and Multi-Instance (MI) <xref target="RFC8202" format="default"/>
concepts concepts
are used today in link-state routing protocols to are used today in link-state routing protocols to
support several domains on the same support several domains on the same
physical topology. RIFT supports this capability by physical topology. RIFT supports this capability by
carrying transport ports in the LIE protocol carrying transport ports in the LIE protocol
exchanges. Multiplexing of LIEs can be achieved by exchanges. Multiplexing of LIEs can be achieved by
either choosing varying multicast addresses or ports either choosing varying multicast addresses or ports
on the same address. on the same address.
</t> </t>
<t>BFD interactions in <xref target="bfd" format="default"/> <t>BFD interactions in <xref target="bfd" format="default"/>
are implementation dependent when multiple RIFT instances run on the are implementation-dependent when multiple RIFT instances run on the
same link.</t> same link.</t>
</section> </section>
<section anchor="healing" numbered="true" toc="default"> <section anchor="healing" numbered="true" toc="default">
<name>One-Hop Healing of Levels with East-West Links</name> <name>One-Hop Healing of Levels with East-West Links</name>
<t> <t>
Based on the rules defined in <xref target="calculate" format="default"/ Based on the rules defined in Sections <xref target="calculate" format="
>, counter"/> and
<xref target="defaultrouterules" format="default"/> and <xref target="defaultrouterules" format="counter"/> and
given the presence of E-W links, RIFT can provide a one-hop protection f or nodes that have lost given the presence of E-W links, RIFT can provide a one-hop protection f or nodes that have lost
all their northbound links. This can also be applied to multi-plane desi gns all their northbound links. This can also be applied to multi-plane desi gns
where complex link set failures occur at the ToF when links are exclusiv ely where complex link set failures occur at the ToF when links are exclusiv ely
used for flooding topology information. used for flooding topology information.
<xref target="onastickexample" format="default"/> outlines this behavior . <xref target="onastickexample" format="default"/> outlines this behavior .
</t> </t>
</section> </section>
</section> </section>
<section anchor="security-section" numbered="true" toc="default"> <section anchor="security-section" numbered="true" toc="default">
<name>Security</name> <name>Security</name>
<section anchor="model" numbered="true" toc="default"> <section anchor="model" numbered="true" toc="default">
<name>Security Model</name> <name>Security Model</name>
<t> <t>
An inherent property of any security and ZTP architecture is the An inherent property of any security and ZTP architecture is the
resulting trade-off in regard to integrity verification of the resulting trade-off in regard to integrity verification of the
information distributed through the fabric vs. provisioning information distributed through the fabric vs. provisioning
and auto-configuration requirements. At a minimum the security of and autoconfiguration requirements. At a minimum, the security of
an established adjacency should be ensured. The stricter the security an established adjacency should be ensured. The stricter the security
model the more provisioning must take over the role of ZTP. model, the more provisioning must take over the role of ZTP.
</t> </t>
<t> <t>
RIFT supports the following security models to allow for flexible contro l by the operator. RIFT supports the following security models to allow for flexible contro l by the operator:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
The most security conscious operators may choose to have control over which The most security-conscious operators may choose to have control over which
ports interconnect between a given pair of nodes, such a model is called the "Port-Association Model" (PAM). ports interconnect between a given pair of nodes, such a model is called the "Port-Association Model" (PAM).
This is achievable by configuring each pair of directly connected ports with a designated This is achievable by configuring each pair of directly connected ports with a designated
shared key or public/private key pair. shared key or public/private key pair.
</li> </li>
<li> <li>
In physically secure data center locations, operators may choose to In physically secure data center locations, operators may choose to
control connectivity between entire nodes, called here control connectivity between entire nodes, called here
the "Node-Association Model" (NAM). A benefit of this model is the "Node-Association Model" (NAM). A benefit of this model is
that it allows for simplified port sparing. that it allows for simplified port sparing.
</li> </li>
skipping to change at line 11141 skipping to change at line 11386
These models may be mixed throughout the fabric depending upon s ecurity These models may be mixed throughout the fabric depending upon s ecurity
requirements at various levels of the fabric and willingness to accept requirements at various levels of the fabric and willingness to accept
increased provisioning complexity. increased provisioning complexity.
</li> </li>
</ul> </ul>
<t> <t>
In order to support the cases mentioned above, RIFT implementations supp orts, through In order to support the cases mentioned above, RIFT implementations supp orts, through
operator control, mechanisms that allow for: operator control, mechanisms that allow for:
</t> </t>
<ol spacing="normal" type="a">
<li>specification of the appropriate level in the fabric,</li>
<li>discovery and reporting of missing connections, </li>
<li>discovery and reporting of unexpected connections while preventi
ng them
from forming insecure adjacencies. </li>
</ol>
<t>
Operators may only choose to configure the level of each node, <ul spacing="normal">
<li>a specification of the appropriate level in the fabric,</li>
<li>discovery and reporting of missing connections, and </li>
<li>discovery and reporting of unexpected connections while
preventing them from forming insecure adjacencies. </li>
</ul>
<t>
Operators may only choose to configure the level of each node
but not explicitly configure which connections are allowed. but not explicitly configure which connections are allowed.
In this case, RIFT will only allow adjacencies to establish between In this case, RIFT will only allow adjacencies to establish between
nodes that are in adjacent levels. Operators with the lowest nodes that are in adjacent levels. Operators with the lowest
security requirements may not use any configuration to specify security requirements may not use any configuration to specify
which connections are allowed. Nodes in such fabrics could rely which connections are allowed. Nodes in such fabrics could rely
fully on ZTP and only established adjacencies between nodes in adjacent fully on ZTP and established adjacencies between nodes in adjacent level
levels. s.
<xref target="security-model-dig" format="default"/> illustrates inheren <xref target="security-model-dig" format="default"/> illustrates inheren
t tradeoffs t trade-offs
between the different security models. between the different security models.
</t> </t>
<t> <t>
Some level of link quality verification may be required prior to an Some level of link quality verification may be required prior to an
adjacency being used for forwarding. adjacency being used for forwarding.
For For
example, an implementation may require that a BFD session comes up example, an implementation may require that a BFD session comes up
before advertising the adjacency. before advertising the adjacency.
</t> </t>
<t> <t>
For the cases outlined above, RIFT has two approaches to enforce For the cases outlined above, RIFT has two approaches to enforce
that a local port is connected to the correct port on the correct remote node. that a local port is connected to the correct port on the correct remote node.
One approach is to piggy-back on RIFT's authentication mechanism. One approach is to piggyback on RIFT's authentication mechanism.
Assuming the provisioning model (e.g. YANG) is flexible enough, operators Assuming the provisioning model (e.g., YANG) is flexible enough, operators
can choose to provision a unique authentication key for the following concep tual models: can choose to provision a unique authentication key for the following concep tual models:
</t> </t>
<ol spacing="normal" type="a"> <ul spacing="normal">
<li> each pair of ports in "port-association model" or </li> <li> each pair of ports in "port-association model" </li>
<li> each pair of switches in "node-association model" or </li> <li> each pair of switches in "node-association model", or </li>
<li> the entire fabric in "fabric-association model". </li> <li> the entire fabric in "fabric-association model". </li>
</ol> </ul>
<t> <t>
The other approach is to rely on the System ID, port-id and level The other approach is to rely on the System ID, port-id, and level
fields in the LIE message to validate an adjacency against the fields in the LIE message to validate an adjacency against the
expected cabling topology, and optionally introduce some expected cabling topology and optionally introduce some
new rules in the FSM to allow the adjacency to come up if the new rules in the FSM to allow the adjacency to come up if the
expectations are met. expectations are met.
</t> </t>
<figure anchor="security-model-dig"> <figure anchor="security-model-dig">
<name>Security Model</name> <name>Security Model</name>
<artset> <artset>
<artwork align="center" name="" type="ascii-art" originalSrc="art/ rift-rift-security-model.ascii-art"> ^ /\ | <artwork align="center" name="" type="ascii-art" originalSrc="art/ rift-rift-security-model.ascii-art"> ^ /\ |
/|\ / \ | /|\ / \ |
| / \ | | / \ |
| / PAM \ | | / PAM \ |
skipping to change at line 11211 skipping to change at line 11457
| +--------------------+ \|/ | +--------------------+ \|/
| / Zero Configuration \ v | / Zero Configuration \ v
+------------------------+ +------------------------+
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="security-mechanisms" numbered="true" toc="default"> <section anchor="security-mechanisms" numbered="true" toc="default">
<name>Security Mechanisms</name> <name>Security Mechanisms</name>
<t> <t>
RIFT Security goals are to ensure: RIFT security goals are to ensure:
</t> </t>
<ol spacing="normal" type="1"> <ul spacing="normal">
<li>authentication</li> <li>authentication,</li>
<li>message integrity</li> <li>message integrity,</li>
<li>the prevention of replay attacks</li> <li>the prevention of replay attacks,</li>
<li>low processing overhead</li> <li>low processing overhead, and</li>
<li>efficient messaging</li> <li>efficient messaging</li>
</ol> </ul>
<t> <t>
unless no security is deployed by means of using `undefined_security key_id` unless no security is deployed by means of using 'undefined_security key_id'
as key identifiers. as key identifiers.
</t> </t>
<t> <t>
Message confidentiality is a non-goal. Message confidentiality is a non-goal.
</t> </t>
<t> <t>
The model in the previous section allows a range of security key types The model in the previous section allows a range of security key types
that are analogous to the various security association models. that are analogous to the various security association models.
PAM and NAM allow security PAM and NAM allow security
associations at the port or node level using symmetric or asymmetric key s associations at the port or node level using symmetric or asymmetric key s
that are pre-installed. FAM argues for security that are preinstalled. FAM argues for security
associations to be applied only at a group level or to be refined once associations to be applied only at a group level or to be refined once
the topology has been established. the topology has been established.
RIFT does not specify how security keys are installed or updated, RIFT does not specify how security keys are installed or updated,
though it does specify how the key can be used to achieve security goals . though it does specify how the key can be used to achieve security goals .
</t> </t>
<t>The protocol has provisions for "weak" nonces to prevent replay att acks <t>The protocol has provisions for "weak" nonces to prevent replay att acks
and includes authentication and includes authentication
mechanisms comparable to <xref target="RFC5709" format="default"/> a nd mechanisms comparable to those described in <xref target="RFC5709" f ormat="default"/> and
<xref target="RFC7987" format="default"/>. <xref target="RFC7987" format="default"/>.
</t> </t>
</section> </section>
<section anchor="security-envelope" numbered="true" toc="default"> <section anchor="security-envelope" numbered="true" toc="default">
<name>Security Envelope</name> <name>Security Envelope</name>
<t> <t>
A serialized schema <em>ProtocolPacket</em> MUST be carried in a secure enve lope illustrated in A serialized schema <em>ProtocolPacket</em> <bcp14>MUST</bcp14> be carried i n a secure envelope as illustrated in
<xref target="secenvelope" format="default"/>. <xref target="secenvelope" format="default"/>.
The <em>ProtocolPacket</em> MUST be serialized using the default Thrift's Bi The <em>ProtocolPacket</em> <bcp14>MUST</bcp14> be serialized using the defa
nary Protocol. ult Thrift's binary protocol.
Any value in the packet following a security fingerprint MUST be used by a r
eceiver only <!--[rfced] As this is a long sentence, may we break it up to improve
its readability?
Original:
Any value in
the packet following a security fingerprint MUST be used by a
receiver only after the fingerprint generated based on acceptable,
advertised key ID has been validated against the data covered by it
bare exceptions arising from operational exigencies where, based on
local configuration, a node MAY allow for the envelope's integrity
checks to be skipped and for behavior specified in Section 6.9.6.
Perhaps:
Any value in
the packet following a security fingerprint MUST be used by a
receiver only after the fingerprint generated based on an acceptable,
advertised key ID has been validated against the data covered by the
bare exceptions arising from operational exigencies. Based on
local configuration, a node MAY allow for the envelope's integrity
checks to be skipped and for the procedure specified in Section 6.9.6
to be implemented.
-->
Any value in the packet following a security fingerprint <bcp14>MUST</bcp14>
be used by a receiver only
after the fingerprint generated based on acceptable, advertised key ID has b een validated against the data covered by after the fingerprint generated based on acceptable, advertised key ID has b een validated against the data covered by
it bare exceptions arising from operational exigencies where, based on it bare exceptions arising from operational exigencies where, based on
local configuration, a node MAY allow for the envelope's integrity chec ks to be skipped local configuration, a node <bcp14>MAY</bcp14> allow for the envelope's integrity checks to be skipped
and for behavior specified in <xref target="security-association"/>. Th is means that for all packets, in case the node is and for behavior specified in <xref target="security-association"/>. Th is means that for all packets, in case the node is
configured to validate the outer fingerprint based on a key ID, an unexpecte d key ID or fingerprint not validating against configured to validate the outer fingerprint based on a key ID, an unexpecte d key ID or fingerprint not validating against the
expected key ID will lead to packet expected key ID will lead to packet
rejection. Further, in case of reception of a TIE, and the receiver being co nfigured to validate rejection. Further, in case of reception of a TIE and the receiver being con figured to validate
the originator by checking the TIE Origin Security Envelope Header fingerpri nt against a key ID, an incorrect the originator by checking the TIE Origin Security Envelope Header fingerpri nt against a key ID, an incorrect
key ID or key ID or
inner fingerprint not validating against the key ID will lead to the rejecti on of the packet. inner fingerprint not validating against the key ID will lead to the rejecti on of the packet.
</t> </t>
<t> <t>
For reasons of clarity it is important to observe that the speci For reasons of clarity, it is important to observe that the spec
fication uses the word fingerprint and ification uses the words "fingerprint" and
signature interchangeably since the specific properties of the f "signature" interchangeably since the specific properties of the
ingerprint part of the envelope depend fingerprint part of the envelope depend
on the algorithms used to insure the payload integrity. Moreover , any security chosen never implies on the algorithms used to insure the payload integrity. Moreover , any security chosen never implies
encryption due to performance impact involved but only fingerpri nt or signature generation and validation. encryption due to performance impact involved but only fingerpri nt or signature generation and validation.
</t> </t>
<t> <t>
An implementation MUST implement at least both sending and recei ving An implementation <bcp14>MUST</bcp14> implement at least both se nding and receiving
HMAC-SHA256 fingerprints as defined in <xref target="keys-regist ry"/> to ensure HMAC-SHA256 fingerprints as defined in <xref target="keys-regist ry"/> to ensure
interoperability but MAY use `undefined_securitykey_id` by defau lt. interoperability but <bcp14>MAY</bcp14> use 'undefined_securityk ey_id' by default.
</t> </t>
<figure anchor="secenvelope"> <figure anchor="secenvelope">
<name>Security Envelope</name> <name>Security Envelope</name>
<artset> <artset>
<artwork align="center" name="" type="ascii-art" originalSrc="art/ <artwork align="center" name="" type="ascii-art" originalSrc="art/
rift-rift-security-envelope.ascii-art"> 0 1 rift-rift-security-envelope.ascii-art">
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
UDP Header: UDP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | RIFT destination port | | Source Port | RIFT destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum | | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer Security Envelope Header: -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outer Security Envelope Header:
| RIFT MAGIC | Packet Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RIFT MAGIC | Packet Number |
| Reserved | RIFT Major | Outer Key ID | Fingerprint | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Version | | Length | | Reserved | RIFT Major | Outer Key ID | Fingerprint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Version | | Length |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Security Fingerprint covers all following content ~ | |
| | ~ Security Fingerprint covers all following content ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| Weak Nonce Local | Weak Nonce Remote | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weak Nonce Local | Weak Nonce Remote |
| Remaining TIE Lifetime (all 1s in case of LIE) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remaining TIE Lifetime (all 1s in case of LIE) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TIE Origin Security Envelope Header: -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TIE Origin Security Envelope Header:
| TIE Origin Key ID | Fingerprint | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Length | | TIE Origin Key ID | Fingerprint |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Length |
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Security Fingerprint covers all following content ~ | |
| | ~ Security Fingerprint covers all following content ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Serialized RIFT Model Object -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Serialized RIFT Model Object
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Serialized RIFT Model Object ~ | |
| | ~ Serialized RIFT Model Object ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork> | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>
</artset> </artset>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+&lt;/artwork&gt;
</figure> </figure>
<dl newline="true" spacing="normal"> <dl newline="false" spacing="normal">
<dt>RIFT MAGIC:</dt> <dt>RIFT MAGIC:</dt>
<dd>16 bits. Constant value of 0xA1F7 that allows easy classificatio <dd><t>16 bits</t>
n of <t>Constant value of 0xA1F7 that allows easy classification of
RIFT packets independent of the UDP port used. RIFT packets independent of the UDP port used.
</dd> </t></dd>
<dt>Packet Number:</dt> <dt>Packet Number:</dt>
<dd>16 bits. An optional, per adjacency, per packet type number set <dd><t>16 bits</t>
using <t>An optional, per-adjacency, per-packet type number set using
the sequence number arithmetic defined in <xref target="arithmeti the sequence number arithmetic defined in <xref
c" format="default"/>. target="arithmetic" format="default"/>. If the arithmetic in
If the arithmetic in <xref target="arithmetic" format="default"/> <xref target="arithmetic" format="default"/> is not used, the node
is not used the node <bcp14>MUST</bcp14> set the value to
MUST set the value to <em>undefined_packet_number</em>. This numb <em>undefined_packet_number</em>. This number can be used to
er can detect losses and misordering in flooding for either operational
be used to detect losses and misordering in flooding for ei purposes or in implementation to adjust flooding behavior to
ther operational current link or buffer quality. This number <bcp14>MUST
purposes or in implementation to adjust flooding behavior t NOT</bcp14> be used to discard or validate the correctness of
o current packets. Packet numbers are incremented on each interface and
link or buffer quality. This number MUST NOT be used to dis within that for each type of packet independently. This allows
card or parallelizing packet generation and processing for different types
validate the correctness of packets. Packet numbers are inc within an implementation, if so desired.</t>
remented on
each interface and within that for each type of packet inde
pendently. This allows parallelizing packet generation and processing for differ
ent types within an
implementation if so desired.
</dd> </dd>
<dt>RIFT Major Version:</dt> <dt>RIFT Major Version:</dt>
<dd>8 bits. <dd><t>8 bits</t>
This value MUST be set to `protocol_major_version` defined i <t>This value <bcp14>MUST</bcp14> be set to
n the schema and used to "protocol_major_version", which is defined in the schema and used to
serialize the object contained. serialize the object contained. It allows checking whether
It allows checking whether protocol versions are compatible on both sides, i.e., which schema
protocol versions are compatible on both sides, i.e., which version is necessary to decode the serialized object. An
schema version is necessary to decode implementation <bcp14>MUST</bcp14> drop packets with unexpected
the serialized object. values and <bcp14>MAY</bcp14> report a problem. The specification
An implementation MUST drop packets with unexpected values of how an implementation may negotiate the schema's major version
and MAY report a is outside the scope of this document.</t>
problem. The specification of how an implementation may neg
otiate the schema's major version is
outside the scope of this document.
</dd> </dd>
<dt>Outer Key ID:</dt> <dt>Outer Key ID:</dt>
<dd>8 bits. A simple, unstructured value acting as indirection into <dd><t>8 bits</t>
a structure holding an algorithm and any related secrets <t>A simple, unstructured value acting as indirection into a
necessary to validate any provided outer security fingerprint or structure holding an algorithm and any related secrets necessary
signature. to validate any provided outer security fingerprint or signature.
Value <em>undefined_securitykey_id</em> means that no valid fing The value <em>undefined_securitykey_id</em> means that no valid
erprint was computed or is fingerprint was computed or is provided; otherwise, one of the
provided, otherwise one of the algorithms in <xref target="keys- algorithms in <xref target="keys-registry"/> <bcp14>MUST</bcp14>
registry"/> MUST be used to compute the fingerprint. be used to compute the fingerprint.
This Key ID This key ID
scope is scope is
local to the nodes on both ends of the adjacency. local to the nodes on both ends of the adjacency.
</dd> </t></dd>
<dt>TIE Origin Key ID:</dt> <dt>TIE Origin Key ID:</dt>
<dd> 24 bits. A simple, unstructured value acting as indirection in <dd><t>24 bits</t>
to a structure holding an algorithm and any related secrets <t>A simple, unstructured value acting as indirection into a
necessary to validate any provided inner security fingerprint or structure holding an algorithm and any related secrets necessary
signature. to validate any provided inner security fingerprint or signature.
Value <em>undefined_securitykey_id</em> means that no valid fing The value <em>undefined_securitykey_id</em> means that no valid
erprint was computed, fingerprint was computed; otherwise, one of the algorithms in <xref
otherwise one of the algorithms in <xref target="keys-registry"/ target="keys-registry"/> <bcp14>MUST</bcp14> be used to compute
> MUST be used to compute the fingerprint.. This Key ID the fingerprint. This key ID scope is global to the RIFT instance
scope is since it may imply the originator of the TIE so the contained
global to the RIFT instance since it may imply the originat object does not have to be deserialized to obtain the originator.
or of the TIE so the </t></dd>
contained object does not have to be de-serialized to obtai <dt>Fingerprint Length:</dt>
n the originator. <dd><t>8 bits</t>
</dd> <t>Length in 32-bit multiples of the following fingerprint (not
<dt>Length of Fingerprint:</dt> including lifetime or weak nonces). It allows the structure to be
<dd>8 bits. Length in 32-bit multiples of the navigated when an unknown key type is present. To clarify, a
following common corner case when this value is set to 0 is when it
fingerprint (not including lifetime or weak nonces). signifies an empty (0 bytes long) security fingerprint.
It allows the structure to be navigated when an unknown key </t></dd>
type is present.
To clarify, a common corner case when this value is set to
0 is when it
signifies an empty (0 bytes long) security fingerprint.
</dd>
<dt>Security Fingerprint:</dt> <dt>Security Fingerprint:</dt>
<dd>32 bits * Length of Fingerprint. <dd><t>32 bits * Fingerprint Length.</t>
This is a signature that is computed over all data followin <t>This is a signature that is computed over all data following
g after it. If the significant bits of the fingerprint are fewer than
after it. If the significant bits of fingerprint are fewer the 32-bit padded length, then the significant bits
than the 32 bits padded length <bcp14>MUST</bcp14> be left aligned and the remaining bits on the
then the significant bits MUST be left right are padded with 0s. When using Public Key Infrastructure (PKI
aligned and ),
remaining bits on the right padded with 0s. the security fingerprint originating node uses its private key to
When using PKI (Public Key Infrastructure) the Security fin create the signature. The original packet can then be verified,
gerprint originating node uses its private key provided the public key is shared and current. Methodology to
to create the signature. The original packet can then be ve negotiate, distribute, or rollover keys is outside the scope of
rified provided the public key is shared this document.
and current. Methodology to negotiate, distribute, or roll </t></dd>
over keys are outside the scope of this document.
</dd>
<dt>Remaining TIE Lifetime:</dt> <dt>Remaining TIE Lifetime:</dt>
<dd>32 bits. <dd><t>32 bits</t>
In case of anything but TIEs this field MUST be set to all <t>In case of anything but TIEs, this field <bcp14>MUST</bcp14> be
ones and Origin set to all ones and the Origin Security Envelope Header <bcp14>MUST
Security Envelope Header MUST NOT be present in the packet. NOT</bcp14> be present in the packet. For TIEs, this field
For TIEs this field represents the remaining lifetime of the TIE and the Origin Security
represents the remaining lifetime of the TIE and Origin Envelope Header <bcp14>MUST</bcp14> be present in the packet.
Security Envelope Header MUST be present in the packet. </t></dd>
</dd> <dt>Weak Nonce Local:</dt>
<dt>Weak Nonce Local: </dt> <dd><t>16 bits</t>
<dd>16 bits. Local Weak Nonce of the adjacency as advertised in <t>Local Weak Nonce of the adjacency, as advertised in LIEs.
LIEs. </t></dd>
</dd> <dt>Weak Nonce Remote:</dt>
<dt>Weak Nonce Remote: </dt> <dd><t>16 bits</t>
<dd>16 bits. Remote Weak Nonce of the adjacency as received in <t>Remote Weak Nonce of the adjacency, as received in LIEs.
LIEs. </t></dd>
</dd>
<dt>TIE Origin Security Envelope Header:</dt> <dt>TIE Origin Security Envelope Header:</dt>
<dd>It MUST be present if <dd>It <bcp14>MUST</bcp14> be present if and only if the Remaining
and only if the Remaining TIE Lifetime TIE Lifetime field is <strong>not</strong> all ones. It carries
field is through the originator's key ID and corresponding fingerprint of
<strong>not</strong> all ones. the object to protect TIE from modification during flooding. This
ensures origin validation and integrity (but does not provide
It carries through the originators Key ID and corresponding validation of a chain of trust).
fingerprint of the
object to protect TIE from modification during flooding. Th
is ensures
origin validation and integrity
(but does not provide validation of a chain of trust).
</dd> </dd>
</dl> </dl>
<t>Observe that due to the schema migration rules per <xref target="sc
hema" format="default"/> the contained <t>Observe that, due to the schema migration rules per <xref target="s
model can be always decoded if the major version matches and the en chema" format="default"/>, the contained
velope integrity model can always be decoded if the major version matches and the en
velope integrity
has been validated. Consequently, description has been validated. Consequently, description
of the TIE is available to flood it properly including unknown TIE types. of the TIE is available to flood it properly, including unknown TIE types.
</t> </t>
</section> </section>
<section anchor="nonces" numbered="true" toc="default"> <section anchor="nonces" numbered="true" toc="default">
<name>Weak Nonces</name> <name>Weak Nonces</name>
<t> <t>
The protocol uses two 16-bit nonces to salt generated signatures. Th e The protocol uses two 16-bit nonces to salt generated signatures. Th e
term "nonce" is used a bit loosely since RIFT nonces are not being c hanged term "nonce" is used a bit loosely since RIFT nonces are not being c hanged
in every packet as often common in cryptography. in every packet, which is common in cryptography.
For efficiency purposes they are changed at a high enough frequency to dwarf For efficiency purposes, they are changed at a high enough frequency to dwarf
practical replay attack attempts. practical replay attack attempts.
And hence, And hence,
such nonces are called from this point on "weak" nonces. such nonces are called from this point on "weak" nonces.
</t> </t>
<t> <t>
Any implementation using outer key ID different from `undefined_secu Any implementation using a different outer key ID from 'undefined_se
ritykey_id` MUST generate and wrap around curitykey_id' <bcp14>MUST</bcp14> generate and wrap around
local nonces properly and SHOULD do it even if not using any algorit local nonces properly and <bcp14>SHOULD</bcp14> do it even if not us
hm in <xref target="keys-registry"/>. ing any algorithm from <xref target="keys-registry"/>.
When a nonce increment leads to <em>undefined_nonce</em> value, When a nonce increment leads to the <em>undefined_nonce</em> value
the value MUST be incremented again immediately. ,
All implementations MUST reflect the neighbor's nonces. the value <bcp14>MUST</bcp14> be incremented again immediately.
An implementation SHOULD All implementations <bcp14>MUST</bcp14> reflect the neighbor's n
onces.
An implementation <bcp14>SHOULD</bcp14>
increment a chosen nonce on every LIE FSM transition that ends up in a different state increment a chosen nonce on every LIE FSM transition that ends up in a different state
from the previous one and MUST increment its nonce at least from the previous one and <bcp14>MUST</bcp14> increment its nonce at least
every <em>nonce_regeneration_interval</em> if using any algorithm in <xref target="keys-registry"/> every <em>nonce_regeneration_interval</em> if using any algorithm in <xref target="keys-registry"/>
(such considerations (such considerations
allow for efficient implementations without opening a significant se curity risk). allow for efficient implementations without opening a significant se curity risk).
When flooding TIEs, the implementation MUST use recent (i.e. within allowed difference) When flooding TIEs, the implementation <bcp14>MUST</bcp14> use recen t (i.e., within allowed difference)
nonces reflected in the LIE exchange. nonces reflected in the LIE exchange.
The schema specifies in <em>maximum_valid_nonce_delta</em> the The schema specifies in <em>maximum_valid_nonce_delta</em> the
maximum allowable nonce value difference on a packet compared to ref lected nonces in the maximum allowable nonce value difference on a packet compared to ref lected nonces in the
LIEs. Any packet received with nonces deviating more than the allowe d delta MUST be LIEs. Any packet received with nonces deviating more than the allowe d delta <bcp14>MUST</bcp14> be
discarded without further computation of signatures to prevent compu tation load attacks. discarded without further computation of signatures to prevent compu tation load attacks.
The delta is either a negative or positive difference that a mirrore d nonce can The delta is either a negative or positive difference that a mirrore d nonce can
deviate from local value to be considered valid. If nonces are deviate from the local value to be considered valid. If nonces are
not changed on every packet but at the maximum interval on both side not changed on every packet, but at the maximum interval on both sid
s this opens statistically es, this opens statistically
a <em>maximum_valid_nonce_delta</em>/2 window for identical LIEs, a <em>maximum_valid_nonce_delta</em>/2 window for identical LIEs,
TIE and TI(x)E replays. TIE, and TI(x)E replays.
The interval cannot be too small since LIE FSM may change The interval cannot be too small since LIE FSM may change
states fairly quickly during ZTP without sending LIEs and additional ly, UDP can states fairly quickly during ZTP without sending LIEs, and additiona lly, UDP can
both loose as well as misorder packets. both loose as well as misorder packets.
</t> </t>
<t> <t>
In cases where a secure implementation does not receive signatures o r In cases where a secure implementation does not receive signatures o r
receives undefined nonces from a neighbor (indicating that it does n ot support receives undefined nonces from a neighbor (indicating that it does n ot support
or verify signatures), it is a matter of local policy as to how thos e or verify signatures), it is a matter of local policy as to how thos e
packets are treated. packets are treated.
A secure implementation MAY refuse forming an adjacency with an impl A secure implementation <bcp14>MAY</bcp14> refuse forming an adjacen
ementation cy with an implementation
that is not advertising signatures or valid nonces, or it MAY contin that is not advertising signatures or valid nonces, or it <bcp14>MAY
ue signing local </bcp14> continue signing local
packets while accepting a neighbor's packets without further securit y validation. packets while accepting a neighbor's packets without further securit y validation.
</t> </t>
<t> <t>
As a necessary exception, an implementation MUST advertise the remot e nonce As a necessary exception, an implementation <bcp14>MUST</bcp14> adve rtise the remote nonce
value as <em>undefined_nonce</em> when the FSM is not in <em>TwoWay< /em> or <em>ThreeWay</em> state value as <em>undefined_nonce</em> when the FSM is not in <em>TwoWay< /em> or <em>ThreeWay</em> state
and accept an <em>undefined_nonce</em> and accept an <em>undefined_nonce</em>
for its local nonce value on packets in any other state than <em>Thr eeWay</em>. for its local nonce value on packets in any other state than <em>Thr eeWay</em>.
</t> </t>
<t> <t>
As an optional optimization, an implementation MAY send one LIE with previously negotiated As an optional optimization, an implementation <bcp14>MAY</bcp14> se nd one LIE with a previously negotiated
neighbor's nonce to try to neighbor's nonce to try to
speed up a neighbor's transition from <em>ThreeWay</em> to <em>OneWa y</em> and MUST revert to sending speed up a neighbor's transition from <em>ThreeWay</em> to <em>OneWa y</em> and <bcp14>MUST</bcp14> revert to sending
<em>undefined_nonce</em> after that. <em>undefined_nonce</em> after that.
</t> </t>
</section> </section>
<section anchor="sec-lifetime" numbered="true" toc="default"> <section anchor="sec-lifetime" numbered="true" toc="default">
<name>Lifetime</name> <name>Lifetime</name>
<t> <t>
Reflooding same TIE version quickly with small variations in its lif etime Reflooding the same TIE version quickly with small variations in its lifetime
may lead to an excessive number of may lead to an excessive number of
security fingerprint security fingerprint
computations. To avoid this, the application generating the fingerpr ints for flooded TIEs computations. To avoid this, the application generating the fingerpr ints for flooded TIEs
MAY round the value down to the next <em>rounddown_lifetime_interval </em> on the <bcp14>MAY</bcp14> round the value down to the next <em>rounddown_li fetime_interval</em> on the
packet header to reuse previous computation results. TIEs flooded w ith packet header to reuse previous computation results. TIEs flooded w ith
such rounded lifetimes only will limit the amount of computations ne such rounded lifetimes will only limit the amount of computations ne
cessary during transitions cessary during transitions
that lead to advertisement of same TIEs with same information within that lead to advertisement of the same TIEs with the same informatio
a short period of time. n within a short period of time.
</t> </t>
</section> </section>
<section anchor="security-association" numbered="true" toc="default"> <section anchor="security-association" numbered="true" toc="default">
<name>Security Association Changes</name> <name>Security Association Changes</name>
<t> <t>
No mechanism is specified to convert a security envelope for the same Ke y ID No mechanism is specified to convert a security envelope for the same ke y ID
from one algorithm to from one algorithm to
another once the envelope is operational. another once the envelope is operational.
The recommended procedure to change to a new algorithm is to take the The recommended procedure to change to a new algorithm is to take the
adjacency down, make the necessary changes to the secret and algorithm u sed adjacency down, make the necessary changes to the secret and algorithm u sed
by the according key ID, and bring the adjacency back up. by the according key ID, and bring the adjacency back up.
Obviously, an implementation MAY choose to stop verifying Obviously, an implementation <bcp14>MAY</bcp14> choose to stop verifying
security envelope for the duration of algorithm change to keep the adjac the
ency up security envelope for the duration of the algorithm change to keep the a
djacency up,
but since this introduces but since this introduces
a security vulnerability window, such roll-over SHOULD NOT be recommende a security vulnerability window, such rollover <bcp14>SHOULD NOT</bcp14>
d. be recommended.
Other approaches, such as accepting multiple algorithms for same key ID Other approaches, such as accepting multiple algorithms for same key ID
for a configured time window for a configured time window,
are possible but in the realm of implementation choices rather than prot ocol specification. are possible but in the realm of implementation choices rather than prot ocol specification.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="schema" numbered="true" toc="default"> <section anchor="schema" numbered="true" toc="default">
<name>Information Elements Schema</name> <name>Information Elements Schema</name>
<t>This section introduces the schema for information elements. <t>This section introduces the schema for information elements.
The IDL is <xref target="thrift" format="default">Thrift</xref>. The IDL is <xref target="thrift" format="default">Thrift</xref>.
</t> </t>
<t>On schema changes that</t> <t>On schema changes that</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>change field numbers <strong>or</strong></li> <li>change field numbers,</li>
<li>add new <strong>required</strong> fields <strong>or</strong></li> <li>add new <strong>required</strong> fields,</li>
<li>remove any fields <strong>or</strong></li> <li>remove any fields.</li>
<li>change lists into sets, unions into structures <strong>or</strong>< <li>change lists into sets and unions into structures,</li>
/li> <li>change the multiplicity of fields,</li>
<li>change multiplicity of fields <strong>or</strong></li> <li>change the type or name of any field,</li>
<li>changes type or name of any field <strong>or</strong></li> <li>change data types of the type of any field,</li>
<li>change data types of the type of any field <strong>or</strong></li> <li>add, change, or remove a default value of any <strong>existing</stro
<li>adds, changes or removes a default value of any <strong>existing</st ng> field,</li>
rong> field <strong>or</strong></li> <li>remove or change any defined constant or constant value,</li>
<li>removes or changes any defined constant or constant value <strong>or <li>change any enumeration type except extending 'common.TIETypeType'
</strong></li> (use of enumeration types is generally discouraged), or</li>
<li>changes any enumeration type except extending `common.TIETypeType` <li>add a new TIE type to <em>TIETypeType</em> with the flooding scope d
(use of enumeration types is generally discouraged) <strong> ifferent from the
or</strong></li>
<li>adds new TIE type to <em>TIETypeType</em> with flooding scope differ
ent from
prefix TIE flooding scope</li> prefix TIE flooding scope</li>
</ol> </ol>
<t>major version of the schema MUST increase. <t>the major version of the schema <bcp14>MUST</bcp14> increase.
All other changes MUST All other changes <bcp14>MUST</bcp14>
increase minor version within the same major.</t> increase the minor version within the same major.</t>
<t>Introducing an optional field <t>Introducing an optional field
does not cause a major version increase even if the fields insid e the does not cause a major version increase even if the fields insid e the
structure are optional with defaults.</t> structure are optional with defaults.</t>
<t>All signed integer as forced by <xref target="thrift" format="default"> Thrift</xref> support must be cast for internal <t>All signed integers, as forced by <xref target="thrift" format="default ">Thrift</xref> support, must be cast for internal
purposes to equivalent unsigned values without discarding the si gnedness bit. purposes to equivalent unsigned values without discarding the si gnedness bit.
An implementation SHOULD try to avoid using the signedness bit w hen An implementation <bcp14>SHOULD</bcp14> try to avoid using the s ignedness bit when
generating values.</t> generating values.</t>
<t>The schema is normative.</t> <t>The schema is normative.</t>
<section anchor="schema_updates" numbered="true" toc="default"> <section anchor="schema_updates" numbered="true" toc="default">
<name>Backwards-Compatible Extension of Schema</name> <name>Backwards-Compatible Extension of Schema</name>
<t> <t>
The set of rules in <xref target="schema"/> guarantees that every decoder can process The set of rules in <xref target="schema"/> guarantees that every decoder can process
serialized content generated serialized content generated
by a higher minor version of the schema and with that the pr otocol can progress without a by a higher minor version of the schema, and with that, the protocol can progress without a
'flag-day'. 'flag-day'.
Contrary to that, content serialized using a major version X is <strong>not</strong> expected to be Contrary to that, content serialized using a major version X is <strong>not</strong> expected to be
decodable by any implementation using decoder for a model wi th a major version lower than X. decodable by any implementation using a decoder for a model with a major version lower than X.
Schema negotiation and translation within RIFT is outside th e scope of this document. Schema negotiation and translation within RIFT is outside th e scope of this document.
</t> </t>
<t>Additionally, based on the propagated minor version in encoded conten t and added <t>Additionally, based on the propagated minor version in encoded conten t and added
optional node capabilities new TIE types or even de-facto ma optional node capabilities, new TIE types or even de facto m
ndatory fields can be introduced andatory fields can be introduced
without progressing the major version albeit only nodes supp without progressing the major version, albeit only nodes sup
orting such new extensions would porting such new extensions would
decode them. Given the model is encoded at the source and ne decode them. Given the model is encoded at the source and ne
ver re-encoded flooding through ver re-encoded, flooding through
nodes not understanding any new extensions will preserve the corresponding fields. nodes not understanding any new extensions will preserve the corresponding fields.
However, it is important to understand that a higher minor v ersion of a schema does <strong>not</strong> However, it is important to understand that a higher minor v ersion of a schema does <strong>not</strong>
guarantee that capabilities introduced in lower minors of th e same major are supported. guarantee that capabilities introduced in lower minors of th e same major are supported.
The <em>node_capabilities</em> field is used to indicate whi ch capabilities are supported. The <em>node_capabilities</em> field is used to indicate whi ch capabilities are supported.
</t> </t>
<t> <t>
Specifically, the schema SHOULD add elements to <em>NodeCapa Specifically, the schema <bcp14>SHOULD</bcp14> add elements
bilities</em> to the <em>NodeCapabilities</em>
field future capabilities to indicate whether it will suppor field's future capabilities to indicate whether it will supp
t ort
interpretation of schema extensions on the same major interpretation of schema extensions on the same major
revision if they are present. Such fields MUST be optional a nd have an implicit or revision if they are present. Such fields <bcp14>MUST</bcp14 > be optional and have an implicit or
explicit false default value. If a future capability changes route explicit false default value. If a future capability changes route
selection or generates conditions that cause packet loss if some nodes are not supporting selection or generates conditions that cause packet loss if some nodes are not supporting
it then a major version increment will be however unavoidabl it, then a major version increment will be unavoidable.
e. <em>NodeCapabilities</em> shown in LIE <bcp14>MUST</bcp14> m
<em>NodeCapabilities</em> shown in LIE MUST match the capabi atch the capabilities shown in the Node TIEs;
lities shown in the Node TIEs, otherwise,
otherwise
the behavior is unspecified. A node detecting the mismatch the behavior is unspecified. A node detecting the mismatch
SHOULD generate a notification. <bcp14>SHOULD</bcp14> generate a notification.
</t> </t>
<t> <t>
Alternately or additionally, new optional fields can be intr oduced Alternately or additionally, new optional fields can be intr oduced
into e.g. <em>NodeTIEElement</em> into, e.g., <em>NodeTIEElement</em>,
if a special field is chosen to indicate via its presence th at an optional feature if a special field is chosen to indicate via its presence th at an optional feature
is enabled (since capability to support a feature does not n ecessarily mean is enabled (since capability to support a feature does not n ecessarily mean
that the feature is actually configured and operational). that the feature is actually configured and operational).
</t> </t>
<t>To support new TIE types without increasing the major version enumera tion <t>To support new TIE types without increasing the major version enumera tion,
<em>TIEElement</em> can be extended with new optional elemen ts <em>TIEElement</em> can be extended with new optional elemen ts
for new `common.TIETypeType` values as long the scope of the new TIE matches for new 'common.TIETypeType' values as long the scope of the new TIE matches
the prefix TIE scope. In case it is necessary to understand whether the prefix TIE scope. In case it is necessary to understand whether
all nodes can parse the new TIE type a node capability MUST all nodes can parse the new TIE type, a node capability <bcp 14>MUST</bcp14>
be added in <em>NodeCapabilities</em> to prevent a non-homog enous network. be added in <em>NodeCapabilities</em> to prevent a non-homog enous network.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="common_thrift_app"> <section numbered="true" toc="default" anchor="common_thrift_app">
<name>common.thrift</name> <name>common.thrift</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<!--[rfced] We note that the following references are only cited in the
sourcecode in Section 7.2. In order to have a 1:1 match-up between the
references section and the text, please review the text and let us know
where a citation for each of the following may be included.
[RFC5837]
[RFC5880]
[RFC6550]
Alternatively, a sentence can be included before the sourcecode stating
that it refers to the following (and then list the citations).
Perhaps:
This schema references [RFC5837], [RFC5880], and [RFC6550].
-->
<sourcecode type=""><![CDATA[
/** /**
Thrift file with common definitions for RIFT Thrift file with common definitions for RIFT
*/ */
namespace py common namespace py common
/** @note MUST be interpreted in implementation as unsigned 64 bits. /** @note MUST be interpreted in implementation as unsigned 64 bits.
*/ */
typedef i64 SystemIDType typedef i64 SystemIDType
typedef i32 IPv4Address typedef i32 IPv4Address
skipping to change at line 11623 skipping to change at line 11925
rolling over number */ rolling over number */
typedef i64 SeqNrType typedef i64 SeqNrType
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i32 LifeTimeInSecType typedef i32 LifeTimeInSecType
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i8 LevelType typedef i8 LevelType
typedef i16 PacketNumberType typedef i16 PacketNumberType
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i32 PodType typedef i32 PodType
/** @note MUST be interpreted in implementation as unsigned. /** @note MUST be interpreted in implementation as unsigned.
/** this has to be long enough to accomodate prefix */ /** this has to be long enough to accommodate prefix */
typedef binary IPv6Address typedef binary IPv6Address
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i16 UDPPortType typedef i16 UDPPortType
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i32 TIENrType typedef i32 TIENrType
/** @note MUST be interpreted in implementation as unsigned /** @note MUST be interpreted in implementation as unsigned
This is carried in the This is carried in the security envelope and must
security envelope and must hence fit into 8 bits. */ hence fit into 8 bits. */
typedef i8 VersionType typedef i8 VersionType
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i16 MinorVersionType typedef i16 MinorVersionType
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i32 MetricType typedef i32 MetricType
/** @note MUST be interpreted in implementation as unsigned /** @note MUST be interpreted in implementation as unsigned
and unstructured */ and unstructured */
typedef i64 RouteTagType typedef i64 RouteTagType
/** @note MUST be interpreted in implementation as unstructured /** @note MUST be interpreted in implementation as unstructured
label value */ label value */
typedef i32 LabelType typedef i32 LabelType
/** @note MUST be interpreted in implementation as unsigned */ /** @note MUST be interpreted in implementation as unsigned */
typedef i32 BandwithInMegaBitsType typedef i32 BandwidthInMegaBitsType
/** @note Key Value Key ID type */ /** @note Key Value key ID type */
typedef i32 KeyIDType typedef i32 KeyIDType
/** node local, unique identification for a link (interface/tunnel /** node local, unique identification for a link (interface/tunnel/
* etc. Basically anything RIFT runs on). This is kept * etc., basically anything RIFT runs on). This is kept
* at 32 bits so it aligns with BFD [RFC5880] discriminator size. * at 32 bits so it aligns with BFD (RFC 5880) discriminator size.
*/ */
typedef i32 LinkIDType typedef i32 LinkIDType
/** @note MUST be interpreted in implementation as unsigned, /** @note MUST be interpreted in implementation as unsigned,
especially since we have the /128 IPv6 case. */ especially since we have the /128 IPv6 case. */
typedef i8 PrefixLenType typedef i8 PrefixLenType
/** timestamp in seconds since the epoch */ /** timestamp in seconds since the epoch */
typedef i64 TimestampInSecsType typedef i64 TimestampInSecsType
/** security nonce. /** security nonce.
@note MUST be interpreted in implementation as rolling @note MUST be interpreted in implementation as rolling
over unsigned value */ over unsigned value */
typedef i16 NonceType typedef i16 NonceType
/** LIE FSM holdtime type */ /** LIE FSM holdtime type */
typedef i16 TimeIntervalInSecType typedef i16 TimeIntervalInSecType
/** Transaction ID type for prefix mobility as specified by RFC6550, /** Transaction ID type for prefix mobility as specified by RFC 6550,
value MUST be interpreted in implementation as unsigned */ value MUST be interpreted in implementation as unsigned */
typedef i8 PrefixTransactionIDType typedef i8 PrefixTransactionIDType
/** Timestamp per IEEE 802.1AS, all values MUST be interpreted in /** Timestamp per IEEE 802.1AS, all values MUST be interpreted in
implementation as unsigned. */ implementation as unsigned. */
struct IEEE802_1ASTimeStampType { struct IEEE802_1ASTimeStampType {
1: required i64 AS_sec; 1: required i64 AS_sec;
2: optional i32 AS_nsec; 2: optional i32 AS_nsec;
} }
/** generic counter type */ /** generic counter type */
typedef i64 CounterType typedef i64 CounterType
/** Platform Interface Index type, i.e. index of interface on hardware, /** Platform Interface Index type, i.e., index of interface on hardware,
can be used e.g. with RFC5837 */ can be used, e.g., with RFC 5837 */
typedef i32 PlatformInterfaceIndex typedef i32 PlatformInterfaceIndex
/** Flags indicating node configuration in case of ZTP. /** Flags indicating node configuration in case of ZTP.
*/ */
enum HierarchyIndications { enum HierarchyIndications {
/** forces level to `leaf_level` and enables according procedures */ /** forces level to 'leaf_level' and enables according procedures */
leaf_only = 0, leaf_only = 0,
/** forces level to `leaf_level` and enables according procedures */ /** forces level to 'leaf_level' and enables according procedures */
leaf_only_and_leaf_2_leaf_procedures = 1, leaf_only_and_leaf_2_leaf_procedures = 1,
/** forces level to `top_of_fabric` and enables according /** forces level to 'top_of_fabric' and enables according
procedures */ procedures */
top_of_fabric = 2, top_of_fabric = 2,
} }
const PacketNumberType undefined_packet_number = 0 const PacketNumberType undefined_packet_number = 0
/** used when node is configured as top of fabric in ZTP.*/ /** used when node is configured as top of fabric in ZTP.*/
const LevelType top_of_fabric_level = 24 const LevelType top_of_fabric_level = 24
/** default bandwidth on a link */ /** default bandwidth on a link */
const BandwithInMegaBitsType default_bandwidth = 100 const BandwidthInMegaBitsType default_bandwidth = 100
/** fixed leaf level when ZTP is not used */ /** fixed leaf level when ZTP is not used */
const LevelType leaf_level = 0 const LevelType leaf_level = 0
const LevelType default_level = leaf_level const LevelType default_level = leaf_level
const PodType default_pod = 0 const PodType default_pod = 0
const LinkIDType undefined_linkid = 0 const LinkIDType undefined_linkid = 0
/** invalid key for key value */ /** invalid key for key value */
const KeyIDType invalid_key_value_key = 0 const KeyIDType invalid_key_value_key = 0
/** default distance used */ /** default distance used */
const MetricType default_distance = 1 const MetricType default_distance = 1
/** any distance larger than this will be considered infinity */ /** any distance larger than this will be considered infinity */
const MetricType infinite_distance = 0x7FFFFFFF const MetricType infinite_distance = 0x7FFFFFFF
/** represents invalid distance */ /** represents invalid distance */
const MetricType invalid_distance = 0 const MetricType invalid_distance = 0
const bool overload_default = false const bool overload_default = false
const bool flood_reduction_default = true const bool flood_reduction_default = true
/** default LIE FSM LIE TX internval time */ /** default LIE FSM LIE TX interval time */
const TimeIntervalInSecType default_lie_tx_interval = 1 const TimeIntervalInSecType default_lie_tx_interval = 1
/** default LIE FSM holddown time */ /** default LIE FSM holddown time */
const TimeIntervalInSecType default_lie_holdtime = 3 const TimeIntervalInSecType default_lie_holdtime = 3
/** multipler for default_lie_holdtime to hold down multiple neighbors */ /** multipler for default_lie_holdtime to hold down multiple neighbors */
const i8 multiple_neighbors_lie_holdtime_multipler = 4 const i8 multiple_neighbors_lie_holdtime_multipler = 4
/** default ZTP FSM holddown time */ /** default ZTP FSM holddown time */
const TimeIntervalInSecType default_ztp_holdtime = 1 const TimeIntervalInSecType default_ztp_holdtime = 1
/** by default LIE levels are ZTP offers */ /** by default LIE levels are ZTP offers */
const bool default_not_a_ztp_offer = false const bool default_not_a_ztp_offer = false
/** by default everyone is repeating flooding */ /** by default everyone is repeating flooding */
const bool default_you_are_flood_repeater = true const bool default_you_are_flood_repeater = true
/** 0 is illegal for SystemID */ /** 0 is illegal for System IDs */
const SystemIDType IllegalSystemID = 0 const SystemIDType IllegalSystemID = 0
/** empty set of nodes */ /** empty set of nodes */
const set<SystemIDType> empty_set_of_nodeids = {} const set<SystemIDType> empty_set_of_nodeids = {}
/** default lifetime of TIE is one week */ /** default lifetime of TIE is one week */
const LifeTimeInSecType default_lifetime = 604800 const LifeTimeInSecType default_lifetime = 604800
/** default lifetime when TIEs are purged is 5 minutes */ /** default lifetime when TIEs are purged is 5 minutes */
const LifeTimeInSecType purge_lifetime = 300 const LifeTimeInSecType purge_lifetime = 300
/** optional round down interval when TIEs are sent with security signatures /** optional round down interval when TIEs are sent with security signatures
to prevent excessive computation. **/ to prevent excessive computation. **/
const LifeTimeInSecType rounddown_lifetime_interval = 60 const LifeTimeInSecType rounddown_lifetime_interval = 60
/** any `TieHeader` that has a smaller lifetime difference /** any 'TieHeader' that has a smaller lifetime difference
than this constant is equal (if other fields equal). */ than this constant is equal (if other fields equal). */
const LifeTimeInSecType lifetime_diff2ignore = 400 const LifeTimeInSecType lifetime_diff2ignore = 400
/** default UDP port to run LIEs on */ /** default UDP port to run LIEs on */
const UDPPortType default_lie_udp_port = 914 const UDPPortType default_lie_udp_port = 914
/** default UDP port to receive TIEs on, that can be peer specific */ /** default UDP port to receive TIEs on, which can be peer specific */
const UDPPortType default_tie_udp_flood_port = 915 const UDPPortType default_tie_udp_flood_port = 915
/** default MTU link size to use */ /** default MTU link size to use */
const MTUSizeType default_mtu_size = 1400 const MTUSizeType default_mtu_size = 1400
/** default link being BFD capable */ /** default link being BFD capable */
const bool bfd_default = true const bool bfd_default = true
/** type used to target nodes with key value */ /** type used to target nodes with key value */
typedef i64 KeyValueTargetType typedef i64 KeyValueTargetType
/** default target for key value are all nodes. */ /** default target for key value are all nodes. */
const KeyValueTargetType keyvaluetarget_default = 0 const KeyValueTargetType keyvaluetarget_default = 0
/** value for _all leaves_ addressing. Represented by all bits set. */ /** value for _all leaves_ addressing. Represented by all bits set. */
const KeyValueTargetType keyvaluetarget_all_south_leaves = -1 const KeyValueTargetType keyvaluetarget_all_south_leaves = -1
/** undefined nonce, equivalent to missing nonce */ /** undefined nonce, equivalent to missing nonce */
const NonceType undefined_nonce = 0; const NonceType undefined_nonce = 0;
/** outer security Key ID, MUST be interpreted as in implementation /** outer security key ID, MUST be interpreted as in implementation
as unsigned */ as unsigned */
typedef i8 OuterSecurityKeyID typedef i8 OuterSecurityKeyID
/** security Key ID, MUST be interpreted as in implementation /** security key ID, MUST be interpreted as in implementation
as unsigned */ as unsigned */
typedef i32 TIESecurityKeyID typedef i32 TIESecurityKeyID
/** undefined key */ /** undefined key */
const TIESecurityKeyID undefined_securitykey_id = 0; const TIESecurityKeyID undefined_securitykey_id = 0;
/** Maximum delta (negative or positive) that a mirrored nonce can /** Maximum delta (negative or positive) that a mirrored nonce can
deviate from local value to be considered valid. */ deviate from local value to be considered valid. */
const i16 maximum_valid_nonce_delta = 5; const i16 maximum_valid_nonce_delta = 5;
const TimeIntervalInSecType nonce_regeneration_interval = 300; const TimeIntervalInSecType nonce_regeneration_interval = 300;
/** Direction of TIEs. */ /** Direction of TIEs. */
skipping to change at line 11810 skipping to change at line 12112
/** IP address type. */ /** IP address type. */
union IPAddressType { union IPAddressType {
/** Content is IPv4 */ /** Content is IPv4 */
1: optional IPv4Address ipv4address; 1: optional IPv4Address ipv4address;
/** Content is IPv6 */ /** Content is IPv6 */
2: optional IPv6Address ipv6address; 2: optional IPv6Address ipv6address;
} }
/** Prefix advertisement. /** Prefix advertisement.
@note: for interface @note: For interface
addresses the protocol can propagate the address part beyond addresses, the protocol can propagate the address part beyond
the subnet mask and on reachability computation that has to the subnet mask and on reachability computation that has to
be normalized. The non-significant bits can be used be normalized. The non-significant bits can be used
for operational purposes. for operational purposes.
*/ */
union IPPrefixType { union IPPrefixType {
1: optional IPv4PrefixType ipv4prefix; 1: optional IPv4PrefixType ipv4prefix;
2: optional IPv6PrefixType ipv6prefix; 2: optional IPv6PrefixType ipv6prefix;
} }
/** Sequence of a prefix in case of move. /** Sequence of a prefix in case of move.
*/ */
struct PrefixSequenceType { struct PrefixSequenceType {
1: required IEEE802_1ASTimeStampType timestamp; 1: required IEEE802_1ASTimeStampType timestamp;
/** Transaction ID set by client in e.g. in 6LoWPAN. */ /** Transaction ID set by the client in, e.g., 6LoWPAN. */
2: optional PrefixTransactionIDType transactionid; 2: optional PrefixTransactionIDType transactionid;
} }
/** Type of TIE. /** Type of TIE.
*/ */
enum TIETypeType { enum TIETypeType {
Illegal = 0, Illegal = 0,
TIETypeMinValue = 1, TIETypeMinValue = 1,
/** first legal value */ /** first legal value */
NodeTIEType = 2, NodeTIEType = 2,
skipping to change at line 11848 skipping to change at line 12150
NegativeDisaggregationPrefixTIEType = 5, NegativeDisaggregationPrefixTIEType = 5,
PGPrefixTIEType = 6, PGPrefixTIEType = 6,
KeyValueTIEType = 7, KeyValueTIEType = 7,
ExternalPrefixTIEType = 8, ExternalPrefixTIEType = 8,
PositiveExternalDisaggregationPrefixTIEType = 9, PositiveExternalDisaggregationPrefixTIEType = 9,
TIETypeMaxValue = 10, TIETypeMaxValue = 10,
} }
/** RIFT route types. /** RIFT route types.
@note: The only purpose of those values is to introduce an @note: The only purpose of those values is to introduce an
ordering whereas an implementation can choose internally ordering, whereas an implementation can internally choose
any other values as long the ordering is preserved any other values as long the ordering is preserved.
*/ */
enum RouteType { enum RouteType {
Illegal = 0, Illegal = 0,
RouteTypeMinValue = 1, RouteTypeMinValue = 1,
/** First legal value. */ /** First legal value. */
/** Discard routes are most preferred */ /** Discard routes are most preferred */
Discard = 2, Discard = 2,
/** Local prefixes are directly attached prefixes on the /** Local prefixes are directly attached prefixes on the
* system such as e.g. interface routes. * system, such as interface routes.
*/ */
LocalPrefix = 3, LocalPrefix = 3,
/** Advertised in S-TIEs */ /** Advertised in S-TIEs */
SouthPGPPrefix = 4, SouthPGPPrefix = 4,
/** Advertised in N-TIEs */ /** Advertised in N-TIEs */
NorthPGPPrefix = 5, NorthPGPPrefix = 5,
/** Advertised in N-TIEs */ /** Advertised in N-TIEs */
NorthPrefix = 6, NorthPrefix = 6,
/** Externally imported north */ /** Externally imported north */
NorthExternalPrefix = 7, NorthExternalPrefix = 7,
skipping to change at line 11884 skipping to change at line 12186
SouthExternalPrefix = 9, SouthExternalPrefix = 9,
/** Negative, transitive prefixes are least preferred */ /** Negative, transitive prefixes are least preferred */
NegativeSouthPrefix = 10, NegativeSouthPrefix = 10,
RouteTypeMaxValue = 11, RouteTypeMaxValue = 11,
} }
enum KVTypes { enum KVTypes {
Experimental = 1, Experimental = 1,
WellKnown = 2, WellKnown = 2,
OUI = 3, OUI = 3,
} }]]></sourcecode>
]]></artwork>
</section> </section>
<section numbered="true" toc="default" anchor="encoding_thrift_app"> <section numbered="true" toc="default" anchor="encoding_thrift_app">
<name>encoding.thrift</name> <name>encoding.thrift</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type=""><![CDATA[
/** /**
Thrift file for packet encodings for RIFT Thrift file for packet encodings for RIFT
*/ */
include "common.thrift" include "common.thrift"
namespace py encoding namespace py encoding
/** Represents protocol encoding schema major version */ /** Represents protocol encoding schema major version */
const common.VersionType protocol_major_version = 8 const common.VersionType protocol_major_version = 8
skipping to change at line 11917 skipping to change at line 12216
/** Major version of protocol. */ /** Major version of protocol. */
1: required common.VersionType major_version = 1: required common.VersionType major_version =
protocol_major_version; protocol_major_version;
/** Minor version of protocol. */ /** Minor version of protocol. */
2: required common.MinorVersionType minor_version = 2: required common.MinorVersionType minor_version =
protocol_minor_version; protocol_minor_version;
/** Node sending the packet, in case of LIE/TIRE/TIDE /** Node sending the packet, in case of LIE/TIRE/TIDE
also the originator of it. */ also the originator of it. */
3: required common.SystemIDType sender; 3: required common.SystemIDType sender;
/** Level of the node sending the packet, required on everything /** Level of the node sending the packet, required on everything
except LIEs. Lack of presence on LIEs indicates UNDEFINED_LEVEL except LIEs. Lack of presence on LIEs indicates
and is used in ZTP procedures. UNDEFINED_LEVEL and is used in ZTP procedures.
*/ */
4: optional common.LevelType level; 4: optional common.LevelType level;
} }
/** Prefix community. */ /** Prefix community. */
struct Community { struct Community {
/** Higher order bits */ /** Higher order bits */
1: required i32 top; 1: required i32 top;
/** Lower order bits */ /** Lower order bits */
2: required i32 bottom; 2: required i32 bottom;
skipping to change at line 11942 skipping to change at line 12241
struct Neighbor { struct Neighbor {
/** System ID of the originator. */ /** System ID of the originator. */
1: required common.SystemIDType originator; 1: required common.SystemIDType originator;
/** ID of remote side of the link. */ /** ID of remote side of the link. */
2: required common.LinkIDType remote_id; 2: required common.LinkIDType remote_id;
} }
/** Capabilities the node supports. */ /** Capabilities the node supports. */
struct NodeCapabilities { struct NodeCapabilities {
/** Must advertise supported minor version dialect that way. */ /** Must advertise supported minor version dialect that way. */
1: required common.MinorVersionType protocol_minor_version = 1: required common.MinorVersionType protocol_minor_version =
protocol_minor_version; protocol_minor_version;
/** indicates that node supports flood reduction. */ /** indicates that node supports flood reduction. */
2: optional bool flood_reduction = 2: optional bool flood_reduction =
common.flood_reduction_default; common.flood_reduction_default;
/** indicates place in hierarchy, i.e. top-of-fabric or /** indicates place in hierarchy, i.e., top of fabric or
leaf only (in ZTP) or support for leaf-2-leaf leaf only (in ZTP) or support for leaf-to-leaf
procedures. */ procedures. */
3: optional common.HierarchyIndications hierarchy_indications; 3: optional common.HierarchyIndications hierarchy_indications;
} }
/** Link capabilities. */ /** Link capabilities. */
struct LinkCapabilities { struct LinkCapabilities {
/** Indicates that the link is supporting BFD. */ /** Indicates that the link is supporting BFD. */
1: optional bool bfd = 1: optional bool bfd =
common.bfd_default; common.bfd_default;
/** Indicates whether the interface will support IPv4 forwarding. */ /** Indicates whether the interface will support IPv4
2: optional bool ipv4_forwarding_capable = forwarding. */
2: optional bool ipv4_forwarding_capable =
true; true;
} }
/** RIFT LIE Packet. /** RIFT LIE Packet.
@note: this node's level is already included on the packet header @note: This node's level is already included on the packet header.
*/ */
struct LIEPacket { struct LIEPacket {
/** Node or adjacency name. */ /** Node or adjacency name. */
1: optional string name; 1: optional string name;
/** Local link ID. */ /** Local link ID. */
2: required common.LinkIDType local_id; 2: required common.LinkIDType local_id;
/** UDP port to which we can receive flooded TIEs. */ /** UDP port to which we can receive flooded TIEs. */
3: required common.UDPPortType flood_port = 3: required common.UDPPortType flood_port =
common.default_tie_udp_flood_port; common.default_tie_udp_flood_port;
/** Layer 2 MTU, used to discover mismatch. */ /** Layer 2 MTU, used to discover mismatch. */
4: optional common.MTUSizeType link_mtu_size = 4: optional common.MTUSizeType link_mtu_size =
common.default_mtu_size; common.default_mtu_size;
/** Local link bandwidth on the interface. */ /** Local link bandwidth on the interface. */
5: optional common.BandwithInMegaBitsType 5: optional common.BandwidthInMegaBitsType
link_bandwidth = common.default_bandwidth; link_bandwidth = common.default_bandwidth;
/** Reflects the neighbor once received to provide /** Reflects the neighbor once received to provide
3-way connectivity. */ 3-way connectivity. */
6: optional Neighbor neighbor; 6: optional Neighbor neighbor;
/** Node's PoD. */ /** Node's PoD. */
7: optional common.PodType pod = 7: optional common.PodType pod =
common.default_pod; common.default_pod;
/** Node capabilities supported. */ /** Node capabilities supported. */
10: required NodeCapabilities node_capabilities; 10: required NodeCapabilities node_capabilities;
/** Capabilities of this link. */ /** Capabilities of this link. */
11: optional LinkCapabilities link_capabilities; 11: optional LinkCapabilities link_capabilities;
/** Required holdtime of the adjacency, i.e. for how /** Required holdtime of the adjacency, i.e., for how long a
long a period should adjacency be kept up without valid LIE reception. */ period adjacency should be kept up without valid LIE
reception. */
12: required common.TimeIntervalInSecType 12: required common.TimeIntervalInSecType
holdtime = common.default_lie_holdtime; holdtime = common.default_lie_holdtime;
/** Optional, unsolicited, downstream assigned locally significant label /** Optional, unsolicited, downstream assigned locally significant
value for the adjacency. */ label value for the adjacency. */
13: optional common.LabelType label; 13: optional common.LabelType label;
/** Indicates that the level on the LIE must not be used /** Indicates that the level on the LIE must not be used
to derive a ZTP level by the receiving node. */ to derive a ZTP level by the receiving node. */
21: optional bool not_a_ztp_offer = 21: optional bool not_a_ztp_offer =
common.default_not_a_ztp_offer; common.default_not_a_ztp_offer;
/** Indicates to northbound neighbor that it should /** Indicates to northbound neighbor that it should
be reflooding TIEs received from this node to achieve flood be reflooding TIEs received from this node to achieve flood
reduction and balancing for northbound flooding. */ reduction and balancing for northbound flooding. */
22: optional bool you_are_flood_repeater = 22: optional bool you_are_flood_repeater =
common.default_you_are_flood_repeater; common.default_you_are_flood_repeater;
/** Indicates to neighbor to flood node TIEs only and slow down /** Indicates to neighbor to flood node TIEs only and slow down
all other TIEs. Ignored when received from southbound neighbor. */ all other TIEs. Ignored when received from southbound
23: optional bool you_are_sending_too_quickly = neighbor. */
23: optional bool you_are_sending_too_quickly =
false; false;
/** Instance name in case multiple RIFT instances running on same /** Instance name in case multiple RIFT instances running on same
interface. */ interface. */
24: optional string instance_name; 24: optional string instance_name;
/** It provides the optional ID of the Fabric configured. This MUST match the /** It provides the optional ID of the fabric configured. This
information advertised MUST match the information advertised on the node element. */
on the node element. */ 35: optional common.FabricIDType fabric_id =
35: optional common.FabricIDType fabric_id = common.default_fabric_id; common.default_fabric_id;
} }
/** LinkID pair describes one of parallel links between two nodes. */ /** LinkID pair describes one of parallel links between two nodes. */
struct LinkIDPair { struct LinkIDPair {
/** Node-wide unique value for the local link. */ /** Node-wide unique value for the local link. */
1: required common.LinkIDType local_id; 1: required common.LinkIDType local_id;
/** Received remote link ID for this link. */ /** Received remote link ID for this link. */
2: required common.LinkIDType remote_id; 2: required common.LinkIDType remote_id;
/** Describes the local interface index of the link. */ /** Describes the local interface index of the link. */
10: optional common.PlatformInterfaceIndex platform_interface_index; 10: optional common.PlatformInterfaceIndex
platform_interface_index;
/** Describes the local interface name. */ /** Describes the local interface name. */
11: optional string platform_interface_name; 11: optional string platform_interface_name;
/** Indicates whether the link is secured, i.e. protected by /** Indicates whether the link is secured, i.e., protected by
outer key, absence of this element means no indication, outer key, absence of this element means no indication,
undefined outer key means not secured. */ undefined outer key means not secured. */
12: optional common.OuterSecurityKeyID 12: optional common.OuterSecurityKeyID
trusted_outer_security_key; trusted_outer_security_key;
/** Indicates whether the link is protected by established /** Indicates whether the link is protected by established
BFD session. */ BFD session. */
13: optional bool bfd_up; 13: optional bool bfd_up;
/** Optional indication which address families are up on the /** Optional indication which address families are up on the
interface */ interface */
14: optional set<common.AddressFamilyType> 14: optional set<common.AddressFamilyType>
skipping to change at line 12068 skipping to change at line 12371
/** Header of a TIE. */ /** Header of a TIE. */
struct TIEHeader { struct TIEHeader {
/** ID of the tie. */ /** ID of the tie. */
2: required TIEID tieid; 2: required TIEID tieid;
/** Sequence number of the tie. */ /** Sequence number of the tie. */
3: required common.SeqNrType seq_nr; 3: required common.SeqNrType seq_nr;
/** Absolute timestamp when the TIE was generated. */ /** Absolute timestamp when the TIE was generated. */
10: optional common.IEEE802_1ASTimeStampType origination_time; 10: optional common.IEEE802_1ASTimeStampType origination_time;
/** Original lifetime when the TIE was generated. */ /** Original lifetime when the TIE was generated. */
12: optional common.LifeTimeInSecType origination_lifetime; 12: optional common.LifeTimeInSecType origination_lifetime;
} }
/** Header of a TIE as described in TIRE/TIDE. /** Header of a TIE as described in TIRE/TIDE.
*/ */
struct TIEHeaderWithLifeTime { struct TIEHeaderWithLifeTime {
1: required TIEHeader header; 1: required TIEHeader header;
/** Remaining lifetime. */ /** Remaining lifetime. */
2: required common.LifeTimeInSecType remaining_lifetime; 2: required common.LifeTimeInSecType remaining_lifetime;
} }
/** TIDE with *sorted* TIE headers. */ /** TIDE with *sorted* TIE headers. */
struct TIDEPacket { struct TIDEPacket {
/** First TIE header in the tide packet. */ /** First TIE header in the TIDE packet. */
1: required TIEID start_range; 1: required TIEID start_range;
/** Last TIE header in the tide packet. */ /** Last TIE header in the TIDE packet. */
2: required TIEID end_range; 2: required TIEID end_range;
/** _Sorted_ list of headers. */ /** _Sorted_ list of headers. */
3: required list<TIEHeaderWithLifeTime> 3: required list<TIEHeaderWithLifeTime>
headers; headers;
} }
/** TIRE packet */ /** TIRE packet */
struct TIREPacket { struct TIREPacket {
1: required set<TIEHeaderWithLifeTime> 1: required set<TIEHeaderWithLifeTime>
headers; headers;
} }
/** neighbor of a node */ /** neighbor of a node */
struct NodeNeighborsTIEElement { struct NodeNeighborsTIEElement {
/** level of neighbor */ /** level of neighbor */
1: required common.LevelType level; 1: required common.LevelType level;
/** Cost to neighbor. Ignore anything equal/larger than `infinite_distance` /** Cost to neighbor. Ignore anything equal/larger than
or equal `invalid_distance` */ 'infinite_distance' or equal 'invalid_distance' */
3: optional common.MetricType cost 3: optional common.MetricType cost
= common.default_distance; = common.default_distance;
/** can carry description of multiple parallel links in a TIE */ /** can carry description of multiple parallel links in a TIE */
4: optional set<LinkIDPair> 4: optional set<LinkIDPair>
link_ids; link_ids;
/** total bandwith to neighbor as sum of all parallel links */ /** total bandwidth to neighbor as sum of all parallel links */
5: optional common.BandwithInMegaBitsType 5: optional common.BandwidthInMegaBitsType
bandwidth = common.default_bandwidth; bandwidth = common.default_bandwidth;
} }
/** Indication flags of the node. */ /** Indication flags of the node. */
struct NodeFlags { struct NodeFlags {
/** Indicates that node is in overload, do not transit traffic /** Indicates that node is in overload, do not transit traffic
through it. */ through it. */
1: optional bool overload = common.overload_default; 1: optional bool overload = common.overload_default;
} }
/** Description of a node. */ /** Description of a node. */
struct NodeTIEElement { struct NodeTIEElement {
/** Level of the node. */ /** Level of the node. */
1: required common.LevelType level; 1: required common.LevelType level;
/** Node's neighbors. Multiple node TIEs can carry disjoint sets of neighbor /** Node's neighbors. Multiple node TIEs can carry disjoint sets
s. */ of neighbors. */
2: required map<common.SystemIDType, 2: required map<common.SystemIDType,
NodeNeighborsTIEElement> neighbors; NodeNeighborsTIEElement> neighbors;
/** Capabilities of the node. */ /** Capabilities of the node. */
3: required NodeCapabilities capabilities; 3: required NodeCapabilities capabilities;
/** Flags of the node. */ /** Flags of the node. */
4: optional NodeFlags flags; 4: optional NodeFlags flags;
/** Optional node name for easier operations. */ /** Optional node name for easier operations. */
5: optional string name; 5: optional string name;
/** PoD to which the node belongs. */ /** PoD to which the node belongs. */
6: optional common.PodType pod; 6: optional common.PodType pod;
/** optional startup time of the node */ /** Optional startup time of the node */
7: optional common.TimestampInSecsType startup_time; 7: optional common.TimestampInSecsType startup_time;
/** If any local links are miscabled, this indication is flooded. */ /** If any local links are miscabled, this indication is
flooded. */
10: optional set<common.LinkIDType> 10: optional set<common.LinkIDType>
miscabled_links; miscabled_links;
/** ToFs in the same plane. Only carried by ToF. Multiple Node TIEs can carry /** ToFs in the same plane. Only carried by ToF. Multiple Node
disjoint sets of ToFs TIEs can carry disjoint sets of ToFs that MUST be joined to
which MUST be joined to form a single set. */ form a single set. */
12: optional set<common.SystemIDType> 12: optional set<common.SystemIDType>
same_plane_tofs; same_plane_tofs;
/** It provides the optional ID of the Fabric configured */ /** It provides the optional ID of the fabric configured */
20: optional common.FabricIDType fabric_id = common.default_fabri 20: optional common.FabricIDType fabric_id =
c_id; common.default_fabric_id;
} }
/** Attributes of a prefix. */ /** Attributes of a prefix. */
struct PrefixAttributes { struct PrefixAttributes {
/** Distance of the prefix. */ /** Distance of the prefix. */
2: required common.MetricType metric 2: required common.MetricType metric
= common.default_distance; = common.default_distance;
/** Generic unordered set of route tags, can be redistributed /** Generic unordered set of route tags, can be redistributed
to other protocols or use within the context of real time to other protocols or used within the context of real time
analytics. */ analytics. */
3: optional set<common.RouteTagType> 3: optional set<common.RouteTagType>
tags; tags;
/** Monotonic clock for mobile addresses. */ /** Monotonic clock for mobile addresses. */
4: optional common.PrefixSequenceType monotonic_clock; 4: optional common.PrefixSequenceType monotonic_clock;
/** Indicates if the prefix is a node loopback. */ /** Indicates if the prefix is a node loopback. */
6: optional bool loopback = false; 6: optional bool loopback = false;
/** Indicates that the prefix is directly attached. */ /** Indicates that the prefix is directly attached. */
7: optional bool directly_attached = true; 7: optional bool directly_attached = true;
/** link to which the address belongs to. */ /** Link to which the address belongs to. */
10: optional common.LinkIDType from_link; 10: optional common.LinkIDType from_link;
/** Optional, per prefix significant label. */ /** Optional, per-prefix significant label. */
12: optional common.LabelType label; 12: optional common.LabelType label;
} }
/** TIE carrying prefixes */ /** TIE carrying prefixes */
struct PrefixTIEElement { struct PrefixTIEElement {
/** Prefixes with the associated attributes. */ /** Prefixes with the associated attributes. */
1: required map<common.IPPrefixType, PrefixAttributes> prefixes; 1: required map<common.IPPrefixType, PrefixAttributes> prefixes;
} }
/** Defines the targeted nodes and the value carried. */ /** Defines the targeted nodes and the value carried. */
struct KeyValueTIEElementContent { struct KeyValueTIEElementContent {
1: optional common.KeyValueTargetType targets = common.keyvaluetarget 1: optional common.KeyValueTargetType targets =
_default; common.keyvaluetarget_default;
2: optional binary value; 2: optional binary value;
} }
/** Generic key value pairs. */ /** Generic key value pairs. */
struct KeyValueTIEElement { struct KeyValueTIEElement {
1: required map<common.KeyIDType, KeyValueTIEElementContent> keyvalues; 1: required map<common.KeyIDType, KeyValueTIEElementContent>
keyvalues;
} }
/** Single element in a TIE. */ /** Single element in a TIE. */
union TIEElement { union TIEElement {
/** Used in case of enum common.TIETypeType.NodeTIEType. */ /** Used in case of enum common.TIETypeType.NodeTIEType. */
1: optional NodeTIEElement node; 1: optional NodeTIEElement node;
/** Used in case of enum common.TIETypeType.PrefixTIEType. */ /** Used in case of enum common.TIETypeType.PrefixTIEType. */
2: optional PrefixTIEElement prefixes; 2: optional PrefixTIEElement prefixes;
/** Positive prefixes (always southbound). */ /** Positive prefixes (always southbound). */
3: optional PrefixTIEElement positive_disaggregation_prefixes; 3: optional PrefixTIEElement positive_disaggregation_prefixes;
/** Transitive, negative prefixes (always southbound) */ /** Transitive, negative prefixes (always southbound) */
5: optional PrefixTIEElement negative_disaggregation_prefixes; 5: optional PrefixTIEElement negative_disaggregation_prefixes;
/** Externally reimported prefixes. */ /** Externally reimported prefixes. */
6: optional PrefixTIEElement external_prefixes; 6: optional PrefixTIEElement external_prefixes;
/** Positive external disaggregated prefixes (always southbound). */ /** Positive external disaggregated prefixes (always
southbound). */
7: optional PrefixTIEElement 7: optional PrefixTIEElement
positive_external_disaggregation_prefixes; positive_external_disaggregation_prefixes;
/** Key-Value store elements. */ /** Key-Value store elements. */
9: optional KeyValueTIEElement keyvalues; 9: optional KeyValueTIEElement keyvalues;
} }
/** TIE packet */ /** TIE packet */
struct TIEPacket { struct TIEPacket {
1: required TIEHeader header; 1: required TIEHeader header;
2: required TIEElement element; 2: required TIEElement element;
skipping to change at line 12226 skipping to change at line 12537
1: optional LIEPacket lie; 1: optional LIEPacket lie;
2: optional TIDEPacket tide; 2: optional TIDEPacket tide;
3: optional TIREPacket tire; 3: optional TIREPacket tire;
4: optional TIEPacket tie; 4: optional TIEPacket tie;
} }
/** RIFT packet structure. */ /** RIFT packet structure. */
struct ProtocolPacket { struct ProtocolPacket {
1: required PacketHeader header; 1: required PacketHeader header;
2: required PacketContent content; 2: required PacketContent content;
} }]]></sourcecode>
]]></artwork>
</section> </section>
</section> </section>
<section numbered="true" toc="default" anchor="more_implementation_sec"> <section numbered="true" toc="default" anchor="more_implementation_sec">
<name>Further Details on Implementation</name> <name>Further Details on Implementation</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Considerations for Leaf-Only Implementation</name> <name>Considerations for Leaf-Only Implementation</name>
<t> RIFT can and is intended to be stretched to the lowest level in the IP fabric to <t> RIFT can and is intended to be stretched to the lowest level in the IP fabric to
integrate ToRs or even servers. Since those entities would run as le aves integrate ToRs or even servers. Since those entities would run as le aves
only, it is worth to observe that a leaf only version is significant ly only, it is worth it to observe that a leaf-only version is signific antly
simpler to implement and requires much less resources: simpler to implement and requires much less resources:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>Leaf nodes only need to maintain a multipath default <li>Leaf nodes only need to maintain a multipath default
route under normal circumstances. However, in cases of route under normal circumstances. However, in cases of
catastrophic partitioning, leaf nodes SHOULD be capable of catastrophic partitioning, leaf nodes <bcp14>SHOULD</bcp14> be capable of
accommodating all the leaf routes in their own PoD to accommodating all the leaf routes in their own PoD to
prevent traffic loss.</li> prevent traffic loss.</li>
<li>Leaf nodes hold only their own North TIEs and the South TIEs of Le vel 1 nodes <li>Leaf nodes only hold their own North TIEs and the South TIEs of le vel 1 nodes
they are connected to.</li> they are connected to.</li>
<li>Leaf nodes do not have to support any type <li>Leaf nodes do not have to support any type
of disaggregation computation or propagation.</li> of disaggregation computation or propagation.</li>
<li>Leaf nodes are not required to support the overload flag.</li> <li>Leaf nodes are not required to support the overload flag.</li>
<li>Leaf nodes do not need to originate S-TIEs unless optional leaf-2- leaf <li>Leaf nodes do not need to originate S-TIEs unless optional leaf-to -leaf
features are desired.</li> features are desired.</li>
</ol> </ol>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Considerations for Spine Implementation</name> <name>Considerations for Spine Implementation</name>
<t> Nodes that do not act as ToF are not required to discover fallen <t> Nodes that do not act as ToF are not required to discover fallen
leaves by comparing reachable destinations with peers and therefore leaves by comparing reachable destinations with peers and therefore
do not need to run the computation of disaggregated routes based on do not need to run the computation of disaggregated routes based on
that discovery. that discovery.
On the other hand, non-ToF nodes need to respect disaggregated routes On the other hand, non-ToF nodes need to respect disaggregated routes
skipping to change at line 12279 skipping to change at line 12588
<section anchor="security" numbered="true" toc="default"> <section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>General</name> <name>General</name>
<t>One can consider attack vectors where a router <t>One can consider attack vectors where a router
may reboot many times while changing its System ID and pollute may reboot many times while changing its System ID and pollute
the network with many stale TIEs or TIEs that are sent with very long the network with many stale TIEs or TIEs that are sent with very long
lifetimes and not cleaned up when the routes vanish. lifetimes and not cleaned up when the routes vanish.
Those attack vectors are not unique to RIFT. Those attack vectors are not unique to RIFT.
Given large memory footprints Given large memory footprints
available today those attacks should be relatively benign. Otherwise, available today, those attacks should be relatively benign. Otherwise,
a node SHOULD implement a strategy of discarding contents of all TIEs a node <bcp14>SHOULD</bcp14> implement a strategy of discarding contents
of all TIEs
that were not present in the SPF tree over a certain, configurable that were not present in the SPF tree over a certain, configurable
period of time. Since the protocol is self-stabilizing and will advertis e the presence period of time. Since the protocol is self-stabilizing and will advertis e the presence
of such TIEs to its neighbors, they can be of such TIEs to its neighbors, they can be
re-requested again if a computation finds that it has an re-requested again if a computation finds that it has an
adjacency formed towards the System ID of the discarded adjacency formed towards the System ID of the discarded
TIEs. TIEs.
</t> </t>
<t> <t>
The inner protection configured based on any of the mechanisms in The inner protection configured based on any of the mechanisms in
<xref target="keys-registry"/> guarantees the integrity of TIE <xref target="keys-registry"/> guarantees the integrity of TIE
content and when combined with outer part of the envelope content, and when combined with the outer part of the envelope,
using any of the mechanisms in <xref target="keys-registry"/> guar using any of the mechanisms in <xref target="keys-registry"/>, gua
antees rantees
protection against replay attacks as well. If only outer protectio n (i.e., an outer key ID protection against replay attacks as well. If only outer protectio n (i.e., an outer key ID
different from `undefined_securitykey_id`) different from 'undefined_securitykey_id')
is applied to an adjacency is applied to an adjacency
by the means of any mechanism in <xref target="keys-registry"/> by the means of any mechanism in <xref target="keys-registry"/>,
the integrity of the packet and replay protection the integrity of the packet and replay protection
is guaranteed only over the adjacency involved in any of the confi gured directions. is guaranteed only over the adjacency involved in any of the confi gured directions.
Further considerations can be found in <xref target="out-protect"/ > and <xref target="in-protect"/>. Further considerations can be found in Sections <xref target="out- protect" format="counter"/> and <xref target="in-protect" format="counter"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Time to Live and Hop Limit Values</name> <name>Time to Live and Hop Limit Values</name>
<t> <t>
RIFT explicitly requires the use of a TTL/HL value of 1 <strong>or</stro ng> 255 RIFT explicitly requires the use of a TTL/HL value of 1 <strong>or</stro ng> 255
when sending/receiving LIEs and TIEs so that implementors have a choice when sending/receiving LIEs and TIEs so that implementors have a choice
between the two. between the two.
</t> </t>
<t> <t>
Using a TTL/HL value of 255 does come with security concerns, but those Using a TTL/HL value of 255 does come with security concerns, but those
risks are addressed in <xref target="RFC5082"/>. However, this approach risks are addressed in <xref target="RFC5082"/>. However, this approach
may still have difficulties with some forwarding implementations (e.g. may still have difficulties with some forwarding implementations (e.g.,
incorrectly processing TTL/HL, loops within forwarding plane itself, etc incorrectly processing TTL/HL, loops within the forwarding plane itself,
.). etc.).
</t> </t>
<t> <t>
It is for this reason that RIFT also allows implementations to use a TTL /HL of 1. It is for this reason that RIFT also allows implementations to use a TTL /HL of 1.
Attacks that exploit this by spoofing it from several hops away are inde ed possible, but are exceptionally Attacks that exploit this by spoofing it from several hops away are inde ed possible but are exceptionally
difficult to engineer. Replay attacks are another potential attack difficult to engineer. Replay attacks are another potential attack
vector, but as described in the subsequent security sections, RIFT is we ll vector, but as described in the subsequent security sections, RIFT is we ll
protected against such attacks if any of the mechanisms in <xref target= "keys-registry"/> protected against such attacks if any of the mechanisms in <xref target= "keys-registry"/>
is applied. Additionally, for link-local scoped multicast addresses us ed for LIE the value are applied. Additionally, for link-local scoped multicast addresses u sed for LIE, the value
of 1 presents a more consistent choice. of 1 presents a more consistent choice.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Malformed Packets</name> <name>Malformed Packets</name>
<t> <t>
The protocol protects packets extensively through optional The protocol protects packets extensively through optional
signatures and nonces so if the possibility of maliciously injec signatures and nonces, so if the possibility of maliciously inje
ted cted
malformed or replayed packets exist in a deployment algorithms malformed or replayed packets exist in a deployment, algorithms
in <xref target="keys-registry"/> must be applied. in <xref target="keys-registry"/> must be applied.
</t> </t>
<t> <t>
Even with the security envelope, since RIFT relies on Thrift enc oders and decoders generated Even with the security envelope, since RIFT relies on Thrift enc oders and decoders generated
automatically from IDL it is conceivable that errors in such enc oders/decoders automatically from IDL, it is conceivable that errors in such en coders/decoders
could be discovered and lead to delivery of corrupted packets or reception could be discovered and lead to delivery of corrupted packets or reception
of packets that cannot be decoded. Misformatted packets lead nor of packets that cannot be decoded. Misformatted packets normally
mally lead
to decoder returning an error condition to the caller and with t to the decoder returning an error condition to the caller, and w
hat ith that,
the packet is basically unparsable with no other choice but to the packet is basically unparsable with no other choice but to
discard it. Should the unlikely scenario occur of the decoder be ing forced discard it. Should the unlikely scenario occur of the decoder be ing forced
to abort the protocol this is neither to abort the protocol, this is neither
better nor worse than today's behavior of other protocols. better nor worse than today's behavior of other protocols.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>RIFT ZTP</name> <name>RIFT ZTP</name>
<t><xref target="ZTP" format="default"/> presents many attack vectors in untrusted environments, <t><xref target="ZTP" format="default"/> presents many attack vectors in untrusted environments,
starting with nodes that oscillate their level offers to the starting with nodes that oscillate their level offers to the
possibility of nodes offering a <em>ThreeWay</em> adjacency with the highest possibility of nodes offering a <em>ThreeWay</em> adjacency with the highest
possible level value and a very long holdtime trying to put itself possible level value and a very long holdtime trying to put itself
"on top of the lattice" thereby allowing it to gain access to the whole "on top of the lattice", thereby allowing it to gain access to the whole
southbound topology. southbound topology.
Session authentication mechanisms are necessary Session authentication mechanisms are necessary
in environments where this is possible and RIFT provides the in environments where this is possible, and RIFT provides the
security envelope to ensure this if so desired if any mechanism in <xref targ security envelope to ensure this, if so desired, if any mechanism in <xref ta
et="keys-registry"/> is deployed. rget="keys-registry"/> is deployed.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Lifetime</name> <name>Lifetime</name>
<t>RIFT removes lifetime modification and replay attack vectors by prote cting the lifetime behind a signature <t>RIFT removes lifetime modification and replay attack vectors by prote cting the lifetime behind a signature
computed over it and additional nonce combination which results in the inability of an computed over it and additional nonce combination, which results in the inability of an
attacker to artificially shorten the <em>remaining_lifetime</em> . This only applies if attacker to artificially shorten the <em>remaining_lifetime</em> . This only applies if
any mechanism in <xref target="keys-registry"/> is used. any mechanism in <xref target="keys-registry"/> is used.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Packet Number</name> <name>Packet Number</name>
<t> <t>
An optional defined value number that is carried in the security env elope without any fingerprint A packet number is an optional defined value number that is carried in the security envelope without any fingerprint
protection and is hence vulnerable to replay and modification attack s. protection and is hence vulnerable to replay and modification attack s.
Contrary to nonces, this number must change on every packet and Contrary to nonces, this number must change on every packet and
would present a very high cryptographic load if signed. The attack v ector would present a very high cryptographic load if signed. The attack v ector
packet number present is packet number present is
relatively benign. Changing the packet number by a man-in-the-middle attack relatively benign. Changing the packet number by a man-in-the-middle attack
will only will only
affect operational validation tools and possibly some performance affect operational validation tools and possibly some performance
optimizations on flooding. It is expected that an implementation det ecting optimizations on flooding. It is expected that an implementation det ecting
too many "fake losses" or "misorderings" due to the attack on the pa cket too many "fake losses" or "misorderings" due to the attack on the pa cket
number would number would
simply suppress its further processing. simply suppress its further processing.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="out-protect"> <section numbered="true" toc="default" anchor="out-protect">
<name>Outer Fingerprint Attacks</name> <name>Outer Fingerprint Attacks</name>
<t> <t>
Even when a mechanism in <xref target="keys-registry"/> Even when a mechanism in <xref target="keys-registry"/>
is enabled to generate outer fingerprints further attack is enabled to generate outer fingerprints, further attack
considerations apply. considerations apply.
</t> </t>
<t> <t>
A node can try to inject LIE packets observing a conversation on the wire by A node can try to inject LIE packets observing a conversation on the wire by
using the observed outer Key ID albeit it cannot generate valid sign using the observed outer key ID, albeit it cannot generate valid sig
atures in case it changes natures in case it changes
the integrity of the message so the only possible attack is DoS due the integrity of the message, so the only possible attack is DoS due
to excessive to excessive
LIE validation if any mechanism in <xref target="keys-registry"/> is used. LIE validation if any mechanism in <xref target="keys-registry"/> is used.
</t> </t>
<t> <t>
A node can try to replay previous LIEs with changed state that it re corded A node can try to replay previous LIEs with a changed state that it recorded,
but the attack is hard to replicate since the nonce combination must match but the attack is hard to replicate since the nonce combination must match
the ongoing exchange and is then limited to a single flap only since both the ongoing exchange and is then limited to only a single flap since both
nodes will advance their nonces in case the adjacency state changed. Even in the nodes will advance their nonces in case the adjacency state changed. Even in the
most unlikely case the attack length is limited due to both sides pe riodically most unlikely case, the attack length is limited due to both sides p eriodically
increasing their nonces. increasing their nonces.
</t> </t>
<t> <t>
Generally, since weak nonces are not changed on every packet for p Generally, since weak nonces are not changed on every packet for p
erformance reasons erformance reasons,
a conceivable attack vector by a man-in-the-middle is to flood a r a conceivable attack vector by a man in the middle is to flood a r
eceiving node with eceiving node with the
maximum bandwidth of recently observed packets, both LIEs as well maximum bandwidth of recently observed packets, both LIEs as well
as TIEs. In a scenario where as TIEs.
such attacks are likely <em>maximum_valid_nonce_delta</em> can be
implemented as <!--[rfced] May we make this sentence more concise?
Original:
In a scenario
where such attacks are likely _maximum_valid_nonce_delta_ can be
implemented as configurable, small value and
_nonce_regeneration_interval_ configured to very small value as well.
Perhaps:
In a scenario
where such attacks are likely, _maximum_valid_nonce_delta_ and
_nonce_regeneration_interval_ can be implemented as configurable,
small values.
-->
In a scenario where
such attacks are likely, <em>maximum_valid_nonce_delta</em> can be
implemented as
configurable, small value and configurable, small value and
<em>nonce_regeneration_interval</em> configured to very small valu e as well. This will <em>nonce_regeneration_interval</em> configured to very small valu e as well. This will
likely present a significant computational load on large fabrics u nder normal operation. likely present a significant computational load on large fabrics u nder normal operation.
</t> </t>
</section> </section>
<section numbered="true" toc="default" anchor="in-protect"> <section numbered="true" toc="default" anchor="in-protect">
<name>TIE Origin Fingerprint DoS Attacks</name> <name>TIE Origin Fingerprint DoS Attacks</name>
<t> <t>
Even when a mechanism in <xref target="keys-registry"/> Even when a mechanism in <xref target="keys-registry"/>
is enabled to generate inner fingerprints or signatures is enabled to generate inner fingerprints or signatures,
further attack further attack
considerations apply. considerations apply.
</t> </t>
<t> <t>
In case the inner fingerprint could be generated by a compromised node in the In case the inner fingerprint could be generated by a compromised node in the
network other than the originator based on shared secrets the depl oyment must network other than the originator based on shared secrets, the dep loyment must
fall back on use of signatures that can be fall back on use of signatures that can be
validated but not generated by any other node but the originator. validated but not generated by any other node except the originato r.
</t> </t>
<t> <t>
A compromised node in the network A compromised node in the network
can attempt to brute force "fake TIEs" using other nodes' can attempt to brute force "fake TIEs" using other nodes'
TIE origin key identifiers without possessing the necessary secr ets. TIE origin key identifiers without possessing the necessary secr ets.
Albeit the ultimate validation of the origin signature Albeit the ultimate validation of the origin signature
will fail in such scenarios and not progress further than immedi ately will fail in such scenarios and not progress further than immedi ately
peering nodes, the resulting denial of service attack seems peering nodes, the resulting DoS attack seems
unavoidable since the TIE origin Key ID is only protected by the unavoidable since the TIE origin key ID is only protected by the
(here assumed to be compromised) node. (here assumed to be compromised) node.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Host Implementations</name> <name>Host Implementations</name>
<t> <t>
It can be reasonably expected that with the proliferation of RotH It can be reasonably expected that the proliferation of RotH
servers, rather than dedicated networking devices, servers, rather than dedicated networking devices,
will represent a significant amount of RIFT devices. will represent a significant amount of RIFT devices.
Given their normally far wider software envelope and access granted to them, such Given their normally far wider software envelope and access granted to them, such
servers are servers are
also far more likely to be compromised and present an attack vector on the protocol. also far more likely to be compromised and present an attack vector on the protocol.
Hijacking of prefixes to attract traffic is a trust problem and cann ot be easily addressed Hijacking of prefixes to attract traffic is a trust problem and cann ot be easily addressed
within the protocol if the trust model is breached, i.e. the server presents valid within the protocol if the trust model is breached, i.e., the server presents valid
credentials to form an adjacency and issue TIEs. credentials to form an adjacency and issue TIEs.
In an even more devious way, In an even more devious way,
the servers can present the servers can present
DoS (or even DDoS) vectors of issuing too many LIE packets, flooding large amounts of North TIEs, DoS (or even DDoS) vectors from issuing too many LIE packets, floodi ng large amounts of North TIEs,
and attempting similar resource overrun attacks. A prudent implement ation forming adjacencies and attempting similar resource overrun attacks. A prudent implement ation forming adjacencies
to leaves should implement to leaves should implement
thresholds mechanisms and raise warnings when, e.g., a leaf is adver tising threshold mechanisms and raise warnings when, e.g., a leaf is advert ising
an excess number of TIEs or prefixes. Additionally, such implementat ion an excess number of TIEs or prefixes. Additionally, such implementat ion
could refuse any topology information except the node's own TIEs and authenticated, could refuse any topology information except the node's own TIEs and authenticated,
reflected South Node TIEs at own level. reflected South Node TIEs at their own level.
</t> </t>
<!--[rfced] We are having some difficulty understanding how "leaf level
value and always setting overload flag" fits into the rest of the sentence.
Please let us know how this sentence may be clarified.
Original:
To isolate possible attack vectors on the leaf to the largest
possible extent a dedicated leaf-only implementation could run
without any configuration by hard-coding a well-known adjacency key
(which can be always rolled-over by the means of, e.g., well-known
key-value distributed from top of the fabric), leaf level value and
always setting overload flag.
Perhaps:
To isolate possible attack vectors on the leaf to the largest
possible extent, a dedicated leaf-only implementation could run
without any configuration by
* hard-coding a well-known adjacency key (which can be always
rolled over by means of, e.g., a well-known key-value distributed
from top of the fabric),
* hard-coding a _leaf_level_ value, and
* always setting the overload flag.
-->
<t> <t>
To isolate possible attack vectors on the leaf to the largest possib le extent To isolate possible attack vectors on the leaf to the largest possib le extent,
a dedicated leaf-only implementation could run without any configura tion by a dedicated leaf-only implementation could run without any configura tion by
hard-coding a well-known adjacency key (which can be always rolled-o hard-coding a well-known adjacency key (which can be always rolled o
ver by the means ver by the means
of, e.g., well-known key-value distributed from top of the fabric), of, e.g., a well-known key value distributed from the top of the fab
leaf level value and always setting ric), leaf level value and always setting
overload flag. All other values can be derived by automatic means as described above. overload flag. All other values can be derived by automatic means as described above.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>IPv4 Broadcast and IPv6 All Routers Multicast Implementations</n ame> <name>IPv4 Broadcast and IPv6 All-Routers Multicast Implementations</n ame>
<t><xref target="LIE"/> describes an optional implementation that supp orts LIE exchange over IPv4 broadcast <t><xref target="LIE"/> describes an optional implementation that supp orts LIE exchange over IPv4 broadcast
addresses and/or the IPv6 all routers multicast address. It is importa nt to consider that if an implementation addresses and/or the IPv6 all-routers multicast address. It is importa nt to consider that if an implementation
supports this, the attack surface widens as LIEs may be propagated to devices outside of the intended RIFT topology. supports this, the attack surface widens as LIEs may be propagated to devices outside of the intended RIFT topology.
This may leave RIFT nodes more susceptible to the various attack vecto rs already described in this section. This may leave RIFT nodes more susceptible to the various attack vecto rs already described in this section.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This specification requests multicast address assignments and standard <t>As detailed below, multicast addresses and standard port numbers have b
port numbers. Additionally, een assigned. Additionally,
registries for the schema are requested and suggested values provided th registries for the schema have been created with initial values assigned
at reflect the numbers .
allocated in the given schema.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requested Multicast and Port Numbers</name> <name>Multicast and Port Numbers</name>
<t>This document requests allocation in the 'IPv4 Multicast Address Spac <t>In the "IPv4 Multicast Address Space" registry, the value of 224.0.0.
e' registry the 121 has been assigned for 'ALL_V4_RIFT_ROUTERS'. In the "IPv6 Multicast
suggested value of 224.0.0.121 as 'ALL_V4_RIFT_ROUTERS' and in the ' Address Space" registry, the value of ff02::a1f7 has been assigned f
IPv6 Multicast or 'ALL_V6_RIFT_ROUTERS'.
Address Space' registry the
suggested value of ff02::a1f7 as 'ALL_V6_RIFT_ROUTERS'.
</t> </t>
<t>This document requests the following allocations from the "Service Na me and Transport Protocol Port Number Registry":</t> <t>The following assignments have been made in the "Service Name and Tra nsport Protocol Port Number Registry":</t>
<t><em>RIFT LIE Port</em></t> <t><em>RIFT LIE Port</em></t>
<sourcecode> <dl newline="false" spacing="compact">
Service Name: rift-lies <dt>Service Name:</dt> <dd>rift-lies</dd>
Transport Protocol(s): UDP <dt>Port Number:</dt> <dd>914</dd>
Assignee: Tony Przygienda (prz@juniper.net) <dt>Transport Protocol:</dt> <dd>udp</dd>
Contact: Jordan Head (jhead@juniper.net) <dt>Description:</dt> <dd>Routing in Fat Trees Link Information Element
Description: Routing in Fat Trees Link Information Element </dd>
Reference: This Document <dt>Assignee:</dt> <dd>IESG (iesg@ietf.org)</dd>
Port Number: 914 <dt>Contact:</dt> <dd>IETF Chair (chair@ietf.org)</dd>
</sourcecode> <dt>Reference:</dt> <dd>RFC 9692</dd>
</dl>
<t><em>RIFT TIE Port</em></t> <t><em>RIFT TIE Port</em></t>
<sourcecode> <dl newline="false" spacing="compact">
Service Name: rift-ties <dt>Service Name:</dt> <dd>rift-ties</dd>
Transport Protocol(s): UDP <dt>Port Number:</dt> <dd>915</dd>
Assignee: Tony Przygienda (prz@juniper.net) <dt>Transport Protocol:</dt> <dd>udp</dd>
Contact: Jordan Head (jhead@juniper.net) <dt>Assignee:</dt> <dd>IESG (iesg@ietf.org)</dd>
Description: Routing in Fat Trees Topology Information Element <dt>Contact:</dt> <dd>IETF Chair (chair@ietf.org)</dd>
Reference: This Document <dt>Description:</dt> <dd>Routing in Fat Trees Topology Information Ele
Port Number: 915 ment</dd>
</sourcecode> <dt>Reference:</dt> <dd>RFC 9692</dd>
</dl>
</section> </section>
<section numbered="true" toc="default" anchor="keys-registry"> <section numbered="true" toc="default" anchor="keys-registry">
<name>Requested Registry for RIFT Security Algorithms</name> <name>Registry for RIFT Security Algorithms</name>
<t> <t>
This section requests generation of a new registry holding the a A new registry has been created to hold the allowed
llowed RIFT security algorithms. No particular enumeration values are n
RIFT Security Algorithms. No particular enumeration values are n ecessary since
ecessary since
RIFT uses a key ID abstraction on packets without disclosing any information RIFT uses a key ID abstraction on packets without disclosing any information
about the algorithm or secrets used and only carries the resulti ng about the algorithm or secrets used and only carries the resulti ng
fingerprint or signature protecting the integrity of the data. fingerprint or signature protecting the integrity of the data.
</t> </t>
<t> <t>
The registry applies the "Specification Required" policy per <xr ef target="RFC5226"/>. The The registry applies the "Specification Required" policy per <xr ef target="RFC8126"/>. The
designated expert should ensure that the algorithms suggested re present the state of the art designated expert should ensure that the algorithms suggested re present the state of the art
at a given point in time and avoid introducing algorithms which at a given point in time and avoid introducing algorithms that d
do not represent enhanced o not represent enhanced
security properties or ensure such properties at lower cost as c security properties or ensure such properties at a lower cost as
ompared to existing registry compared to existing registry
entries. entries.
</t> </t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Reference</th> <th align="left">Reference</th>
<th align="right">Recommendation</th> <th align="left">Recommendation</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">HMAC-SHA256</td> <td align="left">HMAC-SHA256</td>
<td align="left"> <td align="left">
<xref target="SHA-2"/> and <xref target="RFC2104"/></td> <xref target="SHA-2"/> and <xref target="RFC2104"/></td>
<!--[rfced] Should 'outer key' be plural 'outer keys' in this sentence?
(If so, we will ask IANA to update the registry accordingly.)
Original (for HMAC-SHA256):
Simplest way to ensure integrity of transmissions across adjacencies
when used as outer key and integrity of TIEs when used as inner keys.
-->
<td align="left">Simplest way to ensure integrity of transmissions across adjacencies <td align="left">Simplest way to ensure integrity of transmissions across adjacencies
when used as outer key and integrity of TIEs when used a s inner keys. Recommended when used as outer key and integrity of TIEs when used a s inner keys. Recommended
for most interoperable security protection.</td> for most interoperable security protection.</td>
</tr> </tr>
<tr> <tr>
<td align="left">HMAC-SHA512</td> <td align="left">HMAC-SHA512</td>
<td align="left"> <td align="left">
<xref target="SHA-2"/> and <xref target="RFC2104"/></td> <xref target="SHA-2"/> and <xref target="RFC2104"/></td>
<td align="left">Same as HMAC-SHA256 with stronger protection. </t d> <td align="left">Same as HMAC-SHA256 with stronger protection. </t d>
</tr> </tr>
<tr> <tr>
<td align="left">SHA256-RSASSA-PKCS1-v1_5</td> <td align="left">SHA256-RSASSA-PKCS1-v1_5</td>
<td align="left"> <td align="left">
<xref target="RFC8017"/> Section 8.2</td> <xref target="RFC8017" sectionFormat="comma" section="8.2"/></td >
<td align="left">Recommended for high security applications where private keys <td align="left">Recommended for high security applications where private keys
are protected by according nodes. Recommended as well in case not only integrity but origin are protected by according nodes. Recommended as well in case not only integrity but origin
validation is necessary for TIEs. Recommended when adjac encies must be protected without validation is necessary for TIEs. Recommended when adjac encies must be protected without
disclosing the secrets on both sides of the adjacency.</ td> disclosing the secrets on both sides of the adjacency.</ td>
</tr> </tr>
<tr> <tr>
<td align="left">SHA512-RSASSA-PKCS1-v1_5</td> <td align="left">SHA512-RSASSA-PKCS1-v1_5</td>
<td align="left"> <td align="left">
<xref target="RFC8017"/></td> <xref target="RFC8017"/></td>
<td align="left">Same as SHA256-RSASSA-PKCS1-v1_5 with stronger pr otection. </td> <td align="left">Same as SHA256-RSASSA-PKCS1-v1_5 with stronger pr otection. </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requested Registries with Assigned Values for Schema Values</name> <name>Registries with Assigned Values for Schema Values</name>
<!-- generated IANA request --> <!-- generated IANA request -->
<t> <t>
This section requests registries that help govern the schema via u This section requests registries that help govern the schema via t
sual IANA registry he usual IANA registry
procedures. A top-level group named 'RIFT' should hold the corresp procedures. The registry group "Routing in Fat Trees (RIFT)" holds
onding registries requested in the following registries.
the following sections with their pre-defined values.
Registry values are stored with their minimum and maximum version in which they are available. Registry values are stored with their minimum and maximum version in which they are available.
All values not provided as to be All values not provided are to be
considered `Unassigned`. The range of every registry is a 16-bit i considered "Unassigned". The range of every registry is a 16-bit i
nteger. nteger.
Allocation of new values is performed via `Expert Review` action Allocation of new values is performed via "Expert Review" action
in case of major or minor Change per rules in <xref target="schema only in the case of minor changes per the rules in <xref target="s
"/>. Any other allocation chema"/>. All other allocations
is performed via 'Specification Required'. are performed via "Specification Required".
</t> </t>
<t> <t>
The registries do not contain in some cases necessary information In some cases, the registries do not contain necessary information
such as whether the fields are such as whether the fields are
optional or required, what units are used or what datatype is optional or required, what units are used, or what datatype is
involved. This information is encoded in the normative schema itse lf by the means involved. This information is encoded in the normative schema itse lf by the means
of IDL syntax or necessary type definitions and their names. of IDL syntax or necessary type definitions and their names.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/Versions</name> <name>RIFTVersions Registry</name>
<t> <t>
This registry stores all RIFT protocol schema major and minor This registry stores all RIFT protocol schema major and minor
versions including the reference versions, including the reference
to the document introducing the version. This means as well th to the document introducing the version. This also means that,
at if multiple documents extend if multiple documents extend
rift schema they have to serialize using this registry to incr rift schema, they have to serialize using this registry to inc
ease the minor or major versions rease the minor or major versions
sequentially. sequentially.
</t> </t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th align="left">Schema Version</th> <th align="left">Schema Version</th>
<th align="right">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="left"> <td align="left">
<eref target="https://datatracker.ietf.org/doc/draft-ietf-rift -rift/"/> <xref target="schema"/></td> RFC 9692, <xref target="schema"/></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/AddressFamilyType</name> <name>RIFTCommonAddressFamilyType Registry</name>
<t>The name of the registry should be RIFTCommonAddressFamilyType.</t> <t>This registry has the following initial values.</t>
<t>Address family type.</t>
<!--[rfced] FYI, we have moved the text preceding Tables 9, 10, 12, 13,
14, 15, 17, 18, 19, 20, 21, 22, 24, 25, 27, 28, 29, 30, 31, 32, 33, 34,
35, 36, 37, 38, 39, 40, 41, 42, and 43 to be the table titles. Please let
us know if you prefer otherwise. (In some cases, perhaps removing the
table title is best because the section title already provides the
corresponding registry name.)
Additionally, please let us know if Tables 7, 8, 11, 16, 23, and 26 should
have titles.
-->
<table align="left"> <table align="left">
<name>Address Family Type</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Min. Schema Version</th>
<th align="right">Min. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="right">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td>
<td align="left">Illegal</td> <td align="left">Illegal</td>
<td align="right">0</td> <td align="left">8.0</td>
<td align="right">8.0</td> <td align="left"/>
<td align="right"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td>
<td align="left">AddressFamilyMinValue</td> <td align="left">AddressFamilyMinValue</td>
<td align="right">1</td> <td align="left">8.0</td>
<td align="right">8.0</td> <td align="left"/>
<td align="right"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">2</td>
<td align="left">IPv4</td> <td align="left">IPv4</td>
<td align="right">2</td> <td align="left">8.0</td>
<td align="right">8.0</td> <td align="left"/>
<td align="right"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">3</td>
<td align="left">IPv6</td> <td align="left">IPv6</td>
<td align="right">3</td> <td align="left">8.0</td>
<td align="right">8.0</td> <td align="left"/>
<td align="right"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">4</td>
<td align="left">AddressFamilyMaxValue</td> <td align="left">AddressFamilyMaxValue</td>
<td align="right">4</td> <td align="left">8.0</td>
<td align="right">8.0</td> <td align="left"/>
<td align="right"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/HierarchyIndications</name> <name>RIFTCommonHierarchyIndications Registry</name>
<t>The name of the registry should be RIFTCommonHierarchyIndications.< <t>This registry has the following initial values.</t>
/t>
<t>Flags indicating node configuration in case of ZTP.</t> <!--[rfced] Regarding Sections 10.3.1 - 10.3.36:
a) Would you like the order of the columns in the tables in the IANA
Considerations to be updated to match the IANA registry? In other words,
would you like to switch the Name and Value columns so that Value is the first
column on the left? See Section 10.3.2 for an example of the update to match
https://www.iana.org/assignments/rift. (If the answer is no, then we will
revert Section 10.3.2.)
b) FYI, the section titles have been updated to match the names
of the IANA registries.
-->
<table align="left"> <table align="left">
<name>Flags Indicating Node Configuration in Case of ZTP</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">leaf_only</td> <td align="left">leaf_only</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">leaf_only_and_leaf_2_leaf_procedures</td> <td align="left">leaf_only_and_leaf_2_leaf_procedures</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">top_of_fabric</td> <td align="left">top_of_fabric</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/IEEE802_1ASTimeStampType</name> <name>RIFTCommonIEEE8021ASTimeStampType Registry</name>
<t>The name of the registry should be RIFTCommonIEEE8021ASTimeStampTyp <t>This registry has the following initial values.</t>
e.</t> <t>The timestamp is per IEEE 802.1AS; all values <bcp14>MUST</bcp14> b
<t>Timestamp per IEEE 802.1AS, all values MUST be interpreted in e interpreted in
implementation as unsigned.</t> implementation as unsigned.</t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">AS_sec</td> <td align="left">AS_sec</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">AS_nsec</td> <td align="left">AS_nsec</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/IPAddressType</name> <name>RIFTCommonIPAddressType Registry</name>
<t>The name of the registry should be RIFTCommonIPAddressType.</t> <t>This registry has the following initial values.</t>
<t>IP address type.</t>
<table align="left"> <table align="left">
<name>IP Address Type</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">ipv4address</td> <td align="left">ipv4address</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Content is ipv4</td> <td align="left"> Content is IPv4</td>
</tr> </tr>
<tr> <tr>
<td align="left">ipv6address</td> <td align="left">ipv6address</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Content is ipv6</td> <td align="left"> Content is IPv6</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/IPPrefixType</name> <name>RIFTCommonIPPrefixType Registry</name>
<t>The name of the registry should be RIFTCommonIPPrefixType.</t> <t>This registry has the following initial values.</t>
<t>Prefix advertisement.</t>
<t>@note: for interface <!--[rfced] Please clarify; how does and "on reachability computation
addresses the protocol can propagate the address part beyond that has to be normalized" connect with the rest of the sentence?
the subnet mask and on reachability computation that has to
be normalized. The non-significant bits can be used Original:
for operational purposes.</t> @note: for interface addresses the protocol can propagate the address
part beyond the subnet mask and on reachability computation that has
to be normalized. The non-significant bits can be used for
operational purposes.
-->
<t>Note: For interface addresses, the protocol can propagate
the address part beyond the subnet mask and on reachability
computation that has to be normalized. The non-significant bits can
be used for operational purposes.</t>
<table align="left"> <table align="left">
<name>Prefix Advertisement</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">ipv4prefix</td> <td align="left">ipv4prefix</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">ipv6prefix</td> <td align="left">ipv6prefix</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/IPv4PrefixType</name> <name>RIFTCommonIPv4PrefixType Registry</name>
<t>The name of the registry should be RIFTCommonIPv4PrefixType.</t> <t>This registry has the following initial values.</t>
<t>IPv4 prefix type.</t>
<table align="left"> <table align="left">
<name>IPv4 Prefix Type</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">address</td> <td align="left">address</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">prefixlen</td> <td align="left">prefixlen</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/IPv6PrefixType</name> <name>RIFTCommonIPv6PrefixType Registry</name>
<t>The name of the registry should be RIFTCommonIPv6PrefixType.</t> <t>This registry has the following initial values.</t>
<t>IPv6 prefix type.</t>
<table align="left"> <table align="left">
<name>IPv6 Prefix Type</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">address</td> <td align="left">address</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">prefixlen</td> <td align="left">prefixlen</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/KVTypes</name> <name>RIFTCommonKVTypes Registry</name>
<t>The name of the registry should be RIFTCommonKVTypes.</t> <t>This registry has the following initial values.</t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Unassigned</td>
<td align="left">0</td>
<td align="left"/>
<td align="left"/>
<td align="left"/>
</tr>
<tr>
<td align="left">Experimental</td> <td align="left">Experimental</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">WellKnown</td> <td align="left">WellKnown</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">OUI</td> <td align="left">OUI</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/PrefixSequenceType</name> <name>RIFTCommonPrefixSequenceType Registry</name>
<t>The name of the registry should be RIFTCommonPrefixSequenceType.</t <t>This registry has the following initial values.</t>
>
<t>Sequence of a prefix in case of move.</t>
<table align="left"> <table align="left">
<name>Sequence of a Prefix in Case of Move</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">timestamp</td> <td align="left">timestamp</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">transactionid</td> <td align="left">transactionid</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Transaction id set by client in e.g. in 6lowp <td align="left"> Transaction ID set by client in, e.g., 6LoWPAN
an.</td> .</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/RouteType</name> <name>RIFTCommonRouteType Registry</name>
<t>The name of the registry should be RIFTCommonRouteType.</t> <t>This registry has the following initial values.</t>
<t>RIFT route types. <t>Note: The only purpose of these values is to introduce an
@note: The only purpose of those values is to introduce an ordering, whereas an implementation can internally choose any other
ordering whereas an implementation can choose internally values as long the ordering is preserved.</t>
any other values as long the ordering is preserved</t>
<table align="left"> <table align="left">
<name>RIFT Route Types</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Illegal</td> <td align="left">Illegal</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">RouteTypeMinValue</td> <td align="left">RouteTypeMinValue</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">Discard</td> <td align="left">Discard</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">LocalPrefix</td> <td align="left">LocalPrefix</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">SouthPGPPrefix</td> <td align="left">SouthPGPPrefix</td>
<td align="right">4</td> <td align="left">4</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">NorthPGPPrefix</td> <td align="left">NorthPGPPrefix</td>
<td align="right">5</td> <td align="left">5</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">NorthPrefix</td> <td align="left">NorthPrefix</td>
<td align="right">6</td> <td align="left">6</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">NorthExternalPrefix</td> <td align="left">NorthExternalPrefix</td>
<td align="right">7</td> <td align="left">7</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">SouthPrefix</td> <td align="left">SouthPrefix</td>
<td align="right">8</td> <td align="left">8</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">SouthExternalPrefix</td> <td align="left">SouthExternalPrefix</td>
<td align="right">9</td> <td align="left">9</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">NegativeSouthPrefix</td> <td align="left">NegativeSouthPrefix</td>
<td align="right">10</td> <td align="left">10</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">RouteTypeMaxValue</td> <td align="left">RouteTypeMaxValue</td>
<td align="right">11</td> <td align="left">11</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/TIETypeType</name> <name>RIFTCommonTIETypeType Registry</name>
<t>The name of the registry should be RIFTCommonTIETypeType.</t> <t>This registry has the following initial values.</t>
<t>Type of TIE.</t>
<table align="left"> <table align="left">
<name>Type of TIE</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Illegal</td> <td align="left">Illegal</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">TIETypeMinValue</td> <td align="left">TIETypeMinValue</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">NodeTIEType</td> <td align="left">NodeTIEType</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">PrefixTIEType</td> <td align="left">PrefixTIEType</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">PositiveDisaggregationPrefixTIEType</td> <td align="left">PositiveDisaggregationPrefixTIEType</td>
<td align="right">4</td> <td align="left">4</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">NegativeDisaggregationPrefixTIEType</td> <td align="left">NegativeDisaggregationPrefixTIEType</td>
<td align="right">5</td> <td align="left">5</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">PGPrefixTIEType</td> <td align="left">PGPrefixTIEType</td>
<td align="right">6</td> <td align="left">6</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">KeyValueTIEType</td> <td align="left">KeyValueTIEType</td>
<td align="right">7</td> <td align="left">7</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">ExternalPrefixTIEType</td> <td align="left">ExternalPrefixTIEType</td>
<td align="right">8</td> <td align="left">8</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">PositiveExternalDisaggregationPrefixTIEType</td <td align="left">PositiveExternalDisaggregation<br/>PrefixTIETyp
> e</td>
<td align="right">9</td> <td align="left">9</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">TIETypeMaxValue</td> <td align="left">TIETypeMaxValue</td>
<td align="right">10</td> <td align="left">10</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/common/TieDirectionType</name> <name>RIFTCommonTieDirectionType Registry</name>
<t>The name of the registry should be RIFTCommonTieDirectionType.</t> <t>This registry has the following initial values.</t>
<t>Direction of TIEs.</t>
<table align="left"> <table align="left">
<name>Direction of TIEs</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Illegal</td> <td align="left">Illegal</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">South</td> <td align="left">South</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">North</td> <td align="left">North</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">DirectionMaxValue</td> <td align="left">DirectionMaxValue</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="left"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/Community</name> <name>RIFTEncodingCommunity Registry</name>
<t>The name of the registry should be RIFTEncodingCommunity.</t> <t>This registry has the following initial values.</t>
<t>Prefix community.</t>
<table align="left"> <table align="left">
<name>Prefix Community</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">top</td> <td align="left">top</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Higher order bits</td> <td align="left"> Higher order bits</td>
</tr> </tr>
<tr> <tr>
<td align="left">bottom</td> <td align="left">bottom</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Lower order bits</td> <td align="left"> Lower order bits</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/KeyValueTIEElement</name> <name>RIFTEncodingKeyValueTIEElement Registry</name>
<t>The name of the registry should be RIFTEncodingKeyValueTIEElement.< <t>This registry has the following initial values.</t>
/t>
<t>Generic key value pairs.</t>
<table align="left"> <table align="left">
<name>Generic Key Value Pairs</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">keyvalues</td> <td align="left">keyvalues</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/KeyValueTIEElementContent</name> <name>RIFTEncodingKeyValueTIEElementContent Registry</name>
<t>The name of the registry should be RIFTEncodingKeyValueTIEElementCo <t>This registry has the following initial values.
ntent.</t> It defines the targeted nodes and the value carried.</t>
<t>Defines the targeted nodes and the value carried.</t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">targets</td> <td align="left">targets</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">value</td> <td align="left">value</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/LIEPacket</name> <name>RIFTEncodingLIEPacket Registry</name>
<t>The name of the registry should be RIFTEncodingLIEPacket.</t> <t>This registry has the following initial values.</t>
<t>RIFT LIE Packet.</t> <t>Note: This node's level is already included on the packet header.</t
<t>@note: this node's level is already included on the packet header</ >
t>
<table align="left"> <table align="left">
<name>RIFT LIE Packet</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">name</td> <td align="left">name</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Node or adjacency name.</td> <td align="left"> Node or adjacency name.</td>
</tr> </tr>
<tr> <tr>
<td align="left">local_id</td> <td align="left">local_id</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Local link id.</td> <td align="left"> Local link ID.</td>
</tr> </tr>
<tr> <tr>
<td align="left">flood_port</td> <td align="left">flood_port</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Udp port to which we can receive flooded ties <td align="left"> UDP port to which we can receive flooded ties.
.</td> </td>
</tr> </tr>
<tr> <tr>
<td align="left">link_mtu_size</td> <td align="left">link_mtu_size</td>
<td align="right">4</td> <td align="left">4</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Layer 2 mtu, used to discover mismatch.</td> <td align="left"> Layer 2 MTU, used to discover mismatch.</td>
</tr> </tr>
<tr> <tr>
<td align="left">link_bandwidth</td> <td align="left">link_bandwidth</td>
<td align="right">5</td> <td align="left">5</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Local link bandwidth on the interface.</td> <td align="left"> Local link bandwidth on the interface.</td>
</tr> </tr>
<tr> <tr>
<td align="left">neighbor</td> <td align="left">neighbor</td>
<td align="right">6</td> <td align="left">6</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Reflects the neighbor once received to provid <td align="left"> Reflects the neighbor once received to provide
e
3-way connectivity.</td> 3-way connectivity.</td>
</tr> </tr>
<tr> <tr>
<td align="left">pod</td> <td align="left">pod</td>
<td align="right">7</td> <td align="left">7</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Node's pod.</td> <td align="left"> Node's PoD.</td>
</tr> </tr>
<tr> <tr>
<td align="left">node_capabilities</td> <td align="left">node_capabilities</td>
<td align="right">10</td> <td align="left">10</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Node capabilities supported.</td> <td align="left"> Node capabilities supported.</td>
</tr> </tr>
<tr> <tr>
<td align="left">link_capabilities</td> <td align="left">link_capabilities</td>
<td align="right">11</td> <td align="left">11</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Capabilities of this link.</td> <td align="left"> Capabilities of this link.</td>
</tr> </tr>
<tr> <tr>
<td align="left">holdtime</td> <td align="left">holdtime</td>
<td align="right">12</td> <td align="left">12</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Required holdtime of the adjacency, i.e. for <td align="left"> Required holdtime of the adjacency, i.e., for
how how
long a period should adjacency be kept up without long a period adjacency should be kept up without
valid lie reception.</td> valid LIE reception.</td>
</tr> </tr>
<tr> <tr>
<td align="left">label</td> <td align="left">label</td>
<td align="right">13</td> <td align="left">13</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Optional, unsolicited, downstream assigned lo <td align="left"> Optional, unsolicited, downstream assigned loc
cally significant label ally significant label
value for the adjacency.</td> value for the adjacency.</td>
</tr> </tr>
<tr> <tr>
<td align="left">not_a_ztp_offer</td> <td align="left">not_a_ztp_offer</td>
<td align="right">21</td> <td align="left">21</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates that the level on the lie must not <td align="left"> Indicates that the level on the lie must not b
be used e used
to derive a ztp level by the receiving node.</td> to derive a ZTP level by the receiving node.</td>
</tr> </tr>
<tr> <tr>
<td align="left">you_are_flood_repeater</td> <td align="left">you_are_flood_repeater</td>
<td align="right">22</td> <td align="left">22</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates to northbound neighbor that it shou <td align="left"> Indicates to the northbound neighbor that it s
ld hould
be reflooding ties received from this node to achi eve flood be reflooding ties received from this node to achi eve flood
reduction and balancing for northbound flooding.</ td> reduction and balancing for northbound flooding.</ td>
</tr> </tr>
<tr> <tr>
<td align="left">you_are_sending_too_quickly</td> <td align="left">you_are_sending_too_quickly</td>
<td align="right">23</td> <td align="left">23</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates to neighbor to flood node ties only <td align="left"> Indicates to the neighbor to flood node ties o
and slow down nly and slow down
all other ties. ignored when received from southbo all other ties. Ignored when received from the sou
und neighbor.</td> thbound neighbor.</td>
</tr> </tr>
<tr> <tr>
<td align="left">instance_name</td> <td align="left">instance_name</td>
<td align="right">24</td> <td align="left">24</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Instance name in case multiple rift instances <td align="left"> Instance name in case multiple rift instances
running on same running on same
interface.</td> interface.</td>
</tr> </tr>
<tr> <tr>
<td align="left">fabric_id</td> <td align="left">fabric_id</td>
<td align="right">35</td> <td align="left">35</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> It provides the optional id of the fabric con <td align="left"> It provides the optional ID of the fabric conf
figured. this must match the information advertised igured. This must match the information advertised
on the node element.</td> on the node element.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/LinkCapabilities</name> <name>RIFTEncodingLinkCapabilities Registry</name>
<t>The name of the registry should be RIFTEncodingLinkCapabilities.</t <t>This registry has the following initial values.</t>
>
<t>Link capabilities.</t>
<table align="left"> <table align="left">
<name>Link Capabilities</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">bfd</td> <td align="left">bfd</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates that the link is supporting bfd.</t <td align="left"> Indicates that the link is supporting BFD.</td
d> >
</tr> </tr>
<tr> <tr>
<td align="left">ipv4_forwarding_capable</td> <td align="left">ipv4_forwarding_capable</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates whether the interface will support <td align="left"> Indicates whether the interface will support I
ipv4 forwarding.</td> Pv4 forwarding.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/LinkIDPair</name> <name>RIFTEncodingLinkIDPair Registry</name>
<t>The name of the registry should be RIFTEncodingLinkIDPair.</t> <t>The LinkID pair describes one of the parallel links between two nod
<t>LinkID pair describes one of parallel links between two nodes.</t> es.</t>
<t>This registry has the following initial values.</t>
<table align="left"> <table align="left">
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">local_id</td> <td align="left">local_id</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Node-wide unique value for the local link.</t <td align="left"> Node-wide unique value for the local link.</td
d> >
</tr> </tr>
<tr> <tr>
<td align="left">remote_id</td> <td align="left">remote_id</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Received remote link id for this link.</td> <td align="left"> Received the remote link ID for this link.</td
>
</tr> </tr>
<tr> <tr>
<td align="left">platform_interface_index</td> <td align="left">platform_interface_index</td>
<td align="right">10</td> <td align="left">10</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Describes the local interface index of the li <td align="left"> Describes the local interface index of the lin
nk.</td> k.</td>
</tr> </tr>
<tr> <tr>
<td align="left">platform_interface_name</td> <td align="left">platform_interface_name</td>
<td align="right">11</td> <td align="left">11</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Describes the local interface name.</td> <td align="left"> Describes the local interface name.</td>
</tr> </tr>
<tr> <tr>
<td align="left">trusted_outer_security_key</td> <td align="left">trusted_outer_security_key</td>
<td align="right">12</td> <td align="left">12</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates whether the link is secured, i.e. p <td align="left"> Indicates whether the link is secured, i.e., p
rotected by rotected by
outer key, absence of this element means no indica tion, outer key, absence of this element means no indica tion,
undefined outer key means not secured.</td> undefined outer key means not secured.</td>
</tr> </tr>
<tr> <tr>
<td align="left">bfd_up</td> <td align="left">bfd_up</td>
<td align="right">13</td> <td align="left">13</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates whether the link is protected by es <td align="left"> Indicates whether the link is protected by an
tablished established
bfd session.</td> BFD session.</td>
</tr> </tr>
<tr> <tr>
<td align="left">address_families</td> <td align="left">address_families</td>
<td align="right">14</td> <td align="left">14</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Optional indication which address families ar <td align="left"> Optional indication that address families are
e up on the up on the
interface.</td> interface.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/Neighbor</name> <name>RIFTEncodingNeighbor Registry</name>
<t>The name of the registry should be RIFTEncodingNeighbor.</t> <t>This registry has the following initial values.</t>
<t>Neighbor structure.</t>
<table align="left"> <table align="left">
<name>Neighbor Structure</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">originator</td> <td align="left">originator</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> System id of the originator.</td> <td align="left"> System ID of the originator.</td>
</tr> </tr>
<tr> <tr>
<td align="left">remote_id</td> <td align="left">remote_id</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Id of remote side of the link.</td> <td align="left"> ID of remote side of the link.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/NodeCapabilities</name> <name>RIFTEncodingNodeCapabilities Registry</name>
<t>The name of the registry should be RIFTEncodingNodeCapabilities.</t <t>This registry has the following initial values.</t>
>
<t>Capabilities the node supports.</t>
<table align="left"> <table align="left">
<name>Capabilities the Node Supports</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">protocol_minor_version</td> <td align="left">protocol_minor_version</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Must advertise supported minor version dialec <td align="left"> Must advertise supported minor version dialect
t that way.</td> that way.</td>
</tr> </tr>
<tr> <tr>
<td align="left">flood_reduction</td> <td align="left">flood_reduction</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates that node supports flood reduction. <td align="left"> Indicates that node supports flood reduction.<
</td> /td>
</tr> </tr>
<tr> <tr>
<td align="left">hierarchy_indications</td> <td align="left">hierarchy_indications</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates place in hierarchy, i.e. top-of-fab <td align="left"> Indicates place in hierarchy, i.e., top of fab
ric or ric or
leaf only (in ztp) or support for leaf-2-leaf leaf only (in ZTP) or support for leaf-to-leaf
procedures.</td> procedures.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/NodeFlags</name> <name>RIFTEncodingNodeFlags Registry</name>
<t>The name of the registry should be RIFTEncodingNodeFlags.</t> <t>This registry has the following initial values.</t>
<t>Indication flags of the node.</t>
<table align="left"> <table align="left">
<name>Indication Flags of the Node</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">overload</td> <td align="left">overload</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates that node is in overload, do not tr <td align="left"> Indicates that node is in overload; do not tra
ansit traffic nsit traffic
through it.</td> through it.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/NodeNeighborsTIEElement</name> <name>RIFTEncodingNodeNeighborsTIEElement Registry</name>
<t>The name of the registry should be RIFTEncodingNodeNeighborsTIEElem <t>This registry has the following initial values.</t>
ent.</t>
<t>neighbor of a node</t>
<table align="left"> <table align="left">
<name>Neighbor of a Node</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">level</td> <td align="left">level</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Level of neighbor.</td> <td align="left"> Level of neighbor.</td>
</tr> </tr>
<tr> <tr>
<td align="left">cost</td> <td align="left">cost</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Cost to neighbor. ignore anything equal or la <td align="left"> Cost to neighbor. Ignore anything equal or lar
rger than `infinite_distance` and equal to `invalid_distance`.</td> ger than 'infinite_distance' and equal to 'invalid_distance'.</td>
</tr> </tr>
<tr> <tr>
<td align="left">link_ids</td> <td align="left">link_ids</td>
<td align="right">4</td> <td align="left">4</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Carries description of multiple parallel link <td align="left"> Carries description of multiple parallel links
s in a tie.</td> in a tie.</td>
</tr> </tr>
<tr> <tr>
<td align="left">bandwidth</td> <td align="left">bandwidth</td>
<td align="right">5</td> <td align="left">5</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Total bandwith to neighbor as sum of all para <td align="left"> Total bandwidth to neighbor as sum of all para
llel links.</td> llel links.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/NodeTIEElement</name> <name>RIFTEncodingNodeTIEElement Registry</name>
<t>The name of the registry should be RIFTEncodingNodeTIEElement.</t> <t>This registry has the following initial values.</t>
<t>Description of a node.</t>
<table align="left"> <table align="left">
<name>Description of a Node</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">level</td> <td align="left">level</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Level of the node.</td> <td align="left"> Level of the node.</td>
</tr> </tr>
<tr> <tr>
<td align="left">neighbors</td> <td align="left">neighbors</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Node's neighbors. multiple node ties can carr <td align="left"> Node's neighbors. Multiple node ties can carry
y disjoint sets of neighbors.</td> disjoint sets of neighbors.</td>
</tr> </tr>
<tr> <tr>
<td align="left">capabilities</td> <td align="left">capabilities</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Capabilities of the node.</td> <td align="left"> Capabilities of the node.</td>
</tr> </tr>
<tr> <tr>
<td align="left">flags</td> <td align="left">flags</td>
<td align="right">4</td> <td align="left">4</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Flags of the node.</td> <td align="left"> Flags of the node.</td>
</tr> </tr>
<tr> <tr>
<td align="left">name</td> <td align="left">name</td>
<td align="right">5</td> <td align="left">5</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Optional node name for easier operations.</td <td align="left"> Optional node name for easier operations.</td>
>
</tr> </tr>
<tr> <tr>
<td align="left">pod</td> <td align="left">pod</td>
<td align="right">6</td> <td align="left">6</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Pod to which the node belongs.</td> <td align="left"> Pod to which the node belongs.</td>
</tr> </tr>
<tr> <tr>
<td align="left">startup_time</td> <td align="left">startup_time</td>
<td align="right">7</td> <td align="left">7</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Optional startup time of the node</td> <td align="left"> Optional startup time of the node.</td>
</tr> </tr>
<tr> <tr>
<td align="left">miscabled_links</td> <td align="left">miscabled_links</td>
<td align="right">10</td> <td align="left">10</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> If any local links are miscabled, this indica <td align="left"> If any local links are miscabled, this indicat
tion is flooded.</td> ion is flooded.</td>
</tr> </tr>
<tr> <tr>
<td align="left">same_plane_tofs</td> <td align="left">same_plane_tofs</td>
<td align="right">12</td> <td align="left">12</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Tofs in the same plane. only carried by tof. <td align="left"> ToFs in the same plane. Only carried by ToF. M
multiple node ties can carry disjoint sets of tofs ultiple node ties can carry disjoint sets of ToFs
which must be joined to form a single set.</td> that must be joined to form a single set.</td>
</tr> </tr>
<tr> <tr>
<td align="left">fabric_id</td> <td align="left">fabric_id</td>
<td align="right">20</td> <td align="left">20</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> It provides the optional id of the fabric con <td align="left"> It provides the optional ID of the fabric conf
figured</td> igured.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/PacketContent</name> <name>RIFTEncodingPacketContent Registry</name>
<t>The name of the registry should be RIFTEncodingPacketContent.</t> <t>This registry has the following initial values.</t>
<t>Content of a RIFT packet.</t>
<table align="left"> <table align="left">
<name>Content of a RIFT Packet</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">lie</td> <td align="left">lie</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">tide</td> <td align="left">tide</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">tire</td> <td align="left">tire</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">tie</td> <td align="left">tie</td>
<td align="right">4</td> <td align="left">4</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/PacketHeader</name> <name>RIFTEncodingPacketHeader Registry</name>
<t>The name of the registry should be RIFTEncodingPacketHeader.</t> <t>This registry has the following initial values.</t>
<t>Common RIFT packet header.</t>
<table align="left"> <table align="left">
<name>Common RIFT Packet Header</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">major_version</td> <td align="left">major_version</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Major version of protocol.</td> <td align="left"> Major version of protocol.</td>
</tr> </tr>
<tr> <tr>
<td align="left">minor_version</td> <td align="left">minor_version</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Minor version of protocol.</td> <td align="left"> Minor version of protocol.</td>
</tr> </tr>
<tr> <tr>
<td align="left">sender</td> <td align="left">sender</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Node sending the packet, in case of lie/tire/ <td align="left"> Node sending the packet, in case of LIE/TIRE/T
tide IDE
also the originator of it.</td> also the originator of it.</td>
</tr> </tr>
<tr> <tr>
<td align="left">level</td> <td align="left">level</td>
<td align="right">4</td> <td align="left">4</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Level of the node sending the packet, require <td align="left"> Level of the node sending the packet, required
d on everything on everything
except lies. lack of presence on lies indicates un except LIEs. Lack of presence on LIEs indicates un
defined_level defined_level
and is used in ztp procedures.</td> and is used in ZTP procedures.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/PrefixAttributes</name> <name>RIFTEncodingPrefixAttributes Registry</name>
<t>The name of the registry should be RIFTEncodingPrefixAttributes.</t <t>This registry has the following initial values.</t>
>
<t>Attributes of a prefix.</t>
<table align="left"> <table align="left">
<name>Attributes of a Prefix</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">metric</td> <td align="left">metric</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Distance of the prefix.</td> <td align="left"> Distance of the prefix.</td>
</tr> </tr>
<tr> <tr>
<td align="left">tags</td> <td align="left">tags</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Generic unordered set of route tags, can be r <td align="left"> Generic unordered set of route tags, can be re
edistributed distributed
to other protocols or use within the context of re to other protocols or used within the context of r
al time eal time
analytics.</td> analytics.</td>
</tr> </tr>
<tr> <tr>
<td align="left">monotonic_clock</td> <td align="left">monotonic_clock</td>
<td align="right">4</td> <td align="left">4</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Monotonic clock for mobile addresses.</td> <td align="left"> Monotonic clock for mobile addresses.</td>
</tr> </tr>
<tr> <tr>
<td align="left">loopback</td> <td align="left">loopback</td>
<td align="right">6</td> <td align="left">6</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates if the prefix is a node loopback.</ <td align="left"> Indicates if the prefix is a node loopback.</t
td> d>
</tr> </tr>
<tr> <tr>
<td align="left">directly_attached</td> <td align="left">directly_attached</td>
<td align="right">7</td> <td align="left">7</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates that the prefix is directly attache <td align="left"> Indicates that the prefix is directly attached
d.</td> .</td>
</tr> </tr>
<tr> <tr>
<td align="left">from_link</td> <td align="left">from_link</td>
<td align="right">10</td> <td align="left">10</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Link to which the address belongs to.</td> <td align="left"> Link to which the address belongs to.</td>
</tr> </tr>
<tr> <tr>
<td align="left">label</td> <td align="left">label</td>
<td align="right">12</td> <td align="left">12</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Optional, per prefix significant label.</td> <td align="left"> Optional, per-prefix significant label.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/PrefixTIEElement</name> <name>RIFTEncodingPrefixTIEElement Registry</name>
<t>The name of the registry should be RIFTEncodingPrefixTIEElement.</t <t>This registry has the following initial values.</t>
>
<t>TIE carrying prefixes</t>
<table align="left"> <table align="left">
<name>TIE Carrying Prefixes</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">prefixes</td> <td align="left">prefixes</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Prefixes with the associated attributes.</td> <td align="left"> Prefixes with the associated attributes.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/ProtocolPacket</name> <name>RIFTEncodingProtocolPacket Registry</name>
<t>The name of the registry should be RIFTEncodingProtocolPacket.</t> <t>This registry has the following initial values.</t>
<t>RIFT packet structure.</t>
<table align="left"> <table align="left">
<name>RIFT Packet Structure</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">header</td> <td align="left">header</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">content</td> <td align="left">content</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/TIDEPacket</name> <name>RIFTEncodingTIDEPacket Registry</name>
<t>The name of the registry should be RIFTEncodingTIDEPacket.</t> <t>This registry has the following initial values.</t>
<t>TIDE with *sorted* TIE headers.</t>
<table align="left"> <table align="left">
<name>TIDE with Sorted TIE Headers</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">start_range</td> <td align="left">start_range</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> First tie header in the tide packet.</td> <td align="left"> First TIE header in the TIDE packet.</td>
</tr> </tr>
<tr> <tr>
<td align="left">end_range</td> <td align="left">end_range</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Last tie header in the tide packet.</td> <td align="left"> Last TIE header in the TIDE packet.</td>
</tr> </tr>
<tr> <tr>
<td align="left">headers</td> <td align="left">headers</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> _sorted_ list of headers.</td> <td align="left"> _sorted_ list of headers.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/TIEElement</name> <name>RIFTEncodingTIEElement Registry</name>
<t>The name of the registry should be RIFTEncodingTIEElement.</t> <t>This registry has the following initial values.</t>
<t>Single element in a TIE.</t>
<table align="left"> <table align="left">
<name>Single Element in a TIE</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">node</td> <td align="left">node</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Used in case of enum common.tietypetype.nodet <td align="left"> Used in case of <br/>enum common.tietypetype.<
ietype.</td> br/>nodetietype.</td>
</tr> </tr>
<tr> <tr>
<td align="left">prefixes</td> <td align="left">prefixes</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Used in case of enum common.tietypetype.prefi <td align="left"> Used in case of <br/>enum common.tietypetype.<
xtietype.</td> br/>prefixtietype.</td>
</tr> </tr>
<tr> <tr>
<td align="left">positive_disaggregation_prefixes</td> <td align="left">positive_disaggregation_<br/>prefixes</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Positive prefixes (always southbound).</td> <td align="left"> Positive prefixes <br/>(always southbound).</t
d>
</tr> </tr>
<tr> <tr>
<td align="left">negative_disaggregation_prefixes</td> <td align="left">negative_disaggregation_<br/>prefixes</td>
<td align="right">5</td> <td align="left">5</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Transitive, negative prefixes (always southbo <td align="left"> Transitive, negative prefixes<br/>(always sout
und)</td> hbound)</td>
</tr> </tr>
<tr> <tr>
<td align="left">external_prefixes</td> <td align="left">external_prefixes</td>
<td align="right">6</td> <td align="left">6</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Externally reimported prefixes.</td> <td align="left"> Externally reimported <br/>prefixes.</td>
</tr> </tr>
<tr> <tr>
<td align="left">positive_external_disaggregation_prefixes</td> <td align="left">positive_external_<br/>disaggregation_prefixes<
<td align="right">7</td> /td>
<td align="right">8.0</td> <td align="left">7</td>
<td align="right"/> <td align="left">8.0</td>
<td align="right"> Positive external disaggregated prefixes (alw <td align="left"/>
ays southbound).</td> <td align="left"> Positive external <br/>disaggregated prefixes
<br/>(always southbound).</td>
</tr> </tr>
<tr> <tr>
<td align="left">keyvalues</td> <td align="left">keyvalues</td>
<td align="right">9</td> <td align="left">9</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Key-value store elements.</td> <td align="left"> Key-value <br/>store elements.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/TIEHeader</name> <name>RIFTEncodingTIEHeader Registry</name>
<t>The name of the registry should be RIFTEncodingTIEHeader.</t> <t>This registry has the following initial values.</t>
<t>Header of a TIE.</t>
<table align="left"> <table align="left">
<name>Header of a TIE</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">tieid</td> <td align="left">tieid</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Id of tie.</td> <td align="left"> ID of TIE.</td>
</tr> </tr>
<tr> <tr>
<td align="left">seq_nr</td> <td align="left">seq_nr</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Sequence number of tie.</td> <td align="left"> Sequence number of TIE.</td>
</tr> </tr>
<tr> <tr>
<td align="left">origination_time</td> <td align="left">origination_time</td>
<td align="right">10</td> <td align="left">10</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Absolute timestamp when tie was generated.</t <td align="left"> Absolute timestamp when TIE was generated.</td
d> >
</tr> </tr>
<tr> <tr>
<td align="left">origination_lifetime</td> <td align="left">origination_lifetime</td>
<td align="right">12</td> <td align="left">12</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Original lifetime when tie was generated.</td <td align="left"> Original lifetime when TIE was generated.</td>
>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/TIEHeaderWithLifeTime</name> <name>RIFTEncodingTIEHeaderWithLifeTime Registry</name>
<t>The name of the registry should be RIFTEncodingTIEHeaderWithLifeTim <t>This registry has the following initial values.</t>
e.</t>
<t>Header of a TIE as described in TIRE/TIDE.</t>
<table align="left"> <table align="left">
<name>Header of a TIE as Described in TIRE/TIDE</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">header</td> <td align="left">header</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">remaining_lifetime</td> <td align="left">remaining_lifetime</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Remaining lifetime.</td> <td align="left"> Remaining lifetime.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/TIEID</name> <name>RIFTEncodingTIEID Registry</name>
<t>The name of the registry should be RIFTEncodingTIEID.</t> <t>This registry has the following initial values.</t>
<t>Unique ID of a TIE.</t>
<table align="left"> <table align="left">
<name>Unique ID of a TIE</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">direction</td> <td align="left">direction</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Direction of tie.</td> <td align="left"> Direction of TIE.</td>
</tr> </tr>
<tr> <tr>
<td align="left">originator</td> <td align="left">originator</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Indicates originator of tie.</td> <td align="left"> Indicates originator of TIE.</td>
</tr> </tr>
<tr> <tr>
<td align="left">tietype</td> <td align="left">tietype</td>
<td align="right">3</td> <td align="left">3</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Type of tie.</td> <td align="left"> Type of TIE.</td>
</tr> </tr>
<tr> <tr>
<td align="left">tie_nr</td> <td align="left">tie_nr</td>
<td align="right">4</td> <td align="left">4</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> Number of tie.</td> <td align="left"> Number of TIE.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/TIEPacket</name> <name>RIFTEncodingTIEPacket Registry</name>
<t>The name of the registry should be RIFTEncodingTIEPacket.</t> <t>This registry has the following initial values.</t>
<t>TIE packet</t>
<table align="left"> <table align="left">
<name>TIE Packet</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">header</td> <td align="left">header</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
<tr> <tr>
<td align="left">element</td> <td align="left">element</td>
<td align="right">2</td> <td align="left">2</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Registry RIFT/encoding/TIREPacket</name> <name>RIFTEncodingTIREPacket Registry</name>
<t>The name of the registry should be RIFTEncodingTIREPacket.</t> <t>This registry has the following initial values.</t>
<t>TIRE packet</t>
<table align="left"> <table align="left">
<name>TIRE Packet</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="right">Value</th> <th align="left">Value</th>
<th align="right">Min. Schema Version</th> <th align="left">Min. Schema Version</th>
<th align="right">Max. Schema Version</th> <th align="left">Max. Schema Version</th>
<th align="left">Comment</th> <th align="left">Comment</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Reserved</td> <td align="left">Reserved</td>
<td align="right">0</td> <td align="left">0</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right">All Versions</td> <td align="left">All Versions</td>
<td align="right"/> <td align="left"/>
</tr> </tr>
<tr> <tr>
<td align="left">headers</td> <td align="left">headers</td>
<td align="right">1</td> <td align="left">1</td>
<td align="right">8.0</td> <td align="left">8.0</td>
<td align="right"/> <td align="left"/>
<td align="right"> </td> <td align="left"> </td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<!-- end generated IANA request --> <!-- end generated IANA request -->
</section> </section>
</section> </section>
<section anchor="Acknowledgments" numbered="true" toc="default">
<name>Acknowledgments</name>
<t>
A new routing protocol in its complexity is not a product of a parent bu
t of a
village as the author list shows already. However, many more people prov
ided input,
fine-combed the specification based on their experience in design, imple
mentation or
application of protocols in IP fabrics.
This section will make an inadequate attempt in recording their contribu
tion.
</t>
<t>Many thanks to Naiming Shen for some of the early
discussions around
the topic of using IGPs for routing in topologies related to Clos.
Russ White to be especially acknowledged for the key
conversation on epistemology that allowed to tie current
asynchronous distributed systems theory results to a modern protocol
design presented in this scope.
Adrian Farrel, Joel Halpern, Jeffrey Zhang, Krzysztof Szarkowicz,
Nagendra Kumar, Melchior Aelmans, Kaushal Tank, Will Jones, Moin Ahmed,
Sandy
Zhang, Donald Eastlake provided thoughtful comments that improved the
readability of the document and found good amount of
corners where the light failed to shine. Kris Price was
first to mention single router, single arm default considerations.
Jeff Tantsura helped out with some initial thoughts on BFD
interactions while Jeff Haas corrected several misconceptions
about BFD's finer points and helped to improve the security section
around leaf considerations. Artur Makutunowicz pointed out
many possible improvements and acted as sounding
board in regard to modern protocol implementation techniques
RIFT is exploring. Barak Gafni formalized first time clearly
the problem of partitioned spine and fallen leaves on a
(clean) napkin in Singapore that led to the very important
part of the specification centered around multiple ToF planes
and negative disaggregation. Igor Gashinsky and others shared many thoug
hts on
problems encountered in design and operation of large-scale data
center fabrics. Xu Benchong found a delicate error in the flooding proce
dures
and a schema datatype size mismatch.
</t>
<t>
Too many people to mention provided reviews from many directions in
IETF,
often pointing to critical defects,
sometimes
asking for things again that have been removed by one the previous r
eviewers as objectionable
or superfluous, and many times claiming the document being somewhere
on the extremes between
too crowded with the obvious and omitting introduction to cryptic
concepts everywhere. The result is the best editors could do
to find a balance of a document guiding the reader by <xref target="
digest"/> into a
specification tight enough to result in interoperable implementation
s while
at the same time introducing enough operational context of IP routab
le fabrics to
guarantee a concise, common language when facing unaccustomed concep
ts
the protocol relies on. In the process it was important to not end u
p carrying
Aesop's donkey of course so while the result may not be perceived as
perfect
by everyone it should be practically speaking more than sufficient f
or everyone
that ends up using it in the future.
</t>
<t>
Last but not least, Alvaro Retana, John Scudder, Andrew
Alston and Jim Guichard guided the undertaking as ADs by asking many
necessary procedural and technical questions which did not only improve
the content
but did also lay out the track towards publication. And Roman Danyliw is
mentioned
very last but not least either for his painstakingly detailed review and
improvement of security aspects of the specification.
</t>
</section>
<section numbered="true" toc="default">
<name>Contributors</name>
<t>
This work is a product of a list of individuals which are all to
be considered major contributors independent of the fact whether
their name made it to the limited boilerplate author's list or n
ot.
</t>
<table anchor="authors" align="center">
<name>RIFT Authors</name>
<thead>
<tr>
<th align="left"/>
<th align="left"/>
<th align="left"/>
<th align="left"/>
<th align="left"/>
</tr>
</thead>
<tbody>
<tr>
<td align="left">Tony Przygienda, Ed.</td>
<td align="left">|</td>
<td align="left"/>
<td align="left">|</td>
<td align="left">Pascal Thubert</td>
</tr>
<tr>
<td align="left">Juniper</td>
<td align="left">|</td>
<td align="left"/>
<td align="left">|</td>
<td align="left">Cisco</td>
</tr>
<tr>
<td align="left">Bruno Rijsman</td>
<td align="left">|</td>
<td align="left">Jordan Head, Ed.</td>
<td align="left">|</td>
<td align="left">Dmitry Afanasiev</td>
</tr>
<tr>
<td align="left">Individual</td>
<td align="left">|</td>
<td align="left">Juniper</td>
<td align="left">|</td>
<td align="left">Individual</td>
</tr>
<tr>
<td align="left">Don Fedyk</td>
<td align="left">|</td>
<td align="left">Alia Atlas</td>
<td align="left">|</td>
<td align="left">John Drake</td>
</tr>
<tr>
<td align="left">LabN</td>
<td align="left">|</td>
<td align="left">Individual</td>
<td align="left">|</td>
<td align="left">Individual</td>
</tr>
<tr>
<td align="left">Ilya Vershkov</td>
<td align="left">|</td>
<td align="left">|</td>
<td align="left">|</td>
<td align="left">|</td>
</tr>
<tr>
<td align="left">NVidia</td>
<td align="left">|</td>
<td align="left">|</td>
<td align="left">|</td>
<td align="left">|</td>
</tr>
</tbody>
</table>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-rift-applicability" to="APPLICABILITY"/> <displayreference target="I-D.ietf-rift-applicability" to="APPLICABILITY"/>
<references> <references>
<!--[rfced] References
a) The original URL for [thrift] goes to a GitHub repository. The web portion
of the style guide (https://www.rfc-editor.org/styleguide/part2/#ref_repo)
recommends using GitHub repositories for informative references only. We found
the site for the Apache Thrift documentation at the following URL:
https://thrift.apache.org/docs/.
We have updated the reference as follows. Please let us know if you
prefer otherwise.
Original:
[thrift] Apache Software Foundation, "Thrift Language
Implementation and Documentation",
<https://github.com/apache/thrift/tree/0.15.0/doc>.
Current:
[thrift] Apache Software Foundation, "Apache Thrift Documentation",
<https://thrift.apache.org/docs/>.
b) FYI, the [SHA-2] reference has been updated from NIST FIPS PUB 180-3
to NIST FIPS 180-4, as per the note from IANA and because it was
superseded.
c) We have updated the URL for [EUI64] from <http://standards.ieee.org/develop/r
egauth/tut/eui.pdf> to
<https://standards-support.ieee.org/hc/en-us/articles/4888705676564-Guidelines-f
or-Use-of-Extended-Unique-Identifier-EUI-Organizationally-Unique-Identifier-OUI-
and-Company-ID-CID>. The original URL led to a page about IEEE Registration
Authority programs. Please review and let us know if you have any
objections.
Original:
[EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier
(EUI), Organizationally Unique Identifier (OUI), and
Company ID (CID)", IEEE EUI,
<http://standards.ieee.org/develop/regauth/tut/eui.pdf>.
Current:
[EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier
(EUI), Organizationally Unique Identifier (OUI), and
Company ID (CID)", <https://standards-support.ieee.org/hc/
en-us/articles/4888705676564-Guidelines-for-Use-of-
Extended-Unique-Identifier-EUI-Organizationally-Unique-
Identifier-OUI-and-Company-ID-CID>.
d) FYI, RFC 5226 has been obsoleted by RFC 8126. We have replaced
usage in this document accordingly.
-->
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<!-- <!--
<reference anchor="ISO10589"> <reference anchor="ISO10589">
<front> <front>
<title> Intermediate system to Intermediate system <title> Intermediate system to Intermediate system
intra-domain intra-domain
routeing information exchange protocol for use routeing information exchange protocol for use
skipping to change at line 14644 skipping to change at line 14948
<author> <author>
<organization>ISO &quot;International Organization for <organization>ISO &quot;International Organization for
Standardization&quot;</organization> Standardization&quot;</organization>
</author> </author>
<date month="Nov" year="2002"/> <date month="Nov" year="2002"/>
</front> </front>
</reference> </reference>
--> -->
<reference anchor="thrift" target="https://github.com/apache/thrift/tree/0.1 5.0/doc"> <reference anchor="thrift" target="https://thrift.apache.org/docs/">
<front> <front>
<title> <title>Apache Thrift Documentation</title>
Thrift Language Implementation and Documentation
</title>
<author> <author>
<organization> <organization>Apache Software Foundation</organization>
Apache Software Foundation
</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
<!-- &RFC2328; --> <!-- &RFC2328; -->
<reference anchor="RFC2365" target="https://www.rfc-editor.org/info/rfc2365"
xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2365.x <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.23
ml"> 65.xml"/>
<front>
<title>Administratively Scoped IP Multicast</title>
<seriesInfo name="DOI" value="10.17487/RFC2365"/>
<seriesInfo name="RFC" value="2365"/>
<seriesInfo name="BCP" value="23"/>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization/>
</author>
<date year="1998" month="July"/>
<abstract>
<t>This document defines the "administratively scoped IPv4 multica
st space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describe
s a simple set of semantics for the implementation of Administratively Scoped IP
Multicast. Finally, it provides a mapping between the IPv6 multicast address cl
asses [RFC1884] and IPv4 multicast address classes. This document specifies an I
nternet Best Current Practices for the Internet Community, and requests discussi
on and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<!-- &RFC4271; --> <!-- &RFC4271; -->
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.42
91.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.50
82.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.51
20.xml"/>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc211
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4
291" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<date month="February" year="2006"/>
<abstract>
<t>This specification defines the addressing architecture of the I
P Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, te
xt representations of IPv6 addresses, definition of IPv6 unicast addresses, anyc
ast addresses, and multicast addresses, and an IPv6 node's required addresses.</
t>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing Arch
itecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
</reference>
<reference anchor="RFC5082" target="https://www.rfc-editor.org/info/rfc5
082" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5082.xml">
<front>
<title>The Generalized TTL Security Mechanism (GTSM)</title>
<author fullname="V. Gill" initials="V." surname="Gill"/>
<author fullname="J. Heasley" initials="J." surname="Heasley"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="P. Savola" initials="P." role="editor" surname="Sa
vola"/>
<author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
<date month="October" year="2007"/>
<abstract>
<t>The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (I
Pv6) to verify whether the packet was originated by an adjacent node on a connec
ted link has been used in many recent protocols. This document generalizes this
technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5082"/>
<seriesInfo name="DOI" value="10.17487/RFC5082"/>
</reference>
<reference anchor="RFC5120" target="https://www.rfc-editor.org/info/rfc5
120" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5120.xml">
<front>
<title>M-ISIS: Multi Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)</title>
<author fullname="T. Przygienda" initials="T." surname="Przygienda"/
>
<author fullname="N. Shen" initials="N." surname="Shen"/>
<author fullname="N. Sheth" initials="N." surname="Sheth"/>
<date month="February" year="2008"/>
<abstract>
<t>This document describes an optional mechanism within Intermedia
te System to Intermediate Systems (IS-ISs) used today by many ISPs for IGP routi
ng within their clouds. This document describes how to run, within a single IS-I
S domain, a set of independent IP topologies that we call Multi-Topologies (MTs)
. This MT extension can be used for a variety of purposes, such as an in-band ma
nagement network "on top" of the original IGP topology, maintaining separate IGP
routing domains for isolated multicast or IPv6 islands within the backbone, or
forcing a subset of an address space to follow a different topology. [STANDARDS-
TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5120"/>
<seriesInfo name="DOI" value="10.17487/RFC5120"/>
</reference>
<!-- AD review, removed <!-- AD review, removed
<xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.5549.xml'/> <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen ce.RFC.5549.xml'/>
--> -->
<reference anchor="RFC5709" target="https://www.rfc-editor.org/info/rfc570 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.57
9" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5709.xml"> 09.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<title>OSPFv2 HMAC-SHA Cryptographic Authentication</title> 81.xml"/>
<author fullname="M. Bhatia" initials="M." surname="Bhatia"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.59
<author fullname="V. Manral" initials="V." surname="Manral"/> 05.xml"/>
<author fullname="M. Fanto" initials="M." surname="Fanto"/>
<author fullname="R. White" initials="R." surname="White"/>
<author fullname="M. Barnes" initials="M." surname="Barnes"/>
<author fullname="T. Li" initials="T." surname="Li"/>
<author fullname="R. Atkinson" initials="R." surname="Atkinson"/>
<date month="October" year="2009"/>
<abstract>
<t>This document describes how the National Institute of Standards
and Technology (NIST) Secure Hash Standard family of algorithms can be used wit
h OSPF version 2's built-in, cryptographic authentication mechanism. This update
s, but does not supercede, the cryptographic authentication mechanism specified
in RFC 2328. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5709"/>
<seriesInfo name="DOI" value="10.17487/RFC5709"/>
</reference>
<reference anchor="RFC5881" target="https://www.rfc-editor.org/info/rfc5
881" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5881.xml">
<front>
<title>Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (S
ingle Hop)</title>
<author fullname="D. Katz" initials="D." surname="Katz"/>
<author fullname="D. Ward" initials="D." surname="Ward"/>
<date month="June" year="2010"/>
<abstract>
<t>This document describes the use of the Bidirectional Forwarding
Detection (BFD) protocol over IPv4 and IPv6 for single IP hops. [STANDARDS-TRAC
K]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5881"/>
<seriesInfo name="DOI" value="10.17487/RFC5881"/>
</reference>
<reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5
905" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml">
<front>
<title>Network Time Protocol Version 4: Protocol and Algorithms Spec
ification</title>
<author fullname="D. Mills" initials="D." surname="Mills"/>
<author fullname="J. Martin" initials="J." role="editor" surname="Ma
rtin"/>
<author fullname="J. Burbank" initials="J." surname="Burbank"/>
<author fullname="W. Kasch" initials="W." surname="Kasch"/>
<date month="June" year="2010"/>
<abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize c
omputer clocks in the Internet. This document describes NTP version 4 (NTPv4), w
hich is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305,
as well as previous versions of the protocol. NTPv4 includes a modified protocol
header to accommodate the Internet Protocol version 6 address family. NTPv4 inc
ludes fundamental improvements in the mitigation and discipline algorithms that
extend the potential accuracy to the tens of microseconds with modern workstatio
ns and fast LANs. It includes a dynamic server discovery scheme, so that in many
cases, specific server configuration is not required. It corrects certain error
s in the NTPv3 design and implementation and includes an optional extension mech
anism. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5905"/>
<seriesInfo name="DOI" value="10.17487/RFC5905"/>
</reference>
<!-- <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ reference.RFC.6830.xml'/> --> <!-- <xi:include href='https://xml2rfc.tools.ietf.org/public/rfc/bibxml/ reference.RFC.6830.xml'/> -->
<reference anchor="RFC7987" target="https://www.rfc-editor.org/info/rfc798
7" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7987.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.79
<front> 87.xml"/>
<title>IS-IS Minimum Remaining Lifetime</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/> 74.xml"/>
<author fullname="P. Wells" initials="P." surname="Wells"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
<author fullname="B. Decraene" initials="B." surname="Decraene"/> 00.xml"/>
<author fullname="T. Przygienda" initials="T." surname="Przygienda"/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.82
> 02.xml"/>
<author fullname="H. Gredler" initials="H." surname="Gredler"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.80
<date month="October" year="2016"/> 17.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.85
<t>Corruption of the Remaining Lifetime field in a Link State Prot 05.xml"/>
ocol Data Unit (LSP) can go undetected. In certain scenarios, this may cause or <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
exacerbate flooding storms. It is also a possible denial-of-service attack vecto 00.xml"/>
r. This document defines a backwards-compatible solution to this problem.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.93
</abstract> 01.xml"/>
</front>
<seriesInfo name="RFC" value="7987"/>
<seriesInfo name="DOI" value="10.17487/RFC7987"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8
200" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml">
<front>
<title>Internet Protocol, Version 6 (IPv6) Specification</title>
<author fullname="S. Deering" initials="S." surname="Deering"/>
<author fullname="R. Hinden" initials="R." surname="Hinden"/>
<date month="July" year="2017"/>
<abstract>
<t>This document specifies version 6 of the Internet Protocol (IPv
6). It obsoletes RFC 2460.</t>
</abstract>
</front>
<seriesInfo name="STD" value="86"/>
<seriesInfo name="RFC" value="8200"/>
<seriesInfo name="DOI" value="10.17487/RFC8200"/>
</reference>
<reference anchor="RFC8202" target="https://www.rfc-editor.org/info/rfc8
202" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8202.xml">
<front>
<title>IS-IS Multi-Instance</title>
<author fullname="L. Ginsberg" initials="L." surname="Ginsberg"/>
<author fullname="S. Previdi" initials="S." surname="Previdi"/>
<author fullname="W. Henderickx" initials="W." surname="Henderickx"/
>
<date month="June" year="2017"/>
<abstract>
<t>This document describes a mechanism that allows a single router
to share one or more circuits among multiple Intermediate System to Intermediat
e System (IS-IS) routing protocol instances.</t>
<t>Multiple instances allow the isolation of resources associated
with each instance. Routers will form instance-specific adjacencies. Each instan
ce can support multiple topologies. Each topology has a unique Link State Databa
se (LSDB). Each Protocol Data Unit (PDU) will contain a new Type-Length-Value (T
LV) identifying the instance and the topology (or topologies) to which the PDU b
elongs.</t>
<t>This document obsoletes RFC 6822.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8202"/>
<seriesInfo name="DOI" value="10.17487/RFC8202"/>
</reference>
<reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8
017" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml">
<front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author fullname="K. Moriarty" initials="K." role="editor" surname="
Moriarty"/>
<author fullname="B. Kaliski" initials="B." surname="Kaliski"/>
<author fullname="J. Jonsson" initials="J." surname="Jonsson"/>
<author fullname="A. Rusch" initials="A." surname="Rusch"/>
<date month="November" year="2016"/>
<abstract>
<t>This document provides recommendations for the implementation o
f public-key cryptography based on the RSA algorithm, covering cryptographic pri
mitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax f
or representing keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from R
SA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing
this RFC, change control is transferred to the IETF.</t>
<t>This document also obsoletes RFC 3447.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8017"/>
<seriesInfo name="DOI" value="10.17487/RFC8017"/>
</reference>
<reference anchor="RFC8505" target="https://www.rfc-editor.org/info/rfc8
505" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8505.xml">
<front>
<title>Registration Extensions for IPv6 over Low-Power Wireless Pers
onal Area Network (6LoWPAN) Neighbor Discovery</title>
<author fullname="P. Thubert" initials="P." role="editor" surname="T
hubert"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="S. Chakrabarti" initials="S." surname="Chakrabarti
"/>
<author fullname="C. Perkins" initials="C." surname="Perkins"/>
<date month="November" year="2018"/>
<abstract>
<t>This specification updates RFC 6775 -- the Low-Power Wireless P
ersonal Area Network (6LoWPAN) Neighbor Discovery specification -- to clarify th
e role of the protocol as a registration technique and simplify the registration
operation in 6LoWPAN routers, as well as to provide enhancements to the registr
ation capabilities and mobility detection for different network topologies, incl
uding the Routing Registrars performing routing for host routes and/or proxy Nei
ghbor Discovery in a low-power network.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8505"/>
<seriesInfo name="DOI" value="10.17487/RFC8505"/>
</reference>
<reference anchor="RFC9300" target="https://www.rfc-editor.org/info/rfc9
300" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9300.xml">
<front>
<title>The Locator/ID Separation Protocol (LISP)</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="D. Meyer" initials="D." surname="Meyer"/>
<author fullname="D. Lewis" initials="D." surname="Lewis"/>
<author fullname="A. Cabellos" initials="A." role="editor" surname="
Cabellos"/>
<date month="October" year="2022"/>
<abstract>
<t>This document describes the data plane protocol for the Locator
/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifier
s (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify
network attachment points. With this, LISP effectively separates control from d
ata and allows routers to create overlay networks. LISP-capable routers exchange
encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Ca
che.</t>
<t>LISP requires no change to either host protocol stacks or under
lay routers and offers Traffic Engineering (TE), multihoming, and mobility, amon
g other features.</t>
<t>This document obsoletes RFC 6830.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9300"/>
<seriesInfo name="DOI" value="10.17487/RFC9300"/>
</reference>
<reference anchor="RFC9301" target="https://www.rfc-editor.org/info/rfc9
301" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9301.xml">
<front>
<title>Locator/ID Separation Protocol (LISP) Control Plane</title>
<author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
<author fullname="F. Maino" initials="F." surname="Maino"/>
<author fullname="V. Fuller" initials="V." surname="Fuller"/>
<author fullname="A. Cabellos" initials="A." role="editor" surname="
Cabellos"/>
<date month="October" year="2022"/>
<abstract>
<t>This document describes the control plane and Mapping Service f
or the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-s
peaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a s
implified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator map
ping databases.</t>
<t>By using this control plane service interface and communicating
with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egre
ss Tunnel Routers (ETRs) are not dependent on the details of mapping database sy
stems; this behavior facilitates modularity with different database designs. Sin
ce these devices implement the "edge" of the LISP control plane infrastructure,
connecting EID addressable nodes of a LISP site, the implementation and operatio
nal complexity of the overall cost and effort of deploying LISP is reduced.</t>
<t>This document obsoletes RFCs 6830 and 6833.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9301"/>
<seriesInfo name="DOI" value="10.17487/RFC9301"/>
</reference>
<!-- <!--
@InProceedings{10.1007/11527954_6, @InProceedings{10.1007/11527954_6,
author="Erlebach, Thomas author="Erlebach, Thomas
and Hall, Alexander and Hall, Alexander
and Panconesi, Alessandro and Panconesi, Alessandro
and Vukadinovi{\'{c}}, Danica", and Vukadinovi{\'{c}}, Danica",
editor="L{\'o}pez-Ortiz, Alejandro editor="L{\'o}pez-Ortiz, Alejandro
and Hamel, Ang{\`e}le M.", and Hamel, Ang{\'e}le M.",
title="Cuts and Disjoint Paths in the Valley-Free Path Model of Internet BGP Routing", title="Cuts and Disjoint Paths in the Valley-Free Path Model of Internet BGP Routing",
booktitle="Combinatorial and Algorithmic Aspects of Networking", booktitle="Combinatorial and Algorithmic Aspects of Networking",
year="2005", year="2005",
publisher="Springer Berlin Heidelberg", publisher="Springer Berlin Heidelberg",
address="Berlin, Heidelberg", address="Berlin, Heidelberg",
pages="49-62", pages="49-62",
--> -->
<reference anchor="SHA-2"> <reference anchor="SHA-2" target="https://csrc.nist.gov/pubs/fips/180-4/ upd1/final">
<front> <front>
<title> <title>Secure Hash Standard (SHS)</title>
Secure
Hash Standard, FIPS PUB 180-3
</title>
<author> <author>
<organization> <organization>NIST</organization>
National Institute of Standards and Technology
</organization>
</author> </author>
<date year="2008"/> <date month="July" year="2015"/>
</front> </front>
<seriesInfo name="FIPS PUB" value="180-4"/>
<seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference> </reference>
<reference anchor="EUI64" target="http://standards.ieee.org/develop/rega
uth/tut/eui.pdf"> <reference anchor="EUI64" target="https://standards-support.ieee.org/hc/
en-us/articles/4888705676564-Guidelines-for-Use-of-Extended-Unique-Identifier-EU
I-Organizationally-Unique-Identifier-OUI-and-Company-ID-CID">
<front> <front>
<title>Guidelines <title>Guidelines for Use of Extended Unique Identifier (EUI), Organ
for izationally Unique Identifier (OUI), and Company ID (CID)</title>
Use
of
Extended
Unique
Identifier
(EUI),
Organizationally
Unique
Identifier
(OUI),
and
Company
ID
(CID)</title>
<seriesInfo name="IEEE" value="EUI"/>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC0826" target="https://www.rfc-editor.org/info/rfc8
26" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0826.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.08
<front> 26.xml"/>
<title>An Ethernet Address Resolution Protocol: Or Converting Networ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
k Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Har 04.xml"/>
dware</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.21
<author fullname="D. Plummer" initials="D." surname="Plummer"/> 31.xml"/>
<date month="November" year="1982"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.29
<abstract> 91.xml"/>
<t>The purpose of this RFC is to present a method of Converting Pr <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.84
otocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet 15.xml"/>
addresses). This is an issue of general concern in the ARPA Internet Community <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.48
at this time. The method proposed here is presented for your consideration and c 61.xml"/>
omment. This is not the specification of an Internet Standard.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.48
</abstract> 62.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.24
<seriesInfo name="STD" value="37"/> 74.xml"/>
<seriesInfo name="RFC" value="826"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.81
<seriesInfo name="DOI" value="10.17487/RFC0826"/> 26.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<reference anchor="RFC2104" target="https://www.rfc-editor.org/info/rfc2 80.xml"/>
104" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
<front> 37.xml"/>
<title>HMAC: Keyed-Hashing for Message Authentication</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.65
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/> 50.xml"/>
<author fullname="M. Bellare" initials="M." surname="Bellare"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.40
<author fullname="R. Canetti" initials="R." surname="Canetti"/> 86.xml"/>
<date month="February" year="1997"/>
<abstract> <!-- [I-D.ietf-rift-applicability] IESG state: IESG Evaluation as of 06/0
<t>This document describes HMAC, a mechanism for message authentic 5/24 -->
ation using cryptographic hash functions. HMAC can be used with any iterative cr
yptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ri
key. The cryptographic strength of HMAC depends on the properties of the underl ft-applicability.xml"/>
ying hash function. This memo provides information for the Internet community. T
his memo does not specify an Internet standard of any kind</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2104"/>
<seriesInfo name="DOI" value="10.17487/RFC2104"/>
</reference>
<reference anchor="RFC2131" target="https://www.rfc-editor.org/info/rfc2
131" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2131.xml">
<front>
<title>Dynamic Host Configuration Protocol</title>
<author fullname="R. Droms" initials="R." surname="Droms"/>
<date month="March" year="1997"/>
<abstract>
<t>The Dynamic Host Configuration Protocol (DHCP) provides a frame
work for passing configuration information to hosts on a TCPIP network. DHCP is
based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allo
cation of reusable network addresses and additional configuration options. [STAN
DARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2131"/>
<seriesInfo name="DOI" value="10.17487/RFC2131"/>
</reference>
<reference anchor="RFC2991" target="https://www.rfc-editor.org/info/rfc2
991" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2991.xml">
<front>
<title>Multipath Issues in Unicast and Multicast Next-Hop Selection<
/title>
<author fullname="D. Thaler" initials="D." surname="Thaler"/>
<author fullname="C. Hopps" initials="C." surname="Hopps"/>
<date month="November" year="2000"/>
<abstract>
<t>The effect of multipath routing on a forwarder is that the forw
arder potentially has several next-hops for any given destination and must use s
ome method to choose which next-hop should be used for a given data packet. This
memo summarizes current practices, problems, and solutions. This memo provides
information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2991"/>
<seriesInfo name="DOI" value="10.17487/RFC2991"/>
</reference>
<reference anchor="RFC8415" target="https://www.rfc-editor.org/info/rfc8
415" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8415.xml">
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<author fullname="T. Mrugalski" initials="T." surname="Mrugalski"/>
<author fullname="M. Siodelski" initials="M." surname="Siodelski"/>
<author fullname="B. Volz" initials="B." surname="Volz"/>
<author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko
"/>
<author fullname="M. Richardson" initials="M." surname="Richardson"/
>
<author fullname="S. Jiang" initials="S." surname="Jiang"/>
<author fullname="T. Lemon" initials="T." surname="Lemon"/>
<author fullname="T. Winters" initials="T." surname="Winters"/>
<date month="November" year="2018"/>
<abstract>
<t>This document describes the Dynamic Host Configuration Protocol
for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network c
onfiguration parameters, IP addresses, and prefixes. Parameters can be provided
statelessly, or in combination with stateful assignment of one or more IPv6 addr
esses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition
to stateless address autoconfiguration (SLAAC).</t>
<t>This document updates the text from RFC 3315 (the original DHCP
v6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv
6 (RFC 3736), an option to specify an upper bound for how long a client should w
ait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6
clients when DHCPv6 service is not available (RFC 7083), and relay agent handlin
g of unknown messages (RFC 7283). In addition, this document clarifies the inter
actions between models of operation (RFC 7550). As such, this document obsoletes
RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8415"/>
<seriesInfo name="DOI" value="10.17487/RFC8415"/>
</reference>
<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4
861" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml">
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="E. Nordmark" initials="E." surname="Nordmark"/>
<author fullname="W. Simpson" initials="W." surname="Simpson"/>
<author fullname="H. Soliman" initials="H." surname="Soliman"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the Neighbor Discovery protocol for IP
Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each o
ther's presence, to determine each other's link-layer addresses, to find routers
, and to maintain reachability information about the paths to active neighbors.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4861"/>
<seriesInfo name="DOI" value="10.17487/RFC4861"/>
</reference>
<reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4
862" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<author fullname="S. Thomson" initials="S." surname="Thomson"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="T. Jinmei" initials="T." surname="Jinmei"/>
<date month="September" year="2007"/>
<abstract>
<t>This document specifies the steps a host takes in deciding how
to autoconfigure its interfaces in IP version 6. The autoconfiguration process i
ncludes generating a link-local address, generating global addresses via statele
ss address autoconfiguration, and the Duplicate Address Detection procedure to v
erify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4862"/>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
</reference>
<reference anchor="RFC2474" target="https://www.rfc-editor.org/info/rfc2
474" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml">
<front>
<title>Definition of the Differentiated Services Field (DS Field) in
the IPv4 and IPv6 Headers</title>
<author fullname="K. Nichols" initials="K." surname="Nichols"/>
<author fullname="S. Blake" initials="S." surname="Blake"/>
<author fullname="F. Baker" initials="F." surname="Baker"/>
<author fullname="D. Black" initials="D." surname="Black"/>
<date month="December" year="1998"/>
<abstract>
<t>This document defines the IP header field, called the DS (for d
ifferentiated services) field. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2474"/>
<seriesInfo name="DOI" value="10.17487/RFC2474"/>
</reference>
<reference anchor="RFC5226" target="https://www.rfc-editor.org/info/rfc5
226" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5226.xml">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand"/
>
<date month="May" year="2008"/>
<abstract>
<t>Many protocols make use of identifiers consisting of constants
and other well-known values. Even after a protocol has been defined and deployme
nt has begun, new values may need to be assigned (e.g., for a new option type in
DHCP, or a new encryption or authentication transform for IPsec). To ensure tha
t such quantities have consistent values and interpretations across all implemen
tations, their assignment must be administered by a central authority. For IETF
protocols, that role is provided by the Internet Assigned Numbers Authority (IAN
A).</t>
<t>In order for IANA to manage a given namespace prudently, it nee
ds guidelines describing the conditions under which new values can be assigned o
r when modifications to existing values can be made. If IANA is expected to play
a role in the management of a namespace, IANA must be given clear and concise i
nstructions describing that role. This document discusses issues that should be
considered in formulating a policy for assigning values to a namespace and provi
des guidelines for authors on the specific text that must be included in documen
ts that place demands on IANA.</t>
<t>This document obsoletes RFC 2434. This document specifies an In
ternet Best Current Practices for the Internet Community, and requests discussio
n and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5226"/>
<seriesInfo name="DOI" value="10.17487/RFC5226"/>
</reference>
<reference anchor="RFC5880" target="https://www.rfc-editor.org/info/rfc5
880" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml">
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<author fullname="D. Katz" initials="D." surname="Katz"/>
<author fullname="D. Ward" initials="D." surname="Ward"/>
<date month="June" year="2010"/>
<abstract>
<t>This document describes a protocol intended to detect faults in
the bidirectional path between two forwarding engines, including interfaces, da
ta link(s), and to the extent possible the forwarding engines themselves, with p
otentially very low latency. It operates independently of media, data protocols,
and routing protocols. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5880"/>
<seriesInfo name="DOI" value="10.17487/RFC5880"/>
</reference>
<reference anchor="RFC5837" target="https://www.rfc-editor.org/info/rfc5
837" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5837.xml">
<front>
<title>Extending ICMP for Interface and Next-Hop Identification</tit
le>
<author fullname="A. Atlas" initials="A." role="editor" surname="Atl
as"/>
<author fullname="R. Bonica" initials="R." role="editor" surname="Bo
nica"/>
<author fullname="C. Pignataro" initials="C." role="editor" surname=
"Pignataro"/>
<author fullname="N. Shen" initials="N." surname="Shen"/>
<author fullname="JR. Rivers" initials="JR." surname="Rivers"/>
<date month="April" year="2010"/>
<abstract>
<t>This memo defines a data structure that can be appended to sele
cted ICMP messages. The ICMP extension defined herein can be used to identify an
y combination of the following: the IP interface upon which a datagram arrived,
the sub-IP component of an IP interface upon which a datagram arrived, the IP in
terface through which the datagram would have been forwarded had it been forward
able, and the IP next hop to which the datagram would have been forwarded.</t>
<t>Devices can use this ICMP extension to identify interfaces and
their components by any combination of the following: ifIndex, IPv4 address, IPv
6 address, name, and MTU. ICMP-aware devices can use these extensions to identif
y both numbered and unnumbered interfaces. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5837"/>
<seriesInfo name="DOI" value="10.17487/RFC5837"/>
</reference>
<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6
550" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml">
<front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</
title>
<author fullname="T. Winter" initials="T." role="editor" surname="Wi
nter"/>
<author fullname="P. Thubert" initials="P." role="editor" surname="T
hubert"/>
<author fullname="A. Brandt" initials="A." surname="Brandt"/>
<author fullname="J. Hui" initials="J." surname="Hui"/>
<author fullname="R. Kelsey" initials="R." surname="Kelsey"/>
<author fullname="P. Levis" initials="P." surname="Levis"/>
<author fullname="K. Pister" initials="K." surname="Pister"/>
<author fullname="R. Struik" initials="R." surname="Struik"/>
<author fullname="JP. Vasseur" initials="JP." surname="Vasseur"/>
<author fullname="R. Alexander" initials="R." surname="Alexander"/>
<date month="March" year="2012"/>
<abstract>
<t>Low-Power and Lossy Networks (LLNs) are a class of network in w
hich both the routers and their interconnect are constrained. LLN routers typica
lly operate with constraints on processing power, memory, and energy (battery po
wer). Their interconnects are characterized by high loss rates, low data rates,
and instability. LLNs are comprised of anything from a few dozen to thousands of
routers. Supported traffic flows include point-to-point (between devices inside
the LLN), point-to-multipoint (from a central control point to a subset of devi
ces inside the LLN), and multipoint-to-point (from devices inside the LLN toward
s a central control point). This document specifies the IPv6 Routing Protocol fo
r Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipo
int-to-point traffic from devices inside the LLN towards a central control point
as well as point-to-multipoint traffic from the central control point to the de
vices inside the LLN are supported. Support for point-to-point traffic is also a
vailable. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6550"/>
<seriesInfo name="DOI" value="10.17487/RFC6550"/>
</reference>
<reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4
086" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml">
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<author fullname="J. Schiller" initials="J." surname="Schiller"/>
<author fullname="S. Crocker" initials="S." surname="Crocker"/>
<date month="June" year="2005"/>
<abstract>
<t>Security systems are built on strong cryptographic algorithms t
hat foil pattern analysis attempts. However, the security of these systems is de
pendent on generating secret quantities for passwords, cryptographic keys, and s
imilar quantities. The use of pseudo-random processes to generate secret quantit
ies can result in pseudo-security. A sophisticated attacker may find it easier t
o reproduce the environment that produced the secret quantities and to search th
e resulting small set of possibilities than to locate the quantities in the whol
e of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated
adversary is surprisingly difficult. This document points out many pitfalls in u
sing poor entropy sources or traditional pseudo-random number generation techniq
ues for generating such quantities. It recommends the use of truly random hardwa
re techniques and shows that the existing hardware on many systems can be used f
or this purpose. It provides suggestions to ameliorate the problem when a hardwa
re solution is not available, and it gives examples of how large such quantities
need to be for some applications. This document specifies an Internet Best Curr
ent Practices for the Internet Community, and requests discussion and suggestion
s for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="106"/>
<seriesInfo name="RFC" value="4086"/>
<seriesInfo name="DOI" value="10.17487/RFC4086"/>
</reference>
<reference anchor="I-D.ietf-rift-applicability" target="https://datatrac
ker.ietf.org/doc/html/draft-ietf-rift-applicability-15" xml:base="https://bib.ie
tf.org/public/rfc/bibxml3/reference.I-D.ietf-rift-applicability.xml">
<front>
<title>RIFT Applicability</title>
<author fullname="Yuehua Wei" initials="Y." surname="Wei">
<organization>ZTE Corporation</organization>
</author>
<author fullname="Zheng Zhang" initials="Z." surname="Zhang">
<organization>ZTE Corporation</organization>
</author>
<author fullname="Dmitry Afanasiev" initials="D." surname="Afanasiev
">
<organization>Yandex</organization>
</author>
<author fullname="Pascal Thubert" initials="P." surname="Thubert">
<organization>Cisco Systems, Inc</organization>
</author>
<author fullname="Tony Przygienda" initials="T." surname="Przygienda
">
<organization>Juniper Networks</organization>
</author>
<date day="13" month="May" year="2024"/>
<abstract>
<t>This document discusses the properties, applicability and opera
tional considerations of RIFT in different network scenarios. It intends to prov
ide a rough guide how RIFT can be deployed to simplify routing operations in Clo
s topologies and their variations.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-rift-applicability
-15"/>
</reference>
<reference anchor="IEEEstd1588" target="https://ieeexplore.ieee.org/docu ment/4579760/"> <reference anchor="IEEEstd1588" target="https://ieeexplore.ieee.org/docu ment/4579760/">
<front> <front>
<title>IEEE Standard for a Precision Clock Synchronization Protocol for <title>IEEE Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems</title> Networked Measurement and Control Systems</title>
<seriesInfo name="IEEE" value="Standard 1588"/>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date/> <date month="July" year="2008"/>
</front>
</reference>
<reference anchor="RFC1982" target="https://www.rfc-editor.org/info/rfc1
982" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.19
82.xml">
<front>
<title>Serial Number Arithmetic</title>
<seriesInfo name="DOI" value="10.17487/RFC1982"/>
<seriesInfo name="RFC" value="1982"/>
<author initials="R." surname="Elz" fullname="R. Elz">
<organization/>
</author>
<author initials="R." surname="Bush" fullname="R. Bush">
<organization/>
</author>
<date year="1996" month="August"/>
<abstract>
<t>The DNS has long relied upon serial number arithmetic, a concep
t which has never really been defined,
certainly not in an IETF document, though which has been widely un
derstood.
This memo supplies the missing definition. It is intended to upda
te RFC1034 and RFC1035. [STANDARDS-TRACK]</t>
</abstract>
</front> </front>
<seriesInfo name="IEEE Std" value="1588-2008"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4579760"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.19
82.xml"/>
<reference anchor="IEEEstd8021AS" target="https://ieeexplore.ieee.org/do cument/5741898/"> <reference anchor="IEEEstd8021AS" target="https://ieeexplore.ieee.org/do cument/5741898/">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Timi ng <title>IEEE Standard for Local and Metropolitan Area Networks - Timi ng
and Synchronization for Time-Sensitive Applications in Bridged L ocal and Synchronization for Time-Sensitive Applications in Bridged L ocal
Area Networks</title> Area Networks</title>
<seriesInfo name="IEEE" value="Standard 802.1AS"/>
<author> <author>
<organization>IEEE</organization> <organization>IEEE</organization>
</author> </author>
<date/> <date month="March" year="2011"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.1AS-2011"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2011.5741898"/>
</reference> </reference>
<reference anchor="CLOS">
<reference anchor="CLOS" target="https://ieeexplore.ieee.org/document/60
12836">
<front> <front>
<title>On Nonblocking Folded-Clos Networks in <title>On Nonblocking Folded-Clos Networks in
Computer Communication Environments</title> Computer Communication Environments</title>
<seriesInfo name="IEEE" value="International Parallel &amp; Distributed Processing Symposium"/>
<author initials="X." surname="Yuan"> <author initials="X." surname="Yuan">
<organization>IEEE International Parallel &amp; <organization/>
Distributed Processing Symposium</organization>
</author> </author>
<date year="2011"/> <date year="2011"/>
</front> </front>
<refcontent>2011 IEEE International Parallel &amp; Distributed Process
ing Symposium</refcontent>
<seriesInfo name="DOI" value="10.1109/IPDPS.2011.27"/>
</reference> </reference>
<reference anchor="DIJKSTRA">
<reference anchor="DIJKSTRA" target="https://link.springer.com/article/1
0.1007/BF01386390">
<front> <front>
<title>A Note on Two Problems in Connexion with Graphs</title> <title>A Note on Two Problems in Connexion with Graphs</title>
<seriesInfo name="Journal Numer. Math." value=""/>
<author initials="E. W." surname="Dijkstra"> <author initials="E. W." surname="Dijkstra">
<organization/> <organization/>
</author> </author>
<date year="1959"/> <date month="December" year="1959"/>
</front> </front>
<refcontent>Numerische Mathematik, vol. 1, pp. 269-271</refcontent>
<seriesInfo name="DOI" value="10.1007/BF01386390"/>
</reference> </reference>
<reference anchor="DYNAMO">
<reference anchor="DYNAMO" target="https://dl.acm.org/doi/10.1145/132329
3.1294281">
<front> <front>
<title>Dynamo: amazon's highly available key-value store</title> <title>Dynamo: amazon's highly available key-value store</title>
<seriesInfo name="ACM" value="SIGOPS symposium on Operating systems <author initials="G." surname="De Candia">
principles (SOSP '07)"/> <organization/>
<author initials="G." surname="De Candia et al."> </author>
<author initials="D." surname="Hastorun">
<organization/>
</author>
<author initials="M." surname="Jampani">
<organization/>
</author>
<author initials="G." surname="Kakulpati">
<organization/>
</author>
<author initials="A." surname="Lakshman">
<organization/>
</author>
<author initials="A." surname="Pilchin">
<organization/>
</author>
<author initials="S." surname="Sivasubramanian">
<organization/>
</author>
<author initials="P." surname="Vosshall">
<organization/>
</author>
<author initials="W." surname="Vogels">
<organization/> <organization/>
</author> </author>
<date year="2007"/> <date year="2007"/>
</front> </front>
<refcontent>ACM SIGOPS Operating Systems Review, vol. 41, no. 6, pp. 2
05-220</refcontent>
<seriesInfo name="DOI" value="10.1145/1323293.1294281"/>
</reference> </reference>
<reference anchor="EPPSTEIN">
<reference anchor="EPPSTEIN" target="https://ics.uci.edu/~eppstein/pubs/
Epp-SJC-98.pdf">
<front> <front>
<title>Finding the k-Shortest Paths</title> <title>Finding the k Shortest Paths</title>
<author initials="D" surname="Eppstein"> <author initials="D" surname="Eppstein">
<organization>USC <organization>USC
</organization> </organization>
</author> </author>
<date year="1997"/> <date year="1997"/>
</front> </front>
</reference> </reference>
<reference anchor="FATTREE">
<reference anchor="FATTREE" target="https://ieeexplore.ieee.org/document
/6312192">
<front> <front>
<title>Fat-Trees: Universal Networks for Hardware-Efficient <title>Fat-Trees: Universal Networks for Hardware-Efficient
Supercomputing</title> Supercomputing</title>
<author initials="C. E." surname="Leiserson"> <author initials="C. E." surname="Leiserson">
<organization>IEEE Transactions on Computers</organization> <organization/>
</author> </author>
<date year="1985"/> <date month="October" year="1985"/>
</front> </front>
<refcontent>IEEE Transactions on Computers, vol. C-34, no. 10, pp. 892
-901</refcontent>
<seriesInfo name="DOI" value="10.1109/TC.1985.6312192"/>
</reference> </reference>
<reference anchor="VAHDAT08">
<reference anchor="VAHDAT08" target="https://dl.acm.org/doi/10.1145/1402
946.1402967">
<front> <front>
<title>A Scalable, Commodity Data Center Network <title>A Scalable, Commodity Data Center Network
Architecture</title> Architecture</title>
<seriesInfo name="SIGCOMM" value=""/>
<author initials="M." surname="Al-Fares"> <author initials="M." surname="Al-Fares">
<organization>USC</organization> <organization>USC</organization>
</author> </author>
<author initials="A." surname="Loukissas"> <author initials="A." surname="Loukissas">
<organization>USC</organization> <organization>USC</organization>
</author> </author>
<author initials="A." surname="Vahdat"> <author initials="A." surname="Vahdat">
<organization>USC</organization> <organization>USC</organization>
</author> </author>
<date year="2008"/> <date month="August" year="2008"/>
</front> </front>
<refcontent>ACM SIGCOMM Computer Communication Review, vol. 38, no. 4,
pp. 63-74</refcontent>
<seriesInfo name="DOI" value="10.1145/1402946.1402967"/>
</reference> </reference>
<reference anchor="VFR">
<reference anchor="VFR" target="https://ieeexplore.ieee.org/document/636
3987">
<front> <front>
<title>Valley-free violation in Internet routing - Analysis based on BGP Community data</title> <title>Valley-free violation in Internet routing - Analysis based on BGP Community data</title>
<seriesInfo name="2012 IEEE International Conference on Communicatio ns (ICC)" value=""/>
<author initials="V." surname="Giotsas"> <author initials="V." surname="Giotsas">
<organization>University College (London, UK)</organization> <organization>University College (London, UK)</organization>
</author> </author>
<author initials="S." surname="Zhou"> <author initials="S." surname="Zhou">
<organization>University College (London, UK)</organization> <organization>University College (London, UK)</organization>
</author> </author>
<date year="2012"/> <date year="2012"/>
</front> </front>
<refcontent>2012 IEEE International Conference on Communications (ICC)
</refcontent>
<seriesInfo name="DOI" value="10.1109/ICC.2012.6363987"/>
</reference> </reference>
<reference anchor="DayOne"> <reference anchor="DayOne">
<front> <front>
<title>Day One: Routing in Fat Trees (RIFT)</title> <title>Day One: Routing in Fat Trees (RIFT)</title>
<seriesInfo name="Juniper DayOne" value=""/>
<author initials="M." surname="Aelmans"> <author initials="M." surname="Aelmans">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
</author> </author>
<author initials="O." surname="Vandezande"> <author initials="O." surname="Vandezande">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
</author> </author>
<author initials="B." surname="Rijsman"> <author initials="B." surname="Rijsman">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
</author> </author>
<author initials="J." surname="Head"> <author initials="J." surname="Head">
skipping to change at line 15342 skipping to change at line 15221
</author> </author>
<author initials="L." surname="Alberro"> <author initials="L." surname="Alberro">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
</author> </author>
<author initials="H." surname="Mali"> <author initials="H." surname="Mali">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
</author> </author>
<author initials="O." surname="Steudler"> <author initials="O." surname="Steudler">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
</author> </author>
<date month="December" year="2020"/>
</front> </front>
<seriesInfo name="ISBN" value="978-1-7363160-0-9"/>
<refcontent>Juniper Network Books</refcontent>
</reference> </reference>
<!-- <!--
<reference anchor="MAKSIC2013"> <reference anchor="MAKSIC2013">
<front> <front>
<title>Improving Utilization of Data Center Networks</title> <title>Improving Utilization of Data Center Networks</title>
<author initials="N." surname="Maksic et al."> <author initials="N." surname="Maksic et al.">
<organization></organization> <organization></organization>
</author><date month="Nov" year="2013"/> </author><date month="Nov" year="2013"/>
</front> </front>
<seriesInfo name="IEEE" value="Communications Magazine"/> <seriesInfo name="IEEE" value="Communications Magazine"/>
</reference> </reference>
skipping to change at line 15402 skipping to change at line 15285
<!-- <reference anchor="Wikipedia"> <!-- <reference anchor="Wikipedia">
<front> <front>
<title>https://en.wikipedia.org/wiki/Serial_number_arithmetic</title > <title>https://en.wikipedia.org/wiki/Serial_number_arithmetic</title >
<author> <author>
<organization>Wikipedia</organization> <organization>Wikipedia</organization>
</author> </author>
<date year="2016"/> <date year="2016"/>
</front> </front>
</reference> --> </reference> -->
</references> </references>
</references> </references>
<section anchor="arithmetic" numbered="true" toc="default"> <section anchor="arithmetic" numbered="true" toc="default">
<name>Sequence Number Binary Arithmetic</name> <name>Sequence Number Binary Arithmetic</name>
<t> <t>This section defines a variant of sequence number arithmetic related
This section defines a variant of sequence number arithmetic related to <xref target="RFC1982"/> explained over two complement arithmetic,
to <xref target="RFC1982"/> which is easy to implement.
explained over two complement arithmetic which is easy to implement
.
</t> </t>
<t>Assuming straight two complement's subtractions on the bit-width <t>Assuming straight two complement's subtractions on the bit width of
of the sequence numbers, the sequence numbers, the corresponding &gt;: and =: relations are
the corresponding &gt;: and =: defined as:
relations
are defined as:
</t> </t>
<artwork align="center" name="" type="" alt=""><![CDATA[ <ul spacing="normal">
U_1, U_2 are 12-bits aligned unsigned version number <li>U_1, U_2 are 12-bits aligned unsigned version number</li>
<li>D_f is ( U_1 - U_2 ) interpreted as two complement signed 12-bits</l
D_f is ( U_1 - U_2 ) interpreted as two complement signed 12-bits i>
D_b is ( U_2 - U_1 ) interpreted as two complement signed 12-bits <li>D_b is ( U_2 - U_1 ) interpreted as two complement signed 12-bits</l
i>
U_1 >: U_2 IIF D_f > 0 *and* D_b < 0 <li>U_1 >: U_2 IIF D_f &gt; 0 <strong>and</strong> D_b &lt; 0</li>
U_1 =: U_2 IIF D_f = 0 <li>U_1 =: U_2 IIF D_f = 0</li>
]]></artwork> </ul>
<t> <t> The &gt;: relationship is anti-symmetric but not transitive.
The &gt;: relationship is anti-symmetric but not transitive. Observe that this leaves &gt;: of the numbers having maximum two
Observe that this leaves &gt;: of the numbers having maximum two complement distance, e.g., ( 0 and 0x800 ) undefined in the 12-bits case
complement since D_f and D_b are both -0x7ff.
distance, e.g. ( 0 and 0x800 ) undefined in the 12-bits case sin
ce D_f and D_b are
both -0x7ff.
</t> </t>
<t>A simple example of the relationship in case of 3-bit arithmetic <t>A simple example of the relationship in case of 3-bit arithmetic
follows as table indicating D_f/D_b values and then the relation follows as table indicating D_f/D_b values and then the relationship of
ship of U_1 to U_2:
U_1 to U_2:
</t> </t>
<artwork align="center" name="" type="" alt=""><![CDATA[
U2 / U1 0 1 2 3 4 5 6 7 <table anchor="Arithmetic-Example-1" align="center">
0 +/+ +/- +/- +/- -/- -/+ -/+ -/+ <thead>
1 -/+ +/+ +/- +/- +/- -/- -/+ -/+ <tr>
2 -/+ -/+ +/+ +/- +/- +/- -/- -/+ <th>U2 / U1</th>
3 -/+ -/+ -/+ +/+ +/- +/- +/- -/- <th>0</th>
4 -/- -/+ -/+ -/+ +/+ +/- +/- +/- <th>1</th>
5 +/- -/- -/+ -/+ -/+ +/+ +/- +/- <th>2</th>
6 +/- +/- -/- -/+ -/+ -/+ +/+ +/- <th>3</th>
7 +/- +/- +/- -/- -/+ -/+ -/+ +/+ <th>4</th>
]]></artwork> <th>5</th>
<artwork align="center" name="" type="" alt=""><![CDATA[ <th>6</th>
U2 / U1 0 1 2 3 4 5 6 7 <th>7</th>
0 = > > > ? < < < </tr>
1 < = > > > ? < < </thead>
2 < < = > > > ? < <tbody>
3 < < < = > > > ? <tr>
4 ? < < < = > > > <td>0</td>
5 > ? < < < = > > <td>+/+</td>
6 > > ? < < < = > <td>+/-</td>
7 > > > ? < < < = <td>+/-</td>
]]></artwork> <td>+/-</td>
<td>-/-</td>
<td>-/+</td>
<td>-/+</td>
<td>-/+</td>
</tr>
<tr>
<td>1</td>
<td>-/+</td>
<td>+/+</td>
<td>+/-</td>
<td>+/-</td>
<td>+/-</td>
<td>-/-</td>
<td>-/+</td>
<td>-/+</td>
</tr>
<tr>
<td>2</td>
<td>-/+</td>
<td>-/+</td>
<td>+/+</td>
<td>+/-</td>
<td>+/-</td>
<td>+/-</td>
<td>-/-</td>
<td>-/+</td>
</tr>
<tr>
<td>3</td>
<td>-/+</td>
<td>-/+</td>
<td>-/+</td>
<td>+/+</td>
<td>+/-</td>
<td>+/-</td>
<td>+/-</td>
<td>-/-</td>
</tr>
<tr>
<td>4</td>
<td>-/-</td>
<td>-/+</td>
<td>-/+</td>
<td>-/+</td>
<td>+/+</td>
<td>+/-</td>
<td>+/-</td>
<td>+/-</td>
</tr>
<tr>
<td>5</td>
<td>+/-</td>
<td>-/-</td>
<td>-/+</td>
<td>-/+</td>
<td>-/+</td>
<td>+/+</td>
<td>+/-</td>
<td>+/-</td>
</tr>
<tr>
<td>6</td>
<td>+/-</td>
<td>+/-</td>
<td>-/-</td>
<td>-/+</td>
<td>-/+</td>
<td>-/+</td>
<td>+/+</td>
<td>+/-</td>
</tr>
<tr>
<td>7</td>
<td>+/-</td>
<td>+/-</td>
<td>+/-</td>
<td>-/-</td>
<td>-/+</td>
<td>-/+</td>
<td>-/+</td>
<td>+/+</td>
</tr>
</tbody>
</table>
<table anchor="Arithmetic-Example-2" align="center">
<thead>
<tr>
<th>U2 / U1</th>
<th>0</th>
<th>1</th>
<th>2</th>
<th>3</th>
<th>4</th>
<th>5</th>
<th>6</th>
<th>7</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>=</td>
<td>&gt;</td>
<td>&gt;</td>
<td>&gt;</td>
<td>?</td>
<td>&lt;</td>
<td>&lt;</td>
<td>&lt;</td>
</tr>
<tr>
<td>1</td>
<td>&lt;</td>
<td>=</td>
<td>&gt;</td>
<td>&gt;</td>
<td>&gt;</td>
<td>?</td>
<td>&lt;</td>
<td>&lt;</td>
</tr>
<tr>
<td>2</td>
<td>&lt;</td>
<td>&lt;</td>
<td>=</td>
<td>&gt;</td>
<td>&gt;</td>
<td>&gt;</td>
<td>?</td>
<td>&lt;</td>
</tr>
<tr>
<td>3</td>
<td>&lt;</td>
<td>&lt;</td>
<td>&lt;</td>
<td>=</td>
<td>&gt;</td>
<td>&gt;</td>
<td>&gt;</td>
<td>?</td>
</tr>
<tr>
<td>4</td>
<td>?</td>
<td>&lt;</td>
<td>&lt;</td>
<td>&lt;</td>
<td>=</td>
<td>&gt;</td>
<td>&gt;</td>
<td>&gt;</td>
</tr>
<tr>
<td>5</td>
<td>&gt;</td>
<td>?</td>
<td>&lt;</td>
<td>&lt;</td>
<td>&lt;</td>
<td>=</td>
<td>&gt;</td>
<td>&gt;</td>
</tr>
<tr>
<td>6</td>
<td>&gt;</td>
<td>&gt;</td>
<td>?</td>
<td>&lt;</td>
<td>&lt;</td>
<td>&lt;</td>
<td>=</td>
<td>&gt;</td>
</tr>
<tr>
<td>7</td>
<td>&gt;</td>
<td>&gt;</td>
<td>&gt;</td>
<td>?</td>
<td>&lt;</td>
<td>&lt;</td>
<td>&lt;</td>
<td>=</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default" anchor="examples_sec"> <section numbered="true" toc="default" anchor="examples_sec">
<name>Examples</name> <name>Examples</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Normal Operation</name> <name>Normal Operation</name>
<figure anchor="pic-topo-normal"> <figure anchor="pic-topo-normal">
<name>Normal Case Topology</name> <name>Normal Case Topology</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-example-baseline.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD /sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xm lns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22- rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http://ww w.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3 .org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 1116 .4 836" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-example-baseline.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD /sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" xm lns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22- rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="http://ww w.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3 .org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox="0 0 1116 .4 836" xml:space="preserve">
<path id="path1583_000000895644396434828990900000041914270278100 91435_" fill="none" stroke="#000000" stroke-width="1.0583" d=" M378,89.6l-153.5 ,249"/> <path id="path1583_000000895644396434828990900000041914270278100 91435_" fill="none" stroke="#000000" stroke-width="1.0583" d=" M378,89.6l-153.5 ,249"/>
<path id="path12779" d="M210.2,427.7v127h1.1v-127H210.2z"/> <path id="path12779" d="M210.2,427.7v127h1.1v-127H210.2z"/>
skipping to change at line 15796 skipping to change at line 15866
| +---0/0---&gt;-----+ 0/0 | +----------------+ | | +---0/0---&gt;-----+ 0/0 | +----------------+ |
0/0 | | | | | | | 0/0 | | | | | | |
| +---&lt;-0/0-----+ | v | +--------------+ | | | +---&lt;-0/0-----+ | v | +--------------+ | |
v | | | | | | | v | | | | | | |
+-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+ +-+---+-+ +--+--+-+ +-+---+-+ +---+-+-+
Level 0 | | | | | | | | Level 0 | | | | | | | |
|Leaf111| |Leaf112| |Leaf121| |Leaf122| |Leaf111| |Leaf112| |Leaf121| |Leaf122|
+-+-----+ +-+---+-+ +--+--+-+ +-+-----+ +-+-----+ +-+---+-+ +--+--+-+ +-+-----+
+ + \ / + + + + \ / + +
Prefix111 Prefix112 \ / Prefix121 Prefix122 Prefix111 Prefix112 \ / Prefix121 Prefix122
multi-homed multihomed
Prefix Prefix
+---------- PoD 1 ---------+ +---------- PoD 2 ---------+</artwork> +---------- PoD 1 ---------+ +---------- PoD 2 ---------+</artwork>
</artset> </artset>
</figure> </figure>
<t>This section describes RIFT deployment in the example topology <t>This section describes RIFT deployment in the example topology
given in <xref target="pic-topo-normal" format="default"/> given in <xref target="pic-topo-normal" format="default"/>
without any node or link failures. The scenario disregards f looding without any node or link failures. The scenario disregards f looding
reduction for simplicity's sake and compresses the node reduction for simplicity's sake and compresses the node
names in some cases to fit them into the picture better. names in some cases to fit them into the picture better.
</t> </t>
<t>First, the following bi-directional adjacencies will be established: <t>First, the following bidirectional adjacencies will be established:
</t> </t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li>ToF 21 (PoD 0) to Spine 111, Spine 112, Spine 121, and S pine 122</li> <li>ToF 21 (PoD 0) to Spine 111, Spine 112, Spine 121, and S pine 122</li>
<li>ToF 22 (PoD 0) to Spine 111, Spine 112, Spine 121, and Spine 122</ li> <li>ToF 22 (PoD 0) to Spine 111, Spine 112, Spine 121, and Spine 122</ li>
<li>Spine 111 to Leaf 111, Leaf 112</li> <li>Spine 111 to Leaf 111 and Leaf 112</li>
<li>Spine 112 to Leaf 111, Leaf 112</li> <li>Spine 112 to Leaf 111 and Leaf 112</li>
<li>Spine 121 to Leaf 121, Leaf 122</li> <li>Spine 121 to Leaf 121 and Leaf 122</li>
<li>Spine 122 to Leaf 121, Leaf 122</li> <li>Spine 122 to Leaf 121 and Leaf 122</li>
</ol> </ol>
<t> <t>
Leaf 111 and Leaf 112 originate N-TIEs for Prefix 111 and Pr efix 112 Leaf 111 and Leaf 112 originate N-TIEs for Prefix 111 and Pr efix 112
(respectively) to both Spine 111 and Spine 112 (Leaf 112 als o originates (respectively) to both Spine 111 and Spine 112 (Leaf 112 als o originates
an N-TIE for the multi-homed prefix). Spine 111 and Spine 1 12 will an N-TIE for the multihomed prefix). Spine 111 and Spine 11 2 will
then originate their own N-TIEs, as well as flood the N-TIEs then originate their own N-TIEs, as well as flood the N-TIEs
received from Leaf 111 and Leaf 112 to both ToF 21 and ToF 2 2. received from Leaf 111 and Leaf 112 to both ToF 21 and ToF 2 2.
</t> </t>
<t> <t>
Similarly, Leaf 121 and Leaf 122 originate North TIEs for Pr efix 121 and Similarly, Leaf 121 and Leaf 122 originate North TIEs for Pr efix 121 and
Prefix 122 (respectively) to Spine 121 and Spine 122 (Leaf 1 21 also originates Prefix 122 (respectively) to Spine 121 and Spine 122 (Leaf 1 21 also originates
a North TIE for the multi-homed prefix). Spine 121 and Spin e 122 will then a North TIE for the multihomed prefix). Spine 121 and Spine 122 will then
originate their own North TIEs, as well as flood the North T IEs received from originate their own North TIEs, as well as flood the North T IEs received from
Leaf 121 and Leaf 122 to both ToF 21 and ToF 22. Leaf 121 and Leaf 122 to both ToF 21 and ToF 22.
</t> </t>
<t>Spines hold only North TIEs of level 0 for their PoD, while leaves on ly hold their own North TIEs <t>Spines hold only North TIEs of level 0 for their PoD, while leaves on ly hold their own North TIEs
while, at this point, both ToF 21 and ToF 22 (as well as any northbound connected controllers) while, at this point, both ToF 21 and ToF 22 (as well as any northbound connected controllers)
would have the complete network topology. would have the complete network topology.
</t> </t>
<t> <t>
ToF 21 and ToF 22 would then originate and flood South TIEs containing any established adjacencies and ToF 21 and ToF 22 would then originate and flood South TIEs containing any established adjacencies and
a default IP route to all spines. Spine 111, Spine 112, Spi ne 121, and Spine 122 will reflect all a default IP route to all spines. Spine 111, Spine 112, Spi ne 121, and Spine 122 will reflect all
Node South TIEs received from ToF 21 to ToF 22, and all Node South TIEs from ToF 22 to ToF 21. South TIEs Node South TIEs received from ToF 21 to ToF 22 and all Node South TIEs from ToF 22 to ToF 21. South TIEs
will not be re-propagated southbound. will not be re-propagated southbound.
</t> </t>
<t> <t>
South TIEs containing a default IP route are then originated by both Spine 111 and Spine 112 toward South TIEs containing a default IP route are then originated by both Spine 111 and Spine 112 towards
Leaf 111 and Leaf 112. Similarly, South TIEs containing a d efault Leaf 111 and Leaf 112. Similarly, South TIEs containing a d efault
IP route are originated by Spine 121 and Spine 122 toward Le af 121 and Leaf 122. IP route are originated by Spine 121 and Spine 122 towards L eaf 121 and Leaf 122.
</t> </t>
<t> <t>
At this point IP connectivity across maximum number of viabl e paths has been established for all leaves, At this point, IP connectivity across the maximum number of viable paths has been established for all leaves,
with routing information constrained to only the minimum amo unt that allows for normal operation and redundancy. with routing information constrained to only the minimum amo unt that allows for normal operation and redundancy.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Leaf Link Failure</name> <name>Leaf Link Failure</name>
<figure anchor="pic-one-link-fail"> <figure anchor="pic-one-link-fail">
<name>Single Leaf Link Failure</name> <name>Single Leaf Link Failure</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-example-leaf-link-failure.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforg e.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/ink scape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/19 99/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg=" http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http ://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox= "0 0 414.7 375" height="375" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-example-leaf-link-failure.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforg e.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/ink scape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/19 99/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg=" http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http ://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox= "0 0 414.7 375" height="375" xml:space="preserve">
skipping to change at line 15960 skipping to change at line 16030
Spine 111. Necessary SPF recomputation Spine 111. Necessary SPF recomputation
will occur, resulting in Spine 112 no longer being in the fo rwarding path for Prefix 112. will occur, resulting in Spine 112 no longer being in the fo rwarding path for Prefix 112.
</t> </t>
<t> <t>
Spine 111 will also disaggregate Prefix 112 by sending new Spine 111 will also disaggregate Prefix 112 by sending new
Prefix South TIE to Leaf 111 and Leaf 112. Though disaggreg ation is covered Prefix South TIE to Leaf 111 and Leaf 112. Though disaggreg ation is covered
in more detail in the following section, it is worth mention ing in this example in more detail in the following section, it is worth mention ing in this example
as it further illustrates RIFT's mechanism to mitigate traff ic loss. Consider as it further illustrates RIFT's mechanism to mitigate traff ic loss. Consider
that Leaf 111 has yet to receive the more specific (disaggre gated) route from Spine 111. that Leaf 111 has yet to receive the more specific (disaggre gated) route from Spine 111.
In such a scenario, traffic from Leaf 111 toward Prefix 112 may still use Spine 112's default In such a scenario, traffic from Leaf 111 towards Prefix 112 may still use Spine 112's default
route, causing it to traverse ToF 21 and ToF 22 back down vi a Spine 111. While this route, causing it to traverse ToF 21 and ToF 22 back down vi a Spine 111. While this
behavior is suboptimal, it is transient in nature and prefer red to dropping traffic. behavior is suboptimal, it is transient in nature and prefer red to dropping traffic.
</t> </t>
</section> </section>
<section anchor="fabriccut" numbered="true" toc="default"> <section anchor="fabriccut" numbered="true" toc="default">
<name>Partitioned Fabric</name> <name>Partitioned Fabric</name>
<figure anchor="pic-part-fabric"> <figure anchor="pic-part-fabric">
<name>Fabric Partition</name> <name>Fabric Partition</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-example-partitioned-fabric.svg"><svg xmlns:sodipodi="http://sodipodi.sourcefor ge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/in kscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1 999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg= "http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="htt p://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox ="0 0 1011.1 792.2" xml:space="preserve"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-example-partitioned-fabric.svg"><svg xmlns:sodipodi="http://sodipodi.sourcefor ge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/in kscape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1 999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg= "http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="htt p://www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox ="0 0 1011.1 792.2" xml:space="preserve">
skipping to change at line 16232 skipping to change at line 16302
Level 3 | | | | | | | | Level 3 | | | | | | | |
|Leaf111| |Leaf112| |Leaf121| |Leaf122| |Leaf111| |Leaf112| |Leaf121| |Leaf122|
+-+-----+ ++------+ +-----+-+ +-+-----+ +-+-----+ ++------+ +-----+-+ +-+-----+
+ + + + + + + +
Prefix111 Prefix112 Prefix121 Prefix122 Prefix111 Prefix112 Prefix121 Prefix122
1.1/16</artwork> 1.1/16</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
<xref target="pic-part-fabric" format="default"/> shows one <xref target="pic-part-fabric" format="default"/> shows more
of more catastrophic catastrophic
scenarios where ToF 21 is completely severed from access to scenario where ToF 21 is completely severed from access to P
Prefix 121 refix 121
due to a double link failure. If only default routes existe d, due to a double link failure. If only default routes existe d,
this would result in 50% of traffic from Leaf 111 and Leaf 1 12 this would result in 50% of traffic from Leaf 111 and Leaf 1 12
toward Prefix 121 being dropped. towards Prefix 121 being dropped.
</t> </t>
<t> <t>
The mechanism to resolve this scenario hinges on ToF 21's The mechanism to resolve this scenario hinges on ToF 21's
South TIEs being reflected from Spine 111 and Spine 112 to T oF 22. South TIEs being reflected from Spine 111 and Spine 112 to T oF 22.
Once ToF 22 is informed that Prefix 121 cannot be reached fr om ToF 21, Once ToF 22 is informed that Prefix 121 cannot be reached fr om ToF 21,
it will begin to disaggregate Prefix 121 by advertising a mo re it will begin to disaggregate Prefix 121 by advertising a mo re
specific route (1.1/16) along with the default IP prefix rou te specific route (1.1/16), along with the default IP prefix ro ute
to all spines (ToF 21 still only sends a default route). Th e to all spines (ToF 21 still only sends a default route). Th e
result is Spine 111 and Spine112 using the more specific result is Spine 111 and Spine 112 using the more specific
route to Prefix 121 via ToF 22. All other prefixes route to Prefix 121 via ToF 22. All other prefixes
continue to use the default IP prefix route toward continue to use the default IP prefix route towards
both ToF 21 and ToF 22. both ToF 21 and ToF 22.
</t> </t>
<t>The more specific route for Prefix 121 being advertised by <t>The more specific route for Prefix 121 being advertised by
ToF 22 does not need to be propagated further south to the l eaves, ToF 22 does not need to be propagated further south to the l eaves,
as they do not benefit from this information. Spine 111 and Spine 112 as they do not benefit from this information. Spine 111 and Spine 112
are only required to reflect the new South Node TIEs receive d from are only required to reflect the new South Node TIEs receive d from
ToF 22 to ToF 21. In short, only the relevant ToF 22 to ToF 21. In short, only the relevant
nodes received the relevant updates, thereby nodes received the relevant updates, thereby
restricting the failure to only the partitioned level rather restricting the failure to only the partitioned level rather
than burdening the whole fabric with the flooding and than burdening the whole fabric with the flooding and
recomputation of the new topology information. recomputation of the new topology information.
</t> </t>
<t> <t>
To finish this example, the following table shows sets compu ted by To finish this example, the following list shows sets comput ed by
ToF 22 using notation introduced in <xref target="disaggrega te" format="default"/>: ToF 22 using notation introduced in <xref target="disaggrega te" format="default"/>:
</t> </t>
<ul empty="true" spacing="normal">
<li>|R = Prefix 111, Prefix 112, Prefix 121, Prefix 122</li> <ul spacing="normal">
<li>|H (for r=Prefix 111) = Spine 111, Spine 112</li> <li>R = Prefix 111, Prefix 112, Prefix 121, Prefix 122</li>
<li>|H (for r=Prefix 112) = Spine 111, Spine 112</li> <li>H (for r=Prefix 111) = Spine 111, Spine 112</li>
<li>|H (for r=Prefix 121) = Spine 121, Spine 122</li> <li>H (for r=Prefix 112) = Spine 111, Spine 112</li>
<li>|H (for r=Prefix 122) = Spine 121, Spine 122</li> <li>H (for r=Prefix 121) = Spine 121, Spine 122</li>
<li>|A (for ToF 21) = Spine 111, Spine 112</li> <li>H (for r=Prefix 122) = Spine 121, Spine 122</li>
<li>A (for ToF 21) = Spine 111, Spine 112</li>
</ul> </ul>
<t>With that and |H (for r=Prefix 121) and |H (for r=Prefix 122) being <t>With that and |H (for r=Prefix 121) and |H (for r=Prefix 122) being
disjoint from |A (for ToF 21), ToF 22 will originate a South disjoint from |A (for ToF 21), ToF 22 will originate a South TIE with
TIE with Prefix 121 and Prefix 122, Prefix 121 and Prefix 122, which will be flooded to all spines.
which will be flooded to all spines.
</t> </t>
</section> </section>
<section anchor="onastickexample" numbered="true" toc="default"> <section anchor="onastickexample" numbered="true" toc="default">
<name>Northbound Partitioned Router and Optional East-West Links</name> <name>Northbound Partitioned Router and Optional East-West Links</name>
<t> <t>
</t> </t>
<figure anchor="north-part-node"> <figure anchor="north-part-node">
<name>North Partitioned Router</name> <name>North Partitioned Router</name>
<artset> <artset>
<artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-north-partitioned-router.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge .net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inks cape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/199 9/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="h ttp://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http: //www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox=" 0 0 707.9 300" xml:space="preserve" height="300"> <artwork align="center" name="" type="svg" originalSrc="art/rift-rif t-north-partitioned-router.svg"><svg xmlns:sodipodi="http://sodipodi.sourceforge .net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inks cape" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/199 9/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:svg="h ttp://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http: //www.w3.org/1999/xlink" version="1.2" baseProfile="tiny" id="svg2384" viewBox=" 0 0 707.9 300" xml:space="preserve" height="300">
skipping to change at line 16400 skipping to change at line 16471
| | | | | | | | | | | | | | | | | |
++-+-+--+ | +---+---+ | +-+---+-++ ++-+-+--+ | +---+---+ | +-+---+-++
| | +-+ +-+ | | | | +-+ +-+ | |
| L01 | | L02 | | L03 | Level 0 | L01 | | L02 | | L03 | Level 0
+-------+ +-------+ +--------+</artwork> +-------+ +-------+ +--------+</artwork>
</artset> </artset>
</figure> </figure>
<t> <t>
<xref target="north-part-node" format="default"/> shows a pa rt of a fabric where <xref target="north-part-node" format="default"/> shows a pa rt of a fabric where
level 1 is horizontally connected and A01 lost its only nort hbound level 1 is horizontally connected and A01 lost its only nort hbound
adjacency. Based on N-SPF rules in <xref target="nspf" forma t="default"/> A01 will adjacency. Based on N-SPF rules in <xref target="nspf" forma t="default"/>, A01 will
compute northbound reachability by using the link A01 to A02 . compute northbound reachability by using the link A01 to A02 .
A02 however, will <strong>not</strong> use this link during N-SPF. The result is A01 However, A02 will <strong>not</strong> use this link during N-SPF. The result is A01
utilizing the horizontal link for default route advertisemen t and unidirectional routing. utilizing the horizontal link for default route advertisemen t and unidirectional routing.
</t> </t>
<t> <t>
Furthermore, if A02 also loses Furthermore, if A02 also loses
its only northbound adjacency (N2), the situation evolves. its only northbound adjacency (N2), the situation evolves.
A01 will no longer have northbound reachability while it rec eives A01 will no longer have northbound reachability while it rec eives
A03's northbound adjacencies in South Node TIEs reflected by nodes south of it. A03's northbound adjacencies in South Node TIEs reflected by nodes south of it.
As a result, A01 will no longer advertise its default route in accordance with <xref target="defaultrouterules" format="default"/>. As a result, A01 will no longer advertise its default route in accordance with <xref target="defaultrouterules" format="default"/>.
skipping to change at line 16431 skipping to change at line 16502
2. simply use a PI "less than characte 2. simply use a PI "less than characte
r"?rfc include="reference.RFC.2119.xml"?> here r"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis .xml") (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis .xml")
Both are cited textually in the same manner: by using xref elements. Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find include d files in the same If you use the PI option, xml2rfc will, by default, try to find include d files in the same
directory as the including file. You can also define the XML_LIBRARY en vironment variable directory as the including file. You can also define the XML_LIBRARY en vironment variable
with a value containing a set of directories to search. These can be e ither in the local with a value containing a set of directories to search. These can be e ither in the local
filing system or remote ones accessed by http (http://domain/dir/... ). --> filing system or remote ones accessed by http (http://domain/dir/... ). -->
<section anchor="Acknowledgments" numbered="false" toc="default">
<name>Acknowledgments</name>
<t> A new routing protocol in its complexity is not a product of a
parent but of a village, as the author list already shows. However, many
more people provided input and fine-combed the specification based on thei
r
experience in design, implementation, or application of protocols in IP
fabrics. This section will make an inadequate attempt in recording
their contribution.
</t>
<t>Many thanks to <contact fullname="Naiming Shen"/> for some of the
early discussions around the topic of using IGPs for routing in
topologies related to Clos. <contact fullname="Russ White"/> is
especially acknowledged for the key conversation on epistemology that
tied the current asynchronous distributed systems theory results
to a modern protocol design presented in this scope. <contact
fullname="Adrian Farrel"/>, <contact fullname="Joel Halpern"/>, <contact
fullname="Jeffrey Zhang"/>, <contact fullname="Krzysztof Szarkowicz"/>,
<contact fullname="Nagendra Kumar"/>, <contact fullname="Melchior
Aelmans"/>, <contact fullname="Kaushal Tank"/>, <contact fullname="Will
Jones"/>, <contact fullname="Moin Ahmed"/>, <contact fullname="Zheng (Sand
y) Zhang"/>, and <contact fullname="Donald Eastlake"/> provided thoughtful
comments that improved the readability of the document and found a good
amount of corners where the light failed to shine. <contact
fullname="Kris Price"/> was first to mention single router, single arm
default considerations. <contact fullname="Jeff Tantsura"/> helped out
with some initial thoughts on BFD interactions while <contact
fullname="Jeff Haas"/> corrected several misconceptions about BFD's
finer points and helped to improve the security section around leaf
considerations. <contact fullname="Artur Makutunowicz"/> pointed out
many possible improvements and acted as a sounding board in regard to
modern protocol implementation techniques RIFT is exploring. <contact
fullname="Barak Gafni"/> formalized the problem of
partitioned spine and fallen leaves for the first time clearly on a (clea
n) napkin in Singapore
that led to the very important part of the specification centered around
multiple ToF planes and negative disaggregation. <contact fullname="Igor
Gashinsky"/> and others shared many thoughts on problems encountered in
design and operation of large-scale data center fabrics. <contact
fullname="Xu Benchong"/> found a delicate error in the flooding
procedures and a schema datatype size mismatch.
</t>
<t>Too many people to mention provided reviews from many directions in
IETF, often pointing to critical defects, sometimes asking for things
again that have been removed by one of the previous reviewers as
objectionable or superfluous, and many times claiming the document being
somewhere on the extremes between too crowded with the obvious and
omitting introduction to cryptic concepts everywhere. The result is the
best editors could do to find a balance of a document guiding the reader
by <xref target="digest"/> into a specification tight enough to result
in interoperable implementations while at the same time introducing
enough operational context of IP routable fabrics to guarantee a
concise, common language when facing unaccustomed concepts the protocol
relies on. In the process, it was important to not end up carrying
Aesop's donkey of course, so while the result may not be perceived as
perfect by everyone, it should be practically speaking more than
sufficient for everyone that ends up using it in the future.
</t>
<t>Last but not least, <contact fullname="Alvaro Retana"/>, <contact
fullname="John Scudder"/>, <contact fullname="Andrew Alston"/>, and
<contact fullname="Jim Guichard"/> guided the undertaking as ADs by
asking many necessary procedural and technical questions that did not
only improve the content but also laid out the track towards
publication. And <contact fullname="Roman Danyliw"/> is mentioned very
last but not least for both his painstakingly detailed review and
improvement of security aspects of the specification. </t>
</section>
<section numbered="false" toc="default">
<!--[rfced] Should Alankar Sharma's name also be listed in the Contributors
section, since the other authors are also listed there?
-->
<name>Contributors</name>
<t> This work is a product of a list of individuals who are all to be
considered major contributors, independent of the fact whether or not thei
r name
made it to the limited author list.
</t>
<contact fullname="Tony Przygienda, Ed.">
<organization>Juniper</organization>
</contact>
<contact fullname="Pascal Thubert">
<organization>Cisco</organization>
</contact>
<contact fullname="Bruno Rijsman">
<organization>Individual</organization>
</contact>
<contact fullname="Jordan Head, Ed.">
<organization>Juniper</organization>
</contact>
<contact fullname="Dmitry Afanasiev">
<organization>Individual</organization>
</contact>
<contact fullname="Don Fedyk">
<organization>LabN</organization>
</contact>
<contact fullname="Alia Atlas">
<organization>Individual</organization>
</contact>
<contact fullname="John Drake">
<organization>Individual</organization>
</contact>
<contact fullname="Ilya Vershkov">
<organization>Nvidia</organization>
</contact>
</section>
</back> </back>
<!-- [rfced] Regarding the SVG questions below, please review the TXT, HTML,
and PDF outputs, as we will need you to update the edited copy
of the XML.
a) The SVG figures contain duplicate ids, which generates invalid HTML. Please
let us know if you want to correct the SVG or if you want us to run a utility
that creates unique ids within the SVG.
b) Please see Figures 14 and 29 in the HTML and PDF outputs. The output for the
SVG appear to be jumbled. To fix the SVG, please provide us with the files of
the updated SVG.
c) We note that the text within many of the SVG figures is not able to be
selected. (For example: text in Figures 1, 2, 32.) Is it possible to modify
the SVG using your preferred SVG editing software to improve the rendering
of the string in the SVG?
Here is an example of SVG where the strings within the SVG are
selectable and searchable:
https://www.rfc-editor.org/rfc/rfc9576.html#figure-1
-->
<!--[rfced] The artwork ("ascii-art") for Figures 3, 13, and 18 is
too wide for the text output. Is it possible to wrap it within
the 72-character line limit?
If not: Because SVG diagrams exist for those 3 figures, you have the option
to remove the ascii-art completely; in that case, the text file would contain
a pointer to the HTML file. For example:
(Artwork only available as SVG: see
https://www.rfc-editor.org/rfc/rfc9692.html)
-->
<!-- [rfced] The sourcecode element in Sections 7.2 (common.thrift)
contains lines that are too long for the line-length limitation of
the text output. Please let us know how we may wrap the text to fit
within 69 characters per line (or please update the XML source
file).
FYI, we added line breaks and adjusted whitespace in sourcecode elements
in the following sections to fit the limit. Please review.
Section 6.3.3 (TIEHeader Comparison Function)
Section 7.3 (encoding.thrift)
-->
<!--[rfced] Please review the "type" attribute of each sourcecode element
in the XML file to ensure correctness. If the current list of preferred
values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types)
does not contain an applicable type, then feel free to let us know.
Also, it is acceptable to leave the "type" attribute not set.
-->
<!-- [rfced] Regarding <em> and <strong> elements:
In the HTML and PDF outputs, <em> yields italics.
In the text output, <em> yields an underscore before and after.
In the HTML and PDF outputs, <strong> yields bold.
In the text output, <strong> yields an asterisk before and after.
Please review the occurrences and let us know if any updates are needed for
consistency.
-->
<!-- [rfced] Some author comments are present in the XML. Please confirm
that no updates related to these comments are outstanding. Note that the
comments will be deleted prior to publication.
-->
<!-- [rfced] Terminology
a) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how they
may be made consistent.
Fallen Leaf vs. fallen leaf
holddown vs. hold down
Radix vs. radix
single-plane vs. single plane
North Node TIE vs. node North TIE
South Node TIE vs. Node South TIE
north prefix TIE vs. Prefix North TIE
South Prefix TIE vs. south prefix TIE vs. Prefix South TIE vs.
prefix South TIE
superspine vs. super-spine
c) May we update "non-significant bits" to "insignificant bits"?
Original (2 instances):
The non-significant bits can be used for operational purposes.
d) May this misspelling be corrected? Apparently "multiplier" was intended.
multiple_neighbors_lie_holdtime_multipler (5 instances)
-> multiple_neighbors_lie_holdtime_multiplier
multipler for default ... -> multiplier for default ...
-->
<!-- [rfced] Acronyms
a) FYI - We have added expansions for the following abbreviations
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Bidirectional Forwarding Detection (BFD)
Internet of Things (IoT)
Layer 3 (L3)
Locator/ID Separation Protocol (LISP)
MAC Address Block Large (MA-L)
Virtual eXtensible Local Area Network (VXLAN)
c) Which form should the following acronyms be expanded as?
AF = Assured Forwarding vs. Address Family vs. Appointed Forwarder
IDL = interface definition language vs. Interface Description Language
L2L = Leaf-to-Leaf vs. leaf-2-leaf
d) After their first expansion, may we update all instances of the following
expanded forms to be their corresponding acronyms?
East-West (E-W)
flood repeater (FR)
key identifiers (key ID)
leaf-2-leaf (L2L)
link state database (LSDB)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the following should be updated:
man in the middle
In addition, please consider whether "traditional" should be updated for clarity
.
While the NIST website
<https://www.nist.gov/nist-research-library/nist-technical-series-publications-a
uthor-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
-->
</rfc> </rfc>
 End of changes. 1324 change blocks. 
4734 lines changed or deleted 4689 lines changed or added

This html diff was produced by rfcdiff 1.48.