idnits 2.17.1 draft-li-6man-ipv6-sfc-ifit-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 11, 2019) is 1872 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) == Outdated reference: A later version (-01) exists of draft-guichard-spring-nsh-sr-00 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-05 == Outdated reference: A later version (-07) exists of draft-kumar-ippm-ifa-01 == Outdated reference: A later version (-16) exists of draft-song-ippm-postcard-based-telemetry-02 == Outdated reference: A later version (-21) exists of draft-song-opsawg-ifit-framework-01 Summary: 0 errors (**), 0 flaws (~~), 8 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: September 12, 2019 March 11, 2019 7 Consideration of IPv6 Encapsulation for SFC and IFIT 8 draft-li-6man-ipv6-sfc-ifit-00 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 September 12, 2019. 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 Metadata Header . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 Service Function Chaining (SFC) [RFC7665] and In-situ Flow 75 Information Telemetry (IFIT) [I-D.song-opsawg-ifit-framework] are 76 important path services along with the packets. In order to support 77 these services, several encapsulations have been defined. Network 78 Service Header (NSH) is defined in [RFC8300] as the encapsulation for 79 SFC. For IFIT encapsulations, In-situ OAM (iOAM) Header is defined 80 in [I-D.ietf-ippm-ioam-data] and Postcard-Based Telemetry (PBT) 81 Header is defined in [I-D.song-ippm-postcard-based-telemetry]. 82 Inband Flow Analyzer (IFA) is also defined in [I-D.kumar-ippm-ifa] to 83 record flow specific information from an end station and/or switches 84 across a network. In the application scenario of IPv6, these 85 encapsulations propose challenges for the data plane. The document 86 analyzes the problems and proposes the possible optimized 87 encapsulation for IPv6. 89 2. Terminology 91 SFC: Service Function Chaining 93 IFIT: In-situ Flow Information Telemetry 95 IOAM: In-situ OAM 96 PBT: Postcard-Based Telemetry 98 IFA: Inband Flow Analyzer 100 SRH: Segment Routing Header 102 3. Problem Statement 104 The problems posed by the current encapsulations for SFC and IFIT in 105 the application scenarios of IPv6 and SRv6 include: 107 1. According to the encapsulation order recommended in [RFC8200], if 108 the IOAM is encapsulated in the IPv6 Hop-by-Hop options header, in 109 the trace mode of IOAM as the number of nodes traversed by the IPv6 110 packets increases, the recorded IOAM information will increase 111 accordingly. This will increase the length of the Hop-by-Hop options 112 header and cause increasing difficulties in reading the following 113 Segment Routing Extension Header (SRH) 114 [I-D.ietf-6man-segment-routing-header] and thereby reduce the 115 forwarding performance of the data plane greatly. 117 2. With the introduction of SRv6 network programming 118 [I-D.filsfils-spring-srv6-network-programming], the path services 119 along with the IPv6 packets can be processed at all the IPv6 network 120 nodes or only at the SRv6 enabled network nodes along the path. It 121 is necessary to distinguish the encapsulations for the specific path 122 service which should be processed by the IPv6 path or the SRv6 path. 124 3. Both NSH and IOAM need the Metadata field to record metadata 125 information. However currently these metadata has to be recorded 126 separately which may generate redundant metadata information or 127 increase the cost of process. 129 4. There is unnecessary inconsistency in the current encapsulations 130 for IOAM, IFA and PBT in the IPv6 scenario. Especially it seems 131 unnecessary to define a new specific IPv6 header for IFA, i.e. IFA 132 header. 134 5. [I-D.guichard-spring-nsh-sr] is proposed for the solution to 135 encapsulate NSH in SRv6 to support SFC. But the encapsulation is not 136 defined yet. 138 4. Design Consideration 140 To solve the problems stated above, in the application scenarios of 141 IPv6 and SRv6, the encapsulations of SFC and IFIT can be optimized 142 with the following design considerations: 144 o To separate the SFC/IFIT path service into two parts, i.e. 145 instruction and recording parts. The instruction part (normally 146 with fixed length) can be placed in the front IPv6 extension 147 headers including Hop-by-Hop options header, Destination options 148 header, Routing header, etc. while the recording part can be 149 placed in the back IPv6 extension headers such as being placed 150 after IPv6 Routing Header. In this way the path service 151 instruction in the IPv6 extension headers can be fixed as much as 152 possible to facilitate hardware process to keep forwarding 153 performance while the SFC/IFIT metadata recording part is placed 154 afterwards which enables to stop recording when too much recording 155 information has to be carried to reach the limitation of hardware 156 process. 158 o To define SFC/IFIT path service instructions as IPv6 options 159 uniformly whichs can be placed either in the Hop-by-hop options 160 which indicates the path service processed by all IPv6 enabled 161 nodes along the path or in the SRH option TLVs which indicates the 162 path service processed only by the SRv6 nodes along the SRv6 path 163 indicated by the Segment List in the SRH. 165 o To define a unified IPv6 metadata header which can be used as a 166 container to record the service metadata of SFC, IFIT and other 167 possible path services. 169 According to the above design optimization consideration, in the 170 application scenarios of IPv6 and SRv6 the encapsulations for SFC and 171 IFIT can be defined as below. 173 4.1. Service Options 175 1. NSH Service Option 177 0 1 2 3 178 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 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Option Type | Opt Data Len | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |Ver|O|U| TTL | Length |U|U|U|U|MD Type| Next Protocol | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Service Path Identifier | Service Index | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 1. IPv6 Options with NSH instructions 189 Option Type: TBD 191 Opt Data Len: 8 octets. 193 Other fields: refer to [RFC8300]. 195 2. IOAM Service Option 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Option Type | Opt Data Len | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Namespace-ID |NodeLen | Flags | RemainingLen| 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | IOAM-Trace-Type | Reserved | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 2. IPv6 Options with IOAM instructions 209 Option Type: TBD 211 Opt Data Len: 8 octets. 213 Other fields: refer to [I-D.ietf-ippm-ioam-data]. 215 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 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 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 Metadata Header 264 IPv6 Metadata Header is defined as a new type of IPv6 extension 265 header shown in Figure 5. The metadata is the information recorded 266 by each hop for specific path services, The length of the metadata is 267 variable. 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Next Header | Hdr Ext Len | | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | | 273 . . 274 . Metadata Stack (Variable) . 275 . . 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 5. Metadata Header 280 Next Header 8-bit selector. Identifies the type of header 281 immediately following the IPv6 metadata 282 header. 284 Hdr Ext Len 8-bit unsigned integer. Length of the 285 IPv6 metadata header in 8-octet units, 286 not including the first 8 octets. 288 Metadata Stack Variable-length field, of length such that the 289 complete IPv6 metadata header is an 290 integer multiple of 8 octets long. Contains 291 one or more type of path service metadata. 293 For specific path service, i.e. SFC/IOAM, the corresponding metadata 294 is defined as follows: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Service Type | Length | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 ~ ~ 302 | Metadata (variable) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 6. Service Metadata 306 Service Type 8-bit selector. Identifies the type of 307 Service Metadata. 309 Length 16-bit unsigned integer. Length of the 310 Service metadata in 8-octet units, 311 not including the first 8 octets. 313 Metadata Variable-length field, of length such that the 314 complete IPv6 metadata header is an 315 integer multiple of 8 octets long. 317 5. IANA Considerations 319 TBD. 321 6. Security Considerations 323 TBD. 325 7. References 327 7.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, 331 DOI 10.17487/RFC2119, March 1997, 332 . 334 7.2. Informative References 336 [I-D.filsfils-spring-srv6-network-programming] 337 Filsfils, C., Camarillo, P., Leddy, J., 338 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 339 Network Programming", draft-filsfils-spring-srv6-network- 340 programming-07 (work in progress), February 2019. 342 [I-D.guichard-spring-nsh-sr] 343 Guichard, J., Song, H., Tantsura, J., Halpern, J., 344 Henderickx, W., and M. Boucadair, "NSH and Segment Routing 345 Integration for Service Function Chaining (SFC)", draft- 346 guichard-spring-nsh-sr-00 (work in progress), September 347 2018. 349 [I-D.ietf-6man-segment-routing-header] 350 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 351 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 352 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 353 progress), February 2019. 355 [I-D.ietf-ippm-ioam-data] 356 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 357 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 358 P., Chang, R., daniel.bernier@bell.ca, d., and J. Lemon, 359 "Data Fields for In-situ OAM", draft-ietf-ippm-ioam- 360 data-05 (work in progress), March 2019. 362 [I-D.kumar-ippm-ifa] 363 Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook, 364 H., Ghanwani, A., Cai, D., Ou, H., and L. Yizhou, "Inband 365 Flow Analyzer", draft-kumar-ippm-ifa-01 (work in 366 progress), February 2019. 368 [I-D.song-ippm-postcard-based-telemetry] 369 Song, H., Zhou, T., Li, Z., and J. Shin, "Postcard-based 370 In-band Flow Data Telemetry", draft-song-ippm-postcard- 371 based-telemetry-02 (work in progress), March 2019. 373 [I-D.song-opsawg-ifit-framework] 374 Song, H., Li, Z., Zhou, T., Li, Z., and J. Shin, "In-situ 375 Flow Information Telemetry Framework", draft-song-opsawg- 376 ifit-framework-01 (work in progress), March 2019. 378 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 379 Chaining (SFC) Architecture", RFC 7665, 380 DOI 10.17487/RFC7665, October 2015, 381 . 383 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 384 (IPv6) Specification", STD 86, RFC 8200, 385 DOI 10.17487/RFC8200, July 2017, 386 . 388 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 389 "Network Service Header (NSH)", RFC 8300, 390 DOI 10.17487/RFC8300, January 2018, 391 . 393 Authors' Addresses 395 Zhenbin Li 396 Huawei Technologies 397 Huawei Bld., No.156 Beiqing Rd. 398 Beijing 100095 399 China 401 Email: lizhenbin@huawei.com 403 Shuping Peng 404 Huawei Technologies 405 Huawei Bld., No.156 Beiqing Rd. 406 Beijing 100095 407 China 409 Email: pengshuping@huawei.com