idnits 2.17.00 (12 Aug 2021) /tmp/idnits2579/draft-yang-spring-ach6-sr-00.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 (July 12, 2021) is 306 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: 'RFC8402' is mentioned on line 81, but not defined -- Looks like a reference, but probably isn't: '0' on line 234 == Outdated reference: A later version (-13) exists of draft-ietf-6man-spring-srv6-oam-10 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-12 == Outdated reference: A later version (-03) exists of draft-ietf-spring-srv6-path-segment-00 == Outdated reference: A later version (-03) exists of draft-song-spring-siam-00 == Outdated reference: A later version (-01) exists of draft-yang-rtgwg-ipv6-associated-channel-00 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group F. Yang 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 13, 2022 July 12, 2021 7 ACH6 in Segment Routing 8 draft-yang-spring-ach6-sr-00 10 Abstract 12 Associated Channel over IPv6 (ACH6) provides a control channel to one 13 specific IPv6 forwarding path for control and management purpose. 14 When ACH6 is used in a Segment Routing network, it provides a control 15 channel to an SRv6 path. This document specifies an SRv6 ACH6 16 mechanism and describes how ACH6 is applied in a Segment Routing 17 network. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 23 "OPTIONAL" in this document are to be interpreted as described in BCP 24 14 [RFC2119] [RFC8174] when, and only when, they appear in all 25 capitals, as shown here. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 13, 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. ACH6 in Segment Routing . . . . . . . . . . . . . . . . . . . 3 63 2.1. ACH6 Network Reference Model in Segment Routing . . . . . 3 64 2.2. Identification of ACH6 in Segment Routing . . . . . . . . 4 65 2.3. ACH6 TLV Format in Segment Routing . . . . . . . . . . . 4 66 2.4. Encapsulation of ACH6 TLV in Segment Routing . . . . . . 5 67 3. Use Case of ACH6 in Segment Routing . . . . . . . . . . . . . 6 68 3.1. OAM to an SRv6 Path . . . . . . . . . . . . . . . . . . . 6 69 3.2. Protection to an SRv6 Path . . . . . . . . . . . . . . . 7 70 3.3. Resource Reservation to an SRv6 Path . . . . . . . . . . 8 71 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 7.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 Segment Routing [RFC8402] leverages the source routing paradigm. By 82 leveraging SR into IPv6 network, an ordered list of SRv6 SIDs 83 provides the certainty of a packet forwarding path as restricted to a 84 specific topological path. The Function part in SRv6 SIDs indicates 85 instructions to be executed on network nodes to achieve network 86 programming to an IPv6 forwarding path. 88 [I-D.yang-rtgwg-ipv6-associated-channel] proposes an Associated 89 Channel over IPv6 (ACH6) to provide a control channel to one specific 90 IPv6 forwarding path for control and management purpose. When ACH6 91 is used in a Segment Routing network, it provides a control channel 92 to an SRv6 path. This document specifies an SRv6 ACH6 mechanism and 93 describes how ACH6 is applied in a Segment Routing network. 95 2. ACH6 in Segment Routing 97 SRv6 ACH6 provides a control channel to carry control and management 98 messages to an SRv6 path separately from data forwarding. It is a 99 method to provide distributed control and management capabilities to 100 an SRv6 path, which complements the SDN centerialized control plane. 101 In SRv6 ACH6 control channel, different types of control and 102 management messages to an SRv6 path are carried. 104 2.1. ACH6 Network Reference Model in Segment Routing 106 In SRv6 network, IPv6 packet is generated and transported from one 107 SRv6 endpoint to another with an ordered list of SRv6 SIDs in Segment 108 Routing Header (SRH) [RFC8754]. SRv6 ACH6 is an inband path-based 109 control channel from one SRv6 endpoint to another. SRv6 ACH6 packet 110 is also encapsulated with an Segment Routing Header. To guarantee 111 ACH6 control packet is transported in the same path as data packets 112 forward, ACH6 packet uses the same SRv6 SID list with the one in SRH 113 of data packets associated with. 115 Figure 1 shows an ACH6 network reference model used in an SRv6 116 network. 118 SRv6 Endpoint SRv6 Endpoint SRv6 Endpoint 119 +----+ +-------+ +---------+ +------+ +----+ 120 ----| Ex |-----| ACH6 |------| ACH6 |------| ACH6 |------| Ey |---- 121 | | |Ingress| |Mid-Point| |Egress| | | 122 +----+ +-------+ +---------+ +------+ +----+ 123 |<-------------SRv6 Path-------------->| 124 |<-------------SRv6 ACH6 ------------->| 125 |<---------------------- SRv6 Domain ------------------------>| 127 Figure 1 ACH6 Network Reference Model in SRv6 129 Ex/Ey: SRv6 endpoint 131 ACH6 Ingress Node: is the node indicates the entering of control and 132 management channel over an SRv6 path, where control and management 133 messages are generated and encapsulated. ACH6 ingress node sets its 134 local IPv6 address as source address of ACH6 packet. 136 ACH6 Mid-Point Node: the SRv6 endpoints on SRv6 SID list of ACH6 137 control packet are ACH6 Mid-Point Node, which would process ACH6 138 packet when hop-by-hop processing on SRv6 endpoints is required by 139 ACH6 control channel. 141 ACH6 Egress Node: indicates the exiting of control and management 142 channel over an SRv6 path, where the control and management messages 143 are extracted and delivered to control or management plane for 144 further process. ACH6 egress node sets its local IPv6 address as 145 destination address of ACH6 packet. 147 2.2. Identification of ACH6 in Segment Routing 149 The Associated Channel ID is the identifier of ACH6 control channel, 150 and indicates the path which control channel is associated with. In 151 SRv6, Path Segment [I-D.ietf-spring-srv6-path-segment] is used to 152 identify a specific SRv6 path. It can also be used as Associated 153 Channel ID to identify the control channel of an SRv6 path. The 154 encoding of Path Segment and how Path Segment is allocated keeps same 155 specifications defined in [I-D.ietf-spring-srv6-path-segment]. 157 2.3. ACH6 TLV Format in Segment Routing 159 ACH6 TLV in Segment Routing is defined as: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type=TBD | length | Channel Type | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | ~ 167 ~ Value ~ 168 ~ | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 2 ACH6 TLV Format in SR 173 Type: 8 bits, indicates it is an ACH6 TLV. 175 Length: 8 bits, defines the length of Value field in bytes. 177 Channel Type: is a 16-bit-length fixed portion as a part of Value 178 field. It indicates the specific type of messages carried in SRv6 179 ACH6 control channel. Note that a new ACH TLV Channel Type Registry 180 would be requested to IANA. In later documents which specify 181 application protocols of associated channel, MUST also specify the 182 applicable Channel Type field value assigned by IANA. 184 Value: is a variable portion of Value field. It specifies the 185 messages indicated by Channel Type and carried in associated channel. 186 Note that the Value field of ACH6 TLV MAY contain sub-TLVs to provide 187 additional context information to ACH6 TLV. 189 2.4. Encapsulation of ACH6 TLV in Segment Routing 191 In SRv6, ACH6 control channel is used in either an end-to-end or a 192 hop-by-hop approach. 194 Regarding an end-to-end case, messages in ACH6 is encapsulated at 195 ACH6 ingress node and decapsulated at ACH6 egress node. ACH6 TLV is 196 recommended to be encapsulated in IPv6 Destination Options Header 197 places after the Segment Routing Header. An alternative way to carry 198 ACH6 TLV is using IPv6 payload. When ACH6 TLV format is encapsulated 199 in payload, TLV Type and Length can be omitted. The method of taking 200 advantage of SRH Flag field to indicate active probing packet 201 [I-D.song-spring-siam] can be used for ACH6 too. 203 Regarding a hop-by-hop case, messages in ACH6 is encapsulated at ACH6 204 ingress node. ACH6 mid-points decapsulate and re-capsulate every 205 ACH6 packet. At last, ACH6 egress node decapsulates ACH6 packet and 206 delivers control and management messages for further process. In 207 this case, ACH6 TLV is recommended to be encapsulated in IPv6 208 Destination Options Header preceding the Segment Routing Header. 210 The encapsulation of ACH6 in IPv6 Destination Options Header is 211 defined as: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 |Version| Traffic Class | Flow Label | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Payload Length | Next Header | Hop Limit | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 // Source Address // 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 // Destination Address // 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 224 | DOH TLV(ACH6) | Hdr Ext Len | Channel Type | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DOH1 226 | ~ (HbH 227 ~ Value (depends on the specific protocol) ~ case) 228 ~ | | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 230 | Next Header | Hdr Ext Len | Routing Type | Segments Left | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 232 | Last Entry | Flags | Tag | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 234 ~ Segment List[0] (128 bits) ~ SRH 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 236 ~ ... ~ | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 238 ~ Segment List[n] (128 bits) ~ | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 240 ~ Path Segment (128 bits) ~ | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 242 ~ SRH TLV (Optional,variable) ~ | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 244 | DOH TLV(ACH6) | Hdr Ext Len | Channel Type | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DOH2 246 | ~ (E2E 247 ~ Value (depends on the specific protocol) ~ case) 248 ~ | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 251 Figure 3 ACH6 TLV Encapsulation in SRv6 253 3. Use Case of ACH6 in Segment Routing 255 3.1. OAM to an SRv6 Path 257 In SRv6, several works are carrying on to establish an SRv6 OAM 258 toolset. [I-D.ietf-6man-spring-srv6-oam] provides the mechanisms of 259 continuity check, path discovery by reusing Ping and Traceroute, and 260 defines a sampling flag for flow information telemetry. Simple Two- 261 way Active Measurement Protocol (STAMP) [RFC8762] is encapsulated 262 after UDP header to measure performance metrics in SRv6 network. 263 [I-D.ietf-ippm-ioam-data] supports extensible data collection for 264 SRv6 network monitor and measurement. 266 ACH6 provides another method of supporting a group of OAM tools in a 267 unified TLV format. In this method, a toolset of OAM functions is 268 classified into three types of messages, including on-demand echo 269 request/reply, proactive continuity check, and performance 270 measurement. By using ACH6 to carry OAM messages, continuity check 271 and performance management can be monitored either hop-by-hop on 272 every SR endpoint or end-to-end from the first endpoint to the last. 273 Leveraging IPv6 extension headers to carry OAM messages can 274 facilitate data plane processing on OAM messages, and further improve 275 processing efficiency and accuracy. At last, by leveraging the 276 native semantics of IPv6 extension headers, this method can naturally 277 reduce OAM configuration and session management on SRv6 endpoints. 279 Figure 4 gives the example format of ACH6 OAM TLV. 281 0 1 2 3 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Channel Type = ODERR/PCC/PM | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | ~ 287 ~ OAM Message Body (Variable) ~ 288 ~ | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 4 ACH6 OAM TLV 293 ACH6 Channel Type to indicate which type of OAM message is 294 encapsulated in the following OAM message body, for example on demand 295 echo request/reply. OAM message can also re-utilize the format of 296 existing protocols. For example, BFD or STAMP protocol formats can 297 be encapsulated in IPv6 payload field after UDP header. 299 3.2. Protection to an SRv6 Path 301 Protection State Coordination (PSC) Protocol [RFC6378] provides a 302 single-phased coordination mechanism used for linear protection 303 between two endpoints. This coordination mechanism is useful when 304 there is a need of traffic to be transported on two co-routed paths. 305 In SRv6, active and backup candidate paths in SR policy can provide 306 an end-to-end protection to a specific SRv6 path. However, without a 307 coordination mechanism like PSC, SR policy cannot guarantee the 308 bidirectional traffics are transported on co-routed paths. 310 ACH6 extends PSC protocol to exchange notification and coordination 311 messages between SRv6 endpoints. An ordered segment list of working 312 path and an ordered segment list of backup path are separately pre- 313 created at the source and destination of an SRv6 path. Working paths 314 on two SRv6 endpoints are co-routed, so does backup paths. When 315 there is failure to indicate protection switchover on working path, 316 ACH6 exchanges protection state coordination messages between SRv6 317 endpoints to indicate synchronized switchover. When two SRv6 318 endpoints accomplish the switchover, the protection paths are co- 319 routed for bidirectional traffics. 321 Figure 5 gives the example format of ACH6 protection state 322 coordination TLV. 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Channel Type = PSC | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |Ver|Request|PT |R| Reserved1 | FPath | Path | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Optional TLVs | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Figure 5 ACH6 PSC TLV 336 The definition and usage of Request, PT, R, FPath and Path fields are 337 referenced to [RFC6378]. 339 3.3. Resource Reservation to an SRv6 Path 341 In current practice of SRv6, a distributed resource reservation 342 protocol like RSVP-TE is not used. SDN controller plays the role of 343 calculating forwarding path and reserving relevant resources to the 344 path. It is feasible for controller to calculate bandwidth and send 345 path setup information to headend via PCEP. But for the other 346 metrics e.g. queues, same parameter may have different formats and 347 values on each node. It is not effective for controller to 348 separately establish PCE session with each node to provision the 349 metrics. 351 The second reason to use a distributed messages exchange mechanism 352 among SRv6 endpoints is that modifications of path-based resource 353 reservation are required to be accomplished fast enough to guarantee 354 service's SLA when network failures happen, especially in the case 355 when thousands of services with independent resource reservations are 356 affected by the same failure on physical path. 358 A proposed hybrid structure of resource reservation in SRv6 network 359 is comprised of distributed ACH6 resource reservation mechanism and a 360 centralized stateful PCE [RFC8231]. 362 4. IANA Considerations 364 o This document requests IANA to assign a codepoint of Destination 365 Options Header TLVs to indicate ACH6 TLV. 367 o This document request IANA to create a new registry of ACH6 368 Channel Types to identify the usage of associated channel. 370 5. Security Considerations 372 TBD 374 6. Acknowledgements 376 TBD 378 7. References 380 7.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, 384 DOI 10.17487/RFC2119, March 1997, 385 . 387 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 388 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 389 May 2017, . 391 7.2. Informative References 393 [I-D.ietf-6man-spring-srv6-oam] 394 Ali, Z., Filsfils, C., Matsushima, S., Voyer, D., and M. 395 Chen, "Operations, Administration, and Maintenance (OAM) 396 in Segment Routing Networks with IPv6 Data plane (SRv6)", 397 draft-ietf-6man-spring-srv6-oam-10 (work in progress), 398 April 2021. 400 [I-D.ietf-ippm-ioam-data] 401 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 402 for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in 403 progress), February 2021. 405 [I-D.ietf-spring-srv6-path-segment] 406 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 407 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 408 ietf-spring-srv6-path-segment-00 (work in progress), 409 November 2020. 411 [I-D.song-spring-siam] 412 Song, H. and T. Pan, "SRv6 In-situ Active Measurement", 413 draft-song-spring-siam-00 (work in progress), December 414 2020. 416 [I-D.yang-rtgwg-ipv6-associated-channel] 417 Yang, F., Chen, M., and T. Zhou, "Associated Channel over 418 IPv6", draft-yang-rtgwg-ipv6-associated-channel-00 (work 419 in progress), February 2021. 421 [RFC6378] Weingarten, Y., Ed., Bryant, S., Osborne, E., Sprecher, 422 N., and A. Fulignoli, Ed., "MPLS Transport Profile (MPLS- 423 TP) Linear Protection", RFC 6378, DOI 10.17487/RFC6378, 424 October 2011, . 426 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 427 Computation Element Communication Protocol (PCEP) 428 Extensions for Stateful PCE", RFC 8231, 429 DOI 10.17487/RFC8231, September 2017, 430 . 432 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 433 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 434 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 435 . 437 [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple 438 Two-Way Active Measurement Protocol", RFC 8762, 439 DOI 10.17487/RFC8762, March 2020, 440 . 442 Authors' Addresses 444 Fan Yang 445 Huawei Technologies 446 Beijing 447 China 449 Email: shirley.yangfan@huawei.com 450 Tianran Zhou 451 Huawei Technologies 452 Beijing 453 China 455 Email: zhoutianran@huawei.com