idnits 2.17.1 draft-ietf-mpls-inband-pm-encapsulation-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 (April 11, 2021) is 1111 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 417, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'SPL' == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-11 == Outdated reference: A later version (-11) exists of draft-ietf-ippm-ioam-direct-export-02 == Outdated reference: A later version (-04) exists of draft-ietf-mpls-sfl-control-00 -- 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: October 13, 2021 ZTE Corp. 6 T. Zhou 7 Huawei 8 X. Dong 9 FiberHome 10 Y. Peleg 11 Broadcom 12 April 11, 2021 14 Encapsulation For MPLS Performance Measurement with Alternate Marking 15 Method 16 draft-ietf-mpls-inband-pm-encapsulation-01 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 October 13, 2021. 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 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 60 1.1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . 3 61 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 62 2. Flow-based PM Encapsulation in MPLS . . . . . . . . . . . . . 4 63 2.1. Examples for Applying Flow-ID Label in a label stack . . 5 64 3. Procedures of Encapsulation, Look-up and Decapsulation . . . 8 65 4. Procedures of Flow-ID allocation . . . . . . . . . . . . . . 9 66 5. FLC and FRLD Considerations . . . . . . . . . . . . . . . . . 10 67 6. Equal-Cost Multipath Considerations . . . . . . . . . . . . . 10 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 10.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 [RFC8321] describes a passive performance measurement method, which 79 can be used to measure packet loss, delay, and jitter on live 80 traffic. Since this method is based on marking consecutive batches 81 of packets, the method is often referred to as Alternate Marking 82 Method. [RFC8372] discusses the desired capabilities for MPLS flow 83 identification, in order to perform a better in-band performance 84 monitoring of user data packets. 86 This document defines the encapsulation for MPLS performance 87 measurement with alternate marking method, which performs flow-based 88 packet loss, delay, and jitter measurements on live traffic. The 89 encapsulation defined in this document supports monitoring at 90 intermediate nodes, as well as flow identification at both transport 91 and service label. 93 This document employs a method, other than Synonymous Flow Label 94 (SFL), to accomplish MPLS flow identification. The method described 95 in this document is complementary to the SFL method [RFC8957] 96 [I-D.ietf-mpls-sfl-control], the former mainly aims at hop-by-hop 97 performance measurement, and the latter mainly aims at end-to-end 98 performance measurement. Different sets of flows may use different 99 methods. 101 The method described in this document is also complementary to the 102 In-situ OAM method [I-D.ietf-ippm-ioam-data] 103 [I-D.ietf-ippm-ioam-direct-export], the former doesn't introduce any 104 new header whereas the latter introduces a new In-situ OAM header, 105 furthermore, the former requests the network nodes to report the data 106 used for performance measurement, and the latter requests the network 107 nodes to report the data used for operational and telemetry 108 information collection. One set of flows may use both of the two 109 methods concurrently. 111 1.1. Conventions Used in This Document 113 1.1.1. Abbreviations 115 ACL: Access Control List 117 cSPL: Composite Special Purpose Label 119 ECMP: Equal-Cost Multipath 121 ELC: Entropy Label Capability 123 ERLD: Entropy Readable Label Depth 125 eSPL: Extended Special Purpose Label 127 FLC: Flow-ID Label Capability 129 FLI: Flow-ID Label Indicator 131 FRLD: Flow-ID Readable Label Depth 133 LSP: Label Switched Path 135 MPLS: Multi-Protocol Label Switching 137 NMS: Network Management System 139 PHP: Penultimate Hop Popping 141 PM: Performance Measurement 143 PW: PseudoWire 144 SFL: Synonymous Flow Label 146 SID: Segment ID 148 SPL: Special Purpose Label 150 SR: Segment Routing 152 TC: Traffic Class 154 TTL: Time to Live 156 VC: Virtual Channel 158 VPN: Virtual Private Network 160 1.1.2. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in BCP 165 14 [RFC2119] [RFC8174] when, and only when, they appear in all 166 capitals, as shown here. 168 2. Flow-based PM Encapsulation in MPLS 170 Flow-based MPLS performance measurement encapsulation with alternate 171 marking method has the following format: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Extension Label (15) | TC |S| TTL | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Flow-ID Label Indicator (TBA1) | TC |S| TTL | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Flow-ID Label | TC |S| TTL | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Figure 1: Flow-based PM Encapsulation in MPLS 185 Flow-ID Label Indicator (FLI) is an Extended Special Purpose Label 186 (eSPL), which is combined with the Extension Label (XL, value 15) to 187 form a Composite Special Purpose Label (cSPL), as defined in 188 [RFC9017]. Flow-ID Label Indicator is defined in this document as 189 value TBA1. 191 Analogous to Entropy Label Indicator [RFC6790], the TC and TTL for 192 the Extension Label and the Flow-ID Label Indicator SHOULD follow the 193 same field values of that label immediately preceding the Extension 194 Label, otherwise, the TC and TTL for the Extension Label and the 195 Flow-ID Label Indicator MAY be different values if it is known that 196 the Extension Label will not be exposed as the top label at any point 197 along the LSP. The S bit for the Extension Label and the Flow-ID 198 Label Indicator MUST be zero. 200 Flow-ID label is used as MPLS flow identification [RFC8372], its 201 value should be unique within the administrative domain. Flow-ID 202 values can be allocated by an external NMS or a controller, based on 203 measurement object instance such as LSP or PW. There is a one-to-one 204 mapping between Flow-ID and flow. The specific method on how to 205 allocate the Flow-ID values is described in Section 4. 207 Analogous to Entropy Label [RFC6790], the Flow-ID label can be placed 208 at either the bottom or the middle of the MPLS label stack, and the 209 Flow-ID label MAY appear multiple times in a label stack. 210 Section 2.1 of this document provides several examples to illustrate 211 how to apply Flow-ID label in a label stack. Again analogous to 212 Entropy Label, the TTL for the Flow-ID label MUST be zero to ensure 213 that it is not used inadvertently for forwarding, the TC for the 214 Flow-ID label may be any value, the S bit for the Flow-ID Label 215 depends on whether or not there are more labels in the label stack. 217 Besides flow identification, a color-marking field is also necessary 218 for alternate marking method. To achieve the purpose of coloring the 219 MPLS traffic, the current practice when writing this document is to 220 reuse the Flow-ID label's TC, i.e., using TC's highest order two bits 221 (called double-marking methodology [RFC8321]) as color-marking bits. 222 Alternatively, allocating multiple Flow-ID labels to the same flow 223 may be used for the purpose of alternate marking. 225 2.1. Examples for Applying Flow-ID Label in a label stack 227 Three examples on different layout of Flow-ID label (4 octets) are 228 illustrated as follows: 230 (1) Layout of Flow-ID label when applied to MPLS transport. 232 +----------------------+ 233 | LSP | 234 | Label | 235 +----------------------+ 236 | Extension | <--+ 237 | Label | | 238 +----------------------+ |--- cSPL 239 | Flow-ID Label | | 240 | Indicator | <--+ 241 +----------------------+ 242 | Flow-ID | 243 | Label | 244 +----------------------+ 245 | Application | 246 | Label | 247 +----------------------+ <= Bottom of stack 248 | | 249 | Payload | 250 | | 251 +----------------------+ 253 Figure 2: Applying Flow-ID to MPLS transport 255 Note that here if penultimate hop popping (PHP) is in use, the PHP 256 LSR that recognizes the cSPL MAY choose not to pop the cSPL and the 257 following Flow-ID label, otherwise the egress LSR would be excluded 258 from the performance measurement. 260 Also note that in other examples of applying Flow-ID to MPLS 261 transport, one LSP label can be substituted by multiple SID labels in 262 the case of using SR Policy, and the combination of cSPL and Flow-ID 263 label can be placed between SID labels, as specified in Section 5. 265 (2) Layout of Flow-ID label when applied to MPLS service. 267 +----------------------+ 268 | LSP | 269 | Label | 270 +----------------------+ 271 | Application | 272 | Label | 273 +----------------------+ 274 | Extension | <--+ 275 | Label | | 276 +----------------------+ |--- cSPL 277 | Flow-ID Label | | 278 | Indicator | <--+ 279 +----------------------+ 280 | Flow-ID | 281 | Label | 282 +----------------------+ <= Bottom of stack 283 | | 284 | Payload | 285 | | 286 +----------------------+ 288 Figure 3: Applying Flow-ID to MPLS service 290 Note that here application label can be MPLS PW label, MPLS Ethernet 291 VPN label or MPLS IP VPN label, and it's also called VC label as 292 defined in [RFC4026]. 294 (3) Layout of Flow-ID label when applied to both MPLS transport and 295 MPLS service. 297 +----------------------+ 298 | LSP | 299 | Label | 300 +----------------------+ 301 | Extension | <--+ 302 | Label | | 303 +----------------------+ |--- cSPL 304 | Flow-ID Label | | 305 | Indicator | <--+ 306 +----------------------+ 307 | Flow-ID | 308 | Label | 309 +----------------------+ 310 | Application | 311 | Label | 312 +----------------------+ 313 | Extension | <--+ 314 | Label | | 315 +----------------------+ |--- cSPL 316 | Flow-ID Label | | 317 | Indicator | <--+ 318 +----------------------+ 319 | Flow-ID | 320 | Label | 321 +----------------------+ <= Bottom of stack 322 | | 323 | Payload | 324 | | 325 +----------------------+ 327 Figure 4: Applying Flow-ID to both MPLS transport and MPLS service 329 Note that for this example the two Flow-ID values appearing in a 330 label stack MUST be different, that is to say, Flow-ID label applied 331 to MPLS transport and Flow-ID label applied to MPLS service share the 332 same value space. Also note that the two Flow-ID label values are 333 independent from each other, e.g., two packets can belong to the same 334 VPN flow but to two different LSP flows, or two packets can belong to 335 two different VPN flows but to the same LSP flow. 337 3. Procedures of Encapsulation, Look-up and Decapsulation 339 The procedures for Flow-ID label encapsulation, look-up and 340 decapsulation are summarized as follows: 342 o The ingress node inserts the Extension Label, the Flow-ID Label 343 Indicator, alongside with the Flow-ID label, into the MPLS label 344 stack. At the same time, the ingress node sets the color-marking 345 field, as needed by alternate-marking technique, and sets the 346 Flow-ID value, as defined in this document. 348 o The transit nodes lookup the Flow-ID label with the help of the 349 Extension Label and the Flow-ID Label Indicator, and transmit the 350 collected information to an external NMS or a controller, which 351 includes the values of the block counters and the timestamps of 352 the marked packets, along with the value of the Flow-ID, referring 353 to the procedures of alternate marking method. Note that in order 354 to lookup the Flow-ID label, the transit nodes need to perform 355 some deep packet inspection beyond the label at the top of the 356 label stack used to take forwarding decisions. 358 o The egress node pops the Extension Label and the Flow-ID Label 359 Indicator, alongside with the Flow-ID label, from the MPLS label 360 stack. This document doesn't introduce any new procedure 361 regarding to the process of the decapsulated packet. 363 4. Procedures of Flow-ID allocation 365 There are two ways of allocating Flow-ID, one way is to allocate 366 Flow-ID by manual trigger from the network operator, and the other 367 way is to allocate Flow-ID by automatic trigger from the ingress 368 node, details are as follows: 370 o In the case of manual trigger, the network operator would manually 371 input the characteristics (e.g. IP five tuples and IP DSCP) of 372 the measured flow, then the NMS or the controller would generate 373 one or two Flow-IDs based on the input from the network operator, 374 and provision the ingress node with the characteristics of the 375 measured flow and the corresponding allocated Flow-ID(s). 377 o In the case of automatic trigger, the ingress node would identify 378 the flow entering the measured path, export the characteristics of 379 the identified flow to the NMS or the controller by IPFIX 380 [RFC7011], then the NMS or the controller would generate one or 381 two Flow-IDs based on the export from the ingress node, and 382 provision the ingress node with the characteristics of the 383 identified flow and the corresponding allocated Flow-ID(s). 385 The policy pre-configured at the NMS or the controller decides 386 whether one Flow-ID or two Flow-IDs would be generated. If the 387 performance measurement on MPLS service is enabled, then one Flow-ID 388 applied to MPLS service would be generated; if the performance 389 measurement on MPLS transport is enabled, then one Flow-ID applied to 390 MPLS transport would be generated; if both of them are enabled, then 391 two Flow-IDs respectively applied to MPLS service and MPLS transport 392 would be generated, in this case the transit nodes need to lookup 393 both of the two Flow-IDs by default, and that can be changed to e.g. 394 lookup only the Flow-ID applied to MPLS transport by configuration. 396 Whether using manual trigger or using automatic trigger, the NMS or 397 the controller MUST guarantee every generated Flow-ID is unique 398 within the administrative domain. 400 5. FLC and FRLD Considerations 402 Analogous to the Entropy Label Capability (ELC) defined in Section 5 403 of [RFC6790], and the Entropy Readable Label Depth (ERLD) defined in 404 Section 4 of [RFC8662], the Flow-ID Label Capability (FLC) and the 405 Flow-ID Readable Label Depth (FRLD) are defined in this document. 406 Both FLC and FRLD have the similar semantics with ELC and ERLD to a 407 router, except that the Flow-ID is used in its flow identification 408 function while the Entropy is used in its load-balancing function. 410 The ingress node MUST insert each Flow-ID label at an appropriate 411 depth, which ensures the node that needs to process the Flow-ID label 412 has the FLC. The ingress node SHOULD insert each Flow-ID label 413 within an appropriate FRLD, which is the minimum FRLD of all on-path 414 nodes that needs to read and use the Flow-ID label in question. How 415 the ingress node knows the Flow-ID label processing node has the FLC 416 and the appropriate FRLD for each Flow-ID label are outside the scope 417 of this document, whereas [I-D.xzc-lsr-mpls-flc-flrd] provides a 418 method to achieve that. 420 When SR paths are used as transport, the label stack grows as the 421 number of on-path segments increases, if the number of on-path 422 segments is high, that may become a challenge for the Flow-ID label 423 to be placed within an appropriate FRLD. In order to overcome this 424 potential challenge, an implementation MAY provide flexibility to the 425 ingress node to place Flow-ID label between SID labels, i.e., 426 multiple identical Flow-ID labels at different depths MAY be 427 interleaved with SID labels, when that happens a sophisticated 428 network planning may be needed and it's beyond the scope of this 429 document. 431 6. Equal-Cost Multipath Considerations 433 Analogous to what's described in Section 5 of [RFC8957], under 434 conditions of Equal-Cost Multipath (ECMP), the introduction of a 435 Flow-ID label may cause the same problem as the introduction of an 436 SFL, and the two solutions proposed for the problem caused by the 437 introduction of SFL would also apply here. 439 7. Security Considerations 441 This document introduces the performance measurement domain that is 442 the scope of a Flow-ID label. The Flow-ID Label Indicator and Flow- 443 ID label MUST NOT be signaled and distributed outside one performance 444 measurement domain. Improper configuration so that the Flow-ID label 445 being passed from one domain to another would likely result in 446 potential Flow-ID conflicts. 448 To prevent packets carrying Flow-ID label from leaking from one 449 domain to another, the domain boundary nodes SHOULD deploy some 450 policies (e.g., ACL) to filter out the packets. Specifically, in the 451 sending end, the domain boundary node SHOULD filter out the packets 452 that carry the Flow-ID Label Indicator and are sent to other domain; 453 in the receiving end, the domain boundary node SHOULD drop the 454 packets that carry the Flow-ID Label Indicator and are from other 455 domains. 457 8. IANA Considerations 459 In the Special-Purpose MPLS Label Values registry defined in [SPL], a 460 new Extended Special-Purpose MPLS Label Value for Flow-ID Label 461 Indicator is requested from IANA as follows: 463 +-----------------------+----------------+--------------+-----------+ 464 | Extended Special- | Description | Semantics | Reference | 465 | Purpose MPLS Label | | Definition | | 466 | Value | | | | 467 +-----------------------+----------------+--------------+-----------+ 468 | TBA1 | Flow-ID Label | Section 2 | This | 469 | | Indicator | | Document | 470 +-----------------------+----------------+--------------+-----------+ 472 Table 1: New Extended Special-Purpose MPLS Label Value for Flow-ID 473 Label Indicator 475 9. Acknowledgements 477 The authors would like to acknowledge Loa Andersson, Tarek Saad, 478 Stewart Bryant, Rakesh Gandhi, Greg Mirsky, Aihua Liu, Shuangping 479 Zhan and Ming Ke for their careful review and very helpful comments. 481 The authors would like to acknowledge Italo Busi and Chandrasekar 482 Ramachandran for their insightful MPLS-RT review and very helpful 483 comments. 485 10. References 487 10.1. Normative References 489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 490 Requirement Levels", BCP 14, RFC 2119, 491 DOI 10.17487/RFC2119, March 1997, 492 . 494 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 495 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 496 May 2017, . 498 [SPL] IANA, "Special-Purpose Multiprotocol Label Switching 499 (MPLS) Label Values", 500 . 502 10.2. Informative References 504 [I-D.ietf-ippm-ioam-data] 505 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 506 for In-situ OAM", draft-ietf-ippm-ioam-data-11 (work in 507 progress), November 2020. 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", draft-ietf-ippm-ioam-direct- 513 export-02 (work in progress), November 2020. 515 [I-D.ietf-mpls-sfl-control] 516 Bryant, S., Swallow, G., and S. Sivabalan, "A Simple 517 Control Protocol for MPLS SFLs", draft-ietf-mpls-sfl- 518 control-00 (work in progress), January 2021. 520 [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual 521 Private Network (VPN) Terminology", RFC 4026, 522 DOI 10.17487/RFC4026, March 2005, 523 . 525 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 526 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 527 RFC 6790, DOI 10.17487/RFC6790, November 2012, 528 . 530 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 531 "Specification of the IP Flow Information Export (IPFIX) 532 Protocol for the Exchange of Flow Information", STD 77, 533 RFC 7011, DOI 10.17487/RFC7011, September 2013, 534 . 536 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 537 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 538 "Alternate-Marking Method for Passive and Hybrid 539 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 540 January 2018, . 542 [RFC8372] Bryant, S., Pignataro, C., Chen, M., Li, Z., and G. 543 Mirsky, "MPLS Flow Identification Considerations", 544 RFC 8372, DOI 10.17487/RFC8372, May 2018, 545 . 547 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 548 Shakir, R., and J. Tantsura, "Entropy Label for Source 549 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 550 DOI 10.17487/RFC8662, December 2019, 551 . 553 [RFC8957] Bryant, S., Chen, M., Swallow, G., Sivabalan, S., and G. 554 Mirsky, "Synonymous Flow Label Framework", RFC 8957, 555 DOI 10.17487/RFC8957, January 2021, 556 . 558 [RFC9017] Andersson, L., Kompella, K., and A. Farrel, "Special- 559 Purpose Label Terminology", RFC 9017, 560 DOI 10.17487/RFC9017, April 2021, 561 . 563 Authors' Addresses 565 Weiqiang Cheng 566 China Mobile 567 Beijing 568 China 570 Email: chengweiqiang@chinamobile.com 571 Xiao Min 572 ZTE Corp. 573 Nanjing 574 China 576 Email: xiao.min2@zte.com.cn 578 Tianran Zhou 579 Huawei 580 Beijing 581 China 583 Email: zhoutianran@huawei.com 585 Ximing Dong 586 FiberHome 587 Wuhan 588 China 590 Email: dxm@fiberhome.com 592 Yoav Peleg 593 Broadcom 594 USA 596 Email: yoav.peleg@broadcom.com