idnits 2.17.1 draft-ietf-lsvr-bgp-spf-04.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 20, 2018) is 1948 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 924, but not defined == Missing Reference: 'RFC5286' is mentioned on line 958, but not defined == Missing Reference: 'RFC4456' is mentioned on line 928, but not defined == Missing Reference: 'RFC4915' is mentioned on line 953, but not defined == Missing Reference: 'RFC5549' is mentioned on line 963, but not defined ** Obsolete undefined reference: RFC 5549 (Obsoleted by RFC 8950) == Missing Reference: 'RFC4790' is mentioned on line 948, but not defined == Missing Reference: 'RFC5880' is mentioned on line 968, but not defined == Missing Reference: 'I-D.ietf-lsvr-applicability' is mentioned on line 918, but not defined == Missing Reference: 'RFC4760' is mentioned on line 943, but not defined == Missing Reference: 'RFC4750' is mentioned on line 938, but not defined == Missing Reference: 'RFC4724' is mentioned on line 933, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-idr-bgpls-segment-routing-epe-15 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) ** Downref: Normative reference to an Informational RFC: RFC 7938 Summary: 3 errors (**), 0 flaws (~~), 14 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 23, 2019 Cisco Systems 6 S. Zandi 7 Linkedin 8 W. Henderickx 9 Nokia 10 December 20, 2018 12 Shortest Path Routing Extensions for BGP Protocol 13 draft-ietf-lsvr-bgp-spf-04.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 (SPF) 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 23, 2019. 43 Copyright Notice 45 Copyright (c) 2018 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 . . 6 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 . . . . . . . . . . . . . . . . . . . . 7 81 4.1. Node NLRI Usage and Modifications . . . . . . . . . . . . 7 82 4.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . . . 8 83 4.2.1. BGP-LS Link NLRI Attribute Prefix-Length TLVs . . . . 9 84 4.2.2. BGP-LS Link NLRI Attribute BGP SPF Status TLV . . . . 9 85 4.2.3. BGP-LS Prefix NLRI Attribute SPF Status TLV . . . . . 10 86 4.3. Prefix NLRI Usage . . . . . . . . . . . . . . . . . . . . 10 87 4.4. BGP-LS Attribute Sequence-Number TLV . . . . . . . . . . 10 88 5. Decision Process with SPF Algorithm . . . . . . . . . . . . . 11 89 5.1. Phase-1 BGP NLRI Selection . . . . . . . . . . . . . . . 12 90 5.2. Dual Stack Support . . . . . . . . . . . . . . . . . . . 13 91 5.3. SPF Calculation based on BGP-LS NLRI . . . . . . . . . . 13 92 5.4. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 16 93 5.5. IPv4/IPv6 Unicast Address Family Interaction . . . . . . 16 94 5.6. NLRI Advertisement and Convergence . . . . . . . . . . . 17 95 5.6.1. Link/Prefix Failure Convergence . . . . . . . . . . . 17 96 5.6.2. Node Failure Convergence . . . . . . . . . . . . . . 17 97 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 18 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 8. Management Considerations . . . . . . . . . . . . . . . . . . 18 101 8.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 18 102 8.2. Operational Data . . . . . . . . . . . . . . . . . . . . 18 103 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 104 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 107 11.2. Information References . . . . . . . . . . . . . . . . . 20 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 110 1. Introduction 112 Many Massively Scaled Data Centers (MSDCs) have converged on 113 simplified layer 3 routing. Furthermore, requirements for 114 operational simplicity have lead many of these MSDCs to converge on 115 BGP [RFC4271] as their single routing protocol for both their fabric 116 routing and their Data Center Interconnect (DCI) routing. 117 Requirements and procedures for using BGP are described in [RFC7938]. 118 This document describes an alternative solution which leverages BGP- 119 LS [RFC7752] and the Shortest Path First algorithm similar to 120 Internal Gateway Protocols (IGPs) such as OSPF [RFC2328]. 122 [RFC4271] defines the Decision Process that is used to select routes 123 for subsequent advertisement by applying the policies in the local 124 Policy Information Base (PIB) to the routes stored in its Adj-RIBs- 125 In. The output of the Decision Process is the set of routes that are 126 announced by a BGP speaker to its peers. These selected routes are 127 stored by a BGP speaker in the speaker's Adj-RIBs-Out according to 128 policy. 130 [RFC7752] describes a mechanism by which link-state and TE 131 information can be collected from networks and shared with external 132 components using BGP. This is achieved by defining NLRI advertised 133 within the BGP-LS/BGP-LS-SPF AFI/SAFI. The BGP-LS extensions defined 134 in [RFC7752] makes use of the Decision Process defined in [RFC4271]. 136 This document augments [RFC7752] by replacing its use of the existing 137 Decision Process. Rather than reusing the BGP-LS SAFI, the BGP-LS- 138 SPF SAFI is introduced to insure backward compatibility. The Phase 1 139 and 2 decision functions of the Decision Process are replaced with 140 the Shortest Path First (SPF) algorithm also known as the Dijkstra 141 algorithm. The Phase 3 decision function is also simplified since it 142 is no longer dependent on the previous phases. This solution avails 143 the benefits of both BGP and SPF-based IGPs. These include TCP based 144 flow-control, no periodic link-state refresh, and completely 145 incremental NLRI advertisement. These advantages can reduce the 146 overhead in MSDCs where there is a high degree of Equal Cost Multi- 147 Path (ECMPs) and the topology is very stable. Additionally, using a 148 SPF-based computation can support fast convergence and the 149 computation of Loop-Free Alternatives (LFAs) [RFC5286] in the event 150 of link failures. Furthermore, a BGP based solution lends itself to 151 multiple peering models including those incorporating route- 152 reflectors [RFC4456] or controllers. 154 Support for Multiple Topology Routing (MTR) as described in [RFC4915] 155 is an area for further study dependent on deployment requirements. 157 1.1. BGP Shortest Path First (SPF) Motivation 159 Given that [RFC7938] already describes how BGP could be used as the 160 sole routing protocol in an MSDC, one might question the motivation 161 for defining an alternate BGP deployment model when a mature solution 162 exists. For both alternatives, BGP offers the operational benefits 163 of a single routing protocol. However, BGP SPF offers some unique 164 advantages above and beyond standard BGP distance-vector routing. 166 A primary advantage is that all BGP speakers in the BGP SPF routing 167 domain will have a complete view of the topology. This will allow 168 support for ECMP, IP fast-reroute (e.g., Loop-Free Alternatives), 169 Shared Risk Link Groups (SRLGs), and other routing enhancements 170 without advertisement of addition BGP paths or other extensions. In 171 short, the advantages of an IGP such as OSPF [RFC2328] are availed in 172 BGP. 174 With the simplified BGP decision process as defined in Section 5.1, 175 NLRI changes can be disseminated throughout the BGP routing domain 176 much more rapidly (equivalent to IGPs with the proper 177 implementation). 179 Another primary advantage is a potential reduction in NLRI 180 advertisement. With standard BGP distance-vector routing, a single 181 link failure may impact 100s or 1000s prefixes and result in the 182 withdrawal or re-advertisement of the attendant NLRI. With BGP SPF, 183 only the BGP speakers corresponding to the link NLRI need withdraw 184 the corresponding BGP-LS Link NLRI. This advantage will contribute 185 to both faster convergence and better scaling. 187 With controller and route-reflector peering models, BGP SPF 188 advertisement and distributed computation require a minimal number of 189 sessions and copies of the NLRI since only the latest version of the 190 NLRI from the originator is required. Given that verification of the 191 adjacencies is done outside of BGP (see Section 2), each BGP speaker 192 will only need as many sessions and copies of the NLRI as required 193 for redundancy (e.g., one for the SPF computation and another for 194 backup). Functions such as Optimized Route Reflection (ORR) are 195 supported without extension by virtue of the primary advantages. 196 Additionally, a controller could inject topology that is learned 197 outside the BGP routing domain. 199 Given that controllers are already consuming BGP-LS NLRI [RFC7752], 200 reusing for the BGP-LS SPF leverages the existing controller 201 implementations. 203 Another potential advantage of BGP SPF is that both IPv6 and IPv4 can 204 be supported in the same address family using the same topology. 205 Although not described in this version of the document, multi- 206 topology extensions can be used to support separate IPv4, IPv6, 207 unicast, and multicast topologies while sharing the same NLRI. 209 Finally, the BGP SPF topology can be used as an underlay for other 210 BGP address families (using the existing model) and realize all the 211 above advantages. A simplified peering model using IPv6 link-local 212 addresses as next-hops can be deployed similar to [RFC5549]. 214 1.2. Requirements Language 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 217 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 218 "OPTIONAL" in this document are to be interpreted as described in BCP 219 14 [RFC2119] [RFC8174] when, and only when, they appear in all 220 capitals, as shown here. 222 2. BGP Peering Models 224 Depending on the requirements, scaling, and capabilities of the BGP 225 speakers, various peering models are supported. The only requirement 226 is that all BGP speakers in the BGP SPF routing domain receive link- 227 state NLRI on a timely basis, run an SPF calculation, and update 228 their data plane appropriately. The content of the Link NLRI is 229 described in Section 4.2. 231 2.1. BGP Single-Hop Peering on Network Node Connections 233 The simplest peering model is the one described in section 5.2.1 of 234 [RFC7938]. In this model, EBGP single-hop sessions are established 235 over direct point-to-point links interconnecting the SPF domain 236 nodes. For the purposes of BGP SPF, Link NLRI is only advertised if 237 a single-hop BGP session has been established and the Link-State/SPF 238 address family capability has been exchanged [RFC4790] on the 239 corresponding session. If the session goes down, the corresponding 240 Link NLRI will be withdrawn. Topologically, this would be equivalent 241 to the peering model in [RFC7938] where there is a BGP session on 242 every link in the data center switch fabric. 244 2.2. BGP Peering Between Directly Connected Network Nodes 246 In this model, BGP speakers peer with all directly connected network 247 nodes but the sessions may be multi-hop and the direct connection 248 discovery and liveliness detection for those connections are 249 independent of the BGP protocol. How this is accomplished is outside 250 the scope of this document. Consequently, there will be a single 251 session even if there are multiple direct connections between BGP 252 speakers. For the purposes of BGP SPF, Link NLRI is advertised as 253 long as a BGP session has been established, the Link-State/SPF 254 address family capability has been exchanged [RFC4790] and the 255 corresponding link is considered is up and considered operational. 256 This is much like the previous peering model only peering is on a 257 single loopback address and the switch fabric links can be 258 unnumbered. However, there will be the same unnumber of sessions as 259 with the previous peering model unless there are parrallel links 260 between switches in the fabric. 262 2.3. BGP Peering in Route-Reflector or Controller Topology 264 In this model, BGP speakers peer solely with one or more Route 265 Reflectors [RFC4456] or controllers. As in the previous model, 266 direct connection discovery and liveliness detection for those 267 connections are done outside the BGP protocol. More specifically, 268 the Liveliness detection is done using BFD protocol described in 269 [RFC5880]. For the purposes of BGP SPF, Link NLRI is advertised as 270 long as the corresponding link is up and considered operational. 272 This peering model, known as sparse peering, allows for many fewer 273 BGP sessions and, consequently, instances of the same NLRI received 274 from multiple peers. It is discussed in greater detail in 275 [I-D.ietf-lsvr-applicability]. 277 3. BGP-LS Shortest Path Routing (SPF) SAFI 279 In order to replace the Phase 1 and 2 decision functions of the 280 existing Decision Process with an SPF-based Decision Process and 281 streamline the Phase 3 decision functions in a backward compatible 282 manner, this draft introduces the BGP-LS-SFP SAFI for BGP-LS SPF 283 operation. The BGP-LS-SPF (AF 16388 / SAFI TBD1) [RFC4790] is 284 allocated by IANA as specified in the Section 6. A BGP speaker using 285 the BGP-LS SPF extensions described herein MUST exchange the AFI/SAFI 286 using Multiprotocol Extensions Capability Code [RFC4760] with other 287 BGP speakers in the SPF routing domain. 289 4. Extensions to BGP-LS 291 [RFC7752] describes a mechanism by which link-state and TE 292 information can be collected from networks and shared with external 293 components using BGP protocol. It describes both the definition of 294 BGP-LS NLRI that describes links, nodes, and prefixes comprising IGP 295 link-state information and the definition of a BGP path attribute 296 (BGP-LS attribute) that carries link, node, and prefix properties and 297 attributes, such as the link and prefix metric or auxiliary Router- 298 IDs of nodes, etc. 300 The BGP protocol will be used in the Protocol-ID field specified in 301 table 1 of [I-D.ietf-idr-bgpls-segment-routing-epe]. The local and 302 remote node descriptors for all NLRI will be the BGP Router-ID (TLV 303 516) and either the AS Number (TLV 512) [RFC7752] or the BGP 304 Confederation Member (TLV 517) [RFC8402]. However, if the BGP 305 Router-ID is known to be unique within the BGP Routing domain, it can 306 be used as the sole descriptor. 308 4.1. Node NLRI Usage and Modifications 310 The SPF capability is a new Node Attribute TLV that will be added to 311 those defined in table 7 of [RFC7752]. The new attribute TLV will 312 only be applicable when BGP is specified in the Node NLRI Protocol ID 313 field. The TBD TLV type will be defined by IANA. The new Node 314 Attribute TLV will contain a single-octet SPF algorithm as defined in 315 [RFC8402]. 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | SPF Algorithm | 323 +-+-+-+-+-+-+-+-+ 325 The SPF Algorithm may take the following values: 327 0 - Normal Shortest Path First (SPF) algorithm based on link 328 metric. This is the standard shortest path algorithm as 329 computed by the IGP protocol. Consistent with the deployed 330 practice for link-state protocols, Algorithm 0 permits any 331 node to overwrite the SPF path with a different path based on 332 its local policy. 333 1 - Strict Shortest Path First (SPF) algorithm based on link 334 metric. The algorithm is identical to Algorithm 0 but Algorithm 335 1 requires that all nodes along the path will honor the SPF 336 routing decision. Local policy at the node claiming support for 337 Algorithm 1 MUST NOT alter the SPF paths computed by Algorithm 1. 339 Note that usage of Strict Shortest Path First (SPF) algorithm is 340 defined in the IGP algorithm registry but usage is restricted to 341 [I-D.ietf-idr-bgpls-segment-routing-epe]. Hence, its usage for BGP- 342 LS SPF is out of scope. 344 When computing the SPF for a given BGP routing domain, only BGP nodes 345 advertising the SPF capability attribute will be included the 346 Shortest Path Tree (SPT). 348 4.2. Link NLRI Usage 350 The criteria for advertisement of Link NLRI are discussed in 351 Section 2. 353 Link NLRI is advertised with local and remote node descriptors as 354 described above and unique link identifiers dependent on the 355 addressing. For IPv4 links, the links local IPv4 (TLV 259) and 356 remote IPv4 (TLV 260) addresses will be used. For IPv6 links, the 357 local IPv6 (TLV 261) and remote IPv6 (TLV 262) addresses will be 358 used. For unnumbered links, the link local/remote identifiers (TLV 359 258) will be used. For links supporting having both IPv4 and IPv6 360 addresses, both sets of descriptors may be included in the same Link 361 NLRI. The link identifiers are described in table 5 of [RFC7752]. 363 The link IGP metric attribute TLV (TLV 1095) as well as any others 364 required for non-SPF purposes SHOULD be advertised. Algorithms such 365 as setting the metric inversely to the link speed as done in the OSPF 366 MIB [RFC4750] MAY be supported. However, this is beyond the scope of 367 this document. 369 4.2.1. BGP-LS Link NLRI Attribute Prefix-Length TLVs 371 Two BGP-LS Attribute TLVs to BGP-LS Link NLRI are defined to 372 advertise the prefix length associated with the IPv4 and IPv6 link 373 prefixes. The prefix length is used for the optional installation of 374 prefixes corresponding to Link NLRI as defined in Section 5.3. 376 0 1 2 3 377 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 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | TBD IPv4 or IPv6 Type | Length | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Prefix-Length | 382 +-+-+-+-+-+-+-+-+ 384 Prefix-length - A one-octet length restricted to 1-32 for IPv4 385 Link NLIR endpoint prefixes and 1-128 for IPv6 386 Link NLRI endpoint prefixes. 388 4.2.2. BGP-LS Link NLRI Attribute BGP SPF Status TLV 390 A BGP-LS Attribute TLV to BGP-LS Link NLRI is defined to indicate the 391 status of the link with respect to the BGP SPF calculation. This 392 will be used to expedite convergence for link failures as discussed 393 in Section 5.6.1. If the BGP SPF Status TLV is not included with the 394 Link NLRI, the link is considered up and available. 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | TBD Type | Length | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | BGP SPF Status| 402 +-+-+-+-+-+-+-+-+ 404 BGP Status Values: 0 - Reserved 405 1 - Link Unreachable with respect to BGP SPF 406 2-254 - Undefined 407 255 - Reserved 409 4.2.3. BGP-LS Prefix NLRI Attribute SPF Status TLV 411 A BGP-LS Attribute TLV to BGP-LS Prefix NLRI is defined to indicate 412 the status of the prefix with respect to the BGP SPF calculation. 413 This will be used to expedite convergence for prefix unreachability 414 as discussed in Section 5.6.1. If the SPF Status TLV is not included 415 with the Prefix NLRI, the prefix is considered reachable. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | TBD Type | Length | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | BGP SPF Status| 423 +-+-+-+-+-+-+-+-+ 425 BGP Status Values: 0 - Reserved 426 1 - Prefix down with respect to SPF 427 2-254 - Undefined 428 255 - Reserved 430 4.3. Prefix NLRI Usage 432 Prefix NLRI is advertised with a local node descriptor as described 433 above and the prefix and length used as the descriptors (TLV 265) as 434 described in [RFC7752]. The prefix metric attribute TLV (TLV 1155) 435 as well as any others required for non-SPF purposes SHOULD be 436 advertised. For loopback prefixes, the metric should be 0. For non- 437 loopback prefixes, the setting of the metric is a local matter and 438 beyond the scope of this document. 440 4.4. BGP-LS Attribute Sequence-Number TLV 442 A new BGP-LS Attribute TLV to BGP-LS NLRI types is defined to assure 443 the most recent version of a given NLRI is used in the SPF 444 computation. The TBD TLV type will be defined by IANA. The new BGP- 445 LS Attribute TLV will contain an 8-octet sequence number. The usage 446 of the Sequence Number TLV is described in Section 5.1. 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type | Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Sequence Number (High-Order 32 Bits) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Sequence Number (Low-Order 32 Bits) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Sequence Number 460 The 64-bit strictly increasing sequence number is incremented for 461 every version of BGP-LS NLRI originated. BGP speakers implementing 462 this specification MUST use available mechanisms to preserve the 463 sequence number's strictly increasing property for the deployed life 464 of the BGP speaker (including cold restarts). One mechanism for 465 accomplishing this would be to use the high-order 32 bits of the 466 sequence number as a wrap/boot count that is incremented anytime the 467 BGP router loses its sequence number state or the low-order 32 bits 468 wrap. 470 When incrementing the sequence number for each self-originated NLRI, 471 the sequence number should be treated as an unsigned 64-bit value. 472 If the lower-order 32-bit value wraps, the higher-order 32-bit value 473 should be incremented and saved in non-volatile storage. If by some 474 chance the BGP Speaker is deployed long enough that there is a 475 possibility that the 64-bit sequence number may wrap or a BGP Speaker 476 completely loses its sequence number state (e.g., the BGP speaker 477 hardware is replaced or experiences a cold-start), the phase 1 478 decision function (see Section 5.1) rules will insure convergence, 479 albeit, not immediately. 481 5. Decision Process with SPF Algorithm 483 The Decision Process described in [RFC4271] takes place in three 484 distinct phases. The Phase 1 decision function of the Decision 485 Process is responsible for calculating the degree of preference for 486 each route received from a BGP speaker's peer. The Phase 2 decision 487 function is invoked on completion of the Phase 1 decision function 488 and is responsible for choosing the best route out of all those 489 available for each distinct destination, and for installing each 490 chosen route into the Loc-RIB. The combination of the Phase 1 and 2 491 decision functions is characterized as a Path Vector algorithm. 493 The SPF based Decision process replaces the BGP best-path Decision 494 process described in [RFC4271]. This process starts with selecting 495 only those Node NLRI whose SPF capability TLV matches with the local 496 BGP speaker's SPF capability TLV value. Since Link-State NLRI always 497 contains the local descriptor [RFC7752], it will only be originated 498 by a single BGP speaker in the BGP routing domain. These selected 499 Node NLRI and their Link/Prefix NLRI are used to build a directed 500 graph during the SPF computation. The best paths for BGP prefixes 501 are installed as a result of the SPF process. 503 When BGP-LS-SPF NLRI is received, all that is required is to 504 determine whether it is the best-path by examining the Node-ID and 505 sequence number as described in Section 5.1. If the received best- 506 path NLRI had changed, it will be advertised to other BGP-LS-SPF 507 peers. If the attributes have changed (other than the sequence 508 number), a BGP SPF calculation will be scheduled. However, a changed 509 NLRI MAY be advertised to other peers almost immediately and 510 propagation of changes can approach IGP convergence times. To 511 accomplish this, the MinRouteAdvertisementIntervalTimer and 512 MinASOriginationIntervalTimer [RFC4271] are not applicable to the 513 BGP-LS-SPF SAFI. Rather, SPF calculations SHOULD be triggered and 514 dampened consistent with the SPF backoff algorithm specified in 515 [RFC8405]. 517 The Phase 3 decision function of the Decision Process [RFC4271] is 518 also simplified since under normal SPF operation, a BGP speaker would 519 advertise the NLRI selected for the SPF to all BGP peers with the 520 BGP-LS/BGP-LS-SPF AFI/SAFI. Application of policy would not be 521 prevented however its usage to best-path process would be limited as 522 the SPF relies solely on link metrics. 524 5.1. Phase-1 BGP NLRI Selection 526 The rules for NLRI selection are greatly simplified from [RFC4271]. 528 1. If the NLRI is received from the BGP speaker originating the NLRI 529 (as determined by the comparing BGP Router ID in the NLRI Node 530 identifiers with the BGP speaker Router ID), then it is preferred 531 over the same NLRI from non-originators. This rule will assure 532 that stale NLRI is updated even if a BGP-LS router loses its 533 sequence number state due to a cold-start. 535 2. If the Sequence-Number TLV is present in the BGP-LS Attribute, 536 then the NLRI with the most recent, i.e., highest sequence number 537 is selected. BGP-LS NLRI with a Sequence-Number TLV will be 538 considered more recent than NLRI without a BGP-LS Attribute or a 539 BGP-LS Attribute that doesn't include the Sequence-Number TLV. 541 3. The final tie-breaker is the NLRI from the BGP Speaker with the 542 numerically largest BGP Router ID. 544 When a BGP speaker completely loses its sequence number state, i.e., 545 due to a cold start, or in the unlikely possibility that that 546 sequence number wraps, the BGP routing domain will still converge. 547 This is due to the fact that BGP speakers adjacent to the router will 548 always accept self-originated NLRI from the associated speaker as 549 more recent (rule # 1). When BGP speaker reestablishes a connection 550 with its peers, any existing session will be taken down and stale 551 NLRI will be replaced by the new NLRI and stale NLRI will be 552 discarded independent of whether or not BGP graceful restart is 553 deployed, [RFC4724]. The adjacent BGP speaker will update their NLRI 554 advertisements in turn until the BGP routing domain has converged. 556 The modified SPF Decision Process performs an SPF calculation rooted 557 at the BGP speaker using the metrics from Link and Prefix NLRI 558 Attribute TLVs [RFC7752]. As a result, any attributes that would 559 influence the Decision process defined in [RFC4271] like ORIGIN, 560 MULTI_EXIT_DISC, and LOCAL_PREF attributes are ignored by the SPF 561 algorithm. Furthermore, the NEXT_HOP attribute value is preserved 562 but otherwise ignored during the SPF or best-path. 564 5.2. Dual Stack Support 566 The SPF-based decision process operates on Node, Link, and Prefix 567 NLRIs that support both IPv4 and IPv6 addresses. Whether to run a 568 single SPF instance or multiple SPF instances for separate AFs is a 569 matter of a local implementation. Normally, IPv4 next-hops are 570 calculated for IPv4 prefixes and IPv6 next-hops are calculated for 571 IPv6 prefixes. However, an interesting use-case is deployment of 572 [RFC5549] where IPv6 next-hops are calculated for both IPv4 and IPv6 573 prefixes. As stated in Section 1, support for Multiple Topology 574 Routing (MTR) is an area for future study. 576 5.3. SPF Calculation based on BGP-LS NLRI 578 This section details the BGP-LS SPF local routing information base 579 (RIB) calculation. The router will use BGP-LS Node, Link, and Prefix 580 NLRI to populate the local RIB using the following algorithm. This 581 calculation yields the set of intra-area routes associated with the 582 BGP-LS domain. A router calculates the shortest-path tree using 583 itself as the root. Variations and optimizations of the algorithm 584 are valid as long as it yields the same set of routes. The algorithm 585 below supports Equal Cost Multi-Path (ECMP) routes. Weighted Unequal 586 Cost Multi-Path are out of scope. The organization of this section 587 owes heavily to section 16 of [RFC2328]. 589 The following abstract data structures are defined in order to 590 specify the algorithm. 592 o Local Route Information Base (RIB) - This is abstract contains 593 reachability information (i.e., next hops) for all prefixes (both 594 IPv4 and IPv6) as well as the Node NLRI reachability. 595 Implementations may choose to implement this as separate RIBs for 596 each address family and/or Node NLRI. 598 o Link State NLRI Database (LSNDB) - Database of BGP-LS NLRI that 599 facilitates access to all Node, Link, and Prefix NLRI as well as 600 all the Link and Prefix NLRI corresponding to a given Node NLRI. 601 Other optimization, such as, resolving bi-directional connectivity 602 associations between Link NLRI are possible but of scope of this 603 document. 605 o Candidate List - This is a list of candidate Node NLRI with the 606 lowest cost Node NLRI at the front of the list. It is typically 607 implemented as a heap but other concrete data structures have also 608 been used. 610 The algorithm is comprised of the steps below: 612 1. The current local RIB is invalidated. The local RIB is built 613 again from scratch. The existing routing entries are preserved 614 for comparision to determine changes that need to be installed in 615 the global RIB. 617 2. The computing router's Node NLRI is installed in the local RIB 618 with a cost of 0 and as as the sole entry in the candidate list. 620 3. The Node NLRI with the lowest cost is removed from the candidate 621 list for processing. The Node corresponding to this NLRI will be 622 referred to as the Current Node. If the candidate list is empty, 623 the SPF calculation has completed and the algorithm proceeds to 624 step 6. 626 4. All the Prefix NLRI with the same Node Identifiers as the Current 627 Node will be considered for installation. The cost for each 628 prefix is the metric advertised in the Prefix NLRI added to the 629 cost to reach the Current Node. 631 * If the BGP-LS Prefix attribute includes an BGP-SPF Status TLV 632 indicating the prefix is unreachable, the BGP-LS Prefix NLRI 633 is considered unreachable and the next BGP-LS Prefix NLRI is 634 examined. 636 * If the prefix is in the local RIB and the cost is greater than 637 the Current route's metric, the Prefix NLRI does not 638 contribute to the route and is ignored. 640 * If the prefix is in the local RIB and the cost is less than 641 the current route's metric, the Prefix is installed with the 642 Current Node's next-hops replacing the local RIB route's next- 643 hops and the metric being updated. 645 * If the prefix is in the local RIB and the cost is same as the 646 current route's metric, the Prefix is installed with the 647 Current Node's next-hops being merged with local RIB route's 648 next-hops. 650 5. All the Link NLRI with the same Node Identifiers as the Current 651 Node will be considered for installation. Each link will be 652 examined and will be referred to in the following text as the 653 Current Link. The cost of the Current Link is the advertised 654 metric in the Link NLRI added to the cost to reach the Current 655 Node. 657 * Optionally, the prefix(es) associated with the Current Link 658 are installed into the local RIB using the same rules as were 659 used for Prefix NLRI in the previous steps. 661 * The Current Link's endpoint Node NLRI is accessed (i.e., the 662 Node NLRI with the same Node identifiers as the Link 663 endpoint). If it exists, it will be referred to as the 664 Endpoint Node NLRI and the algorithm will proceed as follows: 666 + If the BGP-LS Link NLRI includes an BGP-SPF Status TLV 667 indicating the link is down, the BGP-LS Link NLRI is 668 considered down and the next BGP-LS Link NLRI is examined. 670 + All the Link NLRI corresponding the Endpoint Node NLRI will 671 be searched for a back-link NLRI pointing to the current 672 node. Both the Node identifiers and the Link endpoint 673 identifiers in the Endpoint Node's Link NLRI must match for 674 a match. If there is no corresponding Link NLRI 675 corresponding to the Endpoint Node NLRI, the Endpoint Node 676 NLIR fails the bi-directional connectivity test and is not 677 processed further. 679 + If the Endpoint Node NLRI is not on the candidate list, it 680 is inserted based on the link cost and BGP Identifier (the 681 latter being used as a tie-breaker). 683 + If the Endpoint Node NLRI is already on the candidate list 684 with a lower cost, it need not be inserted again. 686 + If the Endpoint Node NLRI is already on the candidate list 687 with a higher cost, it must be removed and reinserted with 688 a lower cost. 690 * Return to step 3 to process the next lowest cost Node NLRI on 691 the candidate list. 693 6. The local RIB is examined and changes (adds, deletes, 694 modifications) are installed into the global RIB. 696 5.4. NEXT_HOP Manipulation 698 A BGP speaker that supports SPF extensions MAY interact with peers 699 that don't support SPF extensions. If the BGP-LS address family is 700 advertised to a peer not supporting the SPF extensions described 701 herein, then the BGP speaker MUST conform to the NEXT_HOP rules 702 specified in [RFC4271] when announcing the Link-State address family 703 routes to those peers. 705 All BGP peers that support SPF extensions would locally compute the 706 Loc-RIB next-hops as a result of the SPF process. Consequently, the 707 NEXT_HOP attribute is always ignored on receipt. However, BGP 708 speakers SHOULD set the NEXT_HOP address according to the NEXT_HOP 709 attribute rules specified in [RFC4271]. 711 5.5. IPv4/IPv6 Unicast Address Family Interaction 713 While the BGP-LS SPF address family and the IPv4/IPv6 unicast address 714 families install routes into the same device routing tables, they 715 will operate independently much the same as OSPF and IS-IS would 716 operate today (i.e., "Ships-in-the-Night" mode). There will be no 717 implicit route redistribution between the BGP address families. 718 However, implementation specific redistribution mechanisms SHOULD be 719 made available with the restriction that redistribution of BGP-LS SPF 720 routes into the IPv4 address family applies only to IPv4 routes and 721 redistribution of BGP-LS SPF route into the IPv6 address family 722 applies only to IPv6 routes. 724 Given the fact that SPF algorithms are based on the assumption that 725 all routers in the routing domain calculate the precisely the same 726 SPF tree and install the same set of routes, it is RECOMMENDED that 727 BGP-LS SPF IPv4/IPv6 routes be given priority by default when 728 installed into their respective RIBs. In common implementations the 729 prioritization is governed by route preference or administrative 730 distance with lower being more preferred. 732 5.6. NLRI Advertisement and Convergence 734 5.6.1. Link/Prefix Failure Convergence 736 A local failure will prevent a link from being used in the SPF 737 calculation due to the IGP bi-directional connectivity requirement. 738 Consequently, local link failures should always be given priority 739 over updates (e.g., withdrawing all routes learned on a session) in 740 order to ensure the highest priority propagation and optimal 741 convergence. 743 An IGP such as OSPF [RFC2328] will stop using the link as soon as the 744 Router-LSA for one side of the link is received. With normal BGP 745 advertisement, the link would continue to be used until the last copy 746 of the BGP-LS Link NLRI is withdrawn. In order to avoid this delay, 747 the originator of the Link NLRI will advertise a more recent version 748 of the BGP-LS Link NLRI including the BGP-SPF Status TLV 749 Section 4.2.2 indicating the link is down with respect to BGP-SPF. 750 After some configurable period of time, e.g., 2-3 seconds, the BGP-LS 751 Link NLRI can be withdrawn with no consequence. If the link becomes 752 available in that period, the originator of the BGP-LS LINK NLRI will 753 simply advertise a more recent version of the BGP-LS Link NLRI 754 without the BGP-SPF status TLV in the BGP-LS Link Attributes. 756 Similarily, when a prefix becomes unreachable, a more recent version 757 of the BGP-LS Prefix NLRI will be advertised with the BGP-SPF status 758 TLV Section 4.2.3 indicating the prefix is unreachable in the BGP-LS 759 Prefix Attributes and the prefix will be considered unreachable with 760 respect to BGP SPF. After some configurable period of time, e.g., 761 2-3 seconds, the BGP-LS Prefix NLRI can be withdrawn with no 762 consequence. If the prefix becomes reachable in that period, the 763 originator of the BGP-LS Prefix NLRI will simply advertise a more 764 recent version of the BGP-LS Prefix NLRI without the BGP-SPF status 765 TLV in the BGP-LS Prefix Attributes. 767 5.6.2. Node Failure Convergence 769 With BGP without graceful restart [RFC4724], all the NLRI advertised 770 by node are implicitly withdrawn when a session failure is detected. 771 If fast failure detection such as BFD is utilized and the node is on 772 the fastest converging path, the most recent versions of BGP-LS NLRI 773 may be withdrawn while these versions are in-flight on longer paths. 774 This will result the older version of the NLRI being used until the 775 new versions arrive and, potentially, unnecessary route flaps. 776 Therefore, BGP-LS SPF NLRI SHOULD always be retained before being 777 implicitly withdrawn for a brief configurable interval, e.g., 2-3 778 seconds. This will not delay convergence since the adjacent nodes 779 will detect the link failure and advertise a more recent NLRI 780 indicating the link is down with respect to BGP SPF Section 5.6.1 and 781 the BGP-SPF calculation will failure the bi-directional connectivity 782 check. 784 5.7. Error Handling 786 When a BGP speaker receives a BGP Update containing a malformed SPF 787 Capability TLV in the Node NLRI BGP-LS Attribute [RFC7752], it MUST 788 ignore the received TLV and the Node NLRI and not pass it to other 789 BGP peers as specified in [RFC7606]. When discarding a Node NLRI 790 with malformed TLV, a BGP speaker SHOULD log an error for further 791 analysis. 793 6. IANA Considerations 795 This document defines an AFI/SAFI for BGP-LS SPF operation and 796 requests IANA to assign the BGP-LS/BGP-LS-SPF (AFI 16388 / SAFI TBD1) 797 as described in [RFC4750]. 799 This document also defines four attribute TLVs for BGP LS NLRI. We 800 request IANA to assign TLVs for the SPF capability, Sequence Number, 801 IPv4 Link Prefix-Length, and IPv6 Link Prefix-Length from the "BGP-LS 802 Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 803 TLVs" Registry. 805 7. Security Considerations 807 This extension to BGP does not change the underlying security issues 808 inherent in the existing [RFC4271], [RFC4724], and [RFC7752]. 810 8. Management Considerations 812 This section includes unique management considerations for the BGP-LS 813 SPF address family. 815 8.1. Configuration 817 In addition to configuration of the BGP-LS SPF address family, 818 implementations SHOULD support the configuratio of the 819 INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY, TIME_TO_LEARN, 820 and HOLDDOWN_INTERVAL as documented in [RFC8405]. 822 8.2. Operational Data 824 In order to troubleshoot SPF issues, implementations SHOULD support 825 an SPF log including entries for previous SPF computations, Each SPF 826 log entry would include the BGP-LS NLRI SPF triggering the SPF, SPF 827 scheduled time, SPF start time, SPF end time, and SPF type if 828 different types of SPF are supported. Since the size of the log will 829 be finite, implementations SHOULD also maintain counters for the 830 total number of SPF computations of each type and the total number of 831 SPF triggering events. Additionally, to troubleshoot SPF scheduling 832 and backoff [RFC8405], the current SPF backoff state, remaining time- 833 to-learn, remaining holddown, last trigger event time, last SPF time, 834 and next SPF time should be available. 836 9. Acknowledgements 838 The authors would like to thank Sue Hares, Jorge Rabadan, Boris 839 Hassanov, Dan Frost, and Fred Baker for their review and comments. 841 The authors extend special thanks to Eric Rosen for fruitful 842 discussions on BGP-LS SPF convergence as compared to IGPs. 844 10. Contributors 846 In addition to the authors listed on the front page, the following 847 co-authors have contributed to the document. 849 Derek Yeung 850 Arrcus, Inc. 851 derek@arrcus.com 853 Gunter Van De Velde 854 Nokia 855 gunter.van_de_velde@nokia.com 857 Abhay Roy 858 Cisco Systems 859 akr@cisco.com 861 Venu Venugopal 862 Cisco Systems 863 venuv@cisco.com 865 11. References 867 11.1. Normative References 869 [I-D.ietf-idr-bgpls-segment-routing-epe] 870 Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. 871 Dong, "BGP-LS extensions for Segment Routing BGP Egress 872 Peer Engineering", draft-ietf-idr-bgpls-segment-routing- 873 epe-15 (work in progress), March 2018. 875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 876 Requirement Levels", BCP 14, RFC 2119, 877 DOI 10.17487/RFC2119, March 1997, . 880 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 881 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 882 DOI 10.17487/RFC4271, January 2006, . 885 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 886 Patel, "Revised Error Handling for BGP UPDATE Messages", 887 RFC 7606, DOI 10.17487/RFC7606, August 2015, 888 . 890 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 891 S. Ray, "North-Bound Distribution of Link-State and 892 Traffic Engineering (TE) Information Using BGP", RFC 7752, 893 DOI 10.17487/RFC7752, March 2016, . 896 [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of 897 BGP for Routing in Large-Scale Data Centers", RFC 7938, 898 DOI 10.17487/RFC7938, August 2016, . 901 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 902 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 903 May 2017, . 905 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 906 Decraene, B., Litkowski, S., and R. Shakir, "Segment 907 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 908 July 2018, . 910 [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., 911 Francois, P., and C. Bowers, "Shortest Path First (SPF) 912 Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, 913 DOI 10.17487/RFC8405, June 2018, . 916 11.2. Information References 918 [I-D.ietf-lsvr-applicability] 919 Patel, K., Lindem, A., Zandi, S., and G. Dawra, "Usage and 920 Applicability of Link State Vector Routing in Data 921 Centers", draft-ietf-lsvr-applicability-00 (work in 922 progress), July 2018. 924 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 925 DOI 10.17487/RFC2328, April 1998, . 928 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 929 Reflection: An Alternative to Full Mesh Internal BGP 930 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 931 . 933 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 934 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 935 DOI 10.17487/RFC4724, January 2007, . 938 [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., 939 Coltun, R., and F. Baker, "OSPF Version 2 Management 940 Information Base", RFC 4750, DOI 10.17487/RFC4750, 941 December 2006, . 943 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 944 "Multiprotocol Extensions for BGP-4", RFC 4760, 945 DOI 10.17487/RFC4760, January 2007, . 948 [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet 949 Application Protocol Collation Registry", RFC 4790, 950 DOI 10.17487/RFC4790, March 2007, . 953 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 954 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 955 RFC 4915, DOI 10.17487/RFC4915, June 2007, 956 . 958 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 959 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 960 DOI 10.17487/RFC5286, September 2008, . 963 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 964 Layer Reachability Information with an IPv6 Next Hop", 965 RFC 5549, DOI 10.17487/RFC5549, May 2009, 966 . 968 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 969 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 970 . 972 Authors' Addresses 974 Keyur Patel 975 Arrcus, Inc. 977 Email: keyur@arrcus.com 979 Acee Lindem 980 Cisco Systems 981 301 Midenhall Way 982 Cary, NC 27513 983 USA 985 Email: acee@cisco.com 987 Shawn Zandi 988 Linkedin 989 222 2nd Street 990 San Francisco, CA 94105 991 USA 993 Email: szandi@linkedin.com 995 Wim Henderickx 996 Nokia 997 Antwerp 998 Belgium 1000 Email: wim.henderickx@nokia.com