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