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