idnits 2.17.1 draft-li-6man-ipv6-sfc-ifit-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 : ---------------------------------------------------------------------------- ** 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 (September 10, 2019) is 1683 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 264, but not defined == Unused Reference: 'I-D.guichard-spring-nsh-sr' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC8126' is defined on line 448, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-22 == 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-04 ** 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: March 13, 2020 K. LEE 6 LG U+ 7 September 10, 2019 9 IPv6 Encapsulation for SFC and IFIT 10 draft-li-6man-ipv6-sfc-ifit-02 12 Abstract 14 Service Function Chaining (SFC) and In-situ Flow Information 15 Telemetry (IFIT) are important path services along with the packets. 16 In order to support these services, several encapsulations have been 17 defined. The document analyzes the problems of these encapsulations 18 in the IPv6 scenario and proposes the possible optimized 19 encapsulation for IPv6. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 March 13, 2020. 44 Copyright Notice 46 Copyright (c) 2019 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 64 4. Design Consideration . . . . . . . . . . . . . . . . . . . . 4 65 4.1. Service Options . . . . . . . . . . . . . . . . . . . . . 4 66 4.2. IPv6 Service Metadata Options . . . . . . . . . . . . . . 7 67 4.2.1. SFC Service Metadata Option . . . . . . . . . . . . . 7 68 4.2.2. IOAM Service Metadata Option . . . . . . . . . . . . 8 69 4.2.3. IFA Service Metadata Option . . . . . . . . . . . . . 8 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Service Function Chaining (SFC) [RFC7665] and In-situ Flow 80 Information Telemetry (IFIT) [I-D.song-opsawg-ifit-framework] are 81 important path services along with the packets. In order to support 82 these services, several encapsulations have been defined. Network 83 Service Header (NSH) is defined in [RFC8300] as the encapsulation for 84 SFC. For IFIT encapsulations, In-situ OAM (iOAM) Header is defined 85 in [I-D.ietf-ippm-ioam-data] and Postcard-Based Telemetry (PBT) 86 Header is defined in [I-D.song-ippm-postcard-based-telemetry]. 87 Inband Flow Analyzer (IFA) is also defined in [I-D.kumar-ippm-ifa] to 88 record flow specific information from an end station and/or switches 89 across a network. In the application scenario of IPv6, these 90 encapsulations propose challenges for the data plane. The document 91 analyzes the problems and proposes the possible optimized 92 encapsulation for IPv6. 94 2. Terminology 96 SFC: Service Function Chaining 98 IFIT: In-situ Flow Information Telemetry 100 IOAM: In-situ OAM 102 PBT: Postcard-Based Telemetry 104 IFA: Inband Flow Analyzer 106 SRH: Segment Routing Header 108 3. Problem Statement 110 The problems posed by the current encapsulations for SFC and IFIT in 111 the application scenarios of IPv6 and SRv6 include: 113 1. According to the encapsulation order recommended in [RFC8200], if 114 the IOAM is encapsulated in the IPv6 Hop-by-Hop options header, in 115 the incremental trace mode of IOAM as the number of nodes traversed 116 by the IPv6 packets increases, the recorded IOAM information will 117 increase accordingly. This will increase the length of the Hop-by- 118 Hop options header and cause increasing difficulties in reading the 119 subsequent Segment Routing Extension Header (SRH) 120 [I-D.ietf-6man-segment-routing-header] and thereby reduce the 121 forwarding performance of the data plane greatly. 123 2. With the introduction of SRv6 network programming 124 [I-D.ietf-spring-srv6-network-programming], the path services along 125 with the IPv6 packets can be processed at all the IPv6 network nodes 126 or only at the SRv6 enabled network nodes along the path. It is 127 necessary to distinguish the encapsulations for the specific path 128 service which should be processed by the IPv6 path or the SRv6 path. 130 3. Both NSH and IOAM need the Metadata field to record metadata 131 information. However currently these metadata has to be recorded 132 separately which may generate redundant metadata information or 133 increase the cost of process. 135 4. There is unnecessary inconsistency in the current encapsulations 136 for IOAM, IFA and PBT in the IPv6 scenario. Especially it seems 137 unnecessary to define a new specific IPv6 header for IFA, i.e. IFA 138 header. 140 4. Design Consideration 142 To solve the problems stated above, in the application scenarios of 143 IPv6 and SRv6, the encapsulations of SFC and IFIT can be optimized 144 with the following design considerations: 146 o To separate the SFC/IFIT path service into two parts, i.e. 147 instruction and recording parts. The instruction part (normally 148 with fixed length) can be placed in the front IPv6 extension 149 headers including Hop-by-Hop options header, Destination options 150 header, Routing header, etc. while the recording part can be 151 placed in the back IPv6 extension headers such as being placed 152 after IPv6 Routing Header. In this way the path service 153 instruction in the IPv6 extension headers can be fixed as much as 154 possible to facilitate hardware process to keep forwarding 155 performance while the SFC/IFIT metadata recording part is placed 156 afterwards which enables to stop recording when too much recording 157 information has to be carried to reach the limitation of hardware 158 process. 160 o To define SFC/IFIT path service instructions as IPv6 options 161 uniformly whichs can be placed either in the Hop-by-hop options 162 which indicates the path service processed by all IPv6 enabled 163 nodes along the path or in the SRH option TLVs which indicates the 164 path service processed only by the SRv6 nodes along the SRv6 path 165 indicated by the Segment List in the SRH. 167 o To define a unified IPv6 metadata header which can be used as a 168 container to record the service metadata of SFC, IFIT and other 169 possible path services. 171 According to the above design optimization consideration, in the 172 application scenarios of IPv6 and SRv6 the encapsulations for SFC and 173 IFIT can be defined as below. 175 4.1. Service Options 177 1. NSH Service Option 178 0 1 2 3 179 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 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Option Type | Opt Data Len | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Service Path Identifier | Service Index | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 Figure 1. IPv6 Options with NSH instructions 190 Option Type: TBD_0 192 Opt Data Len: 8 octets. 194 Other fields: refer to [RFC8300]. 196 2. IOAM Service Option 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Option Type | Opt Data Len | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Namespace-ID |NodeLen | Flags | RemainingLen| 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | IOAM-Trace-Type | Reserved | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 2. IPv6 Options with IOAM instructions 210 Option Type: TBD_1 212 Opt Data Len: 8 octets. 214 Other fields: refer to [I-D.ietf-ippm-ioam-data]. 216 3. PBT Service Option 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Option Type | Opt Data Len | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Next Header | TIH Length | Reserved | Hop Count | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Flow ID | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Flow ID | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Sequence Number | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Data Set ID | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 3. IPv6 Options with PBT instructions 235 Option Type: TBD_2 237 Opt Data Len: 20 octets. 239 Other fields: refer to [I-D.song-ippm-postcard-based-telemetry]. 241 4. IFA Service Option 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Option Type | Opt Data Len | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 |Ver=2.0| GNS |NextHdr = IP_xx|R|R|R|M|T|I|T|C| Max Length | 249 | | | | | | |F|S| |A| | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 4. IPv6 Options with IFA instructions 253 Option Type: TBD_3 255 Opt Data Len: 4 octets. 257 Other fields: refer to [I-D.kumar-ippm-ifa]. 259 These options can be put in the IPv6 Hop-by-Hop Options Header or SRH 260 TLV. 262 4.2. IPv6 Service Metadata Options 264 As introduced in [I-D.li-6man-enhanced-extension-header], IPv6 265 Metadata Header is defined as a new type of IPv6 extension header. 266 The metadata is the information recorded by each hop for specific 267 path services, and carried in corresponding service metadata options. 268 The length of the metadata is variable. 270 4.2.1. SFC Service Metadata Option 272 For the SFC service, the corresponding SFC service metadata option is 273 defined as shown in Figure 5. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | SFC Type | Length | Reserved | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | SFC Metadata Class | Type |U| Length | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Variable-Length Metadata | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 5. SFC Service Metadata 287 SFC Type 8-bit identifier of the service type, i.e. SFC. 288 The value is TBD-4. 290 Length 8-bit unsigned integer. Length of the 291 Service Metadata field, in octets. 293 Metadata Class Defines the scope of the Type field to 294 provide a hierarchical namespace. IANA has 295 set up the "NSH MD Class" registry, which 296 contains 16-bit values [RFC8300]. 298 Type Indicates the explicit type of metadata 299 being carried. The definition of the Type is 300 the responsibility of the MD Class owner. 302 Unassigned bit One unassigned bit is available for future use. 303 This bit MUST NOT be set, and it MUST be 304 ignored on receipt. 306 Length Indicates the length of the variable-length 307 metadata, in bytes. Detailed specification 308 in [RFC8300]. 310 4.2.2. IOAM Service Metadata Option 312 For the IOAM service, the corresponding IOAM service metadata option 313 is defined as shown in Figure 6. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | IOAM Type | Length | Reserved | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 ~ ~ 321 | IOAM Service Metadata Options (variable) | 322 ~ ~ 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 Figure 6. IOAM Service Metadata 327 IOAM Type 8-bit identifier of the IOAM Service Metadata 328 type. The value is TBD-5. 330 Length 8-bit unsigned integer. Length of the 331 IOAM Service Metadata field, in octets. 333 RESERVED 8-bit reserved field MUST be set to zero upon 334 transmission and ignored upon receipt. 336 IOAM Service IOAM option data is present as specified by the 337 Metadata Options IOAM Type field, and is defined in Section 4 of 338 [I-D.ietf-ippm-ioam-data]. 340 All the IOAM IPv6 options require 4n alignment. This ensures that 4 341 octet fields specified in [I-D.ietf-ippm-ioam-data] such as transit 342 delay are aligned at a multiple-of-4 offset from the start of the 343 IPv6 Metadata header. 345 In addition, to maintain IPv6 extension header 8-octet alignment and 346 avoid the need to add or remove padding at every hop, the Trace-Type 347 for Incremental Tracing Option in IPv6 MUST be selected such that the 348 IOAM node data length is a multiple of 8-octets. 350 4.2.3. IFA Service Metadata Option 352 For the IOAM service, the corresponding IOAM service metadata option 353 is defined as shown in Figure 6. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | IFA Type | Length | Reserved | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 ~ ~ 361 | IFA Service Metadata Options (variable) | 362 ~ ~ 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 6. IFA Service Metadata 367 IFA Type 8-bit identifier of the IFA Service Metadata 368 type. The value is TBD-6. 370 Length 8-bit unsigned integer. Length of the 371 IOAM Service Metadata field, in octets. 373 RESERVED 8-bit reserved field MUST be set to zero upon 374 transmission and ignored upon receipt. 376 IFA Service IFA option data is present as specified by the 377 Metadata Options IFA Type field. 379 5. IANA Considerations 381 Value Description Reference 382 --------------------------------------------------------------------- 383 TBD_0 NSH Service Option [This draft] 384 TBD_1 IOAM Service Option [This draft] 385 TBD_2 PBT Service Option [This draft] 386 TBD_3 IFA Service Option [This draft] 387 TBD_4 SFC Service Metadata Type [This draft] 388 TBD_5 IOAM Service Metadata Type [This draft] 389 TBD_6 IFA Service Metadata Type [This draft] 391 6. Security Considerations 393 TBD. 395 7. References 397 7.1. Normative References 399 [I-D.guichard-spring-nsh-sr] 400 Guichard, J., Song, H., Tantsura, J., Halpern, J., 401 Henderickx, W., Boucadair, M., and S. Hassan, "NSH and 402 Segment Routing Integration for Service Function Chaining 403 (SFC)", draft-guichard-spring-nsh-sr-01 (work in 404 progress), March 2019. 406 [I-D.ietf-6man-segment-routing-header] 407 Filsfils, C., Dukes, D., Previdi, S., Leddy, J., 408 Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment 409 Routing Header (SRH)", draft-ietf-6man-segment-routing- 410 header-22 (work in progress), August 2019. 412 [I-D.ietf-ippm-ioam-data] 413 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 414 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 415 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 416 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 417 data-06 (work in progress), July 2019. 419 [I-D.ietf-spring-srv6-network-programming] 420 Filsfils, C., Camarillo, P., Leddy, J., 421 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 422 Network Programming", draft-ietf-spring-srv6-network- 423 programming-01 (work in progress), July 2019. 425 [I-D.kumar-ippm-ifa] 426 Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook, 427 H., Ghanwani, A., Cai, D., Ou, H., and L. Yizhou, "Inband 428 Flow Analyzer", draft-kumar-ippm-ifa-01 (work in 429 progress), February 2019. 431 [I-D.song-ippm-postcard-based-telemetry] 432 Song, H., Zhou, T., Li, Z., Shin, J., and K. Lee, 433 "Postcard-based On-Path Flow Data Telemetry", draft-song- 434 ippm-postcard-based-telemetry-04 (work in progress), June 435 2019. 437 [I-D.song-opsawg-ifit-framework] 438 Song, H., Li, Z., Zhou, T., Qin, F., Shin, J., and J. Jin, 439 "In-situ Flow Information Telemetry Framework", draft- 440 song-opsawg-ifit-framework-04 (work in progress), 441 September 2019. 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, 445 DOI 10.17487/RFC2119, March 1997, 446 . 448 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 449 Writing an IANA Considerations Section in RFCs", BCP 26, 450 RFC 8126, DOI 10.17487/RFC8126, June 2017, 451 . 453 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 454 (IPv6) Specification", STD 86, RFC 8200, 455 DOI 10.17487/RFC8200, July 2017, 456 . 458 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 459 "Network Service Header (NSH)", RFC 8300, 460 DOI 10.17487/RFC8300, January 2018, 461 . 463 7.2. Informative References 465 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 466 Chaining (SFC) Architecture", RFC 7665, 467 DOI 10.17487/RFC7665, October 2015, 468 . 470 Authors' Addresses 472 Zhenbin Li 473 Huawei Technologies 474 Huawei Bld., No.156 Beiqing Rd. 475 Beijing 100095 476 China 478 Email: lizhenbin@huawei.com 480 Shuping Peng 481 Huawei Technologies 482 Huawei Bld., No.156 Beiqing Rd. 483 Beijing 100095 484 China 486 Email: pengshuping@huawei.com 487 Kihoon LEE 488 LG U+ 489 71, Magokjungang 8-ro, Gangseo-gu 490 Seoul 491 Republic of Korea 493 Email: soho8416@lguplus.co.kr