idnits 2.17.1 draft-peng-lsr-algorithm-related-adjacency-sid-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 7, 2020) is 1234 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) == Unused Reference: 'RFC4915' is defined on line 432, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 437, but no explicit reference was found in the text == Unused Reference: 'RFC5340' is defined on line 443, but no explicit reference was found in the text == Unused Reference: 'RFC8668' is defined on line 482, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-lsr-flex-algo-13 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Shaofu. Peng 3 Internet-Draft Ran. Chen 4 Intended status: Standards Track ZTE Corporation 5 Expires: June 10, 2021 Ketan. Talaulikar 6 Cisco Systems 7 December 7, 2020 9 Algorithm Related IGP-Adjacency SID Advertisement 10 draft-peng-lsr-algorithm-related-adjacency-sid-02 12 Abstract 14 Segment Routing architecture supports the use of multiple routing 15 algorithms, i.e, different constraint-based shortest-path 16 calculations can be supported. There are two standard algorithms: 17 SPF and Strict-SPF, defined in Segment Routing architecture. There 18 are also other user defined algorithms according to Flex-algo 19 applicaiton. However, an algorithm identifier is often included as 20 part of a Prefix-SID advertisement, that maybe not satisfy some 21 scenarios where multiple algorithm share the same link resource. 22 This document complement that the algorithm identifier can be also 23 included as part of a Adjacency-SID advertisement 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 10, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 3. Adjacency Segment Identifier per Algorithm . . . . . . . . . 3 62 3.1. ISIS Adjacency Segment Identifier per Algorithm . . . . . 3 63 3.1.1. ISIS Adjacency Segment Identifier (Adj-SID) per 64 Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 4 65 3.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per 66 Algorithm Sub-TLV . . . . . . . . . . . . . . . . . . 4 67 3.2. OSPF Adjacency Segment Identifier per Algorithm . . . . . 5 68 3.2.1. OSPF Adj-SID Sub-TLV . . . . . . . . . . . . . . . . 6 69 3.2.2. OSPF LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . 6 70 3.3. OSPFv3 Adjacency Segment Identifier per Algorithm . . . . 7 71 3.3.1. OSPFv3 Adj-SID Sub-TLV . . . . . . . . . . . . . . . 7 72 3.3.2. OSPFv3 LAN Adj-SID Sub-TLV . . . . . . . . . . . . . 8 73 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Segment Routing architecture [RFC8402] supports the use of multiple 83 routing algorithms, i.e, different constraint-based shortest-path 84 calculations can be supported. There are two standard algorithms, 85 i.e, SPF and Strict-SPF, that defined in Segment Routing 86 architecture. For SPF, the packet is forwarded along the well known 87 ECMP-aware Shortest Path First (SPF) algorithm employed by the IGPs. 88 However, it is explicitly allowed for a midpoint to implement another 89 forwarding based on local policy. For Strict Shortest Path First 90 (Strict-SPF), it mandates that the packet be forwarded according to 91 the ECMP-aware SPF algorithm and instructs any router in the path to 92 ignore any possible local policy overriding the SPF decision. 94 There are also other user defined algorithms according to IGP Flex 95 Algorithm [I-D.ietf-lsr-flex-algo]. IGP Flex Algorithm proposes a 96 solution that allows IGPs themselves to compute constraint based 97 paths over the network, and it also specifies a way of using Segment 98 Routing (SR) Prefix-SIDs and SRv6 locators to steer packets along the 99 constraint-based paths. It specifies a set of extensions to ISIS, 100 OSPFv2 and OSPFv3 that enable a router to send TLVs that identify (a) 101 calculation-type, (b) specify a metric-type, and (c )describe a set 102 of constraints on the topology, that are to be used to compute the 103 best paths along the constrained topology. A given combination of 104 calculation-type, metric-type, and constraints is known as an FAD 105 (Flexible Algorithm Definition). 107 However, an algorithm identifier is often included as part of a 108 Prefix-SID advertisement, that maybe not satisfy some scenarios where 109 multiple algorithm share the same link resource. For example, an SR- 110 TE policy may be instantiated within specific Flex-algo plane, i.e., 111 the SID list requires to include algorithm related SIDs. An 112 algorithm-unware Adjacency-SID included in the SID list can just 113 steer the packet towards the link, but can not apply different QoS 114 policy for different algorithm. Another example is that the TI-LFA 115 backup path computed in Flex-algo plane may also contain an 116 algorithm-unware Adjacency-SID, which maybe also used in other SR-TE 117 instance that carries other service. 119 This document complement that the algorithm identifier can be also 120 included as part of an Adjacency-SID advertisement for SR-MPLS. 122 2. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Adjacency Segment Identifier per Algorithm 132 3.1. ISIS Adjacency Segment Identifier per Algorithm 134 [RFC8667] describes the IS-IS extensions that need to be introduced 135 for Segment Routing operating on an MPLS data plane. It defined 136 Adjacency Segment Identifier (Adj-SID) sub-TLV advertised with TLV- 137 22/222/23/223/141, and Adjacency Segment Identifier (LAN-Adj-SID) 138 Sub-TLV advetised with TLV-22/222/23/223. Accordingly, this document 139 defines two new optional Sub-TLVs, "ISIS Adjacency Segment Identifier 140 (Adj-SID) per Algorithm Sub-TLV" and "ISIS Adjacency Segment 141 Identifier (LAN-Adj-SID) per Algorithm Sub-TLV". 143 3.1.1. ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm Sub- 144 TLV 146 ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm Sub-TLV has 147 the following format: 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Length | Flags | Weight | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Algorithm | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | SID/Label/Index (variable) | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 1: ISIS Adjacency Segment Identifier (Adj-SID) per Algorithm 160 Format 162 where: 164 Type: TBD1. 166 Length: 6 or 7 depending on size of the SID. 168 Flags: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV. 170 Weight: Refer to Adjacency Segment Identifier (Adj-SID) sub-TLV. 172 Algorithm: The Algorithm field contains the identifier of the 173 algorithm the router uses to apply algorithm specific QoS policy 174 configured on the adjacency. 176 SID/Label/Index: Refer to Adjacency Segment Identifier (Adj-SID) sub- 177 TLV. 179 For a P2P link, an SR-capable router MAY allocate different Adj-SID 180 for different algorithm, if this link will join different algorithm 181 related plane. 183 3.1.2. ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm 184 Sub-TLV 186 ISIS Adjacency Segment Identifier (LAN-Adj-SID) per Algorithm Sub-TLV 187 has the following format: 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Type | Length | Flags | Weight | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Algorithm | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Neighbor System-ID (ID length octets) | 197 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | SID/Label/Index (variable) | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2: ISIS Adjacency Segment Identifier (LAN-Adj-SID) per 206 Algorithm Format 208 where: 210 Type: TBD2. 212 Length: Variable. 214 Flags: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV. 216 Weight: Refer to Adjacency Segment Identifier (LAN-Adj-SID) Sub-TLV. 218 Algorithm: The Algorithm field contains the identifier of the 219 algorithm the router uses to apply algorithm specific QoS policy 220 configured on the adjacency. 222 SID/Label/Index: Refer to Adjacency Segment Identifier (LAN-Adj-SID) 223 Sub-TLV. 225 For a broadcast link, an SR-capable router MAY allocate different 226 Adj-SID for different algorithm, if this link will join different 227 algorithm related plane. 229 3.2. OSPF Adjacency Segment Identifier per Algorithm 231 [RFC8665] describes the OSPF extensions that need to be introduced 232 for Segment Routing operating on an MPLS data plane. It defined Adj- 233 SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Extended Link TLV 234 defined in [RFC7684]. This document extends these two Sub-TLVs to 235 carry the specific algorithm. 237 3.2.1. OSPF Adj-SID Sub-TLV 239 The existing Adj-SID Sub-TLV has the following format: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type | Length | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Flags | Algorithm | MT-ID | Weight | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | SID/Label/Index (variable) | 249 +---------------------------------------------------------------+ 251 Figure 3: OSPF Adj-SID Format 253 where: 255 Algorithm: The new Algorithm field contains the identifier of the 256 algorithm the router uses to apply algorithm specific QoS policy 257 configured on the adjacency. 259 For a P2P link, an SR-capable router MAY allocate different Adj-SID 260 for different algorithm, if this link will join different algorithm 261 related plane. 263 3.2.2. OSPF LAN Adj-SID Sub-TLV 265 The existing LAN Adj-SID Sub-TLV has the following format: 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type | Length | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Flags | Algorithm | MT-ID | Weight | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Neighbor ID | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | SID/Label/Index (variable) | 277 +---------------------------------------------------------------+ 279 Figure 4: OSPF LAN Adj-SID Format 281 where: 283 Algorithm: The new Algorithm field contains the identifier of the 284 algorithm the router uses to apply algorithm specific QoS policy 285 configured on the adjacency. 287 For a broadcast link, an SR-capable router MAY allocate different 288 Adj-SID for different algorithm, if this link will join different 289 algorithm related plane. 291 3.3. OSPFv3 Adjacency Segment Identifier per Algorithm 293 [RFC8666] describes the OSPFv3 extensions that need to be introduced 294 for Segment Routing operating on an MPLS data plane. It defined Adj- 295 SID Sub-TLV and LAN Adj-SID Sub-TLV advertised with Router-Link TLV 296 as defined in [RFC8362]. This document extends these two Sub-TLVs to 297 carry the specific algorithm. 299 3.3.1. OSPFv3 Adj-SID Sub-TLV 301 The existing Adj-SID Sub-TLV has the following format: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type | Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Flags | Weight | Algorithm | Reserved | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | SID/Label/Index (variable) | 311 +---------------------------------------------------------------+ 313 Figure 5: OSPFv3 Adj-SID Format 315 where: 317 Algorithm: The new Algorithm field contains the identifier of the 318 algorithm the router uses to apply algorithm specific QoS policy 319 configured on the adjacency. 321 For a P2P link, an SR-capable router MAY allocate different Adj-SID 322 for different algorithm, if this link will join different algorithm 323 related plane. 325 3.3.2. OSPFv3 LAN Adj-SID Sub-TLV 327 The existing LAN Adj-SID Sub-TLV has the following format: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | Flags | Weight | Algorithm | Reserved | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Neighbor ID | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | SID/Label/Index (variable) | 339 +---------------------------------------------------------------+ 341 Figure 6: OSPFv3 LAN Adj-SID Format 343 where: 345 Algorithm: The new Algorithm field contains the identifier of the 346 algorithm the router uses to apply algorithm specific QoS policy 347 configured on the adjacency. 349 For a broadcast link, an SR-capable router MAY allocate different 350 Adj-SID for different algorithm, if this link will join different 351 algorithm related plane. 353 4. Operations 355 The method introduced in this document enables the traffic of 356 different flex-algo plane to be distinguished on the same link, so 357 that these traffic can be applied with different QoS policy per 358 algorithm. 360 The endpoint of a link shared by multiple flex-algo plane can reserve 361 different queue resources for different algorithms locally, and 362 perform priority based queue scheduling and traffic shaping. This 363 algorithm related reserved information can be advertised to other 364 nodes in the network through some mechanism, therefore it has an 365 impact on the constraint based path calculation of the flex-algo 366 plane. How to allocate algorithm related resouce and advertise it in 367 the network is out the scope of this document. 369 Depending on the implementation, operators can configure multiple 370 Adacency-SIDs each for different algorithm on the same link. One of 371 the difficulties is that during this configuration phase it is not 372 straightforward for a link to be included in an FA plane, as this can 373 only be determined after all nodes in the network have negotiated the 374 FAD. A simple way is that as long as an IGP instance enable an FA 375 for a level/area, all links joined to that level/area should allocate 376 Adjacency-SIDs for that algorithm statically. Another way is to 377 allocate and withdraw Adjacency-SID per algorithm dynamically 378 according to the result of FAD negotiation. 380 The following figure shows an example of Adjacency-SID per algorithm. 382 [S1]--------[D]--------[S2] 383 | | | 384 | | | 385 | | | 386 [A]---------[B]--------[C] 388 Figure 7: Flex-algo LFA Path with Adjacency-SID per Algorithm 390 Suppose that node S1, A, B, D and their inter-connected links belongs 391 to FA-id 128 plane, and S2, B, C, D and their inter-connected links 392 belongs to FA-id 129 plane. The IGP metric of link B-D is 100, and 393 all other links have IGP metric 1. In FA-id 128 plane, from S1 to 394 destination D, the primary path is S1-D, and the TI-LFA backup path 395 is segment list {node(B), adjacency(B-D)}. Similarly, In FA-id 129 396 plane, from S2 to destination D, the primary path is S2-D, and the 397 TI-LFA backup path is segment list {node(B), adjacency(B-D)}. The 398 above TI-LFA path of FA-id 128 plane can be translated to {node- 399 SID(B)@FA-id128, adjacency-SID(B-D)@FA-id128}, and TI-LFA path of FA- 400 id 129 plane will be translate to {node-SID(B)@FA-id129, adjacency- 401 SID(B-D)@FA-id129}. So that node B can distinguish the flow of FA-id 402 128 and FA-id 129 based on different adjacency-SID(B-D), and take 403 different treatment (e.g., QoS policy) of them when they are send to 404 the same outgoing link B-D. 406 5. IANA Considerations 408 TBD 410 6. Security Considerations 412 There are no new security issues introduced by the extensions in this 413 document. Refer to [RFC8665], [RFC8666], [RFC8667] for other 414 security considerations. 416 7. Acknowledgements 418 TBD 420 8. Normative References 422 [I-D.ietf-lsr-flex-algo] 423 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 424 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 425 algo-13 (work in progress), October 2020. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, 430 . 432 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 433 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 434 RFC 4915, DOI 10.17487/RFC4915, June 2007, 435 . 437 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 438 Topology (MT) Routing in Intermediate System to 439 Intermediate Systems (IS-ISs)", RFC 5120, 440 DOI 10.17487/RFC5120, February 2008, 441 . 443 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 444 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 445 . 447 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 448 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 449 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 450 2015, . 452 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 453 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 454 May 2017, . 456 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 457 F. Baker, "OSPFv3 Link State Advertisement (LSA) 458 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 459 2018, . 461 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 462 Decraene, B., Litkowski, S., and R. Shakir, "Segment 463 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 464 July 2018, . 466 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 467 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 468 Extensions for Segment Routing", RFC 8665, 469 DOI 10.17487/RFC8665, December 2019, 470 . 472 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 473 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 474 December 2019, . 476 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 477 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 478 Extensions for Segment Routing", RFC 8667, 479 DOI 10.17487/RFC8667, December 2019, 480 . 482 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 483 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 484 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 485 December 2019, . 487 Authors' Addresses 489 Shaofu Peng 490 ZTE Corporation 491 China 493 Email: peng.shaofu@zte.com.cn 495 Ran Chen 496 ZTE Corporation 497 China 499 Email: chen.ran@zte.com.cn 501 Ketan Talaulikar 502 Cisco Systems 503 India 505 Email: ketant@cisco.com