idnits 2.17.1 draft-zzhang-intarea-generic-delivery-functions-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 221: '...is reserved. It MUST be set to 0 on t...' RFC 2119 keyword, line 253: '...is reserved. It MUST be set to 0 on t...' RFC 2119 keyword, line 268: '... SHOULD be the first GDFH....' RFC 2119 keyword, line 270: '...ot necessary but MAY be used for BIER ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 25, 2021) is 972 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) == Unused Reference: 'RFC5120' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'RFC5305' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC5308' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC7684' is defined on line 309, but no explicit reference was found in the text == Unused Reference: 'RFC8362' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 335, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-song-mpls-extension-header-05 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-14 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 intarea Z. Zhang 3 Internet-Draft R. Bonica 4 Intended status: Standards Track K. Kompella 5 Expires: February 26, 2022 Juniper Networks 6 G. Mirsky 7 ZTE 8 August 25, 2021 10 Generic Delivery Functions 11 draft-zzhang-intarea-generic-delivery-functions-02 13 Abstract 15 Some functionalities (e.g., fragmentation/reassembly and 16 Encapsulating Security Payload) provided by IPv6 can be viewed as 17 delivery functions independent of IPv6 or even IP entirely. This 18 document proposes to provide those functionalities at different 19 layers (e.g., MPLS, BIER or even Ethernet) independent of IP. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 10, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Specifications . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. MPLS layer . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. BIER layer . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Other layers . . . . . . . . . . . . . . . . . . . . . . 5 60 2.4. Generic Fragmentation Header (GFH){#gfh} . . . . . . . . 6 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 5.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Consider an operator providing Ethernet services such as EVPN. The 71 Ethernet frames that a Provider Edge (PE) device receives from a 72 Customer Edge (CE) device may have a larger size than the PE-PE path 73 MTU (PMTU) in the provider network. This could be because 75 1. the provider network is built upon virtual connections (e.g., 76 pseudowires) provided by another infrastructure provider, or 78 2. the customer network uses jumbo frames while the provider network 79 does not, or 81 3. the provider-side overhead for transporting customer packets 82 across the network pushes past the PMTU. 84 In any case, the provider cannot simply require its customers to 85 change their MTU. 87 To get those large frames across the provider network, currently, the 88 only workaround is to encapsulate the frames in IP (with or without 89 GRE) and then fragment the IP packets. Even if MPLS is used for 90 service delimiting, IP is used for transportation (MPLS over IP/GRE). 91 This may not be desirable in certain deployment scenarios, where MPLS 92 is the preferred transport or IP encapsulation overhead is deemed 93 excessive. 95 IPv6 fragmentation and reassembly are based on the IPv6 Fragmentation 96 header below [RFC8200]: 98 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 99 | Next Header | Reserved | Fragment Offset |Res|M| 100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 101 | Identification | 102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 Figure 1: IPv6 Fragmentation Header 106 This document proposes adapting this header for use in non-IP 107 contexts since the fragmentation/reassembly function is actually 108 independent of IPv6 except for the following aspects: 110 o The fragment header is identified as such by the "previous" 111 header. 113 o The "Next Header" value is from the "Internet Protocol Numbers" 114 registry. 116 o The "Identification" value is unique in the (source, destination) 117 context provided by the IPv6 header. 119 The "Identification" field, in conjunction with the IPv6 source and 120 destination addresses identifies fragments of the original packet for 121 the purpose of reassembly. 123 Therefore, the fragmentation/reassembly function can be applied at 124 other layers as long as a) the fragment header is identified as such; 125 and b) the context for packet identification is provided. Examples 126 of such layers include MPLS, BIER, and Ethernet (if IEEE determines 127 it is so desired). 129 For the same consideration, the IP Encapsulating Security Payload 130 (ESP) [RFC4303] could also be applied at other layers if ESP is 131 desired there. For example, if for whatever reason the Ethernet 132 service provider wants to provide ESP between its PEs, it could do so 133 without requiring IP encapsulation if ESP is applied at non-IP 134 layers. 136 Similarly, In-Situ OAM (IOAM) functions [I-D.ietf-ippm-ioam-data] can 137 also be applied to many layers. 139 We refer to these as Generic Delivery Functions (GDFs), which could 140 be achieved at a shim layer between a source and destination delivery 141 points, for example: 143 o Source and destination IP/Ethernet nodes 145 o Ingress and egress nodes of MPLS Label Switch Paths (LSPs) 146 o BIER Forwarding Ingress Routers (BFIRs) and BIER Forwarding Egress 147 Routers (BFERs) 149 2. Specifications 151 A Generic Delivery Function, being generic, is likely applicable to 152 IP as well. Therefore, IPv6 Extension Headers (for some GDFs) are 153 directly used at other layers. 155 2.1. MPLS layer 157 [I-D.song-mpls-extension-header] specifies MPLS Extension Headers 158 encoding. A label entry in the stack indicates the presence of 159 extension headers after the label stack. It starts with a Header of 160 Extension Headers, as depicted in the following excerpt from that 161 specification: 163 0 31 164 +--------+--------+--------+--------+ \ 165 | | | 166 ~ MPLS Label Stack ~ | 167 | | | 168 +--------+--------+--------+--------+ | 169 | EH Indicator (TBD) | > MPLS Label Stack 170 +--------+--------+--------+--------+ | (extended with EHI) 171 | | | 172 ~ MPLS Label Stack ~ | 173 | | | 174 +--------+--------+--------+--------+ < 175 | Header of Extension Headers (HEH) | | 176 +--------+--------+--------+--------+ | 177 | | | 178 ~ Extension Header (EH) 1 ~ | 179 | | | 180 +--------+--------+--------+--------+ > MPLS EH Fields 181 ~ ~ | (new) 182 +--------+--------+--------+--------+ | 183 | | | 184 ~ Extension Header (EH) N ~ | 185 | | | 186 +--------+--------+--------+--------+ < 187 | | | 188 ~ Upper Layer Headers/Payload ~ > MPLS Payload 189 | | | (as is) 190 +--------+--------+--------+--------+ / 192 One or more of the EHs in the above can be an IPv6 Extension Header 193 for a GDF. 195 2.2. BIER layer 197 For BIER layer, a TBD value for the "proto" field in the outer BIER 198 header indicates that some BIER Extension Headers follow the BIER 199 header, including some IPv6 Extension Headers for GDFs. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | BIFT-id | TC |S| TTL | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |Nibble | Ver | BSL | Entropy | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 |OAM|R|H| DSCP | Proto | BFIR-id | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Header of Extension Headers (HEH) | 211 +---------------------------------------------------------------+ 212 ~ Extension Header (EH) 1 ~ 213 +---------------------------------------------------------------+ 214 ~ ... ~ 215 +---------------------------------------------------------------+ 216 ~ Extension Header (EH) N ~ 217 +---------------------------------------------------------------+ 218 ~ Upper Layer Headers/Payload ~ 219 +---------------------------------------------------------------+ 221 R: The "R" flag bit is reserved. It MUST be set to 0 on transmit and 222 ignored on receive. 224 H: If the "H" flag bit, it indicates the presence of at least one 225 extension header that needs to be processed hop by hop even before 226 a BFER is reached. In this case, the Proto field must be set to 227 the TBD value indicating the presence of extension headers. 229 2.3. Other layers 231 Similarly, any layer can have an indication in its packet header that 232 some GDF extension headers follow, including some IPv6 Extension 233 Headers for GDF purpose. 235 For example, if the outer header is Ethernet (if IEEE would decide to 236 provide the generic delivery functions on top of Ethernet directly), 237 then a new Ethertype would be assigned by IEEE to indicate the 238 presence of GDF extension headers. 240 2.4. Generic Fragmentation Header (GFH){#gfh} 242 For generic fragmentation/reassembly functionality, the existing IPv6 243 Fragment Header needs to be enhanced for MPLS as following: 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Next Header | Hdr Ext Len | Fragment Offset |R|S|M| 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Fragment/Source Identification (variable) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Figure 2: Generic Fragmentation Header 253 R: The "R" flag bit is reserved. It MUST be set to 0 on transmit and 254 ignored on receive. 256 S: If the "S" flag bit is clear, the context for the Identification 257 field is provided by the outer header, and only the source- 258 identifying information in the outer header is used. 260 If the "S" flag bit is set, the variable Identification field 261 encodes both source-identifying information (e.g., the IP address 262 of the node adding the GFH) and an identification number unique 263 within that source. The length of the Fragment header is encoded 264 in the 8-bit "Hdr Ext Len" field (which is a Reserved field in the 265 original IPv6 Fragment Header). 267 When a GFH is used together with other GDF Headers (GDFH), the GFH 268 SHOULD be the first GDFH. 270 The above enhancement is not necessary but MAY be used for BIER as 271 well. If the outer header is BIER and the "S" flag bit is clear, the 272 "BFIR-id" field in the BIER header provides the context for the 273 "Identification" field. If the bit is set, then the source 274 information embedded in the source/fragment identification field is 275 used. 277 3. Security Considerations 279 To be provided. 281 4. Acknowledgements 283 The authors thank Stewart Bryant and Tony Przygienda for their 284 valuable comments and suggestions. 286 5. References 288 5.1. Normative References 290 [I-D.song-mpls-extension-header] 291 Song, H., Li, Z., Zhou, T., Andersson, L., and Z. Zhang, 292 "MPLS Extension Header", draft-song-mpls-extension- 293 header-05 (work in progress), July 2021. 295 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 296 Topology (MT) Routing in Intermediate System to 297 Intermediate Systems (IS-ISs)", RFC 5120, 298 DOI 10.17487/RFC5120, February 2008, 299 . 301 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 302 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 303 2008, . 305 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 306 DOI 10.17487/RFC5308, October 2008, 307 . 309 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 310 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 311 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 312 2015, . 314 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 315 (IPv6) Specification", STD 86, RFC 8200, 316 DOI 10.17487/RFC8200, July 2017, 317 . 319 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 320 F. Baker, "OSPFv3 Link State Advertisement (LSA) 321 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 322 2018, . 324 5.2. Informative References 326 [I-D.ietf-ippm-ioam-data] 327 Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields 328 for In-situ OAM", draft-ietf-ippm-ioam-data-14 (work in 329 progress), June 2021. 331 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 332 RFC 4303, DOI 10.17487/RFC4303, December 2005, 333 . 335 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 336 Encodings and Procedures for Multicast in MPLS/BGP IP 337 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 338 . 340 Authors' Addresses 342 Zhaohui Zhang 343 Juniper Networks 345 Email: zzhang@juniper.net 347 Ron Bonica 348 Juniper Networks 350 Email: rbonica@juniper.net 352 Kireeti Kompella 353 Juniper Networks 355 Email: kireeti@juniper.net 357 Gregory Mirsky 358 ZTE 360 Email: gregory.mirsky@ztetx.com