idnits 2.17.1 draft-ietf-mpls-inband-pm-encapsulation-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 (25 October 2021) is 911 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'I-D.xzc-lsr-mpls-flc-flrd' is mentioned on line 416, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'SPL' == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-15 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-07 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-sfl-control-01 -- Obsolete informational reference (is this intentional?): RFC 8321 (Obsoleted by RFC 9341) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group W. Cheng 3 Internet-Draft China Mobile 4 Intended status: Standards Track X. Min 5 Expires: 28 April 2022 ZTE Corp. 6 T. Zhou 7 Huawei 8 X. Dong 9 FiberHome 10 Y. Peleg 11 Broadcom 12 25 October 2021 14 Encapsulation For MPLS Performance Measurement with Alternate Marking 15 Method 16 draft-ietf-mpls-inband-pm-encapsulation-02 18 Abstract 20 This document defines the encapsulation for MPLS performance 21 measurement with alternate marking method, which performs flow-based 22 packet loss, delay, and jitter measurements on live traffic. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 28 April 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 59 1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 3 60 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 61 2. Flow-based PM Encapsulation in MPLS . . . . . . . . . . . . . 4 62 2.1. Examples for Applying Flow-ID Label in a label stack . . 5 63 3. Procedures of Encapsulation, Look-up and Decapsulation . . . 8 64 4. Procedures of Flow-ID allocation . . . . . . . . . . . . . . 9 65 5. FLC and FRLD Considerations . . . . . . . . . . . . . . . . . 10 66 6. Equal-Cost Multipath Considerations . . . . . . . . . . . . . 10 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 72 10.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 75 1. Introduction 77 [RFC8321] describes a passive performance measurement method, which 78 can be used to measure packet loss, delay, and jitter on live 79 traffic. Since this method is based on marking consecutive batches 80 of packets, the method is often referred to as Alternate Marking 81 Method. [RFC8372] discusses the desired capabilities for MPLS flow 82 identification, in order to perform a better in-band performance 83 monitoring of user data packets. 85 This document defines the encapsulation for MPLS performance 86 measurement with alternate marking method, which performs flow-based 87 packet loss, delay, and jitter measurements on live traffic. The 88 encapsulation defined in this document supports monitoring at 89 intermediate nodes, as well as flow identification at both transport 90 and service label. 92 This document employs a method, other than Synonymous Flow Label 93 (SFL), to accomplish MPLS flow identification. The method described 94 in this document is complementary to the SFL method [RFC8957] 95 [I-D.ietf-mpls-sfl-control], the former mainly aims at hop-by-hop 96 performance measurement, and the latter mainly aims at end-to-end 97 performance measurement. Different sets of flows may use different 98 methods. 100 The method described in this document is also complementary to the 101 In-situ OAM method [I-D.ietf-ippm-ioam-data] 102 [I-D.ietf-ippm-ioam-direct-export], the former doesn't introduce any 103 new header whereas the latter introduces a new In-situ OAM header, 104 furthermore, the former requests the network nodes to report the data 105 used for performance measurement, and the latter requests the network 106 nodes to report the data used for operational and telemetry 107 information collection. One set of flows may use both of the two 108 methods concurrently. 110 1.1. Conventions Used in This Document 112 1.1.1. Abbreviations 114 ACL: Access Control List 116 cSPL: Composite Special Purpose Label 118 ECMP: Equal-Cost Multipath 120 ELC: Entropy Label Capability 122 ERLD: Entropy Readable Label Depth 124 eSPL: Extended Special Purpose Label 126 FLC: Flow-ID Label Capability 128 FLI: Flow-ID Label Indicator 130 FRLD: Flow-ID Readable Label Depth 132 LSP: Label Switched Path 134 MPLS: Multi-Protocol Label Switching 136 NMS: Network Management System 138 PHP: Penultimate Hop Popping 139 PM: Performance Measurement 141 PW: PseudoWire 143 SFL: Synonymous Flow Label 145 SID: Segment ID 147 SPL: Special Purpose Label 149 SR: Segment Routing 151 TC: Traffic Class 153 TTL: Time to Live 155 VC: Virtual Channel 157 VPN: Virtual Private Network 159 1.1.2. Requirements Language 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in BCP 164 14 [RFC2119] [RFC8174] when, and only when, they appear in all 165 capitals, as shown here. 167 2. Flow-based PM Encapsulation in MPLS 169 Flow-based MPLS performance measurement encapsulation with alternate 170 marking method has the following format: 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Extension Label (15) | TC |S| TTL | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Flow-ID Label Indicator (TBA1) | TC |S| TTL | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Flow-ID Label | TC |S| TTL | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 Figure 1: Flow-based PM Encapsulation in MPLS 184 Flow-ID Label Indicator (FLI) is an Extended Special Purpose Label 185 (eSPL), which is combined with the Extension Label (XL, value 15) to 186 form a Composite Special Purpose Label (cSPL), as defined in 187 [RFC9017]. Flow-ID Label Indicator is defined in this document as 188 value TBA1. 190 Analogous to Entropy Label Indicator [RFC6790], the TC and TTL for 191 the Extension Label and the Flow-ID Label Indicator SHOULD follow the 192 same field values of that label immediately preceding the Extension 193 Label, otherwise, the TC and TTL for the Extension Label and the 194 Flow-ID Label Indicator MAY be different values if it is known that 195 the Extension Label will not be exposed as the top label at any point 196 along the LSP. The S bit for the Extension Label and the Flow-ID 197 Label Indicator MUST be zero. 199 Flow-ID label is used as MPLS flow identification [RFC8372], its 200 value should be unique within the administrative domain. Flow-ID 201 values can be allocated by an external NMS or a controller, based on 202 measurement object instance such as LSP or PW. There is a one-to-one 203 mapping between Flow-ID and flow. The specific method on how to 204 allocate the Flow-ID values is described in Section 4. 206 Analogous to Entropy Label [RFC6790], the Flow-ID label can be placed 207 at either the bottom or the middle of the MPLS label stack, and the 208 Flow-ID label MAY appear multiple times in a label stack. 209 Section 2.1 of this document provides several examples to illustrate 210 how to apply Flow-ID label in a label stack. Again analogous to 211 Entropy Label, the TTL for the Flow-ID label MUST be zero to ensure 212 that it is not used inadvertently for forwarding, the TC for the 213 Flow-ID label may be any value, the S bit for the Flow-ID Label 214 depends on whether or not there are more labels in the label stack. 216 Besides flow identification, a color-marking field is also necessary 217 for alternate marking method. To achieve the purpose of coloring the 218 MPLS traffic, the current practice when writing this document is to 219 reuse the Flow-ID label's TC, i.e., using TC's highest order two bits 220 (called double-marking methodology [RFC8321]) as color-marking bits. 221 Alternatively, allocating multiple Flow-ID labels to the same flow 222 may be used for the purpose of alternate marking. 224 2.1. Examples for Applying Flow-ID Label in a label stack 226 Three examples on different layout of Flow-ID label (4 octets) are 227 illustrated as follows: 229 (1) Layout of Flow-ID label when applied to MPLS transport. 231 +----------------------+ 232 | LSP | 233 | Label | 234 +----------------------+ 235 | Extension | <--+ 236 | Label | | 237 +----------------------+ |--- cSPL 238 | Flow-ID Label | | 239 | Indicator | <--+ 240 +----------------------+ 241 | Flow-ID | 242 | Label | 243 +----------------------+ 244 | Application | 245 | Label | 246 +----------------------+ <= Bottom of stack 247 | | 248 | Payload | 249 | | 250 +----------------------+ 252 Figure 2: Applying Flow-ID to MPLS transport 254 Note that here if penultimate hop popping (PHP) is in use, the PHP 255 LSR that recognizes the cSPL MAY choose not to pop the cSPL and the 256 following Flow-ID label, otherwise the egress LSR would be excluded 257 from the performance measurement. 259 Also note that in other examples of applying Flow-ID to MPLS 260 transport, one LSP label can be substituted by multiple SID labels in 261 the case of using SR Policy, and the combination of cSPL and Flow-ID 262 label can be placed between SID labels, as specified in Section 5. 264 (2) Layout of Flow-ID label when applied to MPLS service. 266 +----------------------+ 267 | LSP | 268 | Label | 269 +----------------------+ 270 | Application | 271 | Label | 272 +----------------------+ 273 | Extension | <--+ 274 | Label | | 275 +----------------------+ |--- cSPL 276 | Flow-ID Label | | 277 | Indicator | <--+ 278 +----------------------+ 279 | Flow-ID | 280 | Label | 281 +----------------------+ <= Bottom of stack 282 | | 283 | Payload | 284 | | 285 +----------------------+ 287 Figure 3: Applying Flow-ID to MPLS service 289 Note that here application label can be MPLS PW label, MPLS Ethernet 290 VPN label or MPLS IP VPN label, and it's also called VC label as 291 defined in [RFC4026]. 293 (3) Layout of Flow-ID label when applied to both MPLS transport and 294 MPLS service. 296 +----------------------+ 297 | LSP | 298 | Label | 299 +----------------------+ 300 | Extension | <--+ 301 | Label | | 302 +----------------------+ |--- cSPL 303 | Flow-ID Label | | 304 | Indicator | <--+ 305 +----------------------+ 306 | Flow-ID | 307 | Label | 308 +----------------------+ 309 | Application | 310 | Label | 311 +----------------------+ 312 | Extension | <--+ 313 | Label | | 314 +----------------------+ |--- cSPL 315 | Flow-ID Label | | 316 | Indicator | <--+ 317 +----------------------+ 318 | Flow-ID | 319 | Label | 320 +----------------------+ <= Bottom of stack 321 | | 322 | Payload | 323 | | 324 +----------------------+ 326 Figure 4: Applying Flow-ID to both MPLS transport and MPLS service 328 Note that for this example the two Flow-ID values appearing in a 329 label stack MUST be different, that is to say, Flow-ID label applied 330 to MPLS transport and Flow-ID label applied to MPLS service share the 331 same value space. Also note that the two Flow-ID label values are 332 independent from each other, e.g., two packets can belong to the same 333 VPN flow but to two different LSP flows, or two packets can belong to 334 two different VPN flows but to the same LSP flow. 336 3. Procedures of Encapsulation, Look-up and Decapsulation 338 The procedures for Flow-ID label encapsulation, look-up and 339 decapsulation are summarized as follows: 341 * The ingress node inserts the Extension Label, the Flow-ID Label 342 Indicator, alongside with the Flow-ID label, into the MPLS label 343 stack. At the same time, the ingress node sets the color-marking 344 field, as needed by alternate-marking technique, and sets the 345 Flow-ID value, as defined in this document. 347 * The transit nodes lookup the Flow-ID label with the help of the 348 Extension Label and the Flow-ID Label Indicator, and transmit the 349 collected information to an external NMS or a controller, which 350 includes the values of the block counters and the timestamps of 351 the marked packets, along with the value of the Flow-ID, referring 352 to the procedures of alternate marking method. Note that in order 353 to lookup the Flow-ID label, the transit nodes need to perform 354 some deep packet inspection beyond the label at the top of the 355 label stack used to take forwarding decisions. 357 * The egress node pops the Extension Label and the Flow-ID Label 358 Indicator, alongside with the Flow-ID label, from the MPLS label 359 stack. This document doesn't introduce any new procedure 360 regarding to the process of the decapsulated packet. 362 4. Procedures of Flow-ID allocation 364 There are two ways of allocating Flow-ID, one way is to allocate 365 Flow-ID by manual trigger from the network operator, and the other 366 way is to allocate Flow-ID by automatic trigger from the ingress 367 node, details are as follows: 369 * In the case of manual trigger, the network operator would manually 370 input the characteristics (e.g. IP five tuples and IP DSCP) of 371 the measured flow, then the NMS or the controller would generate 372 one or two Flow-IDs based on the input from the network operator, 373 and provision the ingress node with the characteristics of the 374 measured flow and the corresponding allocated Flow-ID(s). 376 * In the case of automatic trigger, the ingress node would identify 377 the flow entering the measured path, export the characteristics of 378 the identified flow to the NMS or the controller by IPFIX 379 [RFC7011], then the NMS or the controller would generate one or 380 two Flow-IDs based on the export from the ingress node, and 381 provision the ingress node with the characteristics of the 382 identified flow and the corresponding allocated Flow-ID(s). 384 The policy pre-configured at the NMS or the controller decides 385 whether one Flow-ID or two Flow-IDs would be generated. If the 386 performance measurement on MPLS service is enabled, then one Flow-ID 387 applied to MPLS service would be generated; if the performance 388 measurement on MPLS transport is enabled, then one Flow-ID applied to 389 MPLS transport would be generated; if both of them are enabled, then 390 two Flow-IDs respectively applied to MPLS service and MPLS transport 391 would be generated, in this case the transit nodes need to lookup 392 both of the two Flow-IDs by default, and that can be changed to e.g. 393 lookup only the Flow-ID applied to MPLS transport by configuration. 395 Whether using manual trigger or using automatic trigger, the NMS or 396 the controller MUST guarantee every generated Flow-ID is unique 397 within the administrative domain. 399 5. FLC and FRLD Considerations 401 Analogous to the Entropy Label Capability (ELC) defined in Section 5 402 of [RFC6790], and the Entropy Readable Label Depth (ERLD) defined in 403 Section 4 of [RFC8662], the Flow-ID Label Capability (FLC) and the 404 Flow-ID Readable Label Depth (FRLD) are defined in this document. 405 Both FLC and FRLD have the similar semantics with ELC and ERLD to a 406 router, except that the Flow-ID is used in its flow identification 407 function while the Entropy is used in its load-balancing function. 409 The ingress node MUST insert each Flow-ID label at an appropriate 410 depth, which ensures the node that needs to process the Flow-ID label 411 has the FLC. The ingress node SHOULD insert each Flow-ID label 412 within an appropriate FRLD, which is the minimum FRLD of all on-path 413 nodes that needs to read and use the Flow-ID label in question. How 414 the ingress node knows the Flow-ID label processing node has the FLC 415 and the appropriate FRLD for each Flow-ID label are outside the scope 416 of this document, whereas [I-D.xzc-lsr-mpls-flc-flrd] provides a 417 method to achieve that. 419 When SR paths are used as transport, the label stack grows as the 420 number of on-path segments increases, if the number of on-path 421 segments is high, that may become a challenge for the Flow-ID label 422 to be placed within an appropriate FRLD. In order to overcome this 423 potential challenge, an implementation MAY provide flexibility to the 424 ingress node to place Flow-ID label between SID labels, i.e., 425 multiple identical Flow-ID labels at different depths MAY be 426 interleaved with SID labels, when that happens a sophisticated 427 network planning may be needed and it's beyond the scope of this 428 document. 430 6. Equal-Cost Multipath Considerations 432 Analogous to what's described in Section 5 of [RFC8957], under 433 conditions of Equal-Cost Multipath (ECMP), the introduction of a 434 Flow-ID label may cause the same problem as the introduction of an 435 SFL, and the two solutions proposed for the problem caused by the 436 introduction of SFL would also apply here. 438 7. Security Considerations 440 This document introduces the performance measurement domain that is 441 the scope of a Flow-ID label. The Flow-ID Label Indicator and Flow- 442 ID label MUST NOT be signaled and distributed outside one performance 443 measurement domain. Improper configuration so that the Flow-ID label 444 being passed from one domain to another would likely result in 445 potential Flow-ID conflicts. 447 To prevent packets carrying Flow-ID label from leaking from one 448 domain to another, the domain boundary nodes SHOULD deploy some 449 policies (e.g., ACL) to filter out the packets. Specifically, in the 450 sending end, the domain boundary node SHOULD filter out the packets 451 that carry the Flow-ID Label Indicator and are sent to other domain; 452 in the receiving end, the domain boundary node SHOULD drop the 453 packets that carry the Flow-ID Label Indicator and are from other 454 domains. 456 8. IANA Considerations 458 In the Special-Purpose MPLS Label Values registry defined in [SPL], a 459 new Extended Special-Purpose MPLS Label Value for Flow-ID Label 460 Indicator is requested from IANA as follows: 462 +==========================+===============+============+===========+ 463 | Extended Special-Purpose | Description | Semantics | Reference | 464 | MPLS Label Value | | Definition | | 465 +==========================+===============+============+===========+ 466 | TBA1 | Flow-ID | Section 2 | This | 467 | | Label | | Document | 468 | | Indicator | | | 469 +--------------------------+---------------+------------+-----------+ 471 Table 1: New Extended Special-Purpose MPLS Label Value for Flow- 472 ID Label Indicator 474 9. Acknowledgements 476 The authors would like to acknowledge Loa Andersson, Tarek Saad, 477 Stewart Bryant, Rakesh Gandhi, Greg Mirsky, Aihua Liu, Shuangping 478 Zhan and Ming Ke for their careful review and very helpful comments. 480 The authors would like to acknowledge Italo Busi and Chandrasekar 481 Ramachandran for their insightful MPLS-RT review and very helpful 482 comments. 484 10. References 485 10.1. Normative References 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, 489 DOI 10.17487/RFC2119, March 1997, 490 . 492 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 493 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 494 May 2017, . 496 [SPL] IANA, "Special-Purpose Multiprotocol Label Switching 497 (MPLS) Label Values", 498 . 500 10.2. Informative References 502 [I-D.ietf-ippm-ioam-data] 503 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 504 for In-situ OAM", Work in Progress, Internet-Draft, draft- 505 ietf-ippm-ioam-data-15, 3 October 2021, 506 . 509 [I-D.ietf-ippm-ioam-direct-export] 510 Song, H., Gafni, B., Zhou, T., Li, Z., Brockners, F., 511 Bhandari, S., Sivakolundu, R., and T. Mizrahi, "In-situ 512 OAM Direct Exporting", Work in Progress, Internet-Draft, 513 draft-ietf-ippm-ioam-direct-export-07, 13 October 2021, 514 . 517 [I-D.ietf-mpls-sfl-control] 518 Bryant, S., Swallow, G., and S. Sivabalan, "A Simple 519 Control Protocol for MPLS SFLs", Work in Progress, 520 Internet-Draft, draft-ietf-mpls-sfl-control-01, 10 July 521 2021, . 524 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 525 Private Network (VPN) Terminology", RFC 4026, 526 DOI 10.17487/RFC4026, March 2005, 527 . 529 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 530 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 531 RFC 6790, DOI 10.17487/RFC6790, November 2012, 532 . 534 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 535 "Specification of the IP Flow Information Export (IPFIX) 536 Protocol for the Exchange of Flow Information", STD 77, 537 RFC 7011, DOI 10.17487/RFC7011, September 2013, 538 . 540 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 541 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 542 "Alternate-Marking Method for Passive and Hybrid 543 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 544 January 2018, . 546 [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 547 Mirsky, "MPLS Flow Identification Considerations", 548 RFC 8372, DOI 10.17487/RFC8372, May 2018, 549 . 551 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 552 Shakir, R., and J. Tantsura, "Entropy Label for Source 553 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 554 DOI 10.17487/RFC8662, December 2019, 555 . 557 [RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. 558 Mirsky, "Synonymous Flow Label Framework", RFC 8957, 559 DOI 10.17487/RFC8957, January 2021, 560 . 562 [RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special- 563 Purpose Label Terminology", RFC 9017, 564 DOI 10.17487/RFC9017, April 2021, 565 . 567 Authors' Addresses 569 Weiqiang Cheng 570 China Mobile 571 Beijing 572 China 574 Email: chengweiqiang@chinamobile.com 576 Xiao Min 577 ZTE Corp. 578 Nanjing 579 China 580 Email: xiao.min2@zte.com.cn 582 Tianran Zhou 583 Huawei 584 Beijing 585 China 587 Email: zhoutianran@huawei.com 589 Ximing Dong 590 FiberHome 591 Wuhan 592 China 594 Email: dxm@fiberhome.com 596 Yoav Peleg 597 Broadcom 598 United States of America 600 Email: yoav.peleg@broadcom.com