idnits 2.17.1 draft-li-6man-ipv6-sfc-ifit-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1754 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.li-6man-enhanced-extension-header' is mentioned on line 262, but not defined == Unused Reference: 'I-D.guichard-spring-nsh-sr' is defined on line 397, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 446, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-21 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-06 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-01 == Outdated reference: A later version (-07) exists of draft-kumar-ippm-ifa-01 ** Downref: Normative reference to an Experimental draft: draft-kumar-ippm-ifa (ref. 'I-D.kumar-ippm-ifa') == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-04 ** Downref: Normative reference to an Informational draft: draft-song-ippm-postcard-based-telemetry (ref. 'I-D.song-ippm-postcard-based-telemetry') == Outdated reference: A later version (-21) exists of draft-song-opsawg-ifit-framework-02 ** Downref: Normative reference to an Informational draft: draft-song-opsawg-ifit-framework (ref. 'I-D.song-opsawg-ifit-framework') Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft S. Peng 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 9, 2020 July 8, 2019 7 IPv6 Encapsulation for SFC and IFIT 8 draft-li-6man-ipv6-sfc-ifit-01 10 Abstract 12 Service Function Chaining (SFC) and In-situ Flow Information 13 Telemetry (IFIT) are important path services along with the packets. 14 In order to support these services, several encapsulations have been 15 defined. The document analyzes the problems of these encapsulations 16 in the IPv6 scenario and proposes the possible optimized 17 encapsulation for IPv6. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 9, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Design Consideration . . . . . . . . . . . . . . . . . . . . 3 63 4.1. Service Options . . . . . . . . . . . . . . . . . . . . . 4 64 4.2. IPv6 Service Metadata Options . . . . . . . . . . . . . . 6 65 4.2.1. SFC Service Metadata Option . . . . . . . . . . . . . 6 66 4.2.2. IOAM Service Metadata Option . . . . . . . . . . . . 7 67 4.2.3. IFA Service Metadata Option . . . . . . . . . . . . . 8 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 7.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 Service Function Chaining (SFC) [RFC7665] and In-situ Flow 78 Information Telemetry (IFIT) [I-D.song-opsawg-ifit-framework] are 79 important path services along with the packets. In order to support 80 these services, several encapsulations have been defined. Network 81 Service Header (NSH) is defined in [RFC8300] as the encapsulation for 82 SFC. For IFIT encapsulations, In-situ OAM (iOAM) Header is defined 83 in [I-D.ietf-ippm-ioam-data] and Postcard-Based Telemetry (PBT) 84 Header is defined in [I-D.song-ippm-postcard-based-telemetry]. 85 Inband Flow Analyzer (IFA) is also defined in [I-D.kumar-ippm-ifa] to 86 record flow specific information from an end station and/or switches 87 across a network. In the application scenario of IPv6, these 88 encapsulations propose challenges for the data plane. The document 89 analyzes the problems and proposes the possible optimized 90 encapsulation for IPv6. 92 2. Terminology 94 SFC: Service Function Chaining 96 IFIT: In-situ Flow Information Telemetry 97 IOAM: In-situ OAM 99 PBT: Postcard-Based Telemetry 101 IFA: Inband Flow Analyzer 103 SRH: Segment Routing Header 105 3. Problem Statement 107 The problems posed by the current encapsulations for SFC and IFIT in 108 the application scenarios of IPv6 and SRv6 include: 110 1. According to the encapsulation order recommended in [RFC8200], if 111 the IOAM is encapsulated in the IPv6 Hop-by-Hop options header, in 112 the incremental trace mode of IOAM as the number of nodes traversed 113 by the IPv6 packets increases, the recorded IOAM information will 114 increase accordingly. This will increase the length of the Hop-by- 115 Hop options header and cause increasing difficulties in reading the 116 following Segment Routing Extension Header (SRH) 117 [I-D.ietf-6man-segment-routing-header] and thereby reduce the 118 forwarding performance of the data plane greatly. 120 2. With the introduction of SRv6 network programming 121 [I-D.ietf-spring-srv6-network-programming], the path services along 122 with the IPv6 packets can be processed at all the IPv6 network nodes 123 or only at the SRv6 enabled network nodes along the path. It is 124 necessary to distinguish the encapsulations for the specific path 125 service which should be processed by the IPv6 path or the SRv6 path. 127 3. Both NSH and IOAM need the Metadata field to record metadata 128 information. However currently these metadata has to be recorded 129 separately which may generate redundant metadata information or 130 increase the cost of process. 132 4. There is unnecessary inconsistency in the current encapsulations 133 for IOAM, IFA and PBT in the IPv6 scenario. Especially it seems 134 unnecessary to define a new specific IPv6 header for IFA, i.e. IFA 135 header. 137 4. Design Consideration 139 To solve the problems stated above, in the application scenarios of 140 IPv6 and SRv6, the encapsulations of SFC and IFIT can be optimized 141 with the following design considerations: 143 o To separate the SFC/IFIT path service into two parts, i.e. 144 instruction and recording parts. The instruction part (normally 145 with fixed length) can be placed in the front IPv6 extension 146 headers including Hop-by-Hop options header, Destination options 147 header, Routing header, etc. while the recording part can be 148 placed in the back IPv6 extension headers such as being placed 149 after IPv6 Routing Header. In this way the path service 150 instruction in the IPv6 extension headers can be fixed as much as 151 possible to facilitate hardware process to keep forwarding 152 performance while the SFC/IFIT metadata recording part is placed 153 afterwards which enables to stop recording when too much recording 154 information has to be carried to reach the limitation of hardware 155 process. 157 o To define SFC/IFIT path service instructions as IPv6 options 158 uniformly whichs can be placed either in the Hop-by-hop options 159 which indicates the path service processed by all IPv6 enabled 160 nodes along the path or in the SRH option TLVs which indicates the 161 path service processed only by the SRv6 nodes along the SRv6 path 162 indicated by the Segment List in the SRH. 164 o To define a unified IPv6 metadata header which can be used as a 165 container to record the service metadata of SFC, IFIT and other 166 possible path services. 168 According to the above design optimization consideration, in the 169 application scenarios of IPv6 and SRv6 the encapsulations for SFC and 170 IFIT can be defined as below. 172 4.1. Service Options 174 1. NSH Service Option 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Option Type | Opt Data Len | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Service Path Identifier | Service Index | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Figure 1. IPv6 Options with NSH instructions 188 Option Type: TBD_0 190 Opt Data Len: 8 octets. 192 Other fields: refer to [RFC8300]. 194 2. IOAM Service Option 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Option Type | Opt Data Len | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Namespace-ID |NodeLen | Flags | RemainingLen| 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | IOAM-Trace-Type | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2. IPv6 Options with IOAM instructions 208 Option Type: TBD_1 210 Opt Data Len: 8 octets. 212 Other fields: refer to [I-D.ietf-ippm-ioam-data]. 214 3. PBT Service Option 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Option Type | Opt Data Len | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Next Header | TIH Length | Reserved | Hop Count | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Flow ID | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Flow ID | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Sequence Number | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Data Set ID | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Figure 3. IPv6 Options with PBT instructions 234 Option Type: TBD_2 236 Opt Data Len: 20 octets. 238 Other fields: refer to [I-D.song-ippm-postcard-based-telemetry]. 240 4. IFA Service Option 241 0 1 2 3 242 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Option Type | Opt Data Len | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |Ver=2.0| GNS |NextHdr = IP_xx|R|R|R|M|T|I|T|C| Max Length | 247 | | | | | | |F|S| |A| | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 4. IPv6 Options with IFA instructions 251 Option Type: TBD_3 253 Opt Data Len: 4 octets. 255 Other fields: refer to [I-D.kumar-ippm-ifa]. 257 These options can be put in the IPv6 Hop-by-Hop Options Header or SRH 258 TLV. 260 4.2. IPv6 Service Metadata Options 262 As introduced in [I-D.li-6man-enhanced-extension-header], IPv6 263 Metadata Header is defined as a new type of IPv6 extension header. 264 The metadata is the information recorded by each hop for specific 265 path services, and carried in corresponding service metadata options. 266 The length of the metadata is variable. 268 4.2.1. SFC Service Metadata Option 270 For the SFC service, the corresponding SFC service metadata option is 271 defined as shown in Figure 5. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | SFC Type | Length | Reserved | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | SFC Metadata Class | Type |U| Length | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | Variable-Length Metadata | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 5. SFC Service Metadata 285 SFC Type 8-bit identifier of the service type, i.e. SFC. 286 The value is TBD-4. 288 Length 8-bit unsigned integer. Length of the 289 Service Metadata field, in octets. 291 Metadata Class Defines the scope of the Type field to 292 provide a hierarchical namespace. IANA has 293 set up the "NSH MD Class" registry, which 294 contains 16-bit values [RFC8300]. 296 Type Indicates the explicit type of metadata 297 being carried. The definition of the Type is 298 the responsibility of the MD Class owner. 300 Unassigned bit One unassigned bit is available for future use. 301 This bit MUST NOT be set, and it MUST be 302 ignored on receipt. 304 Length Indicates the length of the variable-length 305 metadata, in bytes. Detailed specification 306 in [RFC8300]. 308 4.2.2. IOAM Service Metadata Option 310 For the IOAM service, the corresponding IOAM service metadata option 311 is defined as shown in Figure 6. 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | IOAM Type | Length | Reserved | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 ~ ~ 319 | IOAM Service Metadata Options (variable) | 320 ~ ~ 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 6. IOAM Service Metadata 325 IOAM Type 8-bit identifier of the IOAM Service Metadata 326 type. The value is TBD-5. 328 Length 8-bit unsigned integer. Length of the 329 IOAM Service Metadata field, in octets. 331 RESERVED 8-bit reserved field MUST be set to zero upon 332 transmission and ignored upon receipt. 334 IOAM Service IOAM option data is present as specified by the 335 Metadata Options IOAM Type field, and is defined in Section 4 of 336 [I-D.ietf-ippm-ioam-data]. 338 All the IOAM IPv6 options require 4n alignment. This ensures that 4 339 octet fields specified in [I-D.ietf-ippm-ioam-data] such as transit 340 delay are aligned at a multiple-of-4 offset from the start of the 341 IPv6 Metadata header. 343 In addition, to maintain IPv6 extension header 8-octet alignment and 344 avoid the need to add or remove padding at every hop, the Trace-Type 345 for Incremental Tracing Option in IPv6 MUST be selected such that the 346 IOAM node data length is a multiple of 8-octets. 348 4.2.3. IFA Service Metadata Option 350 For the IOAM service, the corresponding IOAM service metadata option 351 is defined as shown in Figure 6. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | IFA Type | Length | Reserved | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 ~ ~ 359 | IFA Service Metadata Options (variable) | 360 ~ ~ 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 6. IFA Service Metadata 365 IFA Type 8-bit identifier of the IFA Service Metadata 366 type. The value is TBD-6. 368 Length 8-bit unsigned integer. Length of the 369 IOAM Service Metadata field, in octets. 371 RESERVED 8-bit reserved field MUST be set to zero upon 372 transmission and ignored upon receipt. 374 IFA Service IFA option data is present as specified by the 375 Metadata Options IFA Type field. 377 5. IANA Considerations 379 Value Description Reference 380 --------------------------------------------------------------------- 381 TBD_0 NSH Service Option [This draft] 382 TBD_1 IOAM Service Option [This draft] 383 TBD_2 PBT Service Option [This draft] 384 TBD_3 IFA Service Option [This draft] 385 TBD_4 SFC Service Metadata Type [This draft] 386 TBD_5 IOAM Service Metadata Type [This draft] 387 TBD_6 IFA Service Metadata Type [This draft] 389 6. Security Considerations 391 TBD. 393 7. References 395 7.1. Normative References 397 [I-D.guichard-spring-nsh-sr] 398 Guichard, J., Song, H., Tantsura, J., Halpern, J., 399 Henderickx, W., Boucadair, M., and S. Hassan, "NSH and 400 Segment Routing Integration for Service Function Chaining 401 (SFC)", draft-guichard-spring-nsh-sr-01 (work in 402 progress), March 2019. 404 [I-D.ietf-6man-segment-routing-header] 405 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 406 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 407 Routing Header (SRH)", draft-ietf-6man-segment-routing- 408 header-21 (work in progress), June 2019. 410 [I-D.ietf-ippm-ioam-data] 411 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 412 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 413 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 414 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 415 data-06 (work in progress), July 2019. 417 [I-D.ietf-spring-srv6-network-programming] 418 Filsfils, C., Camarillo, P., Leddy, J., 419 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 420 Network Programming", draft-ietf-spring-srv6-network- 421 programming-01 (work in progress), July 2019. 423 [I-D.kumar-ippm-ifa] 424 Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook, 425 H., Ghanwani, A., Cai, D., Ou, H., and L. Yizhou, "Inband 426 Flow Analyzer", draft-kumar-ippm-ifa-01 (work in 427 progress), February 2019. 429 [I-D.song-ippm-postcard-based-telemetry] 430 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 431 "Postcard-based On-Path Flow Data Telemetry", draft-song- 432 ippm-postcard-based-telemetry-04 (work in progress), June 433 2019. 435 [I-D.song-opsawg-ifit-framework] 436 Song, H., Li, Z., Zhou, T., Qin, F., Shin, J., and J. Jin, 437 "In-situ Flow Information Telemetry Framework", draft- 438 song-opsawg-ifit-framework-02 (work in progress), June 439 2019. 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, 443 DOI 10.17487/RFC2119, March 1997, 444 . 446 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 447 Writing an IANA Considerations Section in RFCs", BCP 26, 448 RFC 8126, DOI 10.17487/RFC8126, June 2017, 449 . 451 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 452 (IPv6) Specification", STD 86, RFC 8200, 453 DOI 10.17487/RFC8200, July 2017, 454 . 456 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 457 "Network Service Header (NSH)", RFC 8300, 458 DOI 10.17487/RFC8300, January 2018, 459 . 461 7.2. Informative References 463 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 464 Chaining (SFC) Architecture", RFC 7665, 465 DOI 10.17487/RFC7665, October 2015, 466 . 468 Authors' Addresses 470 Zhenbin Li 471 Huawei Technologies 472 Huawei Bld., No.156 Beiqing Rd. 473 Beijing 100095 474 China 476 Email: lizhenbin@huawei.com 478 Shuping Peng 479 Huawei Technologies 480 Huawei Bld., No.156 Beiqing Rd. 481 Beijing 100095 482 China 484 Email: pengshuping@huawei.com