< draft-ietf-lsvr-bgp-spf-06.txt   draft-ietf-lsvr-bgp-spf-07.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: April 2, 2020 Cisco Systems Expires: June 12, 2020 Cisco Systems
S. Zandi S. Zandi
Linkedin LinkedIn
W. Henderickx W. Henderickx
Nokia Nokia
September 30, 2019 December 10, 2019
Shortest Path Routing Extensions for BGP Protocol Shortest Path Routing Extensions for BGP Protocol
draft-ietf-lsvr-bgp-spf-06 draft-ietf-lsvr-bgp-spf-07
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 lead 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 a solution which leverages BGP Link-State distribution and describes a solution which leverages BGP Link-State distribution and
the Shortest Path First (SPF) algorithm similar to Internal Gateway the Shortest Path First (SPF) algorithm similar to Internal Gateway
Protocols (IGPs) such as OSPF. Protocols (IGPs) such as OSPF.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 April 2, 2020. This Internet-Draft will expire on June 12, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. BGP Shortest Path First (SPF) Motivation . . . . . . . . 4 1.1. BGP Shortest Path First (SPF) Motivation . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. BGP Peering Models . . . . . . . . . . . . . . . . . . . . . 5 2. BGP Peering Models . . . . . . . . . . . . . . . . . . . . . 5
2.1. BGP Single-Hop Peering on Network Node Connections . . . 5 2.1. BGP Single-Hop Peering on Network Node Connections . . . 5
2.2. BGP Peering Between Directly Connected Network Nodes . . 6 2.2. BGP Peering Between Directly Connected Network Nodes . . 5
2.3. BGP Peering in Route-Reflector or Controller Topology . . 6 2.3. BGP Peering in Route-Reflector or Controller Topology . . 6
3. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . . . . 6 3. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . . . . 6
4. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . . . 7 4. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . . . 6
4.1. Node NLRI Usage . . . . . . . . . . . . . . . . . . . . . 7 4.1. Node NLRI Usage . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Node NLRI Attribute SPF Capability TLV . . . . . . . 7 4.1.1. Node NLRI Attribute SPF Capability TLV . . . . . . . 7
4.1.2. BGP-LS Node NLRI Attribute SPF Status TLV . . . . . . 8 4.1.2. BGP-LS Node NLRI Attribute SPF Status TLV . . . . . . 8
4.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . . . 9 4.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. BGP-LS Link NLRI Attribute Prefix-Length TLVs . . . . 9 4.2.1. BGP-LS Link NLRI Attribute Prefix-Length TLVs . . . . 9
4.2.2. BGP-LS Link NLRI Attribute SPF Status TLV . . . . . . 10 4.2.2. BGP-LS Link NLRI Attribute SPF Status TLV . . . . . . 9
4.3. Prefix NLRI Usage . . . . . . . . . . . . . . . . . . . . 10 4.3. Prefix NLRI Usage . . . . . . . . . . . . . . . . . . . . 10
4.3.1. BGP-LS Prefix NLRI Attribute SPF Status TLV . . . . . 11 4.3.1. BGP-LS Prefix NLRI Attribute SPF Status TLV . . . . . 10
4.4. BGP-LS Attribute Sequence-Number TLV . . . . . . . . . . 11 4.4. BGP-LS Attribute Sequence-Number TLV . . . . . . . . . . 10
5. Decision Process with SPF Algorithm . . . . . . . . . . . . . 12 5. Decision Process with SPF Algorithm . . . . . . . . . . . . . 11
5.1. Phase-1 BGP NLRI Selection . . . . . . . . . . . . . . . 13 5.1. Phase-1 BGP NLRI Selection . . . . . . . . . . . . . . . 12
5.2. Dual Stack Support . . . . . . . . . . . . . . . . . . . 14 5.2. Dual Stack Support . . . . . . . . . . . . . . . . . . . 13
5.3. SPF Calculation based on BGP-LS NLRI . . . . . . . . . . 14 5.3. SPF Calculation based on BGP-LS NLRI . . . . . . . . . . 13
5.4. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 17 5.4. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 16
5.5. IPv4/IPv6 Unicast Address Family Interaction . . . . . . 17 5.5. IPv4/IPv6 Unicast Address Family Interaction . . . . . . 16
5.6. NLRI Advertisement and Convergence . . . . . . . . . . . 17 5.6. NLRI Advertisement and Convergence . . . . . . . . . . . 17
5.6.1. Link/Prefix Failure Convergence . . . . . . . . . . . 17 5.6.1. Link/Prefix Failure Convergence . . . . . . . . . . . 17
5.6.2. Node Failure Convergence . . . . . . . . . . . . . . 18 5.6.2. Node Failure Convergence . . . . . . . . . . . . . . 17
5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 18 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Management Considerations . . . . . . . . . . . . . . . . . . 19 8. Management Considerations . . . . . . . . . . . . . . . . . . 18
8.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 19 8.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 18
8.2. Operational Data . . . . . . . . . . . . . . . . . . . . 19 8.2. Operational Data . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Information References . . . . . . . . . . . . . . . . . 21 11.2. Information References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
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 lead many of these MSDCs to converge on operational simplicity have led many of these MSDCs to converge on
BGP [RFC4271] as their single routing protocol for both their fabric BGP [RFC4271] as their single routing protocol for both their fabric
routing and their Data Center Interconnect (DCI) routing. routing and their Data Center Interconnect (DCI) routing.
Requirements and procedures for using BGP are described in [RFC7938]. Requirements and procedures for using BGP are described in [RFC7938].
This document describes an alternative solution which leverages BGP- This document describes an alternative solution which leverages BGP-
LS [RFC7752] and the Shortest Path First algorithm similar to LS [RFC7752] and the Shortest Path First algorithm similar to
Internal Gateway Protocols (IGPs) such as OSPF [RFC2328]. Internal Gateway Protocols (IGPs) such as OSPF [RFC2328].
[RFC4271] defines the Decision Process that is used to select routes [RFC4271] defines the Decision Process that is used to select routes
for subsequent advertisement by applying the policies in the local for subsequent advertisement by applying the policies in the local
Policy Information Base (PIB) to the routes stored in its Adj-RIBs- Policy Information Base (PIB) to the routes stored in its Adj-RIBs-
skipping to change at page 6, line 24 skipping to change at page 6, line 11
discovery and liveliness detection for those connections are discovery and liveliness detection for those connections are
independent of the BGP protocol. How this is accomplished is outside independent of the BGP protocol. How this is accomplished is outside
the scope of this document. Consequently, there will be a single the scope of this document. Consequently, there will be a single
session even if there are multiple direct connections between BGP session even if there are multiple direct connections between BGP
speakers. For the purposes of BGP SPF, Link NLRI is advertised as speakers. For the purposes of BGP SPF, Link NLRI is advertised as
long as a BGP session has been established, the Link-State/SPF long as a BGP session has been established, the Link-State/SPF
address family capability has been exchanged [RFC4790] and the address family capability has been exchanged [RFC4790] and the
corresponding link is considered is up and considered operational. corresponding link is considered is up and considered operational.
This is much like the previous peering model only peering is on a This is much like the previous peering model only peering is on a
single loopback address and the switch fabric links can be single loopback address and the switch fabric links can be
unnumbered. However, there will be the same unnumber of sessions as unnumbered. However, there will be the same number of sessions as
with the previous peering model unless there are parrallel links with the previous peering model unless there are parallel links
between switches in the fabric. between switches in the fabric.
2.3. BGP Peering in Route-Reflector or Controller Topology 2.3. BGP Peering in Route-Reflector or Controller Topology
In this model, BGP speakers peer solely with one or more Route In this model, BGP 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 direct connection discovery and liveliness detection for those
connections are done outside the BGP protocol. More specifically, connections are done outside the BGP protocol. More specifically,
the Liveliness detection is done using BFD protocol described in the Liveliness detection is done using BFD protocol described in
[RFC5880]. For the purposes of BGP SPF, Link NLRI is advertised as [RFC5880]. For the purposes of BGP SPF, Link NLRI is advertised as
skipping to change at page 6, line 49 skipping to change at page 6, line 36
BGP sessions and, consequently, instances of the same NLRI received BGP sessions and, consequently, instances of the same NLRI received
from multiple peers. It is discussed in greater detail in from multiple peers. It is discussed in greater detail in
[I-D.ietf-lsvr-applicability]. [I-D.ietf-lsvr-applicability].
3. BGP-LS Shortest Path Routing (SPF) SAFI 3. BGP-LS Shortest Path Routing (SPF) SAFI
In order to replace the Phase 1 and 2 decision functions of the In order to replace the Phase 1 and 2 decision functions of the
existing Decision Process with an SPF-based Decision Process and existing Decision Process with an SPF-based Decision Process and
streamline the Phase 3 decision functions in a backward compatible streamline the Phase 3 decision functions in a backward compatible
manner, this draft introduces the BGP-LS-SFP SAFI for BGP-LS SPF manner, this draft introduces the BGP-LS-SFP SAFI for BGP-LS SPF
operation. The BGP-LS-SPF (AF 16388 / SAFI TBD1) [RFC4790] is operation. The BGP-LS-SPF (AFI 16388 / SAFI TBD1) [RFC4790] is
allocated by IANA as specified in the Section 6. A BGP speaker using allocated by IANA as specified in the Section 6. A BGP speaker using
the BGP-LS SPF extensions described herein MUST exchange the AFI/SAFI the BGP-LS SPF extensions described herein MUST exchange the AFI/SAFI
using Multiprotocol Extensions Capability Code [RFC4760] with other using Multiprotocol Extensions Capability Code [RFC4760] with other
BGP speakers in the SPF routing domain. BGP speakers in the SPF routing domain.
4. Extensions to BGP-LS 4. 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 networks and shared with external information can be collected from networks and shared with external
components using BGP protocol. It describes both the definition of components using BGP protocol. It describes both the definition of
skipping to change at page 10, line 14 skipping to change at page 9, line 23
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD IPv4 or IPv6 Type | Length | | TBD IPv4 or IPv6 Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Length | | Prefix-Length |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Prefix-length - A one-octet length restricted to 1-32 for IPv4 Prefix-length - A one-octet length restricted to 1-32 for IPv4
Link NLIR endpoint prefixes and 1-128 for IPv6 Link NLRI endpoint prefixes and 1-128 for IPv6
Link NLRI endpoint prefixes. Link NLRI endpoint prefixes.
4.2.2. BGP-LS Link NLRI Attribute SPF Status TLV 4.2.2. BGP-LS Link NLRI Attribute SPF Status TLV
A BGP-LS Attribute TLV to BGP-LS Link NLRI is defined to indicate the A BGP-LS Attribute TLV to BGP-LS Link NLRI is defined to indicate the
status of the link with respect to the BGP SPF calculation. This status of the link with respect to the BGP SPF calculation. This
will be used to expedite convergence for link failures as discussed will be used to expedite convergence for link failures as discussed
in Section 5.6.1. If the SPF Status TLV is not included with the in Section 5.6.1. If the SPF Status TLV is not included with the
Link NLRI, the link is considered up and available. Link NLRI, the link is considered up and available.
skipping to change at page 13, line 4 skipping to change at page 12, line 22
determine whether it is the best-path by examining the Node-ID and determine whether it is the best-path by examining the Node-ID and
sequence number as described in Section 5.1. If the received best- sequence number as described in Section 5.1. If the received best-
path NLRI had changed, it will be advertised to other BGP-LS-SPF path NLRI had changed, it will be advertised to other BGP-LS-SPF
peers. If the attributes have changed (other than the sequence peers. If the attributes have changed (other than the sequence
number), a BGP SPF calculation will be scheduled. However, a changed number), a BGP SPF calculation will be scheduled. However, a changed
NLRI MAY be advertised to other peers almost immediately and NLRI MAY be advertised to other peers almost immediately and
propagation of changes can approach IGP convergence times. To propagation of changes can approach IGP convergence times. To
accomplish this, the MinRouteAdvertisementIntervalTimer and accomplish this, the MinRouteAdvertisementIntervalTimer and
MinASOriginationIntervalTimer [RFC4271] are not applicable to the MinASOriginationIntervalTimer [RFC4271] are not applicable to the
BGP-LS-SPF SAFI. Rather, SPF calculations SHOULD be triggered and BGP-LS-SPF SAFI. Rather, SPF calculations SHOULD be triggered and
dampened consistent with the SPF backoff algorithm specified in 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 would also simplified since under normal SPF operation, a BGP speaker would
advertise the NLRI selected for the SPF to all BGP peers with the advertise the NLRI selected for the SPF to all BGP peers with the
BGP-LS/BGP-LS-SPF AFI/SAFI. Application of policy would not be BGP-LS/BGP-LS-SPF AFI/SAFI. Application of policy would not be
prevented however its usage to best-path process would be limited as prevented however its usage to best-path process would be limited as
the SPF relies solely on link metrics. the SPF relies solely on link metrics.
5.1. Phase-1 BGP NLRI Selection 5.1. Phase-1 BGP NLRI Selection
skipping to change at page 15, line 8 skipping to change at page 14, line 26
document. document.
o Candidate List - This is a list of candidate Node NLRI with the o Candidate List - This is a list of candidate Node NLRI with the
lowest cost Node NLRI at the front of the list. It is typically lowest cost Node NLRI at the front of the list. It is typically
implemented as a heap but other concrete data structures have also implemented as a heap but other concrete data structures have also
been used. been used.
The algorithm is comprised of the steps below: The algorithm is comprised of the steps below:
1. The current local RIB is invalidated. The local RIB is built 1. The current local RIB is invalidated. The local RIB is built
again from scratch. The existing routing entries are preserved again during the course of the SPF computation. The existing
for comparision to determine changes that need to be installed in routing entries are preserved for comparison to determine changes
the global RIB. that need to be installed in the global RIB.
2. The computing router's Node NLRI is installed in the local RIB 2. The computing router's Node NLRI is installed in the local RIB
with a cost of 0 and as as the sole entry in the candidate list. with a cost of 0 and as the sole entry in the candidate list.
3. The Node NLRI with the lowest cost is removed from the candidate 3. The Node NLRI with the lowest cost is removed from the candidate
list for processing. If the BGP-LS Node attribute includes an list for processing. If the BGP-LS Node attribute includes an
SPF Status TLV (Section 4.1.2) indicating the node is SPF Status TLV (Section 4.1.2) indicating the node is
unreachable, the Node NLRI is ignored and the next lowest cost unreachable, the Node NLRI is ignored and the next lowest cost
Node NLRI is selected from candidate list. The Node Node NLRI is selected from candidate list. The Node
corresponding to this NLRI will be referred to as the Current corresponding to this NLRI will be referred to as the Current
Node. If the candidate list is empty, the SPF calculation has Node. If the candidate list is empty, the SPF calculation has
completed and the algorithm proceeds to step 6. completed and the algorithm proceeds to step 6.
skipping to change at page 16, line 31 skipping to change at page 15, line 50
+ If the BGP-LS Link NLRI attribute includes an SPF Status + If the BGP-LS Link NLRI attribute includes an SPF Status
TLV indicating the link is down, the BGP-LS Link NLRI is TLV indicating the link is down, the BGP-LS Link NLRI is
considered down and the next BGP-LS Link NLRI is examined. considered down and the next BGP-LS Link NLRI is examined.
+ All the Link NLRI corresponding the Endpoint Node NLRI will + All the Link NLRI corresponding the Endpoint Node NLRI will
be searched for a back-link NLRI pointing to the current be searched for a back-link NLRI pointing to the current
node. Both the Node identifiers and the Link endpoint node. Both the Node identifiers and the Link endpoint
identifiers in the Endpoint Node's Link NLRI must match for identifiers in the Endpoint Node's Link NLRI must match for
a match. If there is no corresponding Link NLRI a match. If there is no corresponding Link NLRI
corresponding to the Endpoint Node NLRI, the Endpoint Node corresponding to the Endpoint Node NLRI, the Endpoint Node
NLIR fails the bi-directional connectivity test and is not NLRI fails the bi-directional connectivity test and is not
processed further. processed further.
+ If the Endpoint Node NLRI is not on the candidate list, it + If the Endpoint Node NLRI is not on the candidate list, it
is inserted based on the link cost and BGP Identifier (the is inserted based on the link cost and BGP Identifier (the
latter being used as a tie-breaker). latter being used as a tie-breaker).
+ If the Endpoint Node NLRI is already on the candidate list + If the Endpoint Node NLRI is already on the candidate list
with a lower cost, it need not be inserted again. with a lower cost, it need not be inserted again.
+ If the Endpoint Node NLRI is already on the candidate list + If the Endpoint Node NLRI is already on the candidate list
skipping to change at page 18, line 18 skipping to change at page 17, line 33
of the BGP-LS Link NLRI is withdrawn. In order to avoid this delay, of the BGP-LS Link NLRI is withdrawn. In order to avoid this delay,
the originator of the Link NLRI will advertise a more recent version the originator of the Link NLRI will advertise a more recent version
of the BGP-LS Link NLRI including the SPF Status TLV Section 4.2.2 of the BGP-LS Link NLRI including the SPF Status TLV Section 4.2.2
indicating the link is down with respect to BGP SPF. After some indicating the link is down with respect to BGP SPF. After some
configurable period of time, e.g., 2-3 seconds, the BGP-LS Link NLRI configurable period of time, e.g., 2-3 seconds, the BGP-LS Link NLRI
can be withdrawn with no consequence. If the link becomes available can be withdrawn with no consequence. If the link becomes available
in that period, the originator of the BGP-LS LINK NLRI will simply in that period, the originator of the BGP-LS LINK NLRI will simply
advertise a more recent version of the BGP-LS Link NLRI without the advertise a more recent version of the BGP-LS Link NLRI without the
SPF Status TLV in the BGP-LS Link Attributes. SPF Status TLV in the BGP-LS Link Attributes.
Similarily, when a prefix becomes unreachable, a more recent version Similarly, when a prefix becomes unreachable, a more recent version
of the BGP-LS Prefix NLRI will be advertised with the SPF Status TLV of the BGP-LS Prefix NLRI will be advertised with the SPF Status TLV
Section 4.3.1 indicating the prefix is unreachable in the BGP-LS Section 4.3.1 indicating the prefix is unreachable in the BGP-LS
Prefix Attributes and the prefix will be considered unreachable with Prefix Attributes and the prefix will be considered unreachable with
respect to BGP SPF. After some configurable period of time, e.g., respect to BGP SPF. After some configurable period of time, e.g.,
2-3 seconds, the BGP-LS Prefix NLRI can be withdrawn with no 2-3 seconds, the BGP-LS Prefix NLRI can be withdrawn with no
consequence. If the prefix becomes reachable in that period, the consequence. If the prefix becomes reachable in that period, the
originator of the BGP-LS Prefix NLRI will simply advertise a more originator of the BGP-LS Prefix NLRI will simply advertise a more
recent version of the BGP-LS Prefix NLRI without the SPF Status TLV recent version of the BGP-LS Prefix NLRI without the SPF Status TLV
in the BGP-LS Prefix Attributes. in the BGP-LS Prefix Attributes.
skipping to change at page 19, line 32 skipping to change at page 18, line 47
inherent in the existing [RFC4271], [RFC4724], and [RFC7752]. inherent in the existing [RFC4271], [RFC4724], and [RFC7752].
8. Management Considerations 8. Management Considerations
This section includes unique management considerations for the BGP-LS This section includes unique management considerations for the BGP-LS
SPF address family. SPF address family.
8.1. Configuration 8.1. Configuration
In addition to configuration of the BGP-LS SPF address family, In addition to configuration of the BGP-LS SPF address family,
implementations SHOULD support the configuratio of the implementations SHOULD support the configuration of the
INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY, TIME_TO_LEARN, INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY, TIME_TO_LEARN,
and HOLDDOWN_INTERVAL as documented in [RFC8405]. and HOLDDOWN_INTERVAL as documented in [RFC8405].
8.2. Operational Data 8.2. Operational Data
In order to troubleshoot SPF issues, implementations SHOULD support In order to troubleshoot SPF issues, implementations SHOULD support
an SPF log including entries for previous SPF computations, Each SPF an SPF log including entries for previous SPF computations, Each SPF
log entry would include the BGP-LS NLRI SPF triggering the SPF, SPF log entry would include the BGP-LS NLRI SPF triggering the SPF, SPF
scheduled time, SPF start time, SPF end time, and SPF type if scheduled time, SPF start time, SPF end time, and SPF type if
different types of SPF are supported. Since the size of the log will different types of SPF are supported. Since the size of the log will
be finite, implementations SHOULD also maintain counters for the be finite, implementations SHOULD also maintain counters for the
total number of SPF computations of each type and the total number of total number of SPF computations of each type and the total number of
SPF triggering events. Additionally, to troubleshoot SPF scheduling SPF triggering events. Additionally, to troubleshoot SPF scheduling
and backoff [RFC8405], the current SPF backoff state, remaining time- and back-off [RFC8405], the current SPF back-off state, remaining
to-learn, remaining holddown, last trigger event time, last SPF time, time-to-learn, remaining holddown, last trigger event time, last SPF
and next SPF time should be available. time, and next SPF time should be available.
9. Acknowledgements 9. 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, and Fred Baker for their review and comments. Hassanov, Dan Frost, Matt Anderson, and Fred Baker for their review
Thanks to Chaitanya Yadlapalli and Pushpais Sarkar for discussions on and comments. Thanks to Chaitanya Yadlapalli and Pushpais Sarkar for
preventing a BGP SPF Router from being used for non-local traffic discussions on preventing a BGP SPF Router from being used for non-
(i.e., transit traffic). 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.
10. Contributors 10. 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
skipping to change at page 21, line 21 skipping to change at page 20, line 36
Patel, "Revised Error Handling for BGP UPDATE Messages", Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A.,
Francois, P., and C. Bowers, "Shortest Path First (SPF) Francois, P., and C. Bowers, "Shortest Path First (SPF)
Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, Back-Off Delay Algorithm for Link-State IGPs", RFC 8405,
DOI 10.17487/RFC8405, June 2018, DOI 10.17487/RFC8405, June 2018,
<https://www.rfc-editor.org/info/rfc8405>. <https://www.rfc-editor.org/info/rfc8405>.
11.2. Information References 11.2. Information References
[I-D.ietf-lsvr-applicability] [I-D.ietf-lsvr-applicability]
Patel, K., Lindem, A., Zandi, S., and G. Dawra, "Usage and Patel, K., Lindem, A., Zandi, S., and G. Dawra, "Usage and
Applicability of Link State Vector Routing in Data Applicability of Link State Vector Routing in Data
Centers", draft-ietf-lsvr-applicability-02 (work in Centers", draft-ietf-lsvr-applicability-04 (work in
progress), May 2019. progress), November 2019.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>. <https://www.rfc-editor.org/info/rfc4456>.
skipping to change at page 23, line 5 skipping to change at page 22, line 14
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop", Layer Reachability Information with an IPv6 Next Hop",
RFC 5549, DOI 10.17487/RFC5549, May 2009, RFC 5549, DOI 10.17487/RFC5549, May 2009,
<https://www.rfc-editor.org/info/rfc5549>. <https://www.rfc-editor.org/info/rfc5549>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>.
Authors' Addresses Authors' Addresses
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
Email: keyur@arrcus.com Email: keyur@arrcus.com
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA USA
Email: acee@cisco.com Email: acee@cisco.com
Shawn Zandi Shawn Zandi
Linkedin LinkedIn
222 2nd Street 222 2nd Street
San Francisco, CA 94105 San Francisco, CA 94105
USA USA
Email: szandi@linkedin.com Email: szandi@linkedin.com
Wim Henderickx Wim Henderickx
Nokia Nokia
Antwerp Antwerp
Belgium Belgium
 End of changes. 32 change blocks. 
66 lines changed or deleted 54 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/