< draft-ietf-lsvr-bgp-spf-07.txt   draft-ietf-lsvr-bgp-spf-08.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: June 12, 2020 Cisco Systems Expires: September 25, 2020 Cisco Systems
S. Zandi S. Zandi
LinkedIn LinkedIn
W. Henderickx W. Henderickx
Nokia Nokia
December 10, 2019 March 24, 2020
Shortest Path Routing Extensions for BGP Protocol Shortest Path Routing Extensions for BGP Protocol
draft-ietf-lsvr-bgp-spf-07 draft-ietf-lsvr-bgp-spf-08
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 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
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 June 12, 2020. This Internet-Draft will expire on September 25, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 8, line 49 skipping to change at page 8, line 49
described above and unique link identifiers dependent on the described above and unique link identifiers dependent on the
addressing. For IPv4 links, the links local IPv4 (TLV 259) and addressing. For IPv4 links, the links local IPv4 (TLV 259) and
remote IPv4 (TLV 260) addresses will be used. For IPv6 links, the remote IPv4 (TLV 260) addresses will be used. For IPv6 links, the
local IPv6 (TLV 261) and remote IPv6 (TLV 262) addresses will be local IPv6 (TLV 261) and remote IPv6 (TLV 262) addresses will be
used. For unnumbered links, the link local/remote identifiers (TLV used. For unnumbered links, the link local/remote identifiers (TLV
258) will be used. For links supporting having both IPv4 and IPv6 258) will be used. For links supporting having both IPv4 and IPv6
addresses, both sets of descriptors may be included in the same Link addresses, both sets of descriptors may be included in the same Link
NLRI. The link identifiers are described in table 5 of [RFC7752]. NLRI. The link identifiers are described in table 5 of [RFC7752].
The link IGP metric attribute TLV (TLV 1095) as well as any others The link IGP metric attribute TLV (TLV 1095) as well as any others
required for non-SPF purposes SHOULD be advertised. Algorithms such required for non-SPF purposes SHOULD be advertised. The metric value
as setting the metric inversely to the link speed as done in the OSPF in this TLV is variable length dependent on specific protocol usage
MIB [RFC4750] MAY be supported. However, this is beyond the scope of (refer to section 3.3.2.4 in [RFC7752]). For simplicity, the BGP-LS
this document. SPF metric length will be 4 octets. Algorithms such as setting the
metric inversely to the link speed as done in the OSPF MIB [RFC4750]
MAY be supported. However, this is beyond the scope of this
document.
4.2.1. BGP-LS Link NLRI Attribute Prefix-Length TLVs 4.2.1. BGP-LS Link NLRI Attribute Prefix-Length TLVs
Two BGP-LS Attribute TLVs to BGP-LS Link NLRI are defined to Two BGP-LS Attribute TLVs to BGP-LS 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. The prefix length is used for the optional installation of prefixes. The prefix length is used for the optional installation of
prefixes corresponding to Link NLRI as defined in Section 5.3. prefixes corresponding to Link NLRI as defined in Section 5.3.
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 14, line 25 skipping to change at page 14, line 25
associations between Link NLRI are possible but of scope of this associations between Link NLRI are possible but of scope of this
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 rebuilt
again during the course of the SPF computation. The existing during the course of the SPF computation. The existing routing
routing entries are preserved for comparison to determine changes entries are preserved for comparison to determine changes that
that need to be installed in the global RIB. 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 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
skipping to change at page 17, line 48 skipping to change at page 17, line 48
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.
5.6.2. Node Failure Convergence 5.6.2. Node Failure Convergence
With BGP without graceful restart [RFC4724], all the NLRI advertised With BGP without graceful restart [RFC4724], all the NLRI advertised
by node are implicitly withdrawn when a session failure is detected. by node are implicitly withdrawn when a session failure is detected.
If fast failure detection such as BFD is utilized and the node is on If fast failure detection such as BFD is utilized, and the node is on
the fastest converging path, the most recent versions of BGP-LS NLRI the fastest converging path, the most recent versions of BGP-LS NLRI
may be withdrawn while these versions are in-flight on longer paths. may be withdrawn while these versions are in-flight on longer paths.
This will result the older version of the NLRI being used until the This will result the older version of the NLRI being used until the
new versions arrive and, potentially, unnecessary route flaps. new versions arrive and, potentially, unnecessary route flaps.
Therefore, BGP-LS SPF NLRI SHOULD always be retained before being Therefore, BGP-LS SPF NLRI SHOULD always be retained before being
implicitly withdrawn for a brief configurable interval, e.g., 2-3 implicitly withdrawn for a brief configurable interval, e.g., 2-3
seconds. This will not delay convergence since the adjacent nodes seconds. This will not delay convergence since the adjacent nodes
will detect the link failure and advertise a more recent NLRI will detect the link failure and advertise a more recent NLRI
indicating the link is down with respect to BGP SPF Section 5.6.1 and indicating the link is down with respect to BGP SPF Section 5.6.1 and
the BGP-SPF calculation will failure the bi-directional connectivity the BGP-SPF calculation will failure the bi-directional connectivity
 End of changes. 8 change blocks. 
14 lines changed or deleted 17 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/