idnits 2.17.00 (12 Aug 2021) /tmp/idnits60925/draft-keyupate-idr-bgp-spf-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2016) is 2028 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2328' is mentioned on line 571, but not defined == Missing Reference: 'RFC5286' is mentioned on line 600, but not defined == Missing Reference: 'RFC4456' is mentioned on line 575, but not defined == Missing Reference: 'RFC4915' is mentioned on line 595, but not defined == Missing Reference: 'RFC5549' is mentioned on line 605, but not defined ** Obsolete undefined reference: RFC 5549 (Obsoleted by RFC 8950) == Missing Reference: 'RFC4790' is mentioned on line 590, but not defined == Missing Reference: 'RFC4750' is mentioned on line 585, but not defined == Missing Reference: 'RFC4724' is mentioned on line 580, but not defined == Outdated reference: draft-ietf-idr-bgpls-segment-routing-epe has been published as RFC 9086 ** Downref: Normative reference to an Informational RFC: RFC 7938 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Patel 3 Internet-Draft Arrcus, Inc. 4 Intended status: Standards Track A. Lindem 5 Expires: May 4, 2017 Cisco Systems 6 S. Zandi 7 Linkedin 8 G. Van de Velde 9 Nokia 10 October 31, 2016 12 Shortest Path Routing Extensions for BGP Protocol 13 draft-keyupate-idr-bgp-spf-01.txt 15 Abstract 17 Many Massively Scaled Data Centers (MSDCs) have converged on 18 simplified layer 3 routing. Furthermore, requirements for 19 operational simplicity have lead many of these MSDCs to converge on 20 BGP as their single routing protocol for both their fabric routing 21 and their Data Center Interconnect (DCI) routing. This document 22 describes a solution which leverages BGP Link-State distribution and 23 the Shortest Path First algorithm similar to Internal Gateway 24 Protocols (IGPs) such as OSPF. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 4, 2017. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. BGP Shortest Path First (SPF) Motivation . . . . . . . . 4 74 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 75 2. BGP Peering Models . . . . . . . . . . . . . . . . . . . . . 5 76 2.1. BGP Single-Hop Peering on Network Node Connections . . . 5 77 2.2. BGP Peering Between Directly Connected Network Nodes . . 5 78 2.3. BGP Peering in Route-Reflector or Controller Topology . . 6 79 3. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . . . . 6 80 4. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . . . 6 81 4.1. Node NLRI Usage and Modifications . . . . . . . . . . . . 6 82 4.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . . . 7 83 4.3. Prefix NLRI Usage . . . . . . . . . . . . . . . . . . . . 7 84 4.4. BGP-LS Attribute Sequence-Number TLV . . . . . . . . . . 8 85 5. Decision Process with SPF Algorithm . . . . . . . . . . . . . 9 86 5.1. Phase-1 BGP NLRI Selection . . . . . . . . . . . . . . . 9 87 5.2. Dual Stack Support . . . . . . . . . . . . . . . . . . . 10 88 5.3. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 10 89 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 10 90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 92 7.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 11 93 7.2. Contributorss . . . . . . . . . . . . . . . . . . . . . . 11 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 96 8.2. Information References . . . . . . . . . . . . . . . . . 13 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 99 1. Introduction 101 Many Massively Scaled Data Centers (MSDCs) have converged on 102 simplified layer 3 routing. Furthermore, requirements for 103 operational simplicity have lead many of these MSDCs to converge on 104 BGP [RFC4271] as their single routing protocol for both their fabric 105 routing and their Data Center Interconnect (DCI) routing. 106 Requirements and procedures for using BGP are described in [RFC7938]. 107 This document describes an alternative solution which leverages BGP- 108 LS [RFC7752] and the Shortest Path First algorithm similar to 109 Internal Gateway Protocols (IGPs) such as OSPF [RFC2328]. 111 [RFC4271] defines the Decision Process that is used to select routes 112 for subsequent advertisement by applying the policies in the local 113 Policy Information Base (PIB) to the routes stored in its Adj-RIBs- 114 In. The output of the Decision Process is the set of routes that are 115 announced by a BGP speaker to its peers. These selected routes are 116 stored by a BGP speaker in the speaker's Adj-RIBs-Out according to 117 policy. 119 [RFC7752] describes a mechanism by which link-state and TE 120 information can be collected from networks and shared with external 121 components using BGP. This is achieved by defining NLRI carried 122 within BGP-LS AFI and BGP-LS SAFIs. The BGP-LS extensions defined in 123 [RFC7752] makes use of the Decision Process defined in [RFC4271]. 125 This document augments [RFC7752] by replacing its use of the existing 126 Decision Process. The BGP-LS-SPF and BGP-LS-SPF-VPN AFI/SAFI are 127 introduced to insure backward compatibility. The Phase 1 and 2 128 decision functions of the Decision Process are replaced with the 129 Shortest Path Algorithm (SPF) also known as the Dijkstra Algorithm. 130 The Phase 3 decision function is also simplified since it is no 131 longer dependent on the previous phases. This solution avails the 132 benefits of both BGP and SPF-based IGPs. These include TCP based 133 flow-control, no periodic link-state refresh, and completely 134 incremental NLRI advertisement. These advantages can reduce the 135 overhead in MSDCs where there is a high degree of Equal Cost Multi- 136 Path (ECMPs) and the topology is very stable. Additionally, using a 137 SPF-based computation can support fast convergence and the 138 computation of Loop-Free Alternatives (LFAs) [RFC5286] in the event 139 of link failures. Furthermore, a BGP based solution lends itself to 140 multiple peering models including those incorporating route- 141 reflectors [RFC4456] or controllers. 143 Support for Multiple Topology Routing (MTR) as described in [RFC4915] 144 is an area for further study dependent on deployment requirements. 146 1.1. BGP Shortest Path First (SPF) Motivation 148 Given that [RFC7938] already describes how BGP could be used as the 149 sole routing protocol in an MSDC, one might question the motivation 150 for defining an alternate BGP deployment model when a mature solution 151 exists. For both alternatives, BGP offers the operational benefits 152 of a single routing protocol. However, BGP SPF offers some unique 153 advantages above and beyond standard BGP distance-vector routing. 155 A primary advantage is that all BGP speakers in the BGP SPF routing 156 domain will have a complete view of the topology. This will allow 157 support of ECMP, IP fast-reroute (e.g., Loop-Free Alternatives), 158 Shared Risk Link Groups (SRLGs), and other routing enhancements 159 without advertisement of addition BGP paths or other extensions. In 160 short, the advantages of an IGP such as OSPF [RFC2328] are availed in 161 BGP. 163 With the simplified BGP decision process as defined in Section 5.1, 164 NLRI changes can be disseminated throughout the BGP routing domain 165 much more rapidly (equivalent to IGPs with the proper 166 implementation). 168 Another primary advantage is a potential reduction in NLRI 169 advertisement. With standard BGP distance-vector routing, a single 170 link failure may impact 100s or 1000s prefixes and result in the 171 withdrawal or re-advertisement of the attendant NLRI. With BGP SPF, 172 only the BGP speakers corresponding to the link NLRI need withdraw 173 the corresponding BGP-LS Link NLRI. This advantage will contribute 174 to both faster convergence and better scaling. 176 With controller and route-reflector peering models, BGP SPF 177 advertisement and distributed computation require a minimal number of 178 sessions and copies of the NLRI since only the latest verion of the 179 NLRI from the originator is required. Given that verification of the 180 adjacencies is done outside of BGP (see Section 2), each BGP speaker 181 will only need as many sessions and copies of the NLRI as required 182 for redundancy (e.g., one for SPF computation and another for 183 backup). Functions such as Optimized Route Reflection (ORR) are 184 supported without extension by virture of the primary advantages. 185 Additionally, a controller could inject topology that is learned 186 outside the BGP routing domain. 188 Given that controllers are already consuming BGP-LS NLRI [RFC7752], 189 reusing for the BGP-LS SPF leverages the existing controller 190 implementations. 192 Another potential advantage of BGP SPF is that both IPv6 and IPv4 can 193 be supported in the same address family using the same topology. 194 Although not described in this version of the document, multi- 195 topology extensions can be used to support separate IPv4, IPv6, 196 unicast, and multicast topologies while sharing the same NLRI. 198 Finally, the BGP SPF topology can be used as an underlay for other 199 BGP address families (using the existing model) and realize all the 200 above advantages. A simplified peering model using IPv6 link-local 201 addresses as next-hops can be deployed similar to [RFC5549]. 203 1.2. Requirements Language 205 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 206 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 207 document are to be interpreted as described in RFC 2119 [RFC2119]. 209 2. BGP Peering Models 211 Depending on the requirements, scaling, and capabilities of the BGP 212 speakers, various peering models are supported. The only requirement 213 is that all BGP speakers in the BGP SPF routing domain receive link- 214 state NLRI on a timely basis, run an SPF calculation, and update 215 their data plane appropriately. The content of the Link NLRI is 216 described in Section 4.2. 218 2.1. BGP Single-Hop Peering on Network Node Connections 220 The simplest peering model is the one described in section 5.2.1 of 221 [RFC7938]. In this model, EBGP single-hop sessions are established 222 over direct point-to-point links interconnecting the network nodes. 223 For the purposes of BGP SPF, Link NLRI is only advertised if a 224 single-hop BGP session has been established and the Link-State/SPF 225 adddress family capability has been exchanged [RFC4790] on the 226 corresponding session. If the session goes down, the NLRI will be 227 withdrawn. 229 2.2. BGP Peering Between Directly Connected Network Nodes 231 In this model, BGP speakers peer with all directly connected network 232 nodes but the sessions may be multi-hop and the direct connection 233 discovery and liveliness detection for those connections are 234 independent of the BGP protocol. How this is accomplished is outside 235 the scope of this document. Consequently, there will be a single 236 session even if there are multiple direct connections between BGP 237 speakers. For the purposes of BGP SPF, Link NLRI is advertised as 238 long as a BGP session has been established, the Link-State/SPF 239 address family capability has been exchanged [RFC4790] and the 240 corresponding link is up and considered operational. 242 2.3. BGP Peering in Route-Reflector or Controller Topology 244 In this model, BGP speakers peer solely with one or more Route 245 Reflectors [RFC4456] or controllers. As in the previous model, 246 direct connection discovery and liveliness detection for those 247 connections are done outside the BGP protocol. For the purposes of 248 BGP SPF, Link NLRI is advertised as long as the corresponding link is 249 up and considered operational. 251 3. BGP-LS Shortest Path Routing (SPF) SAFI 253 In order to replace the Phase 1 and 2 decision functions of the 254 existing Decision Process with an SPF-based Decision Process and 255 streamline the Phase 3 decision functions in a backward compatible 256 manner, this draft introduces a couple AFI/SAFIs for BGP LS SPF 257 operation. The BGP-LS-SPF (AF 16388 / SAFI TBD1) and BGP-LS-SPF-VPN 258 (AFI 16388 / SAFI TBD2) [RFC4790] are allocated by IANA as specified 259 in the Section 6. 261 4. Extensions to BGP-LS 263 [RFC7752] describes a mechanism by which link-state and TE 264 information can be collected from networks and shared with external 265 components using BGP protocol. It contains two parts: definition of 266 a new BGP NLRI that describes links, nodes, and prefixes comprising 267 IGP link-state information and definition of a new BGP path attribute 268 (BGP-LS attribute) that carries link, node, and prefix properties and 269 attributes, such as the link and prefix metric or auxiliary Router- 270 IDs of nodes, etc. 272 The BGP protocol will be used in the Protocol-ID field specified in 273 table 1 of [I-D.ietf-idr-bgpls-segment-routing-epe]. The local and 274 remote node descriptors for all NLRI will be the BGP Router-ID (TLV 275 516) and either the AS Number (TLV 512) [RFC7752] or the BGP 276 Confederation Member (TLV 517) 277 [I-D.ietf-idr-bgpls-segment-routing-epe]. However, if the BGP 278 Router-ID is known to be unique within the BGP Routing domain, it can 279 be used as the sole descriptor. 281 4.1. Node NLRI Usage and Modifications 283 The SPF capability is a new Node Attribute TLV that will be added to 284 those defined in table 7 of [RFC7752]. The new attribute TLV will 285 only be applicable when BGP is specified in the Node NLRI Protocol ID 286 field. The TBD TLV type will be defined by IANA. The new Node 287 Attribute TLV will contain a single octet SPF algorithm field: 289 0 1 2 3 290 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 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Type | Length | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | SPF Algorithm | 295 +-+-+-+-+-+-+-+-+ 297 The SPF Algorithm may take the following values: 299 1 - Normal SPF 300 2 - Strict SPF 302 When computing the SPF for a given BGP routing domain, only BGP nodes 303 advertising the SPF capability attribute will be included the 304 Shortest Path Tree (SPT). 306 4.2. Link NLRI Usage 308 The criteria for advertisement of Link NLRI are discussed in 309 Section 2. 311 Link NLRI is advertised with local and remote node descriptors as 312 described above and unique link identifiers dependent on the 313 addressing. For IPv4 links, the links local IPv4 (TLV 259) and 314 remote IPv4 (TLV 260) addresses will be used. For IPv6 links, the 315 local IPv6 (TLV 261) and remote IPv6 (TLV 262) addresses will be 316 used. For unnumbered links, the link local/remote identifiers (TLV 317 258) will be used. For links supporting having both IPv4 and IPv6 318 addresses, both sets of descriptors may be included in the same Link 319 NLRI. The link identifiers are described in table 5 of [RFC7752]. 321 The link IGP metric attribute TLV (TLV 1095) as well as any others 322 required for non-SPF purposes SHOULD be advertised. Algorithms such 323 as setting the metric inversely to the link speed as done in the OSPF 324 MIB [RFC4750] may be supported. However, this is beyond the scope of 325 this document. 327 4.3. Prefix NLRI Usage 329 Prefix NLRI is advertised with a local descriptor as described above 330 and the prefix and length used as the descriptors (TLV 265) as 331 described in [RFC7752]. The prefix metric attribute TLV (TLV 1155) 332 as well as any others required for non-SPF purposes SHOULD be 333 advertised. For loopback prefixes, the metric should be 0. For non- 334 loopback, the setting of the metric is beyond the scope of this 335 document. 337 4.4. BGP-LS Attribute Sequence-Number TLV 339 A new BGP-LS Attribute TLV to BGP-LS NLRI types is defined to assure 340 the most recent version of a given NLRI is used in the SPF 341 computation. The TBD TLV type will be defined by IANA. The new BGP- 342 LS Attribute TLV will contain an 8 octet sequence number. The usage 343 of the Sequence Number TLV is described in Section 5.1. 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Length | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Sequence Number (High-Order 32 Bits) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Sequence Number (Low-Order 32 Bits) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Sequence Number 357 The 64-bit strictly increasing sequence number is incremented for 358 every version of BGP-LS NLRI originated. BGP speakers implementing 359 this specification MUST use available mechanisms to preserve the 360 sequence number's strictly increasing property for the deployed life 361 of the BGP speaker (including cold restarts). One mechanism for 362 accomplishing this would be to use the high-order 32 bits of the 363 sequence number as a wrap/boot count that is incremented anytime the 364 BGP Router router loses its sequence number state or the low-order 32 365 bits wrap. 367 When incrementing the sequence number for each self-originated NLRI, 368 the sequence number should be treated as an unsigned 64-bit value. 369 If the lower-order 32-bit value wraps, the higher-order 32-bit value 370 should be incremented and saved in non-volatile storage. If by some 371 chance the BGP Speaker is deployed long enough that there is a 372 possibility that the 64-bit sequence number may wrap or a BGP Speaker 373 completely loses its sequence number state (e.g, the BGP speaker 374 hardware is replaced), the phase 1 decision function (see 375 Section 5.1) rules should insure convergance, albeit, not 376 immediately. 378 5. Decision Process with SPF Algorithm 380 The Decision Process described in [RFC4271] takes place in three 381 distinct phases. The Phase 1 decision function of the Decision 382 Process is responsible for calculating the degree of preference for 383 each route received from a Speaker's peer. The Phase 2 decision 384 function is invoked on completion of the Phase 1 decision function 385 and is responsible for choosing the best route out of all those 386 available for each distinct destination, and for installing each 387 chosen route into the Loc-RIB. The combination of the Phase 1 and 2 388 decision functions is also known as a Path vector algorithm. 390 When BGP-LS-SPF NLRI is received, all that is required is to 391 determine whether it is the best-path by examining the Node-ID and 392 sequence number as described in Section 5.1. If the best-path NLRI 393 had changed, it will be advertised to other BGP-LS-SPF peers. If the 394 attributes have changed (other than the sequence number), a BGP SPF 395 calculation will be scheduled. However, a changed best-path can be 396 advertised to other peer immediately and propagation of changes can 397 approach IGP convergence times. 399 The SPF based Decision process starts with selecting only those Node 400 NLRI whose SPF capability TLV matches with the local BGP speaker's 401 SPF capability TLV value. Since Link-State NLRI always contains the 402 local descriptor [RFC7752], it will only be originated by a single 403 BGP speaker in the BGP routing domain. These selected Node NLRI and 404 their Link/Prefix NLRI are used to build a directed graph during the 405 SPF computation. The best paths for BGP prefixes are installed as a 406 result of the SPF process. 408 The Phase 3 decision function of the Decision Process [RFC4271] is 409 also simplified since under normal SPF operation, a BGP speaker would 410 advertise the NLRI selected for the SPF to all BGP peers with the 411 BGP-LS/BGP-SPF AFI/SAFI. Application of policy would not be 412 prevented but would normally not be necessary. 414 5.1. Phase-1 BGP NLRI Selection 416 The rules for NLRI selection are greatly simplified from [RFC4271]. 418 1. If the NLRI is received from the BGP speaker originating the NLRI 419 (as determined by the comparing BGP Router ID in the NLRI Node 420 identifiers with the BGP speaker Router ID), then it is preferred 421 over the same NLRI from non-originators. 423 2. If the Sequence-Number TLV is present in the BGP-LS Attribute, 424 then the NLIR with the most recent, i.e., highest sequence number 425 is selected. BGP-LS NLRI with a Sequence-Number TLV will be 426 considered more recent than NLRI without a BGP-LS or a BGP-LS 427 Attribute that doesn't include the Sequence-Number TLV. 429 3. The final tie-breaker is the NLRI from the BGP Speaker with the 430 numerically largest BGP Router ID. 432 The modified Decision Process with SPF algorithm uses the metric from 433 Link and Prefix NLRI Attribute TLVs [RFC7752]. As a result, any 434 attributes that would influence the Decision process defined in 435 [RFC4271] like ORIGIN, MULTI_EXIT_DISC, and LOCAL_PREF attributes are 436 ignored by the SPF algorithm. Furthermore, the NEXT_HOP attribute 437 value is preserved and validated but otherwise ignored during the SPF 438 or best-path. 440 5.2. Dual Stack Support 442 The SPF based decision process operates on Node, Link, and Prefix 443 NLRIs that support both IPv4 and IPv6 addresses. Whether to run a 444 single SPF instance or multiple SPF instances for separate AFs is a 445 matter of a local implementation. Normally, IPv4 next-hops are 446 calculated for IPv4 prefixes and IPv6 next-hops are calculated for 447 IPv6 prefixes. However, an interesting use-case is deployment of 448 [RFC5549] where IPv6 link-local next-hops are calculated for both 449 IPv4 and IPv6 prefixes. As stated in Section 1, support for Multiple 450 Topology Routing (MTR) is an area for future study. 452 5.3. NEXT_HOP Manipulation 454 A BGP speaker that supports SPF extensions MAY interact with peers 455 that don't support SPF extensions. If the BGP Link-State address 456 family is advertised to a peer not supporting the SPF extensions 457 described herein, then the BGP speaker MUST conform to the NEXT_HOP 458 rules mentioned in [RFC4271] when announcing the Link-State address 459 family routes to those peers. 461 All BGP peers that support SPF extensions would locally compute the 462 NEXT_HOP values as result of the SPF process. As a result, the 463 NEXT_HOP attribute is always ignored on receipt. However BGP 464 speakers should set the NEXT_HOP address according to the NEXT_HOP 465 attribute rules mentioned in [RFC4271]. 467 5.4. Error Handling 469 When a BGP speaker receives a BGP Update containing a malformed SPF 470 Capability TLV in the Node NLRI BGP-LS Attribute [RFC7752], it MUST 471 ignore the received TLV and the Node NLRI and not pass it to other 472 BGP peers as specified in [RFC7606]. When discarding a Node NLRI 473 with malformed TLV, a BGP speaker SHOULD log an error for further 474 analysis. 476 6. IANA Considerations 478 This document defines a couple AFI/SAFIs for BGP LS SPF operation and 479 requests IANA to assign the BGP-LS-SPF AFI 16388 / SAFI TBD1 and the 480 BGP-LS-SPF-VPN AFI 16388 / SAFI TBD2 as described in [RFC4750]. 482 This document also defines two attribute TLV for BGP LS NLRI. We 483 request IANA to assign TLVs for the SPF capability and the Sequence 484 Number from the "BGP-LS Node Descriptor, Link Descriptor, Prefix 485 Descriptor, and Attribute TLVs" Registry. Additionally, IANA is 486 requested to create a new registry for "BGP-LS SPF Capability 487 Algorithms" for the value of the algorithm both in the BGP-LS Node 488 Attribute TLV and the BGP SPF Capability. The initial assignments 489 are: 491 +-------------+-----------------------------------+ 492 | Value(s) | Assignment Policy | 493 +-------------+-----------------------------------+ 494 | 0 | Reserved (not to be assigned) | 495 | | | 496 | 1 | SPF | 497 | | | 498 | 2 | Strict SPF | 499 | | | 500 | 3-254 | Unassigned (IETF Review) | 501 | | | 502 | 255 | Reserved (not to be assigned) | 503 +-------------+-----------------------------------+ 505 BGP-LS SPF Capability Algorithms 507 7. Security Considerations 509 This extension to BGP does not change the underlying security issues 510 inherent in the existing [RFC4724] and [RFC4271]. 512 7.1. Acknowledgements 514 The authors would like to thank .... for the review and comments. 516 7.2. Contributorss 518 In addition to the authors listed on the front page, the following 519 co-authors have contributed to the document. 521 Derek Yeung 522 Arrcus, Inc. 523 derek@arrcus.com 525 Abhay Roy 526 Cisco Systems 527 akr@cisco.com 529 Venu Venugopal 530 Cisco Systems 531 venuv@cisco.com 533 8. References 535 8.1. Normative References 537 [I-D.ietf-idr-bgpls-segment-routing-epe] 538 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 539 and M. Chen, "Segment Routing Egress Peer Engineering BGP- 540 LS Extensions", draft-ietf-idr-bgpls-segment-routing- 541 epe-00 (work in progress), June 2015. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, 546 . 548 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 549 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 550 DOI 10.17487/RFC4271, January 2006, 551 . 553 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 554 Patel, "Revised Error Handling for BGP UPDATE Messages", 555 RFC 7606, DOI 10.17487/RFC7606, August 2015, 556 . 558 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 559 S. Ray, "North-Bound Distribution of Link-State and 560 Traffic Engineering (TE) Information Using BGP", RFC 7752, 561 DOI 10.17487/RFC7752, March 2016, 562 . 564 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 565 BGP for Routing in Large-Scale Data Centers", RFC 7938, 566 DOI 10.17487/RFC7938, August 2016, 567 . 569 8.2. Information References 571 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 572 DOI 10.17487/RFC2328, April 1998, 573 . 575 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 576 Reflection: An Alternative to Full Mesh Internal BGP 577 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 578 . 580 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 581 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 582 DOI 10.17487/RFC4724, January 2007, 583 . 585 [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., 586 Coltun, R., and F. Baker, "OSPF Version 2 Management 587 Information Base", RFC 4750, DOI 10.17487/RFC4750, 588 December 2006, . 590 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 591 Application Protocol Collation Registry", RFC 4790, 592 DOI 10.17487/RFC4790, March 2007, 593 . 595 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 596 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 597 RFC 4915, DOI 10.17487/RFC4915, June 2007, 598 . 600 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 601 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 602 DOI 10.17487/RFC5286, September 2008, 603 . 605 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 606 Layer Reachability Information with an IPv6 Next Hop", 607 RFC 5549, DOI 10.17487/RFC5549, May 2009, 608 . 610 Authors' Addresses 612 Keyur Patel 613 Arrcus, Inc. 615 Email: keyur@arrcus.com 616 Acee Lindem 617 Cisco Systems 618 170 W. Tasman Drive 619 San Jose, CA 95134 620 USA 622 Email: acee@cisco.com 624 Shawn Zandi 625 Linkedin 626 222 2nd Street 627 San Francisco, CA 94105 628 USA 630 Email: szandi@linkedin.com 632 Gunter Van de Velde 633 Nokia 634 Antwerp 635 Belgium 637 Email: gunter.van_de_velde@nokia.com