idnits 2.17.1 draft-keyupate-idr-bgp-spf-02.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 (December 21, 2016) is 2654 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 523, but not defined == Missing Reference: 'RFC5286' is mentioned on line 552, but not defined == Missing Reference: 'RFC4456' is mentioned on line 527, but not defined == Missing Reference: 'RFC4915' is mentioned on line 547, but not defined == Missing Reference: 'RFC5549' is mentioned on line 557, but not defined ** Obsolete undefined reference: RFC 5549 (Obsoleted by RFC 8950) == Missing Reference: 'RFC4790' is mentioned on line 542, but not defined == Missing Reference: 'RFC4750' is mentioned on line 537, but not defined == Missing Reference: 'RFC4724' is mentioned on line 532, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-00 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) ** Downref: Normative reference to an Informational RFC: RFC 7938 Summary: 3 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: June 24, 2017 Cisco Systems 6 S. Zandi 7 Linkedin 8 G. Van de Velde 9 Nokia 10 December 21, 2016 12 Shortest Path Routing Extensions for BGP Protocol 13 draft-keyupate-idr-bgp-spf-02.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 June 24, 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 5. Decision Process with SPF Algorithm . . . . . . . . . . . . . 8 85 5.1. Phase-1 BGP NLRI Selection . . . . . . . . . . . . . . . 8 86 5.2. Dual Stack Support . . . . . . . . . . . . . . . . . . . 9 87 5.3. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 9 88 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 9 89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 91 7.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10 92 7.2. Contributorss . . . . . . . . . . . . . . . . . . . . . . 10 93 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 95 8.2. Information References . . . . . . . . . . . . . . . . . 12 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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. 195 Although not described in this version of the document, multi- 196 topology extensions can be used to support separate IPv4, IPv6, 197 unicast, and multicast topologies while sharing the same NLRI. 199 Finally, the BGP SPF topology can be used as an underlay for other 200 BGP address families (using the existing model) and realize all the 201 above advantages. A simplified peering model using IPv6 link-local 202 addresses as next-hops can be deployed similar to [RFC5549]. 204 1.2. Requirements Language 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in RFC 2119 [RFC2119]. 210 2. BGP Peering Models 212 Depending on the requirements, scaling, and capabilities of the BGP 213 speakers, various peering models are supported. The only requirement 214 is that all BGP speakers in the BGP SPF routing domain receive link- 215 state NLRI on a timely basis, run an SPF calculation, and update 216 their data plane appropriately. The content of the Link NLRI is 217 described in Section 4.2. 219 2.1. BGP Single-Hop Peering on Network Node Connections 221 The simplest peering model is the one described in section 5.2.1 of 222 [RFC7938]. In this model, EBGP single-hop sessions are established 223 over direct point-to-point links interconnecting the network nodes. 224 For the purposes of BGP SPF, Link NLRI is only advertised if a 225 single-hop BGP session has been established and the Link-State/SPF 226 adddress family capability has been exchanged [RFC4790] on the 227 corresponding session. If the session goes down, the NLRI will be 228 withdrawn. 230 2.2. BGP Peering Between Directly Connected Network Nodes 232 In this model, BGP speakers peer with all directly connected network 233 nodes but the sessions may be multi-hop and the direct connection 234 discovery and liveliness detection for those connections are 235 independent of the BGP protocol. How this is accomplished is outside 236 the scope of this document. Consequently, there will be a single 237 session even if there are multiple direct connections between BGP 238 speakers. For the purposes of BGP SPF, Link NLRI is advertised as 239 long as a BGP session has been established, the Link-State/SPF 240 address family capability has been exchanged [RFC4790] and the 241 corresponding link is up and considered operational. 243 2.3. BGP Peering in Route-Reflector or Controller Topology 245 In this model, BGP speakers peer solely with one or more Route 246 Reflectors [RFC4456] or controllers. As in the previous model, 247 direct connection discovery and liveliness detection for those 248 connections are done outside the BGP protocol. For the purposes of 249 BGP SPF, Link NLRI is advertised as long as the corresponding link is 250 up and considered operational. 252 3. BGP-LS Shortest Path Routing (SPF) SAFI 254 In order to replace the Phase 1 and 2 decision functions of the 255 existing Decision Process with an SPF-based Decision Process and 256 streamline the Phase 3 decision functions in a backward compatible 257 manner, this draft introduces a couple AFI/SAFIs for BGP LS SPF 258 operation. The BGP-LS-SPF (AF 16388 / SAFI TBD1) and BGP-LS-SPF-VPN 259 (AFI 16388 / SAFI TBD2) [RFC4790] are allocated by IANA as specified 260 in the Section 6. 262 4. Extensions to BGP-LS 264 [RFC7752] describes a mechanism by which link-state and TE 265 information can be collected from networks and shared with external 266 components using BGP protocol. It contains two parts: definition of 267 a new BGP NLRI that describes links, nodes, and prefixes comprising 268 IGP link-state information and definition of a new BGP path attribute 269 (BGP-LS attribute) that carries link, node, and prefix properties and 270 attributes, such as the link and prefix metric or auxiliary Router- 271 IDs of nodes, etc. 273 The BGP protocol will be used in the Protocol-ID field specified in 274 table 1 of [I-D.ietf-idr-bgpls-segment-routing-epe]. The local and 275 remote node descriptors for all NLRI will be the BGP Router-ID (TLV 276 516) and either the AS Number (TLV 512) [RFC7752] or the BGP 277 Confederation Member (TLV 517) 278 [I-D.ietf-idr-bgpls-segment-routing-epe]. However, if the BGP 279 Router-ID is known to be unique within the BGP Routing domain, it can 280 be used as the sole descriptor. 282 4.1. Node NLRI Usage and Modifications 284 The SPF capability is a new Node Attribute TLV that will be added to 285 those defined in table 7 of [RFC7752]. The new attribute TLV will 286 only be applicable when BGP is specified in the Node NLRI Protocol ID 287 field. The TBD TLV type will be defined by IANA. The new Node 288 Attribute TLV will contain a single octet SPF algorithm field: 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | SPF Algorithm | 296 +-+-+-+-+-+-+-+-+ 298 The SPF Algorithm may take the following values: 300 1 - Normal SPF 301 2 - Strict SPF 303 When computing the SPF for a given BGP routing domain, only BGP nodes 304 advertising the SPF capability attribute will be included the 305 Shortest Path Tree (SPT). 307 4.2. Link NLRI Usage 309 The criteria for advertisement of Link NLRI are discussed in 310 Section 2. 312 Link NLRI is advertised with local and remote node descriptors as 313 described above and unique link identifiers dependent on the 314 addressing. For IPv4 links, the links local IPv4 (TLV 259) and 315 remote IPv4 (TLV 260) addresses will be used. For IPv6 links, the 316 local IPv6 (TLV 261) and remote IPv6 (TLV 262) addresses will be 317 used. For unnumbered links, the link local/remote identifiers (TLV 318 258) will be used. For links supporting having both IPv4 and IPv6 319 addresses, both sets of descriptors may be included in the same Link 320 NLRI. The link identifiers are described in table 5 of [RFC7752]. 322 The link IGP metric attribute TLV (TLV 1095) as well as any others 323 required for non-SPF purposes SHOULD be advertised. Algorithms such 324 as setting the metric inversely to the link speed as done in the OSPF 325 MIB [RFC4750] may be supported. However, this is beyond the scope of 326 this document. 328 4.3. Prefix NLRI Usage 330 Prefix NLRI is advertised with a local descriptor as described above 331 and the prefix and length used as the descriptors (TLV 265) as 332 described in [RFC7752]. The prefix metric attribute TLV (TLV 1155) 333 as well as any others required for non-SPF purposes SHOULD be 334 advertised. For loopback prefixes, the metric should be 0. For non- 335 loopback, the setting of the metric is beyond the scope of this 336 document. 338 5. Decision Process with SPF Algorithm 340 The Decision Process described in [RFC4271] takes place in three 341 distinct phases. The Phase 1 decision function of the Decision 342 Process is responsible for calculating the degree of preference for 343 each route received from a Speaker's peer. The Phase 2 decision 344 function is invoked on completion of the Phase 1 decision function 345 and is responsible for choosing the best route out of all those 346 available for each distinct destination, and for installing each 347 chosen route into the Loc-RIB. The combination of the Phase 1 and 2 348 decision functions is also known as a Path vector algorithm. 350 When BGP-LS-SPF NLRI is received, all that is required is to 351 determine whether it is the best-path by examining the Node-ID as 352 described in Section 5.1. If the best-path NLRI had changed, it will 353 be advertised to other BGP-LS-SPF peers. If the attributes have 354 changed a BGP SPF calculation will be scheduled. However, a changed 355 best-path can be advertised to other peer immediately and propagation 356 of changes can approach IGP convergence times. 358 The SPF based Decision process starts with selecting only those Node 359 NLRI whose SPF capability TLV matches with the local BGP speaker's 360 SPF capability TLV value. Since Link-State NLRI always contains the 361 local descriptor [RFC7752], it will only be originated by a single 362 BGP speaker in the BGP routing domain. These selected Node NLRI and 363 their Link/Prefix NLRI are used to build a directed graph during the 364 SPF computation. The best paths for BGP prefixes are installed as a 365 result of the SPF process. 367 The Phase 3 decision function of the Decision Process [RFC4271] is 368 also simplified since under normal SPF operation, a BGP speaker would 369 advertise the NLRI selected for the SPF to all BGP peers with the 370 BGP-LS/BGP-SPF AFI/SAFI. Application of policy would not be 371 prevented but would normally not be necessary. 373 5.1. Phase-1 BGP NLRI Selection 375 The rules for NLRI selection are greatly simplified from [RFC4271]. 377 1. If the NLRI is received from the BGP speaker originating the NLRI 378 (as determined by the comparing BGP Router ID in the NLRI Node 379 identifiers with the BGP speaker Router ID), then it is preferred 380 over the same NLRI from non-originators. 382 2. The final tie-breaker is the NLRI from the BGP Speaker with the 383 numerically largest BGP Router ID. 385 The modified Decision Process with SPF algorithm uses the metric from 386 Link and Prefix NLRI Attribute TLVs [RFC7752]. As a result, any 387 attributes that would influence the Decision process defined in 388 [RFC4271] like ORIGIN, MULTI_EXIT_DISC, and LOCAL_PREF attributes are 389 ignored by the SPF algorithm. Furthermore, the NEXT_HOP attribute 390 value is preserved and validated but otherwise ignored during the SPF 391 or best-path. 393 5.2. Dual Stack Support 395 The SPF based decision process operates on Node, Link, and Prefix 396 NLRIs that support both IPv4 and IPv6 addresses. Whether to run a 397 single SPF instance or multiple SPF instances for separate AFs is a 398 matter of a local implementation. Normally, IPv4 next-hops are 399 calculated for IPv4 prefixes and IPv6 next-hops are calculated for 400 IPv6 prefixes. However, an interesting use-case is deployment of 401 [RFC5549] where IPv6 link-local next-hops are calculated for both 402 IPv4 and IPv6 prefixes. As stated in Section 1, support for Multiple 403 Topology Routing (MTR) is an area for future study. 405 5.3. NEXT_HOP Manipulation 407 A BGP speaker that supports SPF extensions MAY interact with peers 408 that don't support SPF extensions. If the BGP Link-State address 409 family is advertised to a peer not supporting the SPF extensions 410 described herein, then the BGP speaker MUST conform to the NEXT_HOP 411 rules mentioned in [RFC4271] when announcing the Link-State address 412 family routes to those peers. 414 All BGP peers that support SPF extensions would locally compute the 415 NEXT_HOP values as result of the SPF process. As a result, the 416 NEXT_HOP attribute is always ignored on receipt. However BGP 417 speakers should set the NEXT_HOP address according to the NEXT_HOP 418 attribute rules mentioned in [RFC4271]. 420 5.4. Error Handling 422 When a BGP speaker receives a BGP Update containing a malformed SPF 423 Capability TLV in the Node NLRI BGP-LS Attribute [RFC7752], it MUST 424 ignore the received TLV and the Node NLRI and not pass it to other 425 BGP peers as specified in [RFC7606]. When discarding a Node NLRI 426 with malformed TLV, a BGP speaker SHOULD log an error for further 427 analysis. 429 6. IANA Considerations 431 This document defines a couple AFI/SAFIs for BGP LS SPF operation and 432 requests IANA to assign the BGP-LS-SPF AFI 16388 / SAFI TBD1 and the 433 BGP-LS-SPF-VPN AFI 16388 / SAFI TBD2 as described in [RFC4750]. 435 This document also defines two attribute TLV for BGP LS NLRI. We 436 request IANA to assign TLVs for the SPF capability from the "BGP-LS 437 Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 438 TLVs" Registry. Additionally, IANA is requested to create a new 439 registry for "BGP-LS SPF Capability Algorithms" for the value of the 440 algorithm both in the BGP-LS Node Attribute TLV and the BGP SPF 441 Capability. The initial assignments are: 443 +-------------+-----------------------------------+ 444 | Value(s) | Assignment Policy | 445 +-------------+-----------------------------------+ 446 | 0 | Reserved (not to be assigned) | 447 | | | 448 | 1 | SPF | 449 | | | 450 | 2 | Strict SPF | 451 | | | 452 | 3-254 | Unassigned (IETF Review) | 453 | | | 454 | 255 | Reserved (not to be assigned) | 455 +-------------+-----------------------------------+ 457 BGP-LS SPF Capability Algorithms 459 7. Security Considerations 461 This extension to BGP does not change the underlying security issues 462 inherent in the existing [RFC4724] and [RFC4271]. 464 7.1. Acknowledgements 466 The authors would like to thank .... for the review and comments. 468 7.2. Contributorss 470 In addition to the authors listed on the front page, the following 471 co-authors have contributed to the document. 473 Derek Yeung 474 Arrcus, Inc. 475 derek@arrcus.com 477 Abhay Roy 478 Cisco Systems 479 akr@cisco.com 481 Venu Venugopal 482 Cisco Systems 483 venuv@cisco.com 485 8. References 487 8.1. Normative References 489 [I-D.ietf-idr-bgpls-segment-routing-epe] 490 Previdi, S., Filsfils, C., Ray, S., Patel, K., Dong, J., 491 and M. Chen, "Segment Routing Egress Peer Engineering BGP- 492 LS Extensions", draft-ietf-idr-bgpls-segment-routing- 493 epe-00 (work in progress), June 2015. 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 501 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 502 DOI 10.17487/RFC4271, January 2006, 503 . 505 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 506 Patel, "Revised Error Handling for BGP UPDATE Messages", 507 RFC 7606, DOI 10.17487/RFC7606, August 2015, 508 . 510 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 511 S. Ray, "North-Bound Distribution of Link-State and 512 Traffic Engineering (TE) Information Using BGP", RFC 7752, 513 DOI 10.17487/RFC7752, March 2016, 514 . 516 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 517 BGP for Routing in Large-Scale Data Centers", RFC 7938, 518 DOI 10.17487/RFC7938, August 2016, 519 . 521 8.2. Information References 523 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 524 DOI 10.17487/RFC2328, April 1998, 525 . 527 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 528 Reflection: An Alternative to Full Mesh Internal BGP 529 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 530 . 532 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 533 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 534 DOI 10.17487/RFC4724, January 2007, 535 . 537 [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., 538 Coltun, R., and F. Baker, "OSPF Version 2 Management 539 Information Base", RFC 4750, DOI 10.17487/RFC4750, 540 December 2006, . 542 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 543 Application Protocol Collation Registry", RFC 4790, 544 DOI 10.17487/RFC4790, March 2007, 545 . 547 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 548 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 549 RFC 4915, DOI 10.17487/RFC4915, June 2007, 550 . 552 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 553 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 554 DOI 10.17487/RFC5286, September 2008, 555 . 557 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 558 Layer Reachability Information with an IPv6 Next Hop", 559 RFC 5549, DOI 10.17487/RFC5549, May 2009, 560 . 562 Authors' Addresses 564 Keyur Patel 565 Arrcus, Inc. 567 Email: keyur@arrcus.com 568 Acee Lindem 569 Cisco Systems 570 170 W. Tasman Drive 571 San Jose, CA 95134 572 USA 574 Email: acee@cisco.com 576 Shawn Zandi 577 Linkedin 578 222 2nd Street 579 San Francisco, CA 94105 580 USA 582 Email: szandi@linkedin.com 584 Gunter Van de Velde 585 Nokia 586 Antwerp 587 Belgium 589 Email: gunter.van_de_velde@nokia.com