rfc9816xml2.original.xml   rfc9816.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <!DOCTYPE rfc [
<?rfc tocdepth="3"?> <!ENTITY nbsp "&#160;">
<?rfc tocindent="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc symrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc sortrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc comments="yes"?> ]>
<?rfc inline="yes"?>
<?rfc compact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-i
<?rfc subcompact="no"?> etf-lsvr-applicability-22" number="9816" ipr="trust200902" submissionType="IETF"
<rfc category="info" docName="draft-ietf-lsvr-applicability-22" tocDepth="3" version="3" tocInclude="true" symRefs="true" sortRefs="true" updat
ipr="trust200902" submissionType="IETF" tocDepth="5" version="2"> es="" obsoletes="" consensus="true" xml:lang="en">
<front> <front>
<title abbrev="BGP-SPF Applicability">Usage and Applicability of BGP
Link-State Shortest Path Routing (BGP-SPF) in Data Centers</title>
<title abbrev="BGP-LS SPF Applicability in DCs">Usage and Applicability of B
GP
Link State (BGP-LS) Shortest Path First (SPF) Routing in Data Centers</title
>
<seriesInfo name="RFC" value="9816"/>
<author fullname="Keyur Patel" initials="K" surname="Patel"> <author fullname="Keyur Patel" initials="K" surname="Patel">
<organization>Arrcus, Inc.</organization> <organization>Arrcus, Inc.</organization>
<address> <address>
<postal> <postal>
<street>2077 Gateway Pl</street> <street>2077 Gateway Pl</street>
<city>San Jose</city><region>CA</region>
<city>San Jose, CA</city> <country>United States of America</country>
<country>USA</country>
<code>95110</code> <code>95110</code>
</postal> </postal>
<phone/>
<email>keyur@arrcus.com</email> <email>keyur@arrcus.com</email>
</address> </address>
</author> </author>
<author fullname="Acee Lindem" initials="A" surname="Lindem"> <author fullname="Acee Lindem" initials="A" surname="Lindem">
<organization>LabN Consulting, L.L.C.</organization> <organization>Arrcus, Inc.</organization>
<address> <address>
<postal> <postal>
<street>301 Midenhall Way</street> <street>301 Midenhall Way</street>
<city>Cary</city><region>NC</region>
<city>Cary, NC</city> <country>United States of America</country>
<code>27513</code>
<country>USA</country>
<code>95110</code>
</postal> </postal>
<phone/>
<email>acee.ietf@gmail.com</email> <email>acee.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Shawn Zandi" initials="S" surname="Zandi"> <author fullname="Shawn Zandi" initials="S" surname="Zandi">
<organization>Linkedin</organization> <organization/>
<address> <address>
<postal> <email>shafagh@shafagh.com</email>
<street>222 2nd Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94105</code>
<country>USA</country>
</postal>
<email>szandi@linkedin.com</email>
</address> </address>
</author> </author>
<author fullname="Gaurav Dawra" initials="G" surname="Dawra"> <author fullname="Gaurav Dawra" initials="G" surname="Dawra">
<organization>Linkedin</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street>222 2nd Street</street> <city>Sunnyvale</city>
<city>San Francisco</city>
<region>CA</region> <region>CA</region>
<country>United States of America</country>
<code>94105</code>
<country>USA</country>
</postal> </postal>
<email>gdawra.ietf@gmail.com</email>
<email>gdawra@linkedin.com</email>
</address> </address>
</author> </author>
<author fullname="Jie Dong" initials="J." surname="Dong"> <author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>No. 156 Beiqing Road</street> <street>No. 156 Beiqing Road</street>
<city>Beijing</city> <city>Beijing</city>
<region/>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>jie.dong@huawei.com</email> <email>jie.dong@huawei.com</email>
</address> </address>
</author> </author>
<date month="July" year="2025"/>
<area>RTG</area>
<workgroup>lsvr</workgroup>
<date/> <abstract>
<t>This document discusses the usage and applicability of BGP Link State (
<abstract> BGP-LS)
<t>This document discusses the usage and applicability of BGP Link-State Shortest Path First (SPF) extensions in data center networks
Shortest Path First (BGP-SPF) extensions in data center networks utilizing Clos or Fat Tree topologies. The document is intended to
utilizing Clos or Fat-Tree topologies. The document is intended to provide simplified guidance for the deployment of BGP-LS SPF
provide simplified guidance for the deployment of BGP-SPF
extensions.</t> extensions.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section>
<t>This document complements <xref format="default" <name>Introduction</name>
target="I-D.ietf-lsvr-bgp-spf"/> by discussing the applicability of the <t>This document complements <xref format="default" target="RFC9815"/>
BGP-SPF technology in a simple and fairly common deployment scenario, by discussing the applicability of the BGP Link State (BGP-LS) Shortest
which is described in <xref format="default" target="usecases"/>.</t> Path First (SPF) technology in a simple and fairly common deployment
scenario, which is described in <xref format="default"
target="usecases"/>.</t>
<t><xref format="default" target="motivation"/> describes the reasons <t><xref format="default" target="motivation"/> describes the reasons
for BGP modifications for such deployments.</t> for BGP modifications for such deployments.</t>
<t><xref format="default" target="bgpspf"/> covers the BGP Link-State <t><xref format="default" target="bgpspf"/> covers the BGP SPF protocol en
Shortest Path First (IGP-SPF) protocol enhancements to BGP to meet these hancements to BGP to meet these
requirements and their applicability to data center <xref requirements and their applicability to data center <xref format="default"
format="default" target="Clos"/> networks.</t> target="Clos"/> networks.</t>
</section> </section>
<section anchor="reco">
<name>Recommended Reading</name>
<section anchor="reco" title="Recommended Reading">
<t>This document assumes knowledge of existing data center networks and <t>This document assumes knowledge of existing data center networks and
data center network topologies <xref format="default" target="Clos"/>. data center network topologies <xref format="default" target="Clos"/>.
This document also assumes knowledge of data center routing protocols This document also assumes knowledge of data center routing protocols
such as BGP <xref format="default" target="RFC4271"/>, BGP-SPF <xref such as BGP <xref format="default" target="RFC4271"/>, BGP-LS SPF <xref fo
format="default" target="I-D.ietf-lsvr-bgp-spf"/>, OSPF <xref rmat="default" target="RFC9815"/>, and OSPF <xref format="default" target="RFC23
format="default" target="RFC2328"/> <xref target="RFC5340"/>, as well as 28"/> <xref target="RFC5340"/> as well as
data center Operations, Administration, and Maintenance (OAM) protocols data center Operations, Administration, and Maintenance (OAM) protocols
like Link Layer Discovery Protocol (LLDP) <xref format="default" like the Link Layer Discovery Protocol (LLDP) <xref format="default" targe
target="RFC4957"/> and Bi-Directional Forwarding Detection (BFD) <xref t="RFC4957"/> and Bidirectional Forwarding Detection (BFD) <xref format="default
format="default" target="RFC5580"/>.</t> " target="RFC5880"/>.</t>
</section> </section>
<section anchor="usecases">
<section anchor="usecases" title="Common Deployment Scenario"> <name>Common Deployment Scenario</name>
<t>Within a data center, servers are commonly interconnected using the <t>Within a data center, servers are commonly interconnected using the
Clos topology <xref format="default" target="Clos"/>. The Clos topology Clos topology <xref format="default" target="Clos"/>. The Clos topology
is fully non-blocking and the topology is realized using Equal Cost is fully non-blocking, and the topology is realized using Equal-Cost
Multi-Path (ECMP). In a multi-stage Clos topology, the minimum number of Multipath (ECMP). In a multi-stage Clos topology, the minimum number of
parallel paths in each tier is determined by the width of the stage as parallel paths in each tier is determined by the width of the stage as
shown in the figure 1.</t> shown in <xref target="fig1"/>.</t>
<figure anchor="fig1">
<t> <name>Illustration of the Basic Clos</name>
<figure anchor="fig1"> <artwork align="left" alt="" name="" type=""><![CDATA[
<name>Illustration of the basic Clos</name>
<artwork align="left" alt="" name="" type=""><![CDATA[
Tier 1 Tier 1
+-----+ +-----+
|NODE | |NODE |
+->| 1 |--+ +->| 1 |--+
| +-----+ | | +-----+ |
Tier 2 | | Tier 2 Tier 2 | | Tier 2
+-----+ | +-----+ | +-----+ +-----+ | +-----+ | +-----+
+------------->|NODE |--+->|NODE |--+--|NODE |--------------+ +------------->|NODE |--+->|NODE |--+--|NODE |--------------+
| +-----| 5 |--+ | 2 | +--| 7 |-----+ | | +-----| 5 |--+ | 2 | +--| 7 |-----+ |
| | +-----+ +-----+ +-----+ | | | | +-----+ +-----+ +-----+ | |
skipping to change at line 194 skipping to change at line 138
| +------+---->|NODE |--+ |NODE | +--|NODE |-----+------+ | | +------+---->|NODE |--+ |NODE | +--|NODE |-----+------+ |
| | | +---| 6 |--+->| 3 |--+--| 8 |---+ | | | | | | +---| 6 |--+->| 3 |--+--| 8 |---+ | | |
| | | | +-----+ | +-----+ | +-----+ | | | | | | | | +-----+ | +-----+ | +-----+ | | | |
| |Tier 3| | | | | |Tier 3| | | |Tier 3| | | | | |Tier 3| |
+-----+ +-----+ | +-----+ | +-----+ +-----+ +-----+ +-----+ | +-----+ | +-----+ +-----+
|NODE | |NODE | +->|NODE |--+ |NODE | |NODE | |NODE | |NODE | +->|NODE |--+ |NODE | |NODE |
| 9 | | 10 | | 4 | | 11 | | 12 | | 9 | | 10 | | 4 | | 11 | | 12 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | | | | | | | | | | | |
<- Servers -> <- Servers -> <- Servers -> <- Servers ->
]]></artwork>
</figure>
Tier 1 is comprised of Nodes 1, 2, 3, and 4 <ul spacing="normal">
Tier 2 is comprised of Nodes 5, 6, 7, and 8 <li>Tier 1 is comprised of Nodes 1, 2, 3, and 4</li>
Tier 3 is comprised of Nodes 9, 10, 11, and 12 <li>Tier 2 is comprised of Nodes 5, 6, 7, and 8</li>
<li>Tier 3 is comprised of Nodes 9, 10, 11, and 12</li>
</ul>
]]></artwork>
</figure>
</t>
</section> </section>
<section anchor="motivation">
<section anchor="motivation" title="Justification for BGP-SPF Extension"> <name>Justification for the BGP-SPF Extension</name>
<t>To simplify L3 routing and operations, many data centers use BGP as a <t>To simplify Layer 3 (L3) routing and operations, many data centers use
BGP as a
routing protocol to create both an underlay and an overlay network for routing protocol to create both an underlay and an overlay network for
their Clos Topologies <xref format="default" target="RFC7938"/>. their Clos topologies <xref format="default" target="RFC7938"/>.
However, BGP is a path-vector routing protocol. Since it does not create However, BGP is a path-vector routing protocol. Since it does not create
a fabric topology, it uses hop-by-hop External BGP (EBGP) peering to a fabric topology, it uses hop-by-hop External BGP (EBGP) peering to
facilitate hop-by-hop routing to create the underlay network and to facilitate hop-by-hop routing to create the underlay network and to
resolve any overlay next hops. The hop-by-hop BGP peering paradigm resolve any overlay next hops. The hop-by-hop BGP peering paradigm
imposes several restrictions within a Clos. It prohibits the deployment imposes several restrictions within a Clos. It prohibits the deployment
of Route Reflectors/Route Controllers as the EBGP sessions are congruent of route reflectors / route controllers as the EBGP sessions are congruent
with the data path. The BGP best-path algorithm is prefix-based and it with the data path. The BGP best-path algorithm is prefix based, and it
prevents announcements of prefixes to other BGP speakers until the prevents announcements of prefixes to other BGP speakers until the
best-path decision process has been performed for the prefix at each best-path decision process has been performed for the prefix at each
intermediate hop. These restrictions significantly delay the overall intermediate hop. These restrictions significantly delay the overall
convergence of the underlay network within a Clos network.</t> convergence of the underlay network within a Clos network.</t>
<t>The BGP-SPF modifications allow BGP to overcome these limitations. <t>The BGP SPF modifications allow BGP to overcome these limitations.
Furthermore, using the BGP-LS Network Layer Reachability Information Furthermore, using the BGP-LS Network Layer Reachability Information
(NLRI) format allows the BGP-SPF data to be advertised for nodes, links, (NLRI) format allows the BGP SPF data to be advertised for nodes, links,
and prefixes in the BGP routing domain and used for Short-Path-First and prefixes in the BGP routing domain <xref target="RFC9552"/> and used f
(SPF) computations <xref target="RFC9552"/>.</t> or SPF computations <xref target="RFC9815"/>.</t>
<t>Additional motivation for deploying BGP-SPF is included in <xref target
<t>Additional motivation for deploying BGP-SPF is included in <xref ="RFC9815"/>.</t>
target="I-D.ietf-lsvr-bgp-spf"/>.</t>
</section> </section>
<section anchor="bgpspf">
<section anchor="bgpspf" title="BGP-SPF Applicability to Clos Networks"> <name>BGP-SPF Applicability to Clos Networks</name>
<t>With the BGP-SPF extensions <xref format="default" <t>With the BGP-SPF extensions <xref format="default" target="RFC9815"/>,
target="I-D.ietf-lsvr-bgp-spf"/>, the BGP best-path computation and the BGP best-path computation and
route computation are replaced with link-state algorithms such as those route computation are replaced with link-state algorithms such as those
used by OSPF <xref format="default" target="RFC2328"/>, both to used by OSPF <xref format="default" target="RFC2328"/>, both to
determine whether an BGP-LS-SPF NLRI has changed and needs to be determine whether a BGP-LS-SPF NLRI has changed and needs to be
re-advertised and to compute the BGP routes. These modifications will readvertised and to compute the BGP routes. These modifications will
significantly improve convergence of the underlay while affording the significantly improve convergence of the underlay while affording the
operational benefits of a single routing protocol <xref format="default" operational benefits of a single routing protocol <xref format="default" t
target="RFC7938"/>.</t> arget="RFC7938"/>.</t>
<t>Data center controllers typically require visibility to the BGP <t>Data center controllers typically require visibility to the BGP
topology to compute traffic-engineered paths. These controllers learn topology to compute traffic-engineered paths. These controllers learn
the topology and other relevant information via the BGP-LS address the topology and other relevant information via the BGP-LS address
family <xref format="default" target="RFC9552"/> which is totally family <xref format="default" target="RFC9552"/>, which is totally
independent of the underlay address families (usually IPv4/IPv6 independent of the underlay address families (usually IPv4/IPv6
unicast). Furthermore, in traditional BGP underlays, all the BGP routers unicast). Furthermore, in usual BGP underlays, all the BGP routers
will need to advertise their BGP-LS information independently. With the will need to advertise their BGP-LS information independently. With the
BGP-SPF extensions, controllers can learn the topology using the same BGP-SPF extensions, controllers can learn the topology using the same
BGP advertisements used to compute the underlay routes. Furthermore, BGP advertisements used to compute the underlay routes. Furthermore,
these data center controllers can avail the convergence advantages of these data center controllers can avail the convergence advantages of
the BGP-SPF extensions. The placement of controllers can be outside of the BGP-SPF extensions. The placement of controllers can be outside of
the forwarding path or within the forwarding path.</t> the forwarding path or within the forwarding path.</t>
<t>Alternatively, as each and every router in the BGP-SPF domain will <t>Alternatively, as each and every router in the BGP-SPF domain will
have a complete view of the topology, the operator can also choose to have a complete view of the topology, the operator can also choose to
configure BGP sessions in the hop-by-hop peering model described in configure BGP sessions in the hop-by-hop peering model described in
<xref format="default" target="RFC7938"/> along with BFD <xref <xref format="default" target="RFC7938"/> along with BFD <xref format="def
format="default" target="RFC5580"/>. In doing so, while the hop-by-hop ault" target="RFC5880"/>. In doing so, while the hop-by-hop
peering model lacks the inherent benefits of the controller-based model, peering model lacks the inherent benefits of the controller-based model,
BGP updates need not be serialized by the BGP best-path algorithm in BGP updates need not be serialized by the BGP best-path algorithm in
either of these models. This helps overall network convergence.</t> either of these models. This helps overall network convergence.</t>
<section anchor="lsvrsafi">
<section anchor="lsvrsafi" title="Usage of BGP-LS SPF SAFI"> <name>Usage of BGP-LS-SPF SAFI</name>
<t>Section 5.1 of <xref format="default" <t><xref section="5.1" sectionFormat="of" format="default" target="RFC98
target="I-D.ietf-lsvr-bgp-spf"/> defines a new BGP-LS-SPF SAFI for 15"/> defines a new BGP-LS-SPF SAFI for
announcement of the BGP-SPF link-state. The NLRI format and its announcement of the BGP-SPF link-state. The NLRI format and its
associated attributes follow the format of BGP-LS for node, link, and associated attributes follow the format of BGP-LS for node, link, and
prefix announcements. Whether the peering model within a Clos follows prefix announcements. Whether the peering model within a Clos follows
hop-by-hop peering described in <xref format="default" hop-by-hop peering as described in <xref format="default" target="RFC793
target="RFC7938"/> or any controller-based or route-reflector peering, 8"/> or any controller-based or route-reflector peering,
an operator can exchange BGP-LS-SPF SAFI routes over the BGP peering an operator can exchange BGP-LS-SPF SAFI routes over the BGP peering
by simply configuring BGP-LS-SPF SAFI between the necessary BGP by simply configuring BGP-LS-SPF SAFI between the necessary BGP
speakers.</t> speakers.</t>
<t>The BGP-LS-SPF SAFI can also coexist with BGP IP Unicast SAFI
<t>The BGP-LS-SPF SAFI can also co-exist with BGP IP Unicast SAFI <xref target="RFC4760"/>, which could exchange overlapping IP routes.
<xref target="RFC4760"/> which could exchange overlapping IP routes.
One use case for this is where BGP-LS-SPF routes are used for the One use case for this is where BGP-LS-SPF routes are used for the
underlay and BGP IP Unicast routes for VPNs are advertised in the underlay and BGP IP Unicast routes for VPNs are advertised in the
overlay as described in <xref target="RFC4364"/>. The routes received overlay as described in <xref target="RFC4364"/>. The routes received
by these SAFIs are evaluated, stored, and announced independently by these SAFIs are evaluated, stored, and announced independently
according to the rules of <xref format="default" target="RFC4760"/>. according to the rules of <xref format="default" target="RFC4760"/>.
The tie-breaking of route installation is a matter of the local The tiebreaking of route installation is a matter of the local
policies and preferences of the network operator.</t> policies and preferences of the network operator.</t>
<t>Finally, as the BGP-SPF peering is done following the procedures <t>Finally, as the BGP-SPF peering is done following the procedures
described in <xref format="default" target="RFC4271"/>, all the described in <xref format="default" target="RFC4271"/>, all the
existing transport security mechanisms including <xref existing transport security mechanisms including those in <xref format="
format="default" target="RFC5925"/> are available for the BGP-LS-SPF default" target="RFC5925"/> are available for the BGP-LS-SPF
SAFI.</t> SAFI.</t>
<section anchor="other-safi">
<section anchor="other-safi" <name>Relationship to Other BGP AFI/SAFI Tuples</name>
title="Relationship to Other BGP AFI/SAFI Tuples">
<t>Normally, the BGP-LS-SPF AFI/SAFI is used solely to compute the <t>Normally, the BGP-LS-SPF AFI/SAFI is used solely to compute the
underlay and is given precedence over other AFI/SAFIs in route underlay and is given precedence over other AFI/SAFIs in route
processing. Other BGP SAFIs, e.g., IPv6/IPv6 Unicast VPN would use processing. Other BGP SAFIs, e.g., IPv6/IPv6 unicast VPN, would use
the BGP-SPF computed routes for next hop resolution.</t> the BGP-SPF computed routes for next-hop resolution.</t>
</section> </section>
</section> </section>
<section anchor="peering">
<section anchor="peering" title="Peering Models"> <name>Peering Models</name>
<t>As previously stated, BGP-SPF can be deployed using the existing <t>As previously stated, BGP-SPF can be deployed using the existing
peering model where there is a single-hop BGP session on each and peering model where there is a single-hop BGP session on each and
every link in the data center fabric <xref format="default" every link in the data center fabric <xref format="default" target="RFC7
target="RFC7938"/>. This provides for both the advertisement of routes 938"/>. This provides for both the advertisement of routes
and the determination of link and neighboring router availability. and the determination of link and neighboring router availability.
With BGP-SPF, the underlay will converge faster due to changes to the With BGP-SPF, the underlay will converge faster due to changes to the
decision process that will allow NLRI changes to be advertised faster decision process that will allow NLRI changes to be advertised faster
after detecting a change.</t> after detecting a change.</t>
<section anchor="sparse-peering">
<section anchor="sparse-peering" title="Sparse Peering Model"> <name>Sparse Peering Model</name>
<t>Alternately, BFD <xref format="default" target="RFC5580"/> can be <t>Alternately, BFD <xref format="default" target="RFC5880"/> can be
used to swiftly determine the availability of links and the BGP used to swiftly determine the availability of links, and the BGP
peering model can be significantly sparser than the data center peering model can be significantly sparser than the data center
fabric. BGP-SPF sessions only need to be established with enough fabric. BGP-SPF sessions only need to be established with enough
peers to provide a bi-connected graph. If Internal BGP (IBGP) is peers to provide a biconnected graph. If Internal BGP (IBGP) is
used, then the BGP routers at tier N-1 will act as route-reflectors used, then the BGP routers at tier N-1 will act as route-reflectors
for the routers at tier N.</t> for the routers at tier N.</t>
<t>The obvious usage of sparse peering is to avoid parallel BGP <t>The obvious usage of sparse peering is to avoid parallel BGP
sessions on links between the same two routers in the data center sessions on links between the same two routers in the data center
fabric. However, this use case is not very useful since parallel L3 fabric. However, this use case is not very useful since parallel L3
links between the same two BGP routers are rare in Clos or Fat-Tree links between the same two BGP routers are rare in Clos or Fat Tree
topologies. Additionally, when there are multiple links, they are topologies. Additionally, when there are multiple links, they are
often aggregated at the link layer using Link Aggregation Groups often aggregated using Link Aggregation Groups
(LAGs) <xref target="IEEE.802.1AX"/> rather than at the IP layer. (LAGs) at the link layer <xref target="IEEE.802.1AX"/> rather than at
the IP layer.
Two more interesting scenarios are described below.</t> Two more interesting scenarios are described below.</t>
<t>In current data center topologies, there is often a very dense <t>In current data center topologies, there is often a very dense
mesh of links between levels, e.g., leaf and spine, providing mesh of links between levels, e.g., leaf and spine, providing
32-way, 64-way, or more Equal-Cost Multi-Path (ECMP) paths. In these 32-way paths, 64-way paths, or more ECMPs. In these
topologies, it is desirable not to have a BGP session on every link topologies, it is desirable not to have a BGP session on every link,
and techniques such as the one described in <xref format="default" and techniques such as the one described in <xref format="default" tar
target="bi-connected"/> can be used to establish sessions on some get="bi-connected"/> can be used to establish sessions on some
subset of northbound links. For example, in a Spine-Leaf topology, subset of northbound links. For example, in a Spine/Leaf topology,
each leaf router would only peer with a subset of the spines each leaf router would only peer with a subset of the spines
dependent on the flooding redundancy required to be reasonably dependent on the flooding redundancy required to be reasonably
certain that every node within the BGP-SPF routing domain has the certain that every node within the BGP-SPF routing domain has the
complete topology.</t> complete topology.</t>
<t>Alternately, controller-based data center topologies are <t>Alternately, controller-based data center topologies are
envisioned where BGP speakers within the data center only establish envisioned where BGP speakers within the data center only establish
BGP sessions with two or more controllers. In these topologies, BGP sessions with two or more controllers. In these topologies,
fabric nodes below the first tier, as shown in Figure 1 of <xref fabric nodes below the first tier, as shown in Figure 1 of <xref forma
format="default" target="RFC7938"/>, will establish BGP multi-hop t="default" target="RFC7938"/>, will establish BGP multi-hop
sessions with the controllers. For the multi-hop sessions, sessions with the controllers. For the multi-hop sessions,
determining the route to the controllers without depending on BGP determining the route to the controllers without depending on BGP
would need to be through some other means beyond the scope of this would need to be through some other means, which is beyond the scope o
document. However, the BGP discovery mechanisms described in <xref f this
format="default" target="bgp-discovery"/> would be one document. However, the BGP discovery mechanisms described in <xref for
mat="default" target="bgp-discovery"/> would be one
possibility.</t> possibility.</t>
</section> </section>
<section anchor="bi-connected">
<section anchor="bi-connected" title="Bi-Connected Graph Heuristic"> <name>Biconnected Graph Heuristic</name>
<t>With this heuristic, discovery of BGP SPF peers is assumed, e.g., <t>With a biconnected graph heuristic, discovery of BGP SPF peers is a
ssumed, e.g.,
as described in <xref format="default" target="bgp-discovery"/>. In as described in <xref format="default" target="bgp-discovery"/>. In
this context, "bi-connected" refers to the fact that there must be this context, "biconnected" refers to the fact that there must be
an adverised link NLRI for both BGP SPF peers associated with the an advertised Link NLRI for both BGP SPF peers associated with the
link before the link can be used in the BGP SPF route calcuation. link before the link can be used in the BGP SPF route calculation.
Additionally, it assumed that the direction of the peering can be Additionally, it is assumed that the direction of the peering can be
ascertained. In the context of a data center fabric, the direction ascertained. In the context of a data center fabric, the direction
is either northbound (toward the spine), southbound (toward the is either northbound (toward the spine), southbound (toward the
Top-Of-Rack (ToR) routers) or east-west (same level in the Top-of-Rack (ToR) routers), or east-west (same level in the
hierarchy). The determination of the direction is beyond the scope hierarchy). The determination of the direction is beyond the scope
of this document. However, it would be reasonable to assume a of this document. However, it would be reasonable to assume a
technique where the ToR routers can be identified and the number of technique where the ToR routers can be identified and the number of
hops to the ToR is used to determine the direction.</t> hops to the ToR is used to determine the direction.</t>
<t>In this heuristic, BGP speakers allow passive session <t>In this heuristic, BGP speakers allow passive session
establishment for southbound BGP sessions. For northbound sessions, establishment for southbound BGP sessions. For northbound sessions,
BGP speakers will attempt to maintain two northbound BGP sessions BGP speakers will attempt to maintain two northbound BGP sessions
with different routers. For east-west sessions, passive BGP session with different routers. For east-west sessions, passive BGP session
establishment is allowed. However, a BGP speaker will never actively establishment is allowed. However, a BGP speaker will never actively
establish an east-west BGP session unless it cannot establish two establish an east-west BGP session unless it cannot establish two
northbound BGP sessions.</t> northbound BGP sessions.</t>
<t>BGP SPF sparse peering deployments not using this heuristic are
<t>BGP SPF sparse peering deployments not using this hueristic are
possible but are not described herein and are considered out of possible but are not described herein and are considered out of
scope.</t> scope.</t>
</section> </section>
</section> </section>
<section anchor="bgp-policy">
<section anchor="bgp-policy" title="BGP Spine/Leaf Topology Policy"> <name>BGP Spine/Leaf Topology Policy</name>
<t>One of the advantages of using BGP-SPF as the underlay protocol is <t>One of the advantages of using BGP-SPF as the underlay protocol is
that BGP policy can be applied at any level. For example, depending on that BGP policy can be applied at any level. For example, depending on
the topology, it may be possible to aggregate or filter prefix the topology, it may be possible to aggregate or filter prefix
advertisements using existing BGP policy. In Spine/Leaf topologies, it advertisements using the existing BGP policy. In Spine/Leaf topologies,
is not necessary to advertise BGP-LS Prefix NLRI received by leaf it
nodes from the spine back to other spine nodes. If a common AS is used is not necessary to advertise a BGP-LS Prefix NLRI received by leaf
nodes from the spine back to other spine nodes. If a common Autonomous S
ystem (AS) is used
for the spine nodes, this can easily be accomplished with EBGP and a for the spine nodes, this can easily be accomplished with EBGP and a
simple policy to filter advertisements from the leaves to the spine if simple policy to filter advertisements from the leaves to the spine if
the first AS in the AS path is the spine AS.</t> the first AS in the AS path is the spine AS.</t>
<t>In the figure below, the leaves would not advertise any NLRIs with
<t>In the figure below, the leaves would not advertise any NLRI with
AS 64512 as the first AS in the AS path.</t> AS 64512 as the first AS in the AS path.</t>
<figure anchor="fig2">
<t> <name>Spine/Leaf Topology Policy</name>
<figure anchor="fig2"> <artwork align="left" alt="" name="" type=""><![CDATA[
<name>Spine/Leaf Topology Policy</name>
<artwork align="left" alt="" name="" type=""><![CDATA[
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+
AS 64512 | | | | | | AS 64512 | | | | | |
for Spine | Spine 1+----+ Spine 2+- ......... -+ Spine N| for Spine | Spine 1+----+ Spine 2+- ......... -+ Spine N|
Nodes at | | | | | | Nodes at | | | | | |
this Level +-+-+-+-++ ++-+-+-+-+ +-+-+-+-++ this Level +-+-+-+-++ ++-+-+-+-+ +-+-+-+-++
+------+ | | | | | | | | | | | +------+ | | | | | | | | | | |
| +-----|-|-|------+ | | | | | | | | +-----|-|-|------+ | | | | | | |
| | +--|-|-|--------+-|-|-----------------+ | | | | | +--|-|-|--------+-|-|-----------------+ | | |
| | | | | | +---+ | | | | | | | | | | | +---+ | | | | |
| | | | | | | +--|-|-------------------+ | | | | | | | | | +--|-|-------------------+ | |
| | | | | | | | | | +------+ +----+ | | | | | | | | | | +------+ +----+
| | | | | | | | | +--------------|----------+ | | | | | | | | | | +--------------|----------+ |
| | | | | | | | +-------------+ | | | | | | | | | | | +-------------+ | | |
| | | | | +----|--|----------------|--|--------+ | | | | | | | +----|--|----------------|--|--------+ | |
| | | | +------|--|--------------+ | | | | | | | | | +------|--|--------------+ | | | | |
| | | +------+ | | | | | | | | | | | +------+ | | | | | | | |
++--+--++ +-+-+--++ ++-+--+-+ ++-+--+-+ ++--+--++ +-+-+--++ ++-+--+-+ ++-+--+-+
| Leaf 1| | Leaf 2| ........ | Leaf X| | Leaf Y| | Leaf 1| | Leaf 2| ........ | Leaf X| | Leaf Y|
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
]]></artwork>
]]></artwork> </figure>
</figure>
</t>
</section> </section>
<section anchor="bgp-discovery-con">
<section anchor="bgp-discovery-con" <name>BGP Peer Discovery Considerations</name>
title="BGP Peer Discovery Considerations"> <t>The basic functionality of peer discovery is to discover the
<t>The basic functionality of peer discovery is to be discover the address of a single-hop peer in the case where the peer address is not
address of a single-hop peer in case where the peer address is not preconfigured. This is being accomplished today by using IPv6 Router
pre-configured. This is being accomplished today by using IPv6 Router Advertisements (RAs) <xref format="default" target="RFC4861"/> and
Advertisements (RA) <xref format="default" target="RFC4861"/> and
assuming that a BGP session is desired with any discovered peer. assuming that a BGP session is desired with any discovered peer.
Beyond the basic functionality, it may be useful to have the following Beyond the basic functionality, it may be useful to have the following
information relating to the BGP session:</t> information relating to the BGP session:</t>
<ul spacing="normal">
<list style="symbols"> <li>
<t>Autonomous System (AS) and BGP Identifier of a potential <t>The AS and BGP Identifier of a potential
peer.</t> peer.</t>
</li>
<t>Security capabilities supported and for cryptographic <li>
authentication, the security capabilities and possibly a key-chain <t>Supported security capabilities, and for cryptographic
<xref format="default" target="RFC8177"/> to be used.</t> authentication, the security capabilities and possibly a key chain
<xref format="default" target="RFC8177"/> for use.</t>
<t>Session Policy Identifier - A group number or name used to </li>
<li>
<t>A Session Policy Identifier, which is a group number or name used
to
associate common session parameters with the peer. For example, in a associate common session parameters with the peer. For example, in a
data center, BGP sessions with a ToR device could have different data center, BGP sessions with a ToR router could have different
parameters than BGP sessions between leaf and spine.</t> parameters than BGP sessions between leaf and spine nodes.</t>
</list> </li>
</ul>
<t>In a data center fabric, it is often useful to know whether a peer <t>In a data center fabric, it is often useful to know whether a peer
is southbound (towards the servers) or northbound (towards the spine is southbound (towards the servers) or northbound (towards the spine
or super-spine), e.g., <xref format="default" target="bi-connected"/>. or super-spine), e.g., see <xref format="default" target="bi-connected"/ >.
One mechanism, without specifying all the details, might be for the One mechanism, without specifying all the details, might be for the
ToR routers to be identified when installed and for the others routers ToR routers to be identified when installed and for the other routers
in the fabric to determine their level based on the distance from the in the fabric to determine their level based on the distance from the
closest ToR router.</t> closest ToR router.</t>
<t>If there are multiple links between BGP speakers or the links <t>If there are multiple links between BGP speakers or the links
between BGP speakers are unnumbered, it is also useful to be able to between BGP speakers are unnumbered, it is also useful to be able to
establish multi-hop sessions using the loopback addresses. This will establish multi-hop sessions using the loopback addresses. This will
often require the discovery protocol to install route(s) toward the often require the discovery protocol to install one or more routes towar d the
potential peer loopback addresses prior to BGP session potential peer loopback addresses prior to BGP session
establishment.</t> establishment.</t>
<t>Finally, a simple BGP discovery protocol may be used to establish a <t>Finally, a simple BGP discovery protocol may be used to establish a
multi-hop session with one or more controllers by advertising multi-hop session with one or more controllers by advertising
connectivity to one or more controllers.</t> connectivity to one or more controllers.</t>
</section> </section>
<section anchor="bgp-discovery">
<section anchor="bgp-discovery" title="BGP Peer Discovery"> <name>BGP Peer Discovery</name>
<section anchor="bgp-ipv6-peering" title="BGP IPv6 Simplified Peering"> <section anchor="bgp-ipv6-peering">
<name>BGP IPv6 Simplified Peering</name>
<t>To conserve IPv4 address space and simplify operations, BGP-SPF <t>To conserve IPv4 address space and simplify operations, BGP-SPF
routers in Clos/Fat Tree deployments can use IPv6 addresses as peer routers in Clos / Fat Tree deployments can use IPv6 addresses as the p eer
address. For IPv4 address families, IPv6 peering as specified in address. For IPv4 address families, IPv6 peering as specified in
<xref format="default" target="RFC8950"/> can be deployed to avoid <xref format="default" target="RFC8950"/> can be deployed to avoid
configuring IPv4 addresses on router interfaces. When this is done, configuring IPv4 addresses on router interfaces. When this is done,
dynamic discovery mechanisms, as described in <xref format="default" dynamic discovery mechanisms, as described in <xref format="default" t
target="bgp-discovery"/>, can be used to learn the global or arget="bgp-discovery"/>, can be used to learn the global or
link-local IPv6 peer addresses and IPv4 addresses need not be link-local IPv6 peer addresses, and IPv4 addresses need not be
configured on these interfaces. If IPv6 link-local peering is used, configured on these interfaces. If IPv6 link-local peering is used,
then configuration of IPv6 global addresses is also not required then configuration of IPv6 global addresses is also not required
<xref target="RFC7404"/> . The Link Local/Remote Identifiers of the <xref target="RFC7404"/>.
peering interfaces MUST be used in the link NLRI as described in
section 5.2.2 of <xref target="I-D.ietf-lsvr-bgp-spf"/>.</t> The Link Local/Remote Identifiers of the
peering interfaces must be used in the Link NLRI as described in
<xref section="5.2.2" sectionFormat="of" target="RFC9815"/>.</t>
</section> </section>
<section anchor="config-checking">
<section anchor="config-checking" <name>BGP-LS-SPF Topology Visibility for Management</name>
title="BGP-LS SPF Topology Visibility for Management">
<t>Irrespective of whether or not BGP-SPF is used for route <t>Irrespective of whether or not BGP-SPF is used for route
calculation, the BGP-LS-SPF route advertisements can be used to calculation, the BGP-LS-SPF route advertisements can be used to
periodically construct the Clos/Fat Tree topology. This is periodically construct the Clos / Fat Tree topology. This is
especially useful in deployments where an Interior Gateway Protocol especially useful in deployments where an Interior Gateway Protocol
(IGP) is not used and the base BGP-LS routes <xref format="default" (IGP) is not used and the base BGP-LS routes <xref format="default" ta
target="RFC9552"/> are not available. The resultant topology rget="RFC9552"/> are not available. The resultant topology
visibility can then be used for troubleshooting and consistency visibility can then be used for troubleshooting and consistency
checking. This would normally be done on a central controller or checking. This would normally be done on a central controller or
other management tool which could also be used for fabric data path other management tool that could also be used for fabric data path
verification. The precise algorithms and heuristics, as well as the verification. The precise algorithms and heuristics, as well as the
complete set of management applications is beyond the scope of this complete set of management applications, is beyond the scope of this
document.</t> document.</t>
</section> </section>
<section anchor="dci">
<section anchor="dci" <name>Data Center Interconnect (DCI) Applicability</name>
title="Data Center Interconnect (DCI) Applicability"> <t>Since BGP-SPF is to be used for the routing underlay and Data Cente
<t>Since BGP-SPF is to be used for the routing underlay and DCI r Interconnect (DCI)
gateway boxes typically have direct or very simple connectivity, BGP gateway boxes typically have direct or very simple connectivity, BGP
external sessions would typically not include the BGP-LS-SPF external sessions would typically not include the BGP-LS-SPF
SAFI.</t> SAFI.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="other-env" <section anchor="other-env">
title="Non-CLOS/FAT Tree Topology Applicability"> <name>Non-Clos / Fat Tree Topology Applicability</name>
<t>The BGP-SPF extensions <xref format="default" <t>The BGP-SPF extensions <xref format="default" target="RFC9815"/> can be
target="I-D.ietf-lsvr-bgp-spf"/> can be used in other topologies and used in other topologies and
avail the inherent convergence improvements. Additionally, sparse avail the inherent convergence improvements. Additionally, sparse
peering techniques may be utilized <xref format="default" peering techniques may be utilized as described in <xref format="default"
target="peering"/>. However, determining whether to establish a BGP target="peering"/>. However, determining whether to establish a BGP
session is more complex and the heuristic described in <xref session is more complex, and the heuristic described in <xref format="defa
format="default" target="bi-connected"/> cannot be used. In such ult" target="bi-connected"/> cannot be used. In such
topologies, other techniques such as those described in <xref topologies, other techniques such as those described in <xref format="defa
format="default" target="RFC9667"/> may be employed. One potential ult" target="RFC9667"/> may be employed. One potential
deployment would be the underlay for a Service Provider (SP) backbone deployment would be the underlay for a Service Provider (SP) backbone
where usage of a single protocol, i.e., BGP, is desired.</t> where usage of a single protocol, i.e., BGP, is desired.</t>
</section> </section>
<section anchor="non-transit-node">
<section anchor="non-transit-node" title="Non-Transit Node Capability"> <name>Non-Transit Node Capability</name>
<t>In certain scenarios, a BGP node wishes to participate in the BGP-SPF <t>In certain scenarios, a BGP node wishes to participate in the BGP-SPF
topology but never be used for transit traffic. These include situations topology but never be used for transit traffic. These include situations
where a server wants to make application services available to clients where a server wants to make application services available to clients
homed at subnets throughout the BGP-SPF domain but does not ever want to homed at subnets throughout the BGP-SPF domain but does not ever want to
be used as a router (i.e., carry transit traffic). Another specific be used as a router (i.e., carry transit traffic). Another specific
instance is where a controller is resident on a server and direct instance is where a controller is resident on a server and direct
connectivity to the controller is required throughout the entire domain. connectivity to the controller is required throughout the entire domain.
This can readily be accomplished using the BGP-LS Node NLRI Attribute This can readily be accomplished using the BGP-LS-SPF Node NLRI Attribute
SPF Status TLV as described in <xref format="default" SPF Status TLV as described in <xref format="default" target="RFC9815"/>.<
target="I-D.ietf-lsvr-bgp-spf"/>.</t> /t>
</section> </section>
<section anchor="policy">
<section anchor="policy" title="BGP Policy Applicability"> <name>BGP Policy Applicability</name>
<t>Existing BGP policy such as prefix filtering may be used in <t>Existing BGP policy such as prefix filtering may be used in
conjunction with the BGP-LS-SPF SAFI. When BGP policy is used with the conjunction with the BGP-LS-SPF SAFI. When BGP policy is used with the
BGP-LS-SPF SAFI, BGP speakers in the BGP-LS-SPF routing domain will not BGP-LS-SPF SAFI, BGP speakers in the BGP-LS-SPF routing domain will not
all have the same set of NLRI and will compute a different BGP local all have the same set of NLRIs and will compute a different BGP local
routing table. Consequently, care must be taken to assure routing is routing table. Consequently, care must be taken to assure that routing is
consistent and blackholes or routing loops do not ensue. However, this consistent and that routes to unreachable destinations or routing loops do
is no different than if traditional BGP routing using the IPv4 and IPv6 not ensue. However, this
is no different than if classical BGP routing using the IPv4 and IPv6
address families were used.</t> address families were used.</t>
</section> </section>
<section anchor="IANA">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>No IANA updates are requested by this document.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="Security">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>This document introduces no new security considerations above and <t>This document introduces no new security considerations above and
beyond those already specified in the <xref format="default" beyond those already specified in <xref format="default" target="RFC4271"/
target="RFC4271"/> and <xref format="default" > and <xref format="default" target="RFC9815"/>.</t>
target="I-D.ietf-lsvr-bgp-spf"/>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Alvaro Retana, Yan Filyurin, Boris
Hassanov, Stig Venaas, Ron Bonica, Mallory Knodel, Dhruv Dhody, Erik
Kline, Eric Vyncke, and John Scudder for their review and comments.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include='reference.I-D.ietf-lsvr-bgp-spf.xml'?> <name>References</name>
</references> <references>
<name>Normative References</name>
<references title="Informative References">
<?rfc include='reference.RFC.2328.xml'?>
<?rfc include='reference.RFC.4271.xml'?>
<?rfc include='reference.RFC.4364.xml'?>
<?rfc include='reference.RFC.4760.xml'?>
<?rfc include='reference.RFC.4861.xml'?>
<?rfc include='reference.RFC.4957.xml'?>
<?rfc include='reference.RFC.5340.xml'?>
<?rfc include='reference.RFC.5580.xml'?>
<?rfc include='reference.RFC.5925.xml'?>
<?rfc include='reference.RFC.7404.xml'?>
<?rfc include='reference.RFC.7938.xml'?>
<?rfc include='reference.RFC.8177.xml'?>
<?rfc include='reference.RFC.8950.xml'?>
<?rfc include='reference.RFC.9552.xml'?> <!--[RFC9815] draft-ietf-lsvr-bgp-spf-51 is RFC-to-be 9815.
Note: will need an update to the title based on author reply -->
<?rfc include='reference.RFC.9667.xml'?> <reference anchor="RFC9815" target="https://www.rfc-editor.org/info/rfc9
815">
<front>
<title>BGP Link State (BGP-LS) Shortest Path First (SPF) Routing</ti
tle>
<author initials="K." surname="Patel" fullname="Keyur Patel">
<organization>Arrcus, Inc.</organization>
</author>
<author initials="A." surname="Lindem" fullname="Acee Lindem">
<organization>LabN Consulting, LLC</organization>
</author>
<author initials="S." surname="Zandi" fullname="Shawn Zandi">
<organization>LinkedIn</organization>
</author>
<author initials="W." surname="Henderickx" fullname="Wim Henderickx"
>
<organization>Nokia</organization>
</author>
<date month="July" year="2025" />
</front>
<seriesInfo name="RFC" value="9815"/>
<seriesInfo name="DOI" value="10.17487/RFC9815"/>
</reference>
</references>
<reference anchor="IEEE.802.1AX" <references>
target="https://standards.ieee.org/standard/802_1AX-2020.html"> <name>Informative References</name>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<title>IEEE Standard for Local and Metropolitan Area Networks: Link 328.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
271.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
760.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
861.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
957.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.58
80.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
925.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
404.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
938.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
177.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
667.xml"/>
<reference anchor="IEEE.802.1AX">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks--Link
Aggregation</title> Aggregation</title>
<author>
<organization>IEEE</organization>
</author>
<date month="May" year="2020"/>
</front>
<seriesInfo name="IEEE Std" value="802.1AX-2020"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9105034"/>
</reference>
<author> <reference anchor="Clos" target="">
<organization>IEEE</organization> <front>
</author> <title>A Study of Non-Blocking Switching Networks</title>
<author initials="C." surname="Clos">
<date year="2020"/> <organization/>
</front> </author>
<date month="March" year="1953"/>
<seriesInfo name="IEEE Std" value="802.1AX-2020"/> </front>
</reference> <refcontent>The Bell System Technical Journal, vol. 32, no. 2, pp. 406
-424</refcontent>
<reference anchor="Clos" target=""> <seriesInfo name="DOI" value="10.1002/j.1538-7305.1953.tb01433.x"/>
<front> </reference>
<title>A Study of Non-Blocking Switching Networks</title> </references>
</references>
<author initials="" surname="">
<organization/>
</author>
<date month="March" year="1953"/> <section anchor="Acknowledgements" numbered="false">
</front> <name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Alvaro Retana"/>,
<contact fullname="Yan Filyurin"/>, <contact fullname="Boris
Hassanov"/>, <contact fullname="Stig Venaas"/>, <contact fullname="Ron
Bonica"/>, <contact fullname="Mallory Knodel"/>, <contact
fullname="Dhruv Dhody"/>, <contact fullname="Erik Kline"/>, <contact
fullname="Éric Vyncke"/>, and <contact fullname="John Scudder"/> for
their reviews and comments.</t>
</section>
<seriesInfo name=""
value="The Bell System Technical Journal, Vol. 32(2), DOI 10
.1002/j.1538-7305.1953.tb01433.x"/>
</reference>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 118 change blocks. 
357 lines changed or deleted 336 lines changed or added

This html diff was produced by rfcdiff 1.48.