idnits 2.17.1 draft-keyupate-idr-bgp-spf-03.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 date (June 19, 2017) is 2495 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: 'RFC7938' is mentioned on line 543, but not defined == Missing Reference: 'RFC2328' is mentioned on line 504, but not defined == Missing Reference: 'RFC5286' is mentioned on line 533, but not defined == Missing Reference: 'RFC4456' is mentioned on line 508, but not defined == Missing Reference: 'RFC4915' is mentioned on line 528, but not defined == Missing Reference: 'RFC5549' is mentioned on line 538, but not defined ** Obsolete undefined reference: RFC 5549 (Obsoleted by RFC 8950) == Missing Reference: 'RFC4790' is mentioned on line 523, but not defined == Missing Reference: 'RFC4750' is mentioned on line 518, but not defined == Missing Reference: 'RFC4724' is mentioned on line 513, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-12 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) 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: December 21, 2017 Cisco Systems 6 S. Zandi 7 Linkedin 8 G. Van de Velde 9 Nokia 10 June 19, 2017 12 Shortest Path Routing Extensions for BGP Protocol 13 draft-keyupate-idr-bgp-spf-03.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 December 21, 2017. 43 Copyright Notice 45 Copyright (c) 2017 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 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. BGP Shortest Path First (SPF) Motivation . . . . . . . . 3 62 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 63 2. BGP Peering Models . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. BGP Single-Hop Peering on Network Node Connections . . . 5 65 2.2. BGP Peering Between Directly Connected Network Nodes . . 5 66 2.3. BGP Peering in Route-Reflector or Controller Topology . . 5 67 3. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . . . . 6 68 4. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Node NLRI Usage and Modifications . . . . . . . . . . . . 6 70 4.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . . . 7 71 4.3. Prefix NLRI Usage . . . . . . . . . . . . . . . . . . . . 7 72 5. Decision Process with SPF Algorithm . . . . . . . . . . . . . 8 73 5.1. Phase-1 BGP NLRI Selection . . . . . . . . . . . . . . . 8 74 5.2. Dual Stack Support . . . . . . . . . . . . . . . . . . . 9 75 5.3. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 9 76 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 9 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10 80 7.2. Contributorss . . . . . . . . . . . . . . . . . . . . . . 10 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 8.2. Information References . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 Many Massively Scaled Data Centers (MSDCs) have converged on 89 simplified layer 3 routing. Furthermore, requirements for 90 operational simplicity have lead many of these MSDCs to converge on 91 BGP [RFC4271] as their single routing protocol for both their fabric 92 routing and their Data Center Interconnect (DCI) routing. 93 Requirements and procedures for using BGP are described in [RFC7938]. 94 This document describes an alternative solution which leverages BGP- 95 LS [RFC7752] and the Shortest Path First algorithm similar to 96 Internal Gateway Protocols (IGPs) such as OSPF [RFC2328]. 98 [RFC4271] defines the Decision Process that is used to select routes 99 for subsequent advertisement by applying the policies in the local 100 Policy Information Base (PIB) to the routes stored in its Adj-RIBs- 101 In. The output of the Decision Process is the set of routes that are 102 announced by a BGP speaker to its peers. These selected routes are 103 stored by a BGP speaker in the speaker's Adj-RIBs-Out according to 104 policy. 106 [RFC7752] describes a mechanism by which link-state and TE 107 information can be collected from networks and shared with external 108 components using BGP. This is achieved by defining NLRI carried 109 within BGP-LS AFI and BGP-LS SAFIs. The BGP-LS extensions defined in 110 [RFC7752] makes use of the Decision Process defined in [RFC4271]. 112 This document augments [RFC7752] by replacing its use of the existing 113 Decision Process. The BGP-LS-SPF and BGP-LS-SPF-VPN AFI/SAFI are 114 introduced to insure backward compatibility. The Phase 1 and 2 115 decision functions of the Decision Process are replaced with the 116 Shortest Path Algorithm (SPF) also known as the Dijkstra Algorithm. 117 The Phase 3 decision function is also simplified since it is no 118 longer dependent on the previous phases. This solution avails the 119 benefits of both BGP and SPF-based IGPs. These include TCP based 120 flow-control, no periodic link-state refresh, and completely 121 incremental NLRI advertisement. These advantages can reduce the 122 overhead in MSDCs where there is a high degree of Equal Cost Multi- 123 Path (ECMPs) and the topology is very stable. Additionally, using a 124 SPF-based computation can support fast convergence and the 125 computation of Loop-Free Alternatives (LFAs) [RFC5286] in the event 126 of link failures. Furthermore, a BGP based solution lends itself to 127 multiple peering models including those incorporating route- 128 reflectors [RFC4456] or controllers. 130 Support for Multiple Topology Routing (MTR) as described in [RFC4915] 131 is an area for further study dependent on deployment requirements. 133 1.1. BGP Shortest Path First (SPF) Motivation 135 Given that [RFC7938] already describes how BGP could be used as the 136 sole routing protocol in an MSDC, one might question the motivation 137 for defining an alternate BGP deployment model when a mature solution 138 exists. For both alternatives, BGP offers the operational benefits 139 of a single routing protocol. However, BGP SPF offers some unique 140 advantages above and beyond standard BGP distance-vector routing. 142 A primary advantage is that all BGP speakers in the BGP SPF routing 143 domain will have a complete view of the topology. This will allow 144 support of ECMP, IP fast-reroute (e.g., Loop-Free Alternatives), 145 Shared Risk Link Groups (SRLGs), and other routing enhancements 146 without advertisement of addition BGP paths or other extensions. In 147 short, the advantages of an IGP such as OSPF [RFC2328] are availed in 148 BGP. 150 With the simplified BGP decision process as defined in Section 5.1, 151 NLRI changes can be disseminated throughout the BGP routing domain 152 much more rapidly (equivalent to IGPs with the proper 153 implementation). 155 Another primary advantage is a potential reduction in NLRI 156 advertisement. With standard BGP distance-vector routing, a single 157 link failure may impact 100s or 1000s prefixes and result in the 158 withdrawal or re-advertisement of the attendant NLRI. With BGP SPF, 159 only the BGP speakers corresponding to the link NLRI need withdraw 160 the corresponding BGP-LS Link NLRI. This advantage will contribute 161 to both faster convergence and better scaling. 163 With controller and route-reflector peering models, BGP SPF 164 advertisement and distributed computation require a minimal number of 165 sessions and copies of the NLRI since only the latest verion of the 166 NLRI from the originator is required. Given that verification of the 167 adjacencies is done outside of BGP (see Section 2), each BGP speaker 168 will only need as many sessions and copies of the NLRI as required 169 for redundancy (e.g., one for SPF computation and another for 170 backup). Functions such as Optimized Route Reflection (ORR) are 171 supported without extension by virture of the primary advantages. 172 Additionally, a controller could inject topology that is learned 173 outside the BGP routing domain. 175 Given that controllers are already consuming BGP-LS NLRI [RFC7752], 176 reusing for the BGP-LS SPF leverages the existing controller 177 implementations. 179 Another potential advantage of BGP SPF is that both IPv6 and IPv4 can 180 be supported in the same address family using the same topology. 181 Although not described in this version of the document, multi- 182 topology extensions can be used to support separate IPv4, IPv6, 183 unicast, and multicast topologies while sharing the same NLRI. 185 Finally, the BGP SPF topology can be used as an underlay for other 186 BGP address families (using the existing model) and realize all the 187 above advantages. A simplified peering model using IPv6 link-local 188 addresses as next-hops can be deployed similar to [RFC5549]. 190 1.2. Requirements Language 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 193 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 194 document are to be interpreted as described in RFC 2119 [RFC2119]. 196 2. BGP Peering Models 198 Depending on the requirements, scaling, and capabilities of the BGP 199 speakers, various peering models are supported. The only requirement 200 is that all BGP speakers in the BGP SPF routing domain receive link- 201 state NLRI on a timely basis, run an SPF calculation, and update 202 their data plane appropriately. The content of the Link NLRI is 203 described in Section 4.2. 205 2.1. BGP Single-Hop Peering on Network Node Connections 207 The simplest peering model is the one described in section 5.2.1 of 208 [RFC7938]. In this model, EBGP single-hop sessions are established 209 over direct point-to-point links interconnecting the network nodes. 210 For the purposes of BGP SPF, Link NLRI is only advertised if a 211 single-hop BGP session has been established and the Link-State/SPF 212 adddress family capability has been exchanged [RFC4790] on the 213 corresponding session. If the session goes down, the NLRI will be 214 withdrawn. 216 2.2. BGP Peering Between Directly Connected Network Nodes 218 In this model, BGP speakers peer with all directly connected network 219 nodes but the sessions may be multi-hop and the direct connection 220 discovery and liveliness detection for those connections are 221 independent of the BGP protocol. How this is accomplished is outside 222 the scope of this document. Consequently, there will be a single 223 session even if there are multiple direct connections between BGP 224 speakers. For the purposes of BGP SPF, Link NLRI is advertised as 225 long as a BGP session has been established, the Link-State/SPF 226 address family capability has been exchanged [RFC4790] and the 227 corresponding link is up and considered operational. 229 2.3. BGP Peering in Route-Reflector or Controller Topology 231 In this model, BGP speakers peer solely with one or more Route 232 Reflectors [RFC4456] or controllers. As in the previous model, 233 direct connection discovery and liveliness detection for those 234 connections are done outside the BGP protocol. For the purposes of 235 BGP SPF, Link NLRI is advertised as long as the corresponding link is 236 up and considered operational. 238 3. BGP-LS Shortest Path Routing (SPF) SAFI 240 In order to replace the Phase 1 and 2 decision functions of the 241 existing Decision Process with an SPF-based Decision Process and 242 streamline the Phase 3 decision functions in a backward compatible 243 manner, this draft introduces a couple AFI/SAFIs for BGP LS SPF 244 operation. The BGP-LS-SPF (AF 16388 / SAFI TBD1) and BGP-LS-SPF-VPN 245 (AFI 16388 / SAFI TBD2) [RFC4790] are allocated by IANA as specified 246 in the Section 6. 248 4. Extensions to BGP-LS 250 [RFC7752] describes a mechanism by which link-state and TE 251 information can be collected from networks and shared with external 252 components using BGP protocol. It contains two parts: definition of 253 a new BGP NLRI that describes links, nodes, and prefixes comprising 254 IGP link-state information and definition of a new BGP path attribute 255 (BGP-LS attribute) that carries link, node, and prefix properties and 256 attributes, such as the link and prefix metric or auxiliary Router- 257 IDs of nodes, etc. 259 The BGP protocol will be used in the Protocol-ID field specified in 260 table 1 of [I-D.ietf-idr-bgpls-segment-routing-epe]. The local and 261 remote node descriptors for all NLRI will be the BGP Router-ID (TLV 262 516) and either the AS Number (TLV 512) [RFC7752] or the BGP 263 Confederation Member (TLV 517) 264 [I-D.ietf-idr-bgpls-segment-routing-epe]. However, if the BGP 265 Router-ID is known to be unique within the BGP Routing domain, it can 266 be used as the sole descriptor. 268 4.1. Node NLRI Usage and Modifications 270 The SPF capability is a new Node Attribute TLV that will be added to 271 those defined in table 7 of [RFC7752]. The new attribute TLV will 272 only be applicable when BGP is specified in the Node NLRI Protocol ID 273 field. The TBD TLV type will be defined by IANA. The new Node 274 Attribute TLV will contain a single octet SPF algorithm field: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type | Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | SPF Algorithm | 282 +-+-+-+-+-+-+-+-+ 284 The SPF Algorithm may take the following values: 286 1 - Normal SPF 287 2 - Strict SPF 289 When computing the SPF for a given BGP routing domain, only BGP nodes 290 advertising the SPF capability attribute will be included the 291 Shortest Path Tree (SPT). 293 4.2. Link NLRI Usage 295 The criteria for advertisement of Link NLRI are discussed in 296 Section 2. 298 Link NLRI is advertised with local and remote node descriptors as 299 described above and unique link identifiers dependent on the 300 addressing. For IPv4 links, the links local IPv4 (TLV 259) and 301 remote IPv4 (TLV 260) addresses will be used. For IPv6 links, the 302 local IPv6 (TLV 261) and remote IPv6 (TLV 262) addresses will be 303 used. For unnumbered links, the link local/remote identifiers (TLV 304 258) will be used. For links supporting having both IPv4 and IPv6 305 addresses, both sets of descriptors may be included in the same Link 306 NLRI. The link identifiers are described in table 5 of [RFC7752]. 308 The link IGP metric attribute TLV (TLV 1095) as well as any others 309 required for non-SPF purposes SHOULD be advertised. Algorithms such 310 as setting the metric inversely to the link speed as done in the OSPF 311 MIB [RFC4750] may be supported. However, this is beyond the scope of 312 this document. 314 4.3. Prefix NLRI Usage 316 Prefix NLRI is advertised with a local descriptor as described above 317 and the prefix and length used as the descriptors (TLV 265) as 318 described in [RFC7752]. The prefix metric attribute TLV (TLV 1155) 319 as well as any others required for non-SPF purposes SHOULD be 320 advertised. For loopback prefixes, the metric should be 0. For non- 321 loopback, the setting of the metric is beyond the scope of this 322 document. 324 5. Decision Process with SPF Algorithm 326 The Decision Process described in [RFC4271] takes place in three 327 distinct phases. The Phase 1 decision function of the Decision 328 Process is responsible for calculating the degree of preference for 329 each route received from a Speaker's peer. The Phase 2 decision 330 function is invoked on completion of the Phase 1 decision function 331 and is responsible for choosing the best route out of all those 332 available for each distinct destination, and for installing each 333 chosen route into the Loc-RIB. The combination of the Phase 1 and 2 334 decision functions is also known as a Path vector algorithm. 336 When BGP-LS-SPF NLRI is received, all that is required is to 337 determine whether it is the best-path by examining the Node-ID as 338 described in Section 5.1. If the best-path NLRI had changed, it will 339 be advertised to other BGP-LS-SPF peers. If the attributes have 340 changed a BGP SPF calculation will be scheduled. However, a changed 341 best-path can be advertised to other peer immediately and propagation 342 of changes can approach IGP convergence times. 344 The SPF based Decision process starts with selecting only those Node 345 NLRI whose SPF capability TLV matches with the local BGP speaker's 346 SPF capability TLV value. Since Link-State NLRI always contains the 347 local descriptor [RFC7752], it will only be originated by a single 348 BGP speaker in the BGP routing domain. These selected Node NLRI and 349 their Link/Prefix NLRI are used to build a directed graph during the 350 SPF computation. The best paths for BGP prefixes are installed as a 351 result of the SPF process. 353 The Phase 3 decision function of the Decision Process [RFC4271] is 354 also simplified since under normal SPF operation, a BGP speaker would 355 advertise the NLRI selected for the SPF to all BGP peers with the 356 BGP-LS/BGP-SPF AFI/SAFI. Application of policy would not be 357 prevented but would normally not be necessary. 359 5.1. Phase-1 BGP NLRI Selection 361 The rules for NLRI selection are greatly simplified from [RFC4271]. 363 1. If the NLRI is received from the BGP speaker originating the NLRI 364 (as determined by the comparing BGP Router ID in the NLRI Node 365 identifiers with the BGP speaker Router ID), then it is preferred 366 over the same NLRI from non-originators. 368 2. The final tie-breaker is the NLRI from the BGP Speaker with the 369 numerically largest BGP Router ID. 371 The modified Decision Process with SPF algorithm uses the metric from 372 Link and Prefix NLRI Attribute TLVs [RFC7752]. As a result, any 373 attributes that would influence the Decision process defined in 374 [RFC4271] like ORIGIN, MULTI_EXIT_DISC, and LOCAL_PREF attributes are 375 ignored by the SPF algorithm. Furthermore, the NEXT_HOP attribute 376 value is preserved and validated but otherwise ignored during the SPF 377 or best-path. 379 5.2. Dual Stack Support 381 The SPF based decision process operates on Node, Link, and Prefix 382 NLRIs that support both IPv4 and IPv6 addresses. Whether to run a 383 single SPF instance or multiple SPF instances for separate AFs is a 384 matter of a local implementation. Normally, IPv4 next-hops are 385 calculated for IPv4 prefixes and IPv6 next-hops are calculated for 386 IPv6 prefixes. However, an interesting use-case is deployment of 387 [RFC5549] where IPv6 link-local next-hops are calculated for both 388 IPv4 and IPv6 prefixes. As stated in Section 1, support for Multiple 389 Topology Routing (MTR) is an area for future study. 391 5.3. NEXT_HOP Manipulation 393 A BGP speaker that supports SPF extensions MAY interact with peers 394 that don't support SPF extensions. If the BGP Link-State address 395 family is advertised to a peer not supporting the SPF extensions 396 described herein, then the BGP speaker MUST conform to the NEXT_HOP 397 rules mentioned in [RFC4271] when announcing the Link-State address 398 family routes to those peers. 400 All BGP peers that support SPF extensions would locally compute the 401 NEXT_HOP values as result of the SPF process. As a result, the 402 NEXT_HOP attribute is always ignored on receipt. However BGP 403 speakers should set the NEXT_HOP address according to the NEXT_HOP 404 attribute rules mentioned in [RFC4271]. 406 5.4. Error Handling 408 When a BGP speaker receives a BGP Update containing a malformed SPF 409 Capability TLV in the Node NLRI BGP-LS Attribute [RFC7752], it MUST 410 ignore the received TLV and the Node NLRI and not pass it to other 411 BGP peers as specified in [RFC7606]. When discarding a Node NLRI 412 with malformed TLV, a BGP speaker SHOULD log an error for further 413 analysis. 415 6. IANA Considerations 417 This document defines a couple AFI/SAFIs for BGP LS SPF operation and 418 requests IANA to assign the BGP-LS-SPF AFI 16388 / SAFI TBD1 and the 419 BGP-LS-SPF-VPN AFI 16388 / SAFI TBD2 as described in [RFC4750]. 421 This document also defines two attribute TLV for BGP LS NLRI. We 422 request IANA to assign TLVs for the SPF capability from the "BGP-LS 423 Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 424 TLVs" Registry. Additionally, IANA is requested to create a new 425 registry for "BGP-LS SPF Capability Algorithms" for the value of the 426 algorithm both in the BGP-LS Node Attribute TLV and the BGP SPF 427 Capability. The initial assignments are: 429 +-------------+-----------------------------------+ 430 | Value(s) | Assignment Policy | 431 +-------------+-----------------------------------+ 432 | 0 | Reserved (not to be assigned) | 433 | | | 434 | 1 | SPF | 435 | | | 436 | 2 | Strict SPF | 437 | | | 438 | 3-254 | Unassigned (IETF Review) | 439 | | | 440 | 255 | Reserved (not to be assigned) | 441 +-------------+-----------------------------------+ 443 BGP-LS SPF Capability Algorithms 445 7. Security Considerations 447 This extension to BGP does not change the underlying security issues 448 inherent in the existing [RFC4724] and [RFC4271]. 450 7.1. Acknowledgements 452 The authors would like to thank .... for the review and comments. 454 7.2. Contributorss 456 In addition to the authors listed on the front page, the following 457 co-authors have contributed to the document. 459 Derek Yeung 460 Arrcus, Inc. 461 derek@arrcus.com 463 Abhay Roy 464 Cisco Systems 465 akr@cisco.com 467 Venu Venugopal 468 Cisco Systems 469 venuv@cisco.com 471 8. References 473 8.1. Normative References 475 [I-D.ietf-idr-bgpls-segment-routing-epe] 476 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 477 Dong, "BGP-LS extensions for Segment Routing BGP Egress 478 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 479 epe-12 (work in progress), April 2017. 481 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 482 Requirement Levels", BCP 14, RFC 2119, 483 DOI 10.17487/RFC2119, March 1997, 484 . 486 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 487 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 488 DOI 10.17487/RFC4271, January 2006, 489 . 491 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 492 Patel, "Revised Error Handling for BGP UPDATE Messages", 493 RFC 7606, DOI 10.17487/RFC7606, August 2015, 494 . 496 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 497 S. Ray, "North-Bound Distribution of Link-State and 498 Traffic Engineering (TE) Information Using BGP", RFC 7752, 499 DOI 10.17487/RFC7752, March 2016, 500 . 502 8.2. Information References 504 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 505 DOI 10.17487/RFC2328, April 1998, 506 . 508 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 509 Reflection: An Alternative to Full Mesh Internal BGP 510 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 511 . 513 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 514 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 515 DOI 10.17487/RFC4724, January 2007, 516 . 518 [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., 519 Coltun, R., and F. Baker, "OSPF Version 2 Management 520 Information Base", RFC 4750, DOI 10.17487/RFC4750, 521 December 2006, . 523 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 524 Application Protocol Collation Registry", RFC 4790, 525 DOI 10.17487/RFC4790, March 2007, 526 . 528 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 529 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 530 RFC 4915, DOI 10.17487/RFC4915, June 2007, 531 . 533 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 534 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 535 DOI 10.17487/RFC5286, September 2008, 536 . 538 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 539 Layer Reachability Information with an IPv6 Next Hop", 540 RFC 5549, DOI 10.17487/RFC5549, May 2009, 541 . 543 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 544 BGP for Routing in Large-Scale Data Centers", RFC 7938, 545 DOI 10.17487/RFC7938, August 2016, 546 . 548 Authors' Addresses 550 Keyur Patel 551 Arrcus, Inc. 553 Email: keyur@arrcus.com 554 Acee Lindem 555 Cisco Systems 556 170 W. Tasman Drive 557 San Jose, CA 95134 558 USA 560 Email: acee@cisco.com 562 Shawn Zandi 563 Linkedin 564 222 2nd Street 565 San Francisco, CA 94105 566 USA 568 Email: szandi@linkedin.com 570 Gunter Van de Velde 571 Nokia 572 Antwerp 573 Belgium 575 Email: gunter.van_de_velde@nokia.com