< draft-ietf-lsvr-bgp-spf-13.txt   draft-ietf-lsvr-bgp-spf-14.txt >
Network Working Group K. Patel Network Working Group K. Patel
Internet-Draft Arrcus, Inc. Internet-Draft Arrcus, Inc.
Intended status: Standards Track A. Lindem Intended status: Standards Track A. Lindem
Expires: August 26, 2021 Cisco Systems Expires: December 31, 2021 Cisco Systems
S. Zandi S. Zandi
LinkedIn LinkedIn
W. Henderickx W. Henderickx
Nokia Nokia
February 22, 2021 June 29, 2021
BGP Link-State Shortest Path First (SPF) Routing BGP Link-State Shortest Path First (SPF) Routing
draft-ietf-lsvr-bgp-spf-13 draft-ietf-lsvr-bgp-spf-14
Abstract Abstract
Many Massively Scaled Data Centers (MSDCs) have converged on Many Massively Scaled Data Centers (MSDCs) have converged on
simplified layer 3 routing. Furthermore, requirements for simplified layer 3 routing. Furthermore, requirements for
operational simplicity have led many of these MSDCs to converge on operational simplicity have led many of these MSDCs to converge on
BGP as their single routing protocol for both their fabric routing BGP as their single routing protocol for both their fabric routing
and their Data Center Interconnect (DCI) routing. This document and their Data Center Interconnect (DCI) routing. This document
describes extensions to BGP to use BGP Link-State distribution and describes extensions to BGP to use BGP Link-State distribution and
the Shortest Path First (SPF) algorithm used by Internal Gateway the Shortest Path First (SPF) algorithm used by Internal Gateway
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 26, 2021. This Internet-Draft will expire on December 31, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. BGP Shortest Path First (SPF) Motivation . . . . . . . . 4 1.2. BGP Shortest Path First (SPF) Motivation . . . . . . . . 4
1.3. Document Overview . . . . . . . . . . . . . . . . . . . . 6 1.3. Document Overview . . . . . . . . . . . . . . . . . . . . 6
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. Base BGP Protocol Relationship . . . . . . . . . . . . . . . 6 2. Base BGP Protocol Relationship . . . . . . . . . . . . . . . 6
3. BGP Link-State (BGP-LS) Relationship . . . . . . . . . . . . 7 3. BGP Link-State (BGP-LS) Relationship . . . . . . . . . . . . 7
4. BGP Peering Models . . . . . . . . . . . . . . . . . . . . . 8 4. BGP Peering Models . . . . . . . . . . . . . . . . . . . . . 8
4.1. BGP Single-Hop Peering on Network Node Connections . . . 8 4.1. BGP Single-Hop Peering on Network Node Connections . . . 8
4.2. BGP Peering Between Directly-Connected Nodes . . . . . . 8 4.2. BGP Peering Between Directly-Connected Nodes . . . . . . 8
4.3. BGP Peering in Route-Reflector or Controller Topology . . 9 4.3. BGP Peering in Route-Reflector or Controller Topology . . 8
5. BGP Shortest Path Routing (SPF) Protocol Extensions . . . . . 9 5. BGP Shortest Path Routing (SPF) Protocol Extensions . . . . . 9
5.1. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . . 9 5.1. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . . 9
5.1.1. BGP-LS-SPF NLRI TLVs . . . . . . . . . . . . . . . . 9 5.1.1. BGP-LS-SPF NLRI TLVs . . . . . . . . . . . . . . . . 9
5.1.2. BGP-LS Attribute . . . . . . . . . . . . . . . . . . 10 5.1.2. BGP-LS Attribute . . . . . . . . . . . . . . . . . . 10
5.2. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . 11 5.2. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . 11
5.2.1. Node NLRI Usage . . . . . . . . . . . . . . . . . . . 11 5.2.1. Node NLRI Usage . . . . . . . . . . . . . . . . . . . 11
5.2.1.1. Node NLRI Attribute SPF Capability TLV . . . . . 11 5.2.1.1. BGP-LS-SPF Node NLRI Attribute SPF Capability TLV 11
5.2.1.2. BGP-LS-SPF Node NLRI Attribute SPF Status TLV . . 12 5.2.1.2. BGP-LS-SPF Node NLRI Attribute SPF Status TLV . . 12
5.2.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . 13 5.2.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . 13
5.2.2.1. BGP-LS-SPF Link NLRI Attribute Prefix-Length TLVs 14 5.2.2.1. BGP-LS-SPF Link NLRI Attribute Prefix-Length TLVs 14
5.2.2.2. BGP-LS-SPF Link NLRI Attribute SPF Status TLV . . 14 5.2.2.2. BGP-LS-SPF Link NLRI Attribute SPF Status TLV . . 14
5.2.3. IPv4/IPv6 Prefix NLRI Usage . . . . . . . . . . . . . 15 5.2.3. IPv4/IPv6 Prefix NLRI Usage . . . . . . . . . . . . . 15
5.2.3.1. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV . 16 5.2.3.1. BGP-LS-SPF Prefix NLRI Attribute SPF Status TLV . 16
5.2.4. BGP-LS Attribute Sequence-Number TLV . . . . . . . . 16 5.2.4. BGP-LS Attribute Sequence-Number TLV . . . . . . . . 16
5.3. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 17 5.3. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 17
6. Decision Process with SPF Algorithm . . . . . . . . . . . . . 18 6. Decision Process with SPF Algorithm . . . . . . . . . . . . . 18
6.1. BGP NLRI Selection . . . . . . . . . . . . . . . . . . . 19 6.1. BGP NLRI Selection . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 5, line 5 skipping to change at page 5, line 5
Given that [RFC7938] already describes how BGP could be used as the Given that [RFC7938] already describes how BGP could be used as the
sole routing protocol in an MSDC, one might question the motivation sole routing protocol in an MSDC, one might question the motivation
for defining an alternate BGP deployment model when a mature solution for defining an alternate BGP deployment model when a mature solution
exists. For both alternatives, BGP offers the operational benefits exists. For both alternatives, BGP offers the operational benefits
of a single routing protocol as opposed to the combination of an IGP of a single routing protocol as opposed to the combination of an IGP
for the underlay and BGP as an overlay. However, BGP SPF offers some for the underlay and BGP as an overlay. However, BGP SPF offers some
unique advantages above and beyond standard BGP distance-vector unique advantages above and beyond standard BGP distance-vector
routing. With BGP SPF, the standard hop-by-hop peering model is routing. With BGP SPF, the standard hop-by-hop peering model is
relaxed. relaxed.
A primary advantage is that all BGP-LS-SPF speakers in the BGP SPF A primary advantage is that all BGP SPF speakers in the BGP SPF
routing domain will have a complete view of the topology. This will routing domain will have a complete view of the topology. This will
allow support for ECMP, IP fast-reroute (e.g., Loop-Free allow support for ECMP, IP fast-reroute (e.g., Loop-Free
Alternatives), Shared Risk Link Groups (SRLGs), and other routing Alternatives), Shared Risk Link Groups (SRLGs), and other routing
enhancements without advertisement of additional BGP paths [RFC7911] enhancements without advertisement of additional BGP paths [RFC7911]
or other extensions. In short, the advantages of an IGP such as OSPF or other extensions. In short, the advantages of an IGP such as OSPF
[RFC2328] are availed in BGP. [RFC2328] are availed in BGP.
With the simplified BGP decision process as defined in Section 6, With the simplified BGP decision process as defined in Section 6,
NLRI changes can be disseminated throughout the BGP routing domain NLRI changes can be disseminated throughout the BGP routing domain
much more rapidly (equivalent to IGPs with the proper much more rapidly (equivalent to IGPs with the proper
implementation). The added advantage of BGP using TCP for reliable implementation). The added advantage of BGP using TCP for reliable
transport leverages TCP's inherent flow-control and guaranteed in- transport leverages TCP's inherent flow-control and guaranteed in-
order delivery. order delivery.
Another primary advantage is a potential reduction in NLRI Another primary advantage is a potential reduction in NLRI
advertisement. With standard BGP distance-vector routing, a single advertisement. With standard BGP distance-vector routing, a single
link failure may impact 100s or 1000s prefixes and result in the link failure may impact 100s or 1000s prefixes and result in the
withdrawal or re-advertisement of the attendant NLRI. With BGP SPF, withdrawal or re-advertisement of the attendant NLRI. With BGP SPF,
only the BGP speakers corresponding to the link NLRI need to withdraw only the BGP SPF speakers corresponding to the link NLRI need to
the corresponding BGP-LS-SPF Link NLRI. Additionally, the changed withdraw the corresponding BGP-LS-SPF Link NLRI. Additionally, the
NLRI will be advertised immediately as opposed to normal BGP where it changed NLRI will be advertised immediately as opposed to normal BGP
is only advertised after the best route selection. These advantages where it is only advertised after the best route selection. These
will afford NLRI dissemination throughout the BGP SPF routing domain advantages will afford NLRI dissemination throughout the BGP SPF
with efficiencies similar to link-state protocols. routing domain with efficiencies similar to link-state protocols.
With controller and route-reflector peering models, BGP SPF With controller and route-reflector peering models, BGP SPF
advertisement and distributed computation require a minimal number of advertisement and distributed computation require a minimal number of
sessions and copies of the NLRI since only the latest version of the sessions and copies of the NLRI since only the latest version of the
NLRI from the originator is required. Given that verification of the NLRI from the originator is required. Given that verification of the
adjacencies is done outside of BGP (see Section 4), each BGP speaker adjacencies is done outside of BGP (see Section 4), each BGP SPF
will only need as many sessions and copies of the NLRI as required speaker will only need as many sessions and copies of the NLRI as
for redundancy (see Section 4). Additionally, a controller could required for redundancy (see Section 4). Additionally, a controller
inject topology that is learned outside the BGP SPF routing domain. could inject topology that is learned outside the BGP SPF routing
domain.
Given that controllers are already consuming BGP-LS NLRI [RFC7752], Given that controllers are already consuming BGP-LS NLRI [RFC7752],
this functionality can be reused for BGP-LS-SPF NLRI. this functionality can be reused for BGP-LS-SPF NLRI.
Another potential advantage of BGP SPF is that both IPv6 and IPv4 can Another advantage of BGP SPF is that both IPv6 and IPv4 can be
both be supported using the BGP-LS-SPF SAFI with the same BGP-LS-SPF supported using the BGP-LS-SPF SAFI with the same BGP-LS-SPF NLRIs.
NLRIs. In many MSDC fabrics, the IPv4 and IPv6 topologies are In many MSDC fabrics, the IPv4 and IPv6 topologies are congruent,
congruent, refer to Section 5.2.2 and Section 5.2.3. Although beyond refer to Section 5.2.2 and Section 5.2.3. Although beyond the scope
the scope of this document, multi-topology extensions could be used of this document, multi-topology extensions could be used to support
to support separate IPv4, IPv6, unicast, and multicast topologies separate IPv4, IPv6, unicast, and multicast topologies while sharing
while sharing the same NLRI. the same NLRI.
Finally, the BGP SPF topology can be used as an underlay for other Finally, the BGP SPF topology can be used as an underlay for other
BGP SAFIs (using the existing model) and realize all the above BGP SAFIs (using the existing model) and realize all the above
advantages. advantages.
1.3. Document Overview 1.3. Document Overview
The document begins with sections defining the precise relationship The document begins with sections defining the precise relationship
that BGP SPF has with both the base BGP protocol [RFC4271] that BGP SPF has with both the base BGP protocol [RFC4271]
(Section 2) and the BGP Link-State (BGP-LS) extensions [RFC7752] (Section 2) and the BGP Link-State (BGP-LS) extensions [RFC7752]
skipping to change at page 7, line 38 skipping to change at page 7, line 38
[RFC7752] describes a mechanism by which link-state and TE [RFC7752] describes a mechanism by which link-state and TE
information can be collected from networks and shared with external information can be collected from networks and shared with external
entities using BGP. This is achieved by defining NLRI advertised entities using BGP. This is achieved by defining NLRI advertised
using the BGP-LS AFI. The BGP-LS extensions defined in [RFC7752] using the BGP-LS AFI. The BGP-LS extensions defined in [RFC7752]
make use of the decision process defined in [RFC4271]. This document make use of the decision process defined in [RFC4271]. This document
reuses NLRI and TLVs defined in [RFC7752]. Rather than reusing the reuses NLRI and TLVs defined in [RFC7752]. Rather than reusing the
BGP-LS SAFI, the BGP-LS-SPF SAFI Section 5.1 is introduced to insure BGP-LS SAFI, the BGP-LS-SPF SAFI Section 5.1 is introduced to insure
backward compatibility for the BGP-LS SAFI usage. backward compatibility for the BGP-LS SAFI usage.
The BGP SPF extensions reuse the Node, Link, and Prefix NLRI defined The BGP SPF extensions reuse the Node, Link, and Prefix NLRI defined
in [RFC7752]. The usage of the BGP-LS NLRI, metric attributes, and in [RFC7752]. The usage of the BGP-LS NLRI, attributes, and
attribute extensions is described in Section 5.2.1. The usage of attribute extensions is described in Section 5.2. The usage of
others BGP-LS attributes is not precluded and is, in fact, expected. others BGP-LS attributes is not precluded and is, in fact, expected.
However, the details are beyond the scope of this document and will However, the details are beyond the scope of this document and will
be specified in future documents. be specified in future documents.
Support for Multiple Topology Routing (MTR) similar to the OSPF MTR Support for Multiple Topology Routing (MTR) similar to the OSPF MTR
computation described in [RFC4915] is beyond the scope of this computation described in [RFC4915] is beyond the scope of this
document. Consequently, the usage of the Multi-Topology TLV as document. Consequently, the usage of the Multi-Topology TLV as
described in section 3.2.1.5 of [RFC7752] is not specified. described in section 3.2.1.5 of [RFC7752] is not specified.
The rules for setting the NLRI next-hop path attribute for the BGP- The rules for setting the NLRI next-hop path attribute for the BGP-
LS-SPF SAFI will follow the BGP-LS SAFI as specified in section 3.4 LS-SPF SAFI will follow the BGP-LS SAFI as specified in section 3.4
of [RFC7752]. of [RFC7752].
4. BGP Peering Models 4. BGP Peering Models
Depending on the topology, scaling, capabilities of the BGP-LS-SPF Depending on the topology, scaling, capabilities of the BGP SPF
speakers, and redundancy requirements, various peering models are speakers, and redundancy requirements, various peering models are
supported. The only requirements are that all BGP SPF speakers in supported. The only requirements are that all BGP SPF speakers in
the BGP SPF routing domain exchange BGP-LS-SPF NLRI, run an SPF the BGP SPF routing domain exchange BGP-LS-SPF NLRI, run an SPF
calculation, and update their routing table appropriately. calculation, and update their routing table appropriately.
4.1. BGP Single-Hop Peering on Network Node Connections 4.1. BGP Single-Hop Peering on Network Node Connections
The simplest peering model is the one where EBGP single-hop sessions The simplest peering model is the one where EBGP single-hop sessions
are established over direct point-to-point links interconnecting the are established over direct point-to-point links interconnecting the
nodes in the BGP SPF routing domain. Once the single-hop BGP session nodes in the BGP SPF routing domain. Once the single-hop BGP session
skipping to change at page 8, line 29 skipping to change at page 8, line 29
exchanged [RFC4760] for the corresponding session, then the link is exchanged [RFC4760] for the corresponding session, then the link is
considered up from a BGP SPF perspective and the corresponding BGP- considered up from a BGP SPF perspective and the corresponding BGP-
LS-SPF Link NLRI is advertised. If the session goes down, the LS-SPF Link NLRI is advertised. If the session goes down, the
corresponding Link NLRI will be withdrawn. Topologically, this would corresponding Link NLRI will be withdrawn. Topologically, this would
be equivalent to the peering model in [RFC7938] where there is a BGP be equivalent to the peering model in [RFC7938] where there is a BGP
session on every link in the data center switch fabric. The content session on every link in the data center switch fabric. The content
of the Link NLRI is described in Section 5.2.2. of the Link NLRI is described in Section 5.2.2.
4.2. BGP Peering Between Directly-Connected Nodes 4.2. BGP Peering Between Directly-Connected Nodes
In this model, BGP-LS-SPF speakers peer with all directly-connected In this model, BGP SPF speakers peer with all directly-connected
nodes but the sessions may be between loopback addresses (i.e., two- nodes but the sessions may be between loopback addresses (i.e., two-
hop sessions) and the direct connection discovery and liveliness hop sessions) and the direct connection discovery and liveliness
detection for the interconnecting links are independent of the BGP detection for the interconnecting links are independent of the BGP
protocol. the scope of this document. For example, liveliness protocol. For example, liveliness detection could be done using the
detection could be done using the BFD protocol [RFC5880]. Precisely BFD protocol [RFC5880]. Precisely how discovery and liveliness
how discovery and liveliness detection is accomplished is outside the detection is accomplished is outside the scope of this document.
scope of this document. Consequently, there will be a single BGP Consequently, there will be a single BGP session even if there are
session even if there are multiple direct connections between BGP-LS- multiple direct connections between BGP SPF speakers. BGP-LS-SPF
SPF speakers. BGP-LS-SPF Link NLRI is advertised as long as a BGP Link NLRI is advertised as long as a BGP session has been
session has been established, the BGP-LS-SPF AFI/SAFI capability has established, the BGP-LS-SPF AFI/SAFI capability has been exchanged
been exchanged [RFC4760], and the link is operational as determined [RFC4760], and the link is operational as determined using liveliness
using liveliness detection mechanisms outside the scope of this detection mechanisms outside the scope of this document. This is
document. This is much like the previous peering model only peering much like the previous peering model only peering is between loopback
is between loopback addresses and the interconnecting links can be addresses and the interconnecting links can be unnumbered. However,
unnumbered. However, since there are BGP sessions between every since there are BGP sessions between every directly-connected node in
directly-connected node in the BGP SPF routing domain, there is only the BGP SPF routing domain, there is only a reduction in BGP sessions
a reduction in BGP sessions when there are parallel links between when there are parallel links between nodes.
nodes.
4.3. BGP Peering in Route-Reflector or Controller Topology 4.3. BGP Peering in Route-Reflector or Controller Topology
In this model, BGP-LS-SPF speakers peer solely with one or more Route In this model, BGP SPF speakers peer solely with one or more Route
Reflectors [RFC4456] or controllers. As in the previous model, Reflectors [RFC4456] or controllers. As in the previous model,
direct connection discovery and liveliness detection for those links direct connection discovery and liveliness detection for those links
in the BGP SPF routing domain are done outside of the BGP protocol. in the BGP SPF routing domain are done outside of the BGP protocol.
BGP-LS-SPF Link NLRI is advertised as long as the corresponding link BGP-LS-SPF Link NLRI is advertised as long as the corresponding link
is considered up as per the chosen liveness detection mechanism. is considered up as per the chosen liveness detection mechanism.
This peering model, known as sparse peering, allows for fewer BGP This peering model, known as sparse peering, allows for fewer BGP
sessions and, consequently, fewer instances of the same NLRI received sessions and, consequently, fewer instances of the same NLRI received
from multiple peers. Normally, the route-reflectors or controller from multiple peers. Normally, the route-reflectors or controller
BGP sessions would be on directly-connected links to avoid dependence BGP sessions would be on directly-connected links to avoid dependence
skipping to change at page 9, line 32 skipping to change at page 9, line 26
[I-D.ietf-lsvr-applicability]. [I-D.ietf-lsvr-applicability].
5. BGP Shortest Path Routing (SPF) Protocol Extensions 5. BGP Shortest Path Routing (SPF) Protocol Extensions
5.1. BGP-LS Shortest Path Routing (SPF) SAFI 5.1. BGP-LS Shortest Path Routing (SPF) SAFI
In order to replace the existing BGP decision process with an SPF- In order to replace the existing BGP decision process with an SPF-
based decision process in a backward compatible manner by not based decision process in a backward compatible manner by not
impacting the BGP-LS SAFI, this document introduces the BGP-LS-SPF impacting the BGP-LS SAFI, this document introduces the BGP-LS-SPF
SAFI. The BGP-LS-SPF (AFI 16388 / SAFI 80) [RFC4760] is allocated by SAFI. The BGP-LS-SPF (AFI 16388 / SAFI 80) [RFC4760] is allocated by
IANA as specified in the Section 8. In order for two BGP-LS-SPF IANA as specified in the Section 8. In order for two BGP SPF
speakers to exchange BGP SPF NLRI, they MUST exchange the speakers to exchange BGP SPF NLRI, they MUST exchange the
Multiprotocol Extensions Capability [RFC5492] [RFC4760] to ensure Multiprotocol Extensions Capability [RFC5492] [RFC4760] to ensure
that they are both capable of properly processing such NLRI. This is that they are both capable of properly processing such NLRI. This is
done with AFI 16388 / SAFI 80 for BGP-LS-SPF advertised within the done with AFI 16388 / SAFI 80 for BGP-LS-SPF advertised within the
BGP SPF Routing Domain. The BGP-LS-SPF SAFI is used to carry IPv4 BGP SPF Routing Domain. The BGP-LS-SPF SAFI is used to carry IPv4
and IPv6 prefix information in a format facilitating an SPF-based and IPv6 prefix information in a format facilitating an SPF-based
decision process. decision process.
5.1.1. BGP-LS-SPF NLRI TLVs 5.1.1. BGP-LS-SPF NLRI TLVs
skipping to change at page 10, line 13 skipping to change at page 10, line 9
REQUIRED that these TLVs are ordered in ascending order by the TLV REQUIRED that these TLVs are ordered in ascending order by the TLV
value field. Comparison of the value fields is performed by treating value field. Comparison of the value fields is performed by treating
the entire value field as a hexadecimal string. NLRIs having TLVs the entire value field as a hexadecimal string. NLRIs having TLVs
which do not follow the ordering rules MUST be considered as which do not follow the ordering rules MUST be considered as
malformed and discarded with appropriate error logging. malformed and discarded with appropriate error logging.
[RFC7752] defines certain NLRI TLVs as a mandatory TLVs. These TLVs [RFC7752] defines certain NLRI TLVs as a mandatory TLVs. These TLVs
are considered mandatory for the BGP-LS-SPF SAFI as well. All the are considered mandatory for the BGP-LS-SPF SAFI as well. All the
other TLVs are considered as an optional TLVs. other TLVs are considered as an optional TLVs.
Given that there is a single BGP-LS Attribute for all the BGP-LS-SPF
NLRI in a BGP Update, Section 3.3, [RFC7752], a BGP Update will
normally contain a single BGP-LS-SPF NLRI since advertising multiple
NLRI would imply identical attributes.
5.1.2. BGP-LS Attribute 5.1.2. BGP-LS Attribute
The BGP-LS attribute of the BGP-LS-SPF SAFI uses exactly same format The BGP-LS attribute of the BGP-LS-SPF SAFI uses exactly same format
of the BGP-LS AFI [RFC7752]. In other words, all the TLVs used in of the BGP-LS AFI [RFC7752]. In other words, all the TLVs used in
BGP-LS attribute of the BGP-LS AFI are applicable and used for the BGP-LS attribute of the BGP-LS AFI are applicable and used for the
BGP-LS attribute of the BGP-LS-SPF SAFI. This attribute is an BGP-LS attribute of the BGP-LS-SPF SAFI. This attribute is an
optional, non-transitive BGP attribute that is used to carry link, optional, non-transitive BGP attribute that is used to carry link,
node, and prefix properties and attributes. The BGP-LS attribute is node, and prefix properties and attributes. The BGP-LS attribute is
a set of TLVs. a set of TLVs.
The BGP-LS attribute may potentially grow large in size depending on The BGP-LS attribute may potentially grow large in size depending on
the amount of link-state information associated with a single Link- the amount of link-state information associated with a single Link-
State NLRI. The BGP specification [RFC4271] mandates a maximum BGP State NLRI. The BGP specification [RFC4271] mandates a maximum BGP
message size of 4096 octets. It is RECOMMENDED that an message size of 4096 octets. It is RECOMMENDED that an
implementation support [RFC8654] in order to accommodate larger size implementation support [RFC8654] in order to accommodate larger size
of information within the BGP-LS Attribute. BGP-LS-SPF speakers MUST of information within the BGP-LS Attribute. BGP SPF speakers MUST
ensure that they limit the TLVs included in the BGP-LS Attribute to ensure that they limit the TLVs included in the BGP-LS Attribute to
ensure that a BGP update message for a single Link-State NLRI does ensure that a BGP update message for a single Link-State NLRI does
not cross the maximum limit for a BGP message. The determination of not cross the maximum limit for a BGP message. The determination of
the types of TLVs to be included by the BGP-LS-SPF speaker the types of TLVs to be included by the BGP SPF speaker originating
originating the attribute is outside the scope of this document. the attribute is outside the scope of this document. When a BGP SPF
When a BGP-LS-SPF speaker finds that it is exceeding the maximum BGP speaker finds that it is exceeding the maximum BGP message size due
message size due to addition or update of some other BGP Attribute to addition or update of some other BGP Attribute (e.g., AS_PATH), it
(e.g., AS_PATH), it MUST consider the BGP-LS Attribute to be MUST consider the BGP-LS Attribute to be malformed and the attribute
malformed and the attribute discard handling of [RFC7606] applies. discard handling of [RFC7606] applies.
In order to compare the BGP-LS attribute efficiently, it is REQUIRED In order to compare the BGP-LS attribute efficiently, it is REQUIRED
that all the TLVs within the given attribute must be ordered in that all the TLVs within the given attribute must be ordered in
ascending order by the TLV type. For multiple TLVs of same type ascending order by the TLV type. For multiple TLVs of same type
within a single attribute, it is REQUIRED that these TLVs are ordered within a single attribute, it is REQUIRED that these TLVs are ordered
in ascending order by the TLV value field. Comparison of the value in ascending order by the TLV value field. Comparison of the value
fields is performed by treating the entire value field as a fields is performed by treating the entire value field as a
hexadecimal string. Attributes having TLVs which do not follow the hexadecimal string. Attributes having TLVs which do not follow the
ordering rules MUST NOT be considered as malformed. ordering rules MUST NOT be considered as malformed.
All TLVs within the BGP-LS Attribute are considered optional unless All TLVs within the BGP-LS Attribute are considered optional unless
specified otherwise. specified otherwise.
5.2. Extensions to BGP-LS 5.2. Extensions to BGP-LS
[RFC7752] describes a mechanism by which link-state and TE [RFC7752] describes a mechanism by which link-state and TE
information can be collected from IGPs and shared with external information can be collected from IGPs and shared with external
components using the BGP protocol. It describes both the definition components using the BGP protocol. It describes both the definition
of the BGP-LS-SPF NLRI that advertise links, nodes, and prefixes of the BGP-LS NLRI that advertise links, nodes, and prefixes
comprising IGP link-state information and the definition of a BGP comprising IGP link-state information and the definition of a BGP
path attribute (BGP-LS attribute) that carries link, node, and prefix path attribute (BGP-LS attribute) that carries link, node, and prefix
properties and attributes, such as the link and prefix metric or properties and attributes, such as the link and prefix metric or
auxiliary Router-IDs of nodes, etc. This document extends the usage auxiliary Router-IDs of nodes, etc. This document extends the usage
of BGP-LS NLRI for the purpose of BGP SPF calculation via of BGP-LS NLRI for the purpose of BGP SPF calculation via
advertisement in the BGP-LS-SPF SAFI. advertisement in the BGP-LS-SPF SAFI.
The protocol identifier specified in the Protocol-ID field [RFC7752] The protocol identifier specified in the Protocol-ID field [RFC7752]
will represent the origin of the advertised NLRI. For Node NLRI and will represent the origin of the advertised NLRI. For Node NLRI and
Link NLRI, this MUST be the direct protocol (4). Node or Link NLRI Link NLRI, this MUST be the direct protocol (4). Node or Link NLRI
skipping to change at page 11, line 34 skipping to change at page 11, line 34
include the BGP Identifier (TLV 516) and the AS Number (TLV 512) include the BGP Identifier (TLV 516) and the AS Number (TLV 512)
[RFC7752]. The BGP Confederation Member (TLV 517) [RFC7752] is not [RFC7752]. The BGP Confederation Member (TLV 517) [RFC7752] is not
appliable and SHOULD not be included. If TLV 517 is included, it appliable and SHOULD not be included. If TLV 517 is included, it
will be ignored. will be ignored.
5.2.1. Node NLRI Usage 5.2.1. Node NLRI Usage
The Node NLRI MUST be advertised unconditionally by all routers in The Node NLRI MUST be advertised unconditionally by all routers in
the BGP SPF routing domain. the BGP SPF routing domain.
5.2.1.1. Node NLRI Attribute SPF Capability TLV 5.2.1.1. BGP-LS-SPF Node NLRI Attribute SPF Capability TLV
The SPF capability is an additional Node Attribute TLV. This The SPF capability is an additional Node Attribute TLV. This
attribute TLV MUST be included with the BGP-LS-SPF SAFI and SHOULD attribute TLV MUST be included with the BGP-LS-SPF SAFI and SHOULD
NOT be used for other SAFIs. The TLV type 1180 will be assigned by NOT be used for other SAFIs. The TLV type 1180 will be assigned by
IANA. The Node Attribute TLV will contain a single-octet SPF IANA. The Node Attribute TLV will contain a single-octet SPF
algorithm as defined in [RFC8665]. algorithm as defined in [RFC8665].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 43 skipping to change at page 12, line 43
| SPF Status | | SPF Status |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
BGP Status Values: 0 - Reserved BGP Status Values: 0 - Reserved
1 - Node Unreachable with respect to BGP SPF 1 - Node Unreachable with respect to BGP SPF
2 - Node does not support transit with respect 2 - Node does not support transit with respect
to BGP SPF to BGP SPF
3-254 - Undefined 3-254 - Undefined
255 - Reserved 255 - Reserved
If the SPF Status TLV is received and the corresponding Node NLRI has The BGP-LS-SPF Node Attribute SPF Status TLV, Link Attribute SPF
not been received, then the SPF Status TLV is ignored and not used in Status TLV, and Prefix Attribute SPF Status TLV use the same TLV Type
SPF computation but is still announced to other BGP speakers. An (1184). This implies that a BGP Update cannot contain multiple NLRI
implementation MAY log an error for further analysis. If a BGP with differing status. If the BGP-LS-SPF Status TLV is advertised
speaker received the Node NLRI but the SPF Status TLV is not and the advertised value is not defined for all NLRI included in the
received, then any previously received information is considered as BGP update, then the SPF Status TLV is ignored and not used in SPF
implicitly withdrawn and the update is propagated to other BGP computation but is still announced to other BGP SPF speakers. An
speakers. A BGP speaker receiving a BGP Update containing a SPF implementation MAY log an error for further analysis.
If a BGP SPF speaker received the Node NLRI but the SPF Status TLV is
not received, then any previously received information is considered
as implicitly withdrawn and the update is propagated to other BGP SPF
speakers. A BGP SPF speaker receiving a BGP Update containing a SPF
Status TLV in the BGP-LS attribute [RFC7752] with a value that is Status TLV in the BGP-LS attribute [RFC7752] with a value that is
outside the range of defined values SHOULD be processed and announced outside the range of defined values SHOULD be processed and announced
to other BGP speakers. However, a BGP speaker MUST not use the to other BGP SPF speakers. However, a BGP SPF speaker MUST NOT use
Status TLV in its SPF computation. An implementation MAY log this the Status TLV in its SPF computation. An implementation MAY log
condition for further analysis. this condition for further analysis.
5.2.2. Link NLRI Usage 5.2.2. Link NLRI Usage
The criteria for advertisement of Link NLRI are discussed in The criteria for advertisement of Link NLRI are discussed in
Section 4. Section 4.
Link NLRI is advertised with unique local and remote node descriptors Link NLRI is advertised with unique local and remote node descriptors
dependent on the IP addressing. For IPv4 links, the link's local dependent on the IP addressing. For IPv4 links, the link's local
IPv4 (TLV 259) and remote IPv4 (TLV 260) addresses will be used. For IPv4 (TLV 259) and remote IPv4 (TLV 260) addresses will be used. For
IPv6 links, the local IPv6 (TLV 261) and remote IPv6 (TLV 262) IPv6 links, the local IPv6 (TLV 261) and remote IPv6 (TLV 262)
skipping to change at page 13, line 32 skipping to change at page 13, line 37
the same Link NLRI. The link identifiers are described in table 5 of the same Link NLRI. The link identifiers are described in table 5 of
[RFC7752]. [RFC7752].
For a link to be used in Shortest Path Tree (SPT) for a given address For a link to be used in Shortest Path Tree (SPT) for a given address
family, i.e., IPv4 or IPv6, both routers connecting the link MUST family, i.e., IPv4 or IPv6, both routers connecting the link MUST
have an address in the same subnet for that address family. However, have an address in the same subnet for that address family. However,
an IPv4 or IPv6 prefix associated with the link MAY be installed an IPv4 or IPv6 prefix associated with the link MAY be installed
without the corresponding address on the other side of link. without the corresponding address on the other side of link.
The link IGP metric attribute TLV (TLV 1095) MUST be advertised. If The link IGP metric attribute TLV (TLV 1095) MUST be advertised. If
a BGP speaker receives a Link NLRI without an IGP metric attribute a BGP SPF speaker receives a Link NLRI without an IGP metric
TLV, then it SHOULD consider the received NLRI as a malformed and the attribute TLV, then it SHOULD consider the received NLRI as a
receiving BGP speaker MUST handle such malformed NLRI as 'Treat-as- malformed and the receiving BGP SPF speaker MUST handle such
withdraw' [RFC7606]. The BGP SPF metric length is 4 octets. Like malformed NLRI as 'Treat-as-withdraw' [RFC7606]. The BGP SPF metric
OSPF [RFC2328], a cost is associated with the output side of each length is 4 octets. Like OSPF [RFC2328], a cost is associated with
router interface. This cost is configurable by the system the output side of each router interface. This cost is configurable
administrator. The lower the cost, the more likely the interface is by the system administrator. The lower the cost, the more likely the
to be used to forward data traffic. One possible default for metric interface is to be used to forward data traffic. One possible
would be to give each interface a cost of 1 making it effectively a default for metric would be to give each interface a cost of 1 making
hop count. Algorithms such as setting the metric inversely to the it effectively a hop count. Algorithms such as setting the metric
link speed as supported in the OSPF MIB [RFC4750] MAY be supported. inversely to the link speed as supported in the OSPF MIB [RFC4750]
However, this is beyond the scope of this document. Refer to MAY be supported. However, this is beyond the scope of this
Section 10.1.1 for operational guidance. document. Refer to Section 10.1.1 for operational guidance.
The usage of other link attribute TLVs is beyond the scope of this The usage of other link attribute TLVs is beyond the scope of this
document. document.
5.2.2.1. BGP-LS-SPF Link NLRI Attribute Prefix-Length TLVs 5.2.2.1. BGP-LS-SPF Link NLRI Attribute Prefix-Length TLVs
Two BGP-LS Attribute TLVs of the BGP-LS-SPF Link NLRI are defined to Two BGP-LS Attribute TLVs of the BGP-LS-SPF Link NLRI are defined to
advertise the prefix length associated with the IPv4 and IPv6 link advertise the prefix length associated with the IPv4 and IPv6 link
prefixes derived from the link descriptor addresses. The prefix prefixes derived from the link descriptor addresses. The prefix
length is used for the optional installation of prefixes length is used for the optional installation of prefixes
skipping to change at page 15, line 21 skipping to change at page 15, line 21
| Type (1184) | Length (1 Octet) | | Type (1184) | Length (1 Octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPF Status | | SPF Status |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
BGP Status Values: 0 - Reserved BGP Status Values: 0 - Reserved
1 - Link Unreachable with respect to BGP SPF 1 - Link Unreachable with respect to BGP SPF
2-254 - Undefined 2-254 - Undefined
255 - Reserved 255 - Reserved
If the SPF Status TLV is received and the corresponding Link NLRI has The BGP-LS-SPF Node Attribute SPF Status TLV, Link Attribute SPF
not been received, then the SPF Status TLV is ignored and not used in Status TLV, and Prefix Attribute SPF Status TLV use the same TLV Type
SPF computation but is still announced to other BGP speakers. An (1184). This implies that a BGP Update cannot contain multiple NLRI
implementation MAY log an error for further analysis. If a BGP with differing status. If the BGP-LS-SPF Status TLV is advertised
speaker received the Link NLRI but the SPF Status TLV is not and the advertised value is not defined for all NLRI included in the
received, then any previously received information is considered as BGP update, then the SPF Status TLV is ignored and not used in SPF
implicitly withdrawn and the update is propagated to other BGP computation but is still announced to other BGP SPF speakers. An
speakers. A BGP speaker receiving a BGP Update containing an SPF implementation MAY log an error for further analysis.
If a BGP SPF speaker received the Link NLRI but the SPF Status TLV is
not received, then any previously received information is considered
as implicitly withdrawn and the update is propagated to other BGP SPF
speakers. A BGP SPF speaker receiving a BGP Update containing an SPF
Status TLV in the BGP-LS attribute [RFC7752] with a value that is Status TLV in the BGP-LS attribute [RFC7752] with a value that is
outside the range of defined values SHOULD be processed and announced outside the range of defined values SHOULD be processed and announced
to other BGP speakers. However, a BGP speaker MUST not use the to other BGP SPF speakers. However, a BGP SPF speaker MUST NOT use
Status TLV in its SPF computation. An implementation MAY log this the Status TLV in its SPF computation. An implementation MAY log
information for further analysis. this information for further analysis.
5.2.3. IPv4/IPv6 Prefix NLRI Usage 5.2.3. IPv4/IPv6 Prefix NLRI Usage
IPv4/IPv6 Prefix NLRI is advertised with a Local Node Descriptor and IPv4/IPv6 Prefix NLRI is advertised with a Local Node Descriptor and
the prefix and length. The Prefix Descriptors field includes the IP the prefix and length. The Prefix Descriptors field includes the IP
Reachability Information TLV (TLV 265) as described in [RFC7752]. Reachability Information TLV (TLV 265) as described in [RFC7752].
The Prefix Metric attribute TLV (TLV 1155) MUST be advertised. The The Prefix Metric attribute TLV (TLV 1155) MUST be advertised. The
IGP Route Tag TLV (TLV 1153) MAY be advertised. The usage of other IGP Route Tag TLV (TLV 1153) MAY be advertised. The usage of other
attribute TLVs is beyond the scope of this document. For loopback attribute TLVs is beyond the scope of this document. For loopback
prefixes, the metric should be 0. For non-loopback prefixes, the prefixes, the metric should be 0. For non-loopback prefixes, the
skipping to change at page 16, line 28 skipping to change at page 16, line 28
| Type (1184) | Length (1 Octet) | | Type (1184) | Length (1 Octet) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPF Status | | SPF Status |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
BGP Status Values: 0 - Reserved BGP Status Values: 0 - Reserved
1 - Prefix Unreachable with respect to SPF 1 - Prefix Unreachable with respect to SPF
2-254 - Undefined 2-254 - Undefined
255 - Reserved 255 - Reserved
If the SPF Status TLV is received and the corresponding Prefix NLRI The BGP-LS-SPF Node Attribute SPF Status TLV, Link Attribute SPF
has not been received, then the SPF Status TLV is ignored and not Status TLV, and Prefix Attribute SPF Status TLV use the same TLV Type
used in SPF computation but is still announced to other BGP speakers. (1184). This implies that a BGP Update cannot contain multiple NLRI
An implementation MAY log an error for further analysis. If a BGP with differing status. If the BGP-LS-SPF Status TLV is advertised
speaker received the Prefix NLRI but the SPF Status TLV is not and the advertised value is not defined for all NLRI included in the
received, then any previously received information is considered as BGP update, then the SPF Status TLV is ignored and not used in SPF
implicitly withdrawn and the update is propagated to other BGP computation but is still announced to other BGP SPF speakers. An
speakers. A BGP speaker receiving a BGP Update containing an SPF implementation MAY log an error for further analysis.
Status TLV in the BGP-LS attribute [RFC7752] with a value that is
outside the range of defined values SHOULD be processed and announced If a BGP SPF speaker received the Prefix NLRI but the SPF Status TLV
to other BGP speakers. However, a BGP speaker MUST not use the is not received, then any previously received information is
Status TLV in its SPF computation. An implementation MAY log this considered as implicitly withdrawn and the update is propagated to
information for further analysis. other BGP SPF speakers. A BGP SPF speaker receiving a BGP Update
containing an SPF Status TLV in the BGP-LS attribute [RFC7752] with a
value that is outside the range of defined values SHOULD be processed
and announced to other BGP SPF speakers. However, a BGP SPF speaker
MUST NOT use the Status TLV in its SPF computation. An
implementation MAY log this information for further analysis.
5.2.4. BGP-LS Attribute Sequence-Number TLV 5.2.4. BGP-LS Attribute Sequence-Number TLV
A BGP-LS Attribute TLV of the BGP-LS-SPF NLRI types is defined to A BGP-LS Attribute TLV of the BGP-LS-SPF NLRI types is defined to
assure the most recent version of a given NLRI is used in the SPF assure the most recent version of a given NLRI is used in the SPF
computation. The Sequence-Number TLV is mandatory for BGP-LS-SPF computation. The Sequence-Number TLV is mandatory for BGP-LS-SPF
NLRI. The TLV type 1181 has been assigned by IANA. The BGP-LS NLRI. The TLV type 1181 has been assigned by IANA. The BGP-LS
Attribute TLV will contain an 8-octet sequence number. The usage of Attribute TLV will contain an 8-octet sequence number. The usage of
the Sequence Number TLV is described in Section 6.1. the Sequence Number TLV is described in Section 6.1.
skipping to change at page 17, line 18 skipping to change at page 17, line 20
| Type (1181) | Length (8 Octets) | | Type (1181) | Length (8 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (High-Order 32 Bits) | | Sequence Number (High-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Low-Order 32 Bits) | | Sequence Number (Low-Order 32 Bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number Sequence Number
The 64-bit strictly-increasing sequence number MUST be incremented The 64-bit strictly-increasing sequence number MUST be incremented
for every self-originated version of BGP-LS-SPF NLRI. BGP speakers for every self-originated version of BGP-LS-SPF NLRI. BGP SPF
implementing this specification MUST use available mechanisms to speakers implementing this specification MUST use available
preserve the sequence number's strictly increasing property for the mechanisms to preserve the sequence number's strictly increasing
deployed life of the BGP speaker (including cold restarts). One property for the deployed life of the BGP SPF speaker (including cold
mechanism for accomplishing this would be to use the high-order 32 restarts). One mechanism for accomplishing this would be to use the
bits of the sequence number as a wrap/boot count that is incremented high-order 32 bits of the sequence number as a wrap/boot count that
any time the BGP router loses its sequence number state or the low- is incremented any time the BGP router loses its sequence number
order 32 bits wrap. state or the low-order 32 bits wrap.
When incrementing the sequence number for each self-originated NLRI, When incrementing the sequence number for each self-originated NLRI,
the sequence number should be treated as an unsigned 64-bit value. the sequence number should be treated as an unsigned 64-bit value.
If the lower-order 32-bit value wraps, the higher-order 32-bit value If the lower-order 32-bit value wraps, the higher-order 32-bit value
should be incremented and saved in non-volatile storage. If a BGP- should be incremented and saved in non-volatile storage. If a BGP
LS-SPF speaker completely loses its sequence number state (e.g., the SPF speaker completely loses its sequence number state (e.g., the BGP
BGP speaker hardware is replaced or experiences a cold-start), the SPF speaker hardware is replaced or experiences a cold-start), the
BGP NLRI selection rules (see Section 6.1) will insure convergence, BGP NLRI selection rules (see Section 6.1) will insure convergence,
albeit not immediately. albeit not immediately.
The Sequence-Number TLV is mandatory for BGP-LS-SPF NLRI. If the The Sequence-Number TLV is mandatory for BGP-LS-SPF NLRI. If the
Sequence-Number TLV is not received then the corresponding Link NLRI Sequence-Number TLV is not received then the corresponding Link NLRI
is considered as malformed and MUST be handled as 'Treat-as- is considered as malformed and MUST be handled as 'Treat-as-
withdraw'. An implementation MAY log an error for further analysis. withdraw'. An implementation MAY log an error for further analysis.
5.3. NEXT_HOP Manipulation 5.3. NEXT_HOP Manipulation
All BGP peers that support SPF extensions would locally compute the All BGP peers that support SPF extensions would locally compute the
Loc-RIB Next-Hop as a result of the SPF process. Consequently, the LOC-RIB Next-Hop as a result of the SPF process. Consequently, the
Next-Hop is always ignored on receipt. The Next-Hop address MUST be Next-Hop is always ignored on receipt. The Next-Hop address MUST be
encoded as described in [RFC4760]. BGP speakers MUST interpret the encoded as described in [RFC4760]. BGP SPF speakers MUST interpret
Next-Hop address of MP_REACH_NLRI attribute as an IPv4 address the Next-Hop address of MP_REACH_NLRI attribute as an IPv4 address
whenever the length of the Next-Hop address is 4 octets, and as a whenever the length of the Next-Hop address is 4 octets, and as a
IPv6 address whenever the length of the Next-Hop address is 16 IPv6 address whenever the length of the Next-Hop address is 16
octets. octets.
[RFC4760] modifies the rules of NEXT_HOP attribute whenever the [RFC4760] modifies the rules of NEXT_HOP attribute whenever the
multiprotocol extensions for BGP-4 are enabled. BGP speakers MUST multiprotocol extensions for BGP-4 are enabled. BGP SPF speakers
set the NEXT_HOP attribute according to the rules specified in MUST set the NEXT_HOP attribute according to the rules specified in
[RFC4760] as the BGP-LS-SPF routing information is carried within the [RFC4760] as the BGP-LS-SPF routing information is carried within the
multiprotocol extensions for BGP-4. multiprotocol extensions for BGP-4.
6. Decision Process with SPF Algorithm 6. Decision Process with SPF Algorithm
The Decision Process described in [RFC4271] takes place in three The Decision Process described in [RFC4271] takes place in three
distinct phases. The Phase 1 decision function of the Decision distinct phases. The Phase 1 decision function of the Decision
Process is responsible for calculating the degree of preference for Process is responsible for calculating the degree of preference for
each route received from a BGP speaker's peer. The Phase 2 decision each route received from a BGP SPF speaker's peer. The Phase 2
function is invoked on completion of the Phase 1 decision function decision function is invoked on completion of the Phase 1 decision
and is responsible for choosing the best route out of all those function and is responsible for choosing the best route out of all
available for each distinct destination, and for installing each those available for each distinct destination, and for installing
chosen route into the Loc-RIB. The combination of the Phase 1 and 2 each chosen route into the LOC-RIB. The combination of the Phase 1
decision functions is characterized as a Path Vector algorithm. and 2 decision functions is characterized as a Path Vector algorithm.
The SPF based Decision process replaces the BGP Decision process The SPF based Decision process replaces the BGP Decision process
described in [RFC4271]. This process starts with selecting only described in [RFC4271]. This process starts with selecting only
those Node NLRI whose SPF capability TLV matches with the local BGP- those Node NLRI whose SPF capability TLV matches with the local BGP
LS-SPF speaker's SPF capability TLV value. Since Link-State NLRI SPF speaker's SPF capability TLV value. Since Link-State NLRI always
always contains the local node descriptor Section 5.2.1, each NLRI is contains the local node descriptor Section 5.2, each NLRI is uniquely
uniquely originated by a single BGP-LS-SPF speaker in the BGP SPF originated by a single BGP SPF speaker in the BGP SPF routing domain
routing domain (the BGP node matching the NLRI's Node Descriptors). (the BGP node matching the NLRI's Node Descriptors). Instances of
Instances of the same NLRI originated by multiple BGP speakers would the same NLRI originated by multiple BGP SPF speakers would be
be indicative of a configuration error or a masquerading attack indicative of a configuration error or a masquerading attack
(Section 9). These selected Node NLRI and their Link/Prefix NLRI are (Section 9). These selected Node NLRI and their Link/Prefix NLRI are
used to build a directed graph during the SPF computation as used to build a directed graph during the SPF computation as
described below. The best routes for BGP prefixes are installed in described below. The best routes for BGP prefixes are installed in
the RIB as a result of the SPF process. the RIB as a result of the SPF process.
When BGP-LS-SPF NLRI is received, all that is required is to When BGP-LS-SPF NLRI is received, all that is required is to
determine whether it is the most recent by examining the Node-ID and determine whether it is the most recent by examining the Node-ID and
sequence number as described in Section 6.1. If the received NLRI sequence number as described in Section 6.1. If the received NLRI
has changed, it will be advertised to other BGP-LS-SPF peers. If the has changed, it will be advertised to other BGP-LS-SPF peers. If the
attributes have changed (other than the sequence number), a BGP SPF attributes have changed (other than the sequence number), a BGP SPF
calculation will be triggered. However, a changed NLRI MAY be calculation will be triggered. However, a changed NLRI MAY be
advertised immediately to other peers and prior to any SPF advertised immediately to other peers and prior to any SPF
calculation. Note that the BGP MinRouteAdvertisementIntervalTimer calculation. Note that the BGP MinRouteAdvertisementIntervalTimer
and MinASOriginationIntervalTimer [RFC4271] timers are not applicable and MinASOriginationIntervalTimer [RFC4271] timers are not applicable
to the BGP-LS-SPF SAFI. The scheduling of the SPF calculation, as to the BGP-LS-SPF SAFI. The scheduling of the SPF calculation, as
described in Section 6.3, is an implementation issue. Scheduling MAY described in Section 6.3, is an implementation issue. Scheduling MAY
be dampened consistent with the SPF back-off algorithm specified in be dampened consistent with the SPF back-off algorithm specified in
[RFC8405]. [RFC8405].
The Phase 3 decision function of the Decision Process [RFC4271] is The Phase 3 decision function of the Decision Process [RFC4271] is
also simplified since under normal SPF operation, a BGP speaker MUST also simplified since under normal SPF operation, a BGP SPF speaker
advertise the changed NLRIs to all BGP peers with the BGP-LS-SPF AFI/ MUST advertise the changed NLRIs to all BGP peers with the BGP-LS-SPF
SAFI and install the changed routes in the Global RIB. The only AFI/SAFI and install the changed routes in the Global RIB. The only
exception are unchanged NLRIs or stale NLRIs, i.e., NLRI received exception are unchanged NLRIs or stale NLRIs, i.e., NLRI received
with a less recent (numerically smaller) sequence number. with a less recent (numerically smaller) sequence number.
6.1. BGP NLRI Selection 6.1. BGP NLRI Selection
The rules for all BGP-LS-SPF NLRIs selection for phase 1 of the BGP The rules for all BGP-LS-SPF NLRIs selection for phase 1 of the BGP
decision process, section 9.1.1 [RFC4271], no longer apply. decision process, section 9.1.1 [RFC4271], no longer apply.
1. Routes originated by directly connected BGP SPF peers are 1. Routes originated by directly connected BGP SPF peers are
preferred. This condition can be determined by comparing the BGP preferred. This condition can be determined by comparing the BGP
skipping to change at page 19, line 28 skipping to change at page 19, line 31
if a BGP-LS router loses its sequence number state due to a cold- if a BGP-LS router loses its sequence number state due to a cold-
start. start.
2. The NLRI with the most recent Sequence Number TLV, i.e., highest 2. The NLRI with the most recent Sequence Number TLV, i.e., highest
sequence number is selected. sequence number is selected.
3. The route received from the BGP SPF speaker with the numerically 3. The route received from the BGP SPF speaker with the numerically
larger BGP Identifier is preferred. larger BGP Identifier is preferred.
When a BGP SPF speaker completely loses its sequence number state, When a BGP SPF speaker completely loses its sequence number state,
i.e., due to a cold start, or in the unlikely possibility that that i.e., due to a cold start, or in the unlikely possibility that 64-bit
64-bit sequence number wraps, the BGP routing domain will still sequence number wraps, the BGP routing domain will still converge.
converge. This is due to the fact that BGP speakers adjacent to the This is due to the fact that BGP SPF speakers adjacent to the router
router will always accept self-originated NLRI from the associated will always accept self-originated NLRI from the associated speaker
speaker as more recent (rule # 1). When a BGP speaker reestablishes as more recent (rule # 1). When a BGP SPF speaker reestablishes a
a connection with its peers, any existing session will be taken down connection with its peers, any existing session will be taken down
and stale NLRI will be replaced. The adjacent BGP speaker will and stale NLRI will be replaced. The adjacent BGP SPF speaker will
update their NLRI advertisements, hop by hop, until the BGP routing update their NLRI advertisements, hop by hop, until the BGP routing
domain has converged. domain has converged.
The modified SPF Decision Process performs an SPF calculation rooted The modified SPF Decision Process performs an SPF calculation rooted
at the BGP speaker using the metrics from the Link Attribute IGP at the BGP SPF speaker using the metrics from the Link Attribute IGP
Metric TLV (1095) and the Prefix Attribute Prefix Metric TLV (1155) Metric TLV (1095) and the Prefix Attribute Prefix Metric TLV (1155)
[RFC7752]. As a result, any other BGP attributes that would [RFC7752]. As a result, any other BGP attributes that would
influence the BGP decision process defined in [RFC4271] including influence the BGP decision process defined in [RFC4271] including
ORIGIN, MULTI_EXIT_DISC, and LOCAL_PREF attributes are ignored by the ORIGIN, MULTI_EXIT_DISC, and LOCAL_PREF attributes are ignored by the
SPF algorithm. The NEXT_HOP attribute is discussed in Section 5.3. SPF algorithm. The NEXT_HOP attribute is discussed in Section 5.3.
The AS_PATH and AS4_PATH [RFC6793] attributes are preserved and used The AS_PATH and AS4_PATH [RFC6793] attributes are preserved and used
for loop detection [RFC4271]. They are ignored during the SPF for loop detection [RFC4271]. They are ignored during the SPF
computation for BGP-LS-SPF NRLIs. computation for BGP-LS-SPF NRLIs.
6.1.1. BGP Self-Originated NLRI 6.1.1. BGP Self-Originated NLRI
Node, Link, or Prefix NLRI with Node Descriptors matching the local Node, Link, or Prefix NLRI with Node Descriptors matching the local
BGP speaker are considered self-originated. When self-originated BGP SPF speaker are considered self-originated. When self-originated
NLRI is received and it doesn't match the local node's NLRI content NLRI is received and it doesn't match the local node's NLRI content
(including sequence number), special processing is required. (including sequence number), special processing is required.
o If a self-originated NLRI is received and the sequence number is o If a self-originated NLRI is received and the sequence number is
more recent (i.e., greater than the local node's sequence number more recent (i.e., greater than the local node's sequence number
for the NLRI), the NLRI sequence number will be advanced to one for the NLRI), the NLRI sequence number will be advanced to one
greater than the received sequence number and the NLRI will be greater than the received sequence number and the NLRI will be
readvertised to all peers. readvertised to all peers.
o If self-originated NLRI is received and the sequence number is the o If self-originated NLRI is received and the sequence number is the
skipping to change at page 20, line 35 skipping to change at page 20, line 35
Prefix NLRI is no longer being advertised by the local node, the Prefix NLRI is no longer being advertised by the local node, the
NLRI will be withdrawn. NLRI will be withdrawn.
The above actions are performed immediately when the first instance The above actions are performed immediately when the first instance
of a newer self-originated NLRI is received. In this case, the newer of a newer self-originated NLRI is received. In this case, the newer
instance is considered to be a stale instance that was advertised by instance is considered to be a stale instance that was advertised by
the local node prior to a restart where the NLRI state is lost. the local node prior to a restart where the NLRI state is lost.
However, if subsequent newer self-originated NLRI is received for the However, if subsequent newer self-originated NLRI is received for the
same Node, Link, or Prefix NLRI, the readvertisement or withdrawal is same Node, Link, or Prefix NLRI, the readvertisement or withdrawal is
delayed by 5 seconds since it is likely being advertised by a delayed by 5 seconds since it is likely being advertised by a
misconfigured or rogue BGP-LS-SPF speaker Section 9. misconfigured or rogue BGP SPF speaker Section 9.
6.2. Dual Stack Support 6.2. Dual Stack Support
The SPF-based decision process operates on Node, Link, and Prefix The SPF-based decision process operates on Node, Link, and Prefix
NLRIs that support both IPv4 and IPv6 addresses. Whether to run a NLRIs that support both IPv4 and IPv6 addresses. Whether to run a
single SPF computation or multiple SPF computations for separate AFs single SPF computation or multiple SPF computations for separate AFs
is an implementation matter. Normally, IPv4 next-hops are calculated is an implementation matter. Normally, IPv4 next-hops are calculated
for IPv4 prefixes and IPv6 next-hops are calculated for IPv6 for IPv4 prefixes and IPv6 next-hops are calculated for IPv6
prefixes. prefixes.
skipping to change at page 22, line 28 skipping to change at page 22, line 28
Attribute Prefix Metric TLV (1155) added to the cost to reach the Attribute Prefix Metric TLV (1155) added to the cost to reach the
Current-Node. The following will be done for each Prefix NLRI Current-Node. The following will be done for each Prefix NLRI
(referred to as the Current-Prefix): (referred to as the Current-Prefix):
* If the BGP-LS Prefix attribute includes an SPF Status TLV * If the BGP-LS Prefix attribute includes an SPF Status TLV
indicating the prefix is unreachable, the Current-Prefix is indicating the prefix is unreachable, the Current-Prefix is
considered unreachable and the next Prefix NLRI is examined in considered unreachable and the next Prefix NLRI is examined in
Step 4. Step 4.
* If the Current-Prefix's corresponding prefix is in the LOC-RIB * If the Current-Prefix's corresponding prefix is in the LOC-RIB
and the cost is less than the Current-Prefix's metric, the and the LOC-RIB cost is less than the Current-Prefix's metric,
Current-Prefix does not contribute to the route and the next the Current-Prefix does not contribute to the route and the
Prefix NLRI is examined in Step 4. next Prefix NLRI is examined in Step 4.
* If the Current-Prefix's corresponding prefix is not in the * If the Current-Prefix's corresponding prefix is not in the
LOC-RIB, the prefix is installed with the Current-Node's next- LOC-RIB, the prefix is installed with the Current-Node's next-
hops installed as the LOC-RIB route's next-hops and the metric hops installed as the LOC-RIB route's next-hops and the metric
being updated. If the IGP Route Tag TLV (1153) is included in being updated. If the IGP Route Tag TLV (1153) is included in
the Current-Prefix's NLRI Attribute, the tag(s) are installed the Current-Prefix's NLRI Attribute, the tag(s) are installed
in the current LOC-RIB route's tag(s). in the current LOC-RIB route's tag(s).
* If the Current-Prefix's corresponding prefix is in the LOC-RIB * If the Current-Prefix's corresponding prefix is in the LOC-RIB
and the cost is less than the current route's metric, the and the cost is less than the current route's metric, the
skipping to change at page 26, line 46 skipping to change at page 26, line 46
value for the NLRIImplicitWithdrawalDelay timer is 2 seconds. value for the NLRIImplicitWithdrawalDelay timer is 2 seconds.
7. Error Handling 7. Error Handling
This section describes the Error Handling actions, as described in This section describes the Error Handling actions, as described in
[RFC7606], that are specific to SAFI BGP-LS-SPF BGP Update message [RFC7606], that are specific to SAFI BGP-LS-SPF BGP Update message
processing. processing.
7.1. Processing of BGP-LS-SPF TLVs 7.1. Processing of BGP-LS-SPF TLVs
When a BGP speaker receives a BGP Update containing a malformed Node When a BGP SPF speaker receives a BGP Update containing a malformed
NLRI SPF Status TLV in the BGP-LS Attribute [RFC7752], it MUST ignore Node NLRI SPF Status TLV in the BGP-LS Attribute [RFC7752], it MUST
the received TLV and MUST NOT pass it to other BGP peers as specified ignore the received TLV and MUST NOT pass it to other BGP peers as
in [RFC7606]. When discarding an associated Node NLRI with a specified in [RFC7606]. When discarding an associated Node NLRI with
malformed TLV, a BGP speaker SHOULD log an error for further a malformed TLV, a BGP SPF speaker SHOULD log an error for further
analysis. analysis.
When a BGP speaker receives a BGP Update containing a malformed Link When a BGP SPF speaker receives a BGP Update containing a malformed
NLRI SPF Status TLV in the BGP-LS Attribute [RFC7752], it MUST ignore Link NLRI SPF Status TLV in the BGP-LS Attribute [RFC7752], it MUST
the received TLV and MUST NOT pass it to other BGP peers as specified ignore the received TLV and MUST NOT pass it to other BGP peers as
in [RFC7606]. When discarding an associated Link NLRI with a specified in [RFC7606]. When discarding an associated Link NLRI with
malformed TLV, a BGP speaker SHOULD log an error for further a malformed TLV, a BGP SPF speaker SHOULD log an error for further
analysis. analysis.
When a BGP speaker receives a BGP Update containing a malformed When a BGP SPF speaker receives a BGP Update containing a malformed
Prefix NLRI SPF Status TLV in the BGP-LS Attribute [RFC7752], it MUST Prefix NLRI SPF Status TLV in the BGP-LS Attribute [RFC7752], it MUST
ignore the received TLV and MUST NOT pass it to other BGP peers as ignore the received TLV and MUST NOT pass it to other BGP peers as
specified in [RFC7606]. When discarding an associated Prefix NLRI specified in [RFC7606]. When discarding an associated Prefix NLRI
with a malformed TLV, a BGP speaker SHOULD log an error for further with a malformed TLV, a BGP SPF speaker SHOULD log an error for
analysis.
When a BGP speaker receives a BGP Update containing a malformed SPF
Capability TLV in the Node NLRI BGP-LS Attribute [RFC7752], it MUST
ignore the received TLV and the Node NLRI and MUST NOT pass it to
other BGP peers as specified in [RFC7606]. When discarding a Node
NLRI with a malformed TLV, a BGP speaker SHOULD log an error for
further analysis. further analysis.
When a BGP speaker receives a BGP Update containing a malformed IPv4 When a BGP SPF speaker receives a BGP Update containing a malformed
Prefix-Length TLV in the Link NLRI BGP-LS Attribute [RFC7752], it SPF Capability TLV in the Node NLRI BGP-LS Attribute [RFC7752], it
MUST ignore the received TLV and the Node NLRI and MUST NOT pass it MUST ignore the received TLV and the Node NLRI and MUST NOT pass it
to other BGP peers as specified in [RFC7606]. The corresponding Link to other BGP peers as specified in [RFC7606]. When discarding a Node
NLRI is considered as malformed and MUST be handled as 'Treat-as- NLRI with a malformed TLV, a BGP SPF speaker SHOULD log an error for
withdraw'. An implementation MAY log an error for further analysis. further analysis.
When a BGP speaker receives a BGP Update containing a malformed IPv6 When a BGP SPF speaker receives a BGP Update containing a malformed
Prefix-Length TLV in the Link NLRI BGP-LS Attribute [RFC7752], it IPv4 Prefix-Length TLV in the Link NLRI BGP-LS Attribute [RFC7752],
MUST ignore the received TLV and the Node NLRI and MUST NOT pass it it MUST ignore the received TLV and the Node NLRI and MUST NOT pass
to other BGP peers as specified in [RFC7606]. The corresponding Link it to other BGP peers as specified in [RFC7606]. The corresponding
NLRI is considered as malformed and MUST be handled as 'Treat-as- Link NLRI is considered as malformed and MUST be handled as 'Treat-
withdraw'. An implementation MAY log an error for further analysis. as-withdraw'. An implementation MAY log an error for further
analysis.
When a BGP SPF speaker receives a BGP Update containing a malformed
IPv6 Prefix-Length TLV in the Link NLRI BGP-LS Attribute [RFC7752],
it MUST ignore the received TLV and the Node NLRI and MUST NOT pass
it to other BGP peers as specified in [RFC7606]. The corresponding
Link NLRI is considered as malformed and MUST be handled as 'Treat-
as-withdraw'. An implementation MAY log an error for further
analysis.
7.2. Processing of BGP-LS-SPF NLRIs 7.2. Processing of BGP-LS-SPF NLRIs
A Link-State NLRI MUST NOT be considered as malformed or invalid A Link-State NLRI MUST NOT be considered as malformed or invalid
based on the inclusion/exclusion of TLVs or contents of the TLV based on the inclusion/exclusion of TLVs or contents of the TLV
fields (i.e., semantic errors), as described in Section 5.1 and fields (i.e., semantic errors), as described in Section 5.1 and
Section 5.1.1. Section 5.1.1.
A BGP-LS-SPF Speaker MUST perform the following syntactic validation A BGP-LS-SPF Speaker MUST perform the following syntactic validation
of the BGP-LS-SPF NLRI to determine if it is malformed. of the BGP-LS-SPF NLRI to determine if it is malformed.
skipping to change at page 29, line 15 skipping to change at page 29, line 18
Attribute Length are correct but some TLV/sub-TLV length within the Attribute Length are correct but some TLV/sub-TLV length within the
BGP-LS Attribute is invalid), then it MUST handle such malformed BGP- BGP-LS Attribute is invalid), then it MUST handle such malformed BGP-
LS Attribute as 'Attribute Discard'. In other cases, when the error LS Attribute as 'Attribute Discard'. In other cases, when the error
in the BGP-LS Attribute encoding results in the inability to process in the BGP-LS Attribute encoding results in the inability to process
the BGP update message, then the handling is the same as described the BGP update message, then the handling is the same as described
above for malformed NLRI. above for malformed NLRI.
Note that the 'Attribute Discard' action results in the loss of all Note that the 'Attribute Discard' action results in the loss of all
TLVs in the BGP-LS Attribute and not the removal of a specific TLVs in the BGP-LS Attribute and not the removal of a specific
malformed TLV. The removal of specific malformed TLVs may give a malformed TLV. The removal of specific malformed TLVs may give a
wrong indication to a BGP-LS-SPF speaker that the specific wrong indication to a BGP SPF speaker that the specific information
information is being deleted or is not available. is being deleted or is not available.
When a BGP-LS-SPF speaker receives an update message with Link-State When a BGP SPF speaker receives an update message with Link-State
NLRI(s) in the MP_REACH_NLRI but without the BGP-LS-SPF Attribute, it NLRI(s) in the MP_REACH_NLRI but without the BGP-LS-SPF Attribute, it
is most likely an indication that a BGP-LS-SPF speaker preceding it is most likely an indication that a BGP SPF speaker preceding it has
has performed the 'Attribute Discard' fault handling. An performed the 'Attribute Discard' fault handling. An implementation
implementation SHOULD preserve and propagate the Link-State NLRIs in SHOULD preserve and propagate the Link-State NLRIs in such an update
such an update message so that the BGP-LS-SPF speaker can detect the message so that the BGP SPF speaker can detect the loss of link-state
loss of link-state information for that object and not assume its information for that object and not assume its deletion/withdrawal.
deletion/withdrawal. This also makes it possible for a network This also makes it possible for a network operator to trace back to
operator to trace back to the BGP-LS-SPF speaker which actually the BGP SPF speaker which actually detected a problem with the BGP-LS
detected a problem with the BGP-LS Attribute. Attribute.
An implementation SHOULD log an error for further analysis for An implementation SHOULD log an error for further analysis for
problems detected during syntax validation. problems detected during syntax validation.
When a BGP speaker receives a BGP Update containing a malformed IGP When a BGP SPF speaker receives a BGP Update containing a malformed
metric TLV in the Link NLRI BGP-LS Attribute [RFC7752], it MUST IGP metric TLV in the Link NLRI BGP-LS Attribute [RFC7752], it MUST
ignore the received TLV and the Link NLRI and MUST NOT pass it to ignore the received TLV and the Link NLRI and MUST NOT pass it to
other BGP peers as specified in [RFC7606]. When discarding a Link other BGP peers as specified in [RFC7606]. When discarding a Link
NLRI with a malformed TLV, a BGP speaker SHOULD log an error for NLRI with a malformed TLV, a BGP SPF speaker SHOULD log an error for
further analysis. further analysis.
8. IANA Considerations 8. IANA Considerations
This document defines the use of SAFI (80) for BGP SPF operation This document defines the use of SAFI (80) for BGP SPF operation
Section 5.1, and requests IANA to assign the value from the First Section 5.1, and requests IANA to assign the value from the First
Come First Serve (FCFS) range in the Subsequent Address Family Come First Serve (FCFS) range in the Subsequent Address Family
Identifiers (SAFI) Parameters registry. Identifiers (SAFI) Parameters registry.
This document also defines five attribute TLVs of BGP-LS-SPF NLRI. This document also defines five attribute TLVs of BGP-LS-SPF NLRI.
skipping to change at page 32, line 36 skipping to change at page 32, line 38
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
The BGP-LS-SPF implementation status is documented in The BGP-LS-SPF implementation status is documented in
[I-D.psarkar-lsvr-bgp-spf-impl]. [I-D.psarkar-lsvr-bgp-spf-impl].
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Sue Hares, Jorge Rabadan, Boris The authors would like to thank Sue Hares, Jorge Rabadan, Boris
Hassanov, Dan Frost, Matt Anderson, Fred Baker, and Lukas Krattiger Hassanov, Dan Frost, Matt Anderson, Fred Baker, Lukas Krattiger,
for their review and comments. Thanks to Pushpasis Sarkar for Yingzhen Qu for their review and comments. Thanks to Pushpasis
discussions on preventing a BGP SPF Router from being used for non- Sarkar for discussions on preventing a BGP SPF Router from being used
local traffic (i.e., transit traffic). for non-local traffic (i.e., transit traffic).
The authors extend special thanks to Eric Rosen for fruitful The authors extend special thanks to Eric Rosen for fruitful
discussions on BGP-LS-SPF convergence as compared to IGPs. discussions on BGP-LS-SPF convergence as compared to IGPs.
13. Contributors 13. Contributors
In addition to the authors listed on the front page, the following In addition to the authors listed on the front page, the following
co-authors have contributed to the document. co-authors have contributed to the document.
Derek Yeung Derek Yeung
 End of changes. 53 change blocks. 
195 lines changed or deleted 217 lines changed or added

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