idnits 2.17.1 draft-ietf-idr-bgp-ls-app-specific-attr-10.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 (April 28, 2022) is 729 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) ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) ** Obsolete normative reference: RFC 8919 (Obsoleted by RFC 9479) ** Obsolete normative reference: RFC 8920 (Obsoleted by RFC 9492) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-13 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing K. Talaulikar, Ed. 3 Internet-Draft Arrcus Inc 4 Intended status: Standards Track P. Psenak 5 Expires: October 30, 2022 Cisco Systems 6 J. Tantsura 7 Microsoft 8 April 28, 2022 10 Application-Specific Attributes Advertisement with BGP Link-State 11 draft-ietf-idr-bgp-ls-app-specific-attr-10 13 Abstract 15 Various link attributes have been defined in link-state routing 16 protocols like OSPF and IS-IS in the context of the MPLS Traffic 17 Engineering (TE) and GMPLS. BGP Link-State (BGP-LS) extensions have 18 been defined to distribute these attributes along with other topology 19 information from these link-state routing protocols. 21 New extensions have been defined for link-state routing protocols 22 that enable distribution of application-specific link attributes for 23 existing as well as newer applications such as Segment Routing. This 24 document defines extensions to BGP-LS to enable the advertisement of 25 these application-specific attributes as a part of the topology 26 information from the network. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 30, 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Application Specific Link Attributes TLV . . . . . . . . . . 3 65 3. Application-Specific Link Attributes . . . . . . . . . . . . 5 66 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. Manageability Considerations . . . . . . . . . . . . . . . . 9 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 10.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 BGP Link-State [RFC7752] enables the distribution of the link-state 80 topology information from link-state routing protocols (viz., IS-IS 81 [RFC1195], OSPFv2 [RFC2328] and OSPFv3 [RFC5340]) to an application 82 like a controller or Path Computation Engine (PCE) via BGP. The 83 controller/PCE gets the end-to-end topology information across IGP 84 domains so it can perform path computations for use cases like end- 85 to-end traffic engineering (TE). 87 The link-state topology information distributed via BGP-LS includes 88 link attributes that were originally defined for traditional MPLS 89 Traffic Engineering (i.e., using RSVP-TE [RFC3209]) or GMPLS 90 [RFC4202]) applications. In recent years new applications, such as 91 Segment Routing (SR) Policy [RFC8402] and Loop-Free Alternates (LFA) 92 [RFC5286], that also make use of link attributes have been 93 introduced. [RFC8919] and [RFC8920] define extensions for IS-IS and 94 OSPF respectively that enable advertising application-specific link 95 attributes for these and other future applications. This has 96 resulted in the need for a similar BGP-LS extension to include this 97 additional link-state topology information from the link-state 98 routing protocols. 100 This document defines the BGP-LS extensions for the advertisement of 101 application-specific link attributes. It describes the advertisement 102 of these link attributes as top-level TLVs (i.e., as TLVs of the BGP- 103 LS Attribute) and as sub-TLVs of the new (top-level) Application 104 Specific Link Attributes TLV. The document also describes the 105 procedures for the advertisement of these attributes from the 106 underlying IGPs and discusses their deployment aspects. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 2. Application Specific Link Attributes TLV 118 The BGP-LS [RFC7752] specifies the Link NLRI for the advertisement of 119 links and their attributes using the BGP-LS Attribute. The 120 Application-Specific Link Attributes (ASLA) TLV is a new optional 121 top-level BGP-LS Attribute TLV that is introduced for Link NLRIs. It 122 is defined such that it may act as a container for certain existing 123 and future link attributes that require application-specific 124 definition. 126 The format of this TLV is as follows and is similar to the 127 corresponding ASLA sub-TLVs defined for OSPF and IS-IS in [RFC8920] 128 and [RFC8919] respectively. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Type | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | SABM Length | UDABM Length | Reserved | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Standard Application Identifier Bit Mask (variable) // 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | User-Defined Application Identifier Bit Mask (variable) // 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Link Attribute sub-TLVs // 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 Figure 1: Application-Specific Link Attributes TLV 146 where: 148 o Type: 1122 150 o Length: variable. 152 o SABM Length : Standard Application Identifier Bit Mask Length in 153 octets as defined in [RFC8920]. 155 o UDABM Length : User-Defined Application Identifier Bit Mask Length 156 in octets as defined in [RFC8920]. 158 o Standard Application Identifier Bit Mask : An optional set of bits 159 (of size 0, 4, or 8 octets as indicated by the SABML), where each 160 bit represents a single standard application as defined in 161 [RFC8919]. 163 o User-Defined Application Identifier Bit Mask : An optional set of 164 bits (of size 0, 4, or 8 octets as indicated by the UDABML), where 165 each bit represents a single user-defined application as defined 166 in [RFC8919]. 168 o Link Attribute sub-TLVs : BGP-LS Attribute TLVs corresponding to 169 the Link NLRI that are application-specific (including existing 170 ones as specified in Section 3) are included as sub-TLVs of the 171 ASLA TLV. 173 The semantics associated with the standard and user-defined bit masks 174 as well as the encoding scheme for application-specific attributes 175 are as specified in [RFC8920]. 177 The ASLA TLV and its sub-TLVs can only be added to the BGP-LS 178 Attribute associated with the Link NLRI of the node that originates 179 the underlying IGP link attribute TLVs/sub-TLVs. The procedures for 180 originating link attributes in the ASLA TLV from underlying IGPs are 181 specified in Section 4. 183 3. Application-Specific Link Attributes 185 Several BGP-LS Attribute TLVs corresponding to the Link NLRI are 186 defined in BGP-LS and more may be added in the future. Those 187 attributes that have been determined to be, and advertised as 188 application-specific in the underlying IGPs are also encoded in a 189 similar manner in BGP-LS. 191 The following table lists the currently defined BGP-LS Attributes 192 TLVs corresponding to Link NLRI that can have application-specific 193 semantics based on the underlying IGP specifications [RFC8919] 194 [RFC8920]. These were originally defined with semantics for RSVP-TE 195 and GMPLS applications in BGP-LS by the respective reference 196 documents. 198 +---------------+-------------------------------+-------------------+ 199 | TLV Code | Description | Reference | 200 | Point | | Document | 201 +---------------+-------------------------------+-------------------+ 202 | 1088 | Administrative group (color) | [RFC7752] | 203 | 1092 | TE Default Metric | [RFC7752] | 204 | 1096 | Shared Risk Link Group | [RFC7752] | 205 | 1114 | Unidirectional Link Delay | [RFC8571] | 206 | 1115 | Min/Max Unidirectional Link | [RFC8571] | 207 | | Delay | | 208 | 1116 | Unidirectional Delay | [RFC8571] | 209 | | Variation | | 210 | 1117 | Unidirectional Link Loss | [RFC8571] | 211 | 1118 | Unidirectional Residual | [RFC8571] | 212 | | Bandwidth | | 213 | 1119 | Unidirectional Available | [RFC8571] | 214 | | Bandwidth | | 215 | 1120 | Unidirectional Utilized | [RFC8571] | 216 | | Bandwidth | | 217 | 1173 | Extended Administrative Group | [RFC9104] | 218 +---------------+-------------------------------+-------------------+ 220 Table 1: Existing BGP-LS TLVs identified as Application-Specific 222 All the BGP-LS Attribute TLVs defined in the table above are REQUIRED 223 to be advertised as a top-level TLV in the BGP-LS Attribute for 224 carrying link attributes specific to RSVP-TE. 226 BGP-LS Attribute TLVs corresponding to Link NLRI that are identified 227 as application-specific are REQUIRED to be encoded within an ASLA 228 TLV. 230 Link attributes that do not have application-specific semantics MUST 231 NOT be advertised within the ASLA TLV. 233 When the same application-specific link attributes are advertised 234 both within the ASLA TLV and as top-level TLVs in the BGP-LS 235 Attribute, the attributes advertised within the ASLA TLV take 236 precedence for the applications indicated in the ASLA TLV encoding. 238 4. Procedures 240 The BGP-LS originator learns of the association of an application- 241 specific attribute to one or more applications from the underlying 242 IGP protocol LSA/LSPs from which it is advertising the topology 243 information. [RFC8920] and [RFC8919] specify the mechanisms for 244 advertising application-specific link attributes in OSPF and IS-IS 245 respectively. 247 Application-specific link attributes received from an IGP node 248 without the use of ASLA encodings continue to be encoded using the 249 respective BGP-LS top-level TLVs listed in Table 1 as specified in 250 their respective reference documents. 252 A BGP-LS originator node that is advertising link-state information 253 from the underlying IGP using ASLA encodings determines their BGP-LS 254 encoding based on the following rules: 256 1. Application-specific link attributes received from an OSPF node 257 using ASLA sub-TLV or from an IS-IS node using either ASLA sub- 258 TLV or ASLA SRLG TLV MUST be encoded in the BGP-LS ASLA TLV as 259 sub-TLVs. Exceptions to this rule are specified in (2)(F) and 260 (2)(G) below. 262 2. In the case of IS-IS, the following specific procedures are to be 263 followed: 265 A. When application-specific link attributes are received from a 266 node with the L bit set in the ASLA sub-TLV and application 267 bits other than RSVP-TE are set in the application bit masks 268 then the application-specific link attributes advertised in 269 the corresponding legacy IS-IS TLVs/sub-TLVs MUST be encoded 270 within the BGP-LS ASLA TLV as sub-TLVs with the application 271 bits, other than the RSVP-TE bit, copied from the IS-IS ASLA 272 sub-TLV. The link attributes advertised in the legacy IS-IS 273 TLVs/sub-TLVs are also advertised in BGP-LS top-level TLVs as 274 per [RFC7752] [RFC8571] [RFC9104]. The same procedure also 275 applies for the advertisement of the SRLG values from the IS- 276 IS ASLA SRLG TLV. 278 B. When the ASLA sub-TLV has the RSVP-TE application bit set, 279 then the link attributes for the corresponding ASLA sub-TLV 280 MUST be encoded using the respective BGP-LS top-level TLVs as 281 per [RFC7752] [RFC8571] [RFC9104]. Similarly, when the ASLA 282 SRLG TLV has the RSVP-TE application bit set, then the SRLG 283 values within it MUST be encoded using the top-level BGP-LS 284 SRLG TLV (1096) as per [RFC7752]. 286 C. The SRLGs advertised in IS-IS SRLG ASLA TLVs and the other 287 link attributes advertised in IS-IS ASLA sub-TLVs are 288 REQUIRED to be collated, on a per-application basis, for all 289 applications that have their bit set in the SABM/UDABM in at 290 least one of the aforementioned TLV types. When performing 291 this collation, only the TLVs with the application's bit set 292 in SABM/UDABM MUST be used when such TLVs are available from 293 either TLV types. If the bit for an application is set in 294 the SABM/UDABM of only one of the TLV types, then the 295 attributes from the other TLV type with zero-length 296 application bit mask MUST be also collated for that 297 application, if such TLV is available. Such collated link 298 attributes are advertised in a per-application instance of 299 the BGP-LS ASLA TLV. 301 D. If the resulting set of collated link attributes and SRLG 302 values is common across multiple applications, they MAY be 303 advertised in a common BGP-LS ASLA TLV instance where the 304 bits for all such applications would be set in the 305 application bit mask. 307 E. Both the SRLG values from IS-IS ASLA SRLG TLVs and the link 308 attributes from IS-IS ASLA sub-TLVs, with the zero-length 309 application bit mask, MUST be advertised into a BGP-LS ASLA 310 TLV with a zero-length application bit mask, independent of 311 the collation described above. 313 F. [RFC8919] allows the advertisement of the Maximum Link 314 Bandwidth within an ASLA sub-TLV even though it is not an 315 application-specific attribute. However, when originating 316 the Maximum Link Bandwidth into BGP-LS, the attribute MUST be 317 encoded only in the top-level BGP-LS Maximum Link Bandwidth 318 TLV (1089) and MUST NOT be advertised within the BGP-LS ASLA 319 TLV. 321 G. [RFC8919] also allows the advertisement of the Maximum 322 Reservable Link Bandwidth and the Unreserved Bandwidth within 323 an ASLA sub-TLV even though these attributes are specific to 324 RSVP-TE application. However, when originating the Maximum 325 Reservable Link Bandwidth and Unreserved Bandwidth into BGP- 326 LS, these attributes MUST be encoded only in the BGP-LS top- 327 level Maximum Reservable Link Bandwidth TLV (1090) and 328 Unreserved Bandwidth TLV (1091) respectively and not within 329 the BGP-LS ASLA TLV. 331 These rules ensure that a BGP-LS originator performs the 332 advertisement for all application-specific link attributes from the 333 IGP nodes that support or do not support the ASLA extension. 334 Furthermore, it also ensures that the top-level BGP-LS TLVs defined 335 for RSVP-TE and GMPLS applications continue to be used for 336 advertisement of their application-specific attributes. 338 A BGP-LS speaker would normally advertise all the application- 339 specific link attributes corresponding to RSVP-TE and GMPLS 340 applications as existing top-level BGP-LS TLVs while for other 341 applications they are encoded in ASLA TLV(s) with appropriate 342 applicable bit mask setting. The application-specific attribute 343 value received via sub-TLVs within the ASLA TLV have preference over 344 the value received via the top-level TLVs. 346 5. Deployment Considerations 348 BGP-LS sources the link-state topology information (including the 349 extensions introduced by this document) from the underlying link- 350 state IGP protocols. The various deployment aspects related to the 351 advertisement and use of application-specific link attributes are 352 discussed in the Deployment Considerations sections of [RFC8920] and 353 [RFC8919]. The IGP backward compatibility aspects described in those 354 documents associated with application-specific link attributes along 355 with the BGP-LS procedures specified in this document enable backward 356 compatibility in deployments of existing implementations of [RFC7752] 357 [RFC8571] [RFC9104] for applications such as RSVP-TE, SR Policy, and 358 LFA. 360 It is recommended that nodes supporting this specification are 361 selected as originators of BGP-LS information when advertising the 362 link-state information from the IGPs. 364 BGP-LS consumers that do not support this specification can continue 365 to use the existing top-level TLVs for link attributes for existing 366 applications as discussed above. They would, however, not be able to 367 support neither the application-specific link attributes nor newer 368 applications that may be encoded only using the ASLA TLV. 370 6. IANA Considerations 372 IANA has assigned, through the early allocation process, the 373 following code-point from the "BGP-LS Node Descriptor, Link 374 Descriptor, Prefix Descriptor, and Attribute TLVs" registry. This 375 document requests that the allocation be made permanent. The column 376 "IS-IS TLV/Sub-TLV" defined in the registry does not require any 377 value and should be left empty. 379 +------------+------------------------------------------+----------+ 380 | Code Point | Description | Length | 381 +------------+------------------------------------------+----------+ 382 | 1122 | Application-Specific Link Attributes TLV | variable | 383 +------------+------------------------------------------+----------+ 385 Table 2: ASLA TLV Code-Point Allocation 387 7. Manageability Considerations 389 The new protocol extensions introduced in this document augment the 390 existing IGP topology information defined in [RFC7752]. Procedures 391 and protocol extensions defined in this document do not affect the 392 BGP protocol operations and management other than as discussed in the 393 Manageability Considerations section of [RFC7752]. Specifically, the 394 malformed NLRIs attribute tests in the Fault Management section of 395 [RFC7752] now encompasses the BGP-LS TLVs defined in this document. 397 The extensions specified in this document do not specify any new 398 configuration or monitoring aspects in BGP or BGP-LS. The 399 specification of BGP models is an ongoing work based on 400 [I-D.ietf-idr-bgp-model]. 402 8. Security Considerations 404 Security considerations for acquiring and distributing BGP-LS 405 information are discussed in [RFC7752]. 407 The TLVs introduced in this document are used to propagate the 408 application-specific link attributes IGP extensions defined in 409 [RFC8919] and [RFC8920]. It is assumed that the IGP instances 410 originating these TLVs will support all the required security (as 411 described in [RFC8919] and [RFC8920]) to prevent any security issues 412 when propagating the TLVs into BGP-LS. 414 This document defines a new way to advertise link attributes. 415 Tampering with the information defined in this document may affect 416 applications using it, including impacting traffic engineering, which 417 uses various link attributes for its path computation. As the 418 advertisements defined in this document limit the scope to specific 419 applications, the impact of tampering is similarly limited in scope. 420 The advertisement of the link attribute information defined in this 421 document presents no significant additional risk beyond that 422 associated with the existing link attribute information already 423 supported in [RFC7752]. 425 9. Acknowledgements 427 The authors would like to thank Les Ginsberg, Baalajee S, Amalesh 428 Maity, Acee Lindem, Keyur Patel, Paul Wouters, and Rudy Selderslaghs 429 for their review and feedback on this document. The authors would 430 also like to thank Alvaro Retana for his very detailed AD review and 431 comments for improving this document. 433 10. References 435 10.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 443 S. Ray, "North-Bound Distribution of Link-State and 444 Traffic Engineering (TE) Information Using BGP", RFC 7752, 445 DOI 10.17487/RFC7752, March 2016, 446 . 448 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 449 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 450 May 2017, . 452 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 453 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 454 IGP Traffic Engineering Performance Metric Extensions", 455 RFC 8571, DOI 10.17487/RFC8571, March 2019, 456 . 458 [RFC8919] Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and 459 J. Drake, "IS-IS Application-Specific Link Attributes", 460 RFC 8919, DOI 10.17487/RFC8919, October 2020, 461 . 463 [RFC8920] Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura, 464 J., and J. Drake, "OSPF Application-Specific Link 465 Attributes", RFC 8920, DOI 10.17487/RFC8920, October 2020, 466 . 468 [RFC9104] Tantsura, J., Wang, Z., Wu, Q., and K. Talaulikar, 469 "Distribution of Traffic Engineering Extended 470 Administrative Groups Using the Border Gateway Protocol - 471 Link State (BGP-LS)", RFC 9104, DOI 10.17487/RFC9104, 472 August 2021, . 474 10.2. Informative References 476 [I-D.ietf-idr-bgp-model] 477 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 478 YANG Model for Service Provider Networks", draft-ietf-idr- 479 bgp-model-13 (work in progress), March 2022. 481 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 482 dual environments", RFC 1195, DOI 10.17487/RFC1195, 483 December 1990, . 485 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 486 DOI 10.17487/RFC2328, April 1998, 487 . 489 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 490 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 491 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 492 . 494 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 495 in Support of Generalized Multi-Protocol Label Switching 496 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 497 . 499 [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for 500 IP Fast Reroute: Loop-Free Alternates", RFC 5286, 501 DOI 10.17487/RFC5286, September 2008, 502 . 504 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 505 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 506 . 508 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 509 Decraene, B., Litkowski, S., and R. Shakir, "Segment 510 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 511 July 2018, . 513 Authors' Addresses 515 Ketan Talaulikar (editor) 516 Arrcus Inc 517 India 519 Email: ketant.ietf@gmail.com 521 Peter Psenak 522 Cisco Systems 523 Slovakia 525 Email: ppsenak@cisco.com 527 Jeff Tantsura 528 Microsoft 530 Email: jefftant.ietf@gmail.com