idnits 2.17.00 (12 Aug 2021) /tmp/idnits35616/draft-xie-6man-bier-encapsulation-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 : ---------------------------------------------------------------------------- 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 2, 2018) is 1418 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: 'RFC3032' is mentioned on line 234, but not defined == Missing Reference: 'RFC6744' is mentioned on line 238, but not defined -- Looks like a reference, but probably isn't: '0' on line 319 == Missing Reference: 'SL' is mentioned on line 318, but not defined == Missing Reference: 'RFC2780' is mentioned on line 360, but not defined == Outdated reference: A later version (-07) exists of draft-filsfils-spring-srv6-network-programming-04 == Outdated reference: draft-ietf-6man-segment-routing-header has been published as RFC 8754 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track L. Geng 5 Expires: January 3, 2019 L. Wang 6 China Mobile 7 G. Yan 8 M. McBride 9 Y. Xia 10 Huawei 11 July 2, 2018 13 Encapsulation for BIER in Non-MPLS IPv6 Networks 14 draft-xie-6man-bier-encapsulation-01 16 Abstract 18 Bit Index Explicit Replication (BIER) introduces a new multicast- 19 specific BIER Header. Currently BIER has two types of encapsulation 20 formats: one is MPLS encapsulation, the other is Ethernet 21 encapsulation. This document proposes a BIER IPv6 encapsulation for 22 Non-MPLS IPv6 Networks using an IPv6 Destination Option extension 23 header. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 3, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Problem Statement and Requirements . . . . . . . . . . . . . 3 68 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 69 3.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 70 4. IPv6 BIER Encapsulation . . . . . . . . . . . . . . . . . . . 4 71 4.1. Considerations . . . . . . . . . . . . . . . . . . . . . 4 72 4.2. IPv6 BIER Destination Option . . . . . . . . . . . . . . 4 73 4.3. The whole IPv6 header for BIER packets . . . . . . . . . 5 74 5. BIER Forwarding in Non-MPLS IPv6 Networks . . . . . . . . . . 7 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 9.2. Informative References . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 86 that provides optimal multicast forwarding without requiring 87 intermediate routers to maintain any per-flow state by using a 88 multicast-specific BIER header. [RFC8296] defines two types of BIER 89 encapsulation formats: one is MPLS encapsulation, the other is non- 90 MPLS encapsulation. The Non-MPLS encapsulation defined in [RFC8296] 91 is in fact an Ethernet encapsulation with an ethertype 0xAB37, and an 92 'Ethernet encapsulation' will be used to refer to such an 93 encapsulation in the following text. This document proposes a BIER 94 IPv6 encapsulation for Non-MPLS IPv6 Networks using an IPv6 95 Destination Option extension header. 97 2. Terminology 99 Readers of this document are assumed to be familiar with the 100 terminology and concepts of the documents listed as Normative 101 References. 103 3. Problem Statement and Requirements 105 3.1. Problem Statement 107 MPLS is a very popular and successful encapsulation. One of the 108 benefits of MPLS is its ability to easily stack a label onto another, 109 thus forming a label stack. This same label stacking benefit is also 110 available for BIER by using an MPLS encapsulation. For example, an 111 MPLS-encapsulated BIER packet can easily run over an MPLS tunnel, 112 either a legacy RSVP-TE/LDP LSP, or an MPLS Segment Routing tunnel. 113 Such a mechanism is the key to obtain the capability of "fast 114 reroute" or "bypass a Non-capable router". To quote [RFC8279]: 116 o In the event that unicast traffic to the BFR-NBR is being sent via 117 a "bypass tunnel" of some sort, the BIER-encapsulated multicast 118 traffic sent to the BFR-NBR SHOULD also be sent via that tunnel. 119 This allows any existing "fast reroute" schemes to be applied to 120 multicast traffic as well as to unicast traffic. 122 o Unicast tunnels are used to bypass non-BFRs. 124 Some other scenarios also need BIER to run on a tunnel, such as 125 transferring a BIER packet through a whole Non-BIER network or 126 domain. 128 The capability to run BIER on a tunnel, especially the widely 129 deployed mpls tunnel, can be obtained by using a BIER MPLS 130 encapsulation, but cannot be obtained by using a BIER Ethernet 131 encapsulation. It is not possible either, to run BIER on other links 132 such as POS, by using BIER Ethernet encapsulation. 134 The capability of running BIER on various kinds of links and tunnels, 135 by using an MPLS encapsulation, is beneficial to BIER deployments. 136 In an IPv6 network, however, there are considerations of using a non- 137 MPLS encapsulation for unicast as the data-plane, such as SRH defined 138 in [I-D.ietf-6man-segment-routing-header], where the function of a 139 bypass tunnel uses an SRH header, with one or many Segments (or 140 SIDs), instead of MPLS Labels. 142 3.2. Requirements 144 This chapter lists the BIER IPv6 encapsulation requirements needed to 145 make the deployment of BIER on IPv6 network with SRH data-plane the 146 same as on IPv4/IPv6 network with MPLS data-plane. These BIER IPv6 147 encapsulation requirements should provide similar benefits to MPLS 148 encapsulation such as "fast reroute" or "run on any link or 149 interface". 151 1. The listed requirements MUST be supported with any L1/L2 over 152 which BIER layer can be realized. 154 2. It SHOULD support a hop-by-hop replication to multiple 155 destinations in a BIER Domain. 157 3. It SHOULD support BIER on an "SRH tunnel". 159 4. It SHOULD align with the recommendations of the 6MAN working 160 group. 162 4. IPv6 BIER Encapsulation 164 4.1. Considerations 166 BIER is generally a hop-by-hop and one-to-many architecture, while 167 Segment Routing is a source-routing and one-to-one architecture. One 168 of the challenges of an BIER IPv6 Encapsulation is how to allow BIER 169 to run over a Segment Routing tunnel. A suitable method for such a 170 combination is to use a Multicast Address as the Last Segment (or 171 SID). After all the source-routing hops have been processed, the 172 remaining Multicast Address becomes the IPv6 Destination Address. A 173 hop-by-hop replicating diagram begins by using the Destination 174 Multicast Address. 176 We then need to decide where to place the BIER header. According to 177 [RFC8200], [RFC6564], and [RFC7045], a suitable place for a well- 178 known BIER header is an IPv6 Destination Option extension header. 179 Such a Destination Option carrying BIER header is only used for a 180 hop-by-hop Multicast Address destination, but not for the transit 181 router along the source-routing path. 183 4.2. IPv6 BIER Destination Option 185 The IPv6 BIER Destination Option is carried by the IPv6 Destination 186 Option Header (indicated by a Next Header value 60). It is used in a 187 packet sent by an IPv6 BFIR router to inform the routers in an IPv6 188 BIER domain to replicate to destination BFER routers. 190 The IPv6 BIER Destination Option is encoded in type-length-value 191 (TLV) format as follows: 193 0 1 2 3 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Next Header | Hdr Ext Len | Option Type | Option Length | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | | 199 ~ Non-MPLS BIER Header (defined in RFC8296) ~ 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 1: IPv6 BIER Destination Option 205 Next Header 8-bit selector. Identifies the type of header 206 immediately following the Destination Options header. 208 Hdr Ext Len 8-bit unsigned integer. Length of the Destination 209 Options header in 8-octet units, not including the first 8 octets. 211 Option Type TBD. Need to be allocated by IANA. 213 Option Length 8-bit unsigned integer. Length of the option, in 214 octets, excluding the Option Type and Option Length fields. 216 Non-MPLS BIER Header The Non-MPLS BIER Header defined in RFC8296, 217 including the BIFT-id. 219 4.3. The whole IPv6 header for BIER packets 221 [RFC8200] specifies that the Destination Option Header can be located 222 either before the Routing Header or after the Routing Header. 223 However, this document requires that the Destination Option Header 224 with a BIER Destination Option TLV is always located after the 225 Routing Header if the Routing Header is present. 227 This is because the BIER header is always handled after the tunnels 228 (or bypass tunnels) have been handled. BIER MPLS encapsulation has 229 the same behavior. To quote [RFC8296]: 231 o It is crucial to understand that in an MPLS network the first four 232 octets of the BIER encapsulation header are also the last four 233 octets of the MPLS header. Therefore, any prior MPLS label stack 234 entries MUST have the S bit (see [RFC3032]) clear (i.e., the S bit 235 must be 0). 237 Other IPv6 extension headers are not commonly used in the current 238 Internet. For Example, [RFC6744] says that "IPv6 Destination Options 239 headers, and the options carried by such headers, are extremely 240 uncommon in the deployed Internet". [RFC6564] says that "Extension 241 headers, with the exception of the Hop-by-Hop Options header, are not 242 usually processed on intermediate nodes", and that "Reports from the 243 field indicate that some IP routers deployed within the global 244 Internet are configured either to ignore the presence of headers with 245 hop-by-hop behavior or to drop packets containing headers with hop- 246 by-hop behavior." 248 Such IPv6 extension headers will even be more uncommon when a BIER 249 encapsulation is used in data-plane forwarding. The entire IPv6 250 header, with BIER encapsulation and Routing Header, is expected to 251 look like this: 253 IPv6 header 255 Hop-by-Hop Options header [Not Used] 257 Destination Options header [Not Used] 259 Routing header [SRH Header with Multicast Address as last SID] 261 Fragment header [Not Used] 263 Authentication header [Not Used] 265 Encapsulating Security Payload header [Not Used] 267 Destination Options header [BIER header in BIER Option TLV] 269 Upper-layer header [Data-plane Data] 271 Once a packet is encapsulated with a BIER Destination Option, it is 272 basically assumed to be a data-plane multicast packet, so the 'OAM' 273 or similar functions in the SRH Header Optional TLV Objects field 274 should not exist. 276 The last Segment (SID) in the SRH header, or Segment List[0], should 277 be a Multicast Address to indicate a hop-by-hop behavior. Such a 278 Multicast Address can be reserved or unreserved as the Destination 279 Option Header can inform the routers to do the address check. A 280 reserved multicast address should be indicating a 'BIER specific' 281 address. 283 BIER header has a 'proto' field to identify the type of BIER packet 284 payload, and the IANA has created a registry called "BIER Next 285 Protocol Identifiers" to assign the value. That means the 'Upper- 286 layer header' of a BIER packet have already been identified by the 287 'proto' field of the BIER header in the Destination Option Header. 288 Thus the 'Next Header' in the Destination Option Header is not need 289 to identify the 'Upper-layer header' any more, and is recommended to 290 be set to 'No Next Header (value 59)'. 292 5. BIER Forwarding in Non-MPLS IPv6 Networks 294 In a Non-MPLS IPv6 Network, BIER may be deployed in a hop-by-hop 295 manner, or possibly be deployed through an SRH tunnel either for 296 "bypassing Non-capable BIER routers" or "fast rerouting". Here is an 297 example where a packet is firstly forwarded through an SRH tunnel and 298 then through a hop-by-hop BIER domain. 300 When a router along the Segment Routing path receives an IPv6 BIER 301 packet with an SRH header, and if the IPv6 destination address is not 302 one of the router's address, then the packet is forwarded by an IPv6 303 FIB lookup of the destination address and none of the IPv6 extension 304 headers will be checked. If the IPv6 Destination Address is one of 305 the router's address, and also one of the router's Segment (or SID) 306 of some type, then the router will do a specific function indicated 307 by the Segment, as defined in 308 [I-D.filsfils-spring-srv6-network-programming]. If the IPv6 309 Destination Address is a specific type of Segment, called BIER 310 Segment or BIER SID, then the according function is called Endpoint 311 BIER function or 'End.BF' function for short. 313 When router receives a packet destined to X and X is a local End.BF 314 SID, the router does: 316 1. IF SL > 0 317 2. decrement SL 318 3. update IPv6 DA with SRH[SL] 319 4. IF SL = 0 & STATE(SRH[0]) = BIER 320 5. update IPv6 header NH with SRH NH 321 6. pop the SRH 322 7. forward the updated packet 323 8. ELSE 324 9. drop the packet 325 10. ELSE 326 11. drop the packet 328 Figure 2: End.BF Function 330 The End.BF function is used for the SRH tunnel destination router to 331 terminate the source-routing SRH forwarding and begin the hop-by-hop 332 BIER IPv6 forwarding. After the SRH header is popped, the multicast 333 address in the updated IPv6 Destination Address indicates the BIER 334 information of this 'host', and the packet will be forwarded 335 according to the BIER Header in the BIER Destination Option TLV in 336 the IPv6 Destination Option extension header of this 'host'. 338 In the following hop-by-hop forwarding procedure, the IPv6 339 Destination Address in an incoming packet indicates the BIER 340 information of this 'host', and the packet will be forwarded 341 according to the BIER Header in the BIER Destination Option TLV in 342 the IPv6 Destination Option extension header. A router is required 343 to ignore the IPv6 BIER Destination Option if the IPv6 Destination 344 Address of a packet is not a multicast address, or is a multicast 345 adddress without indicating the BIER information of this 'host'. 347 6. Security Considerations 349 An IPv6 BIER Destination Option with Multicast Address Destination 350 would be used only when an IPv6 BIER state with the specific 351 Multicast Address Destination has been built by the control-plane. 352 Otherwise the packet with an IPv6 BIER Destination Option will be 353 discarded. 355 7. IANA Considerations 357 Allocation is expected from IANA for a Destination Option Type 358 codepoint from the "Destination Options and Hop-by-Hop Options" sub- 359 registry of the "Internet Protocol Version 6 (IPv6) Parameters" 360 registry [RFC2780] at . 363 8. Acknowledgements 365 TBD. 367 9. References 369 9.1. Normative References 371 [I-D.filsfils-spring-srv6-network-programming] 372 Filsfils, C., Li, Z., Leddy, J., daniel.voyer@bell.ca, d., 373 daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R., 374 Matsushima, S., Lebrun, D., Decraene, B., Peirens, B., 375 Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and 376 M. Sharif, "SRv6 Network Programming", draft-filsfils- 377 spring-srv6-network-programming-04 (work in progress), 378 March 2018. 380 [I-D.ietf-6man-segment-routing-header] 381 Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and 382 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 383 (SRH)", draft-ietf-6man-segment-routing-header-13 (work in 384 progress), May 2018. 386 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 387 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 388 RFC 6564, DOI 10.17487/RFC6564, April 2012, 389 . 391 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 392 of IPv6 Extension Headers", RFC 7045, 393 DOI 10.17487/RFC7045, December 2013, 394 . 396 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 397 (IPv6) Specification", STD 86, RFC 8200, 398 DOI 10.17487/RFC8200, July 2017, 399 . 401 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 402 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 403 Explicit Replication (BIER)", RFC 8279, 404 DOI 10.17487/RFC8279, November 2017, 405 . 407 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 408 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 409 for Bit Index Explicit Replication (BIER) in MPLS and Non- 410 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 411 2018, . 413 9.2. Informative References 415 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 416 Requirement Levels", BCP 14, RFC 2119, 417 DOI 10.17487/RFC2119, March 1997, 418 . 420 Authors' Addresses 422 Jingrong Xie 423 Huawei Technologies 425 Email: xiejingrong@huawei.com 426 Liang Geng 427 China Mobile 428 Beijing 10053 430 Email: gengliang@chinamobile.com 432 Lei Wang 433 China Mobile 434 Beijing 10053 436 Email: wangleiyjy@chinamobile.com 438 Gang Yan 439 Huawei 441 Email: yangang@huawei.com 443 Mike McBride 444 Huawei 446 Email: mmcbride7@gmail.com 448 Yang Xia 449 Huawei 451 Email: yolanda.xia@huawei.com