idnits 2.17.1 draft-ietf-bier-ipv6-requirements-07.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 (September 16, 2020) is 1318 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2473' is defined on line 358, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-xie-bier-ipv6-encapsulation-08 == Outdated reference: A later version (-09) exists of draft-zhang-bier-bierin6-07 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. McBride 3 Internet-Draft Futurewei 4 Intended status: Informational J. Xie 5 Expires: March 20, 2021 X. Geng 6 S. Dhanaraj 7 Huawei 8 R. Asati 9 Cisco 10 Y. Zhu 11 China Telecom 12 G. Mishra 13 Verizon Inc. 14 Z. Zhang 15 Juniper 16 September 16, 2020 18 BIER IPv6 Requirements 19 draft-ietf-bier-ipv6-requirements-07 21 Abstract 23 There have been several proposed solutions with BIER being used in 24 IPv6. But there hasn't been a document which describes the problem 25 and lists the requirements. The goal of this document is to describe 26 the general BIER IPv6 encapsulation problem, summarize the 27 encapsulation modes of the proposed solutions, detail solution 28 requirements, and assist the working group in the development of 29 acceptable solutions. 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 March 20, 2021. 48 Copyright Notice 50 Copyright (c) 2020 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 4 70 3.1. Independent Model . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Integrated Model . . . . . . . . . . . . . . . . . . . . 5 72 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 6 74 4.1.1. Support various L2 link types . . . . . . . . . . . . 6 75 4.1.2. Support BIER architecture . . . . . . . . . . . . . . 6 76 4.1.3. Support deployment with Non-BFR routers . . . . . . . 6 77 4.1.4. Support OAM . . . . . . . . . . . . . . . . . . . . . 6 78 4.2. Optional Requirements . . . . . . . . . . . . . . . . . . 7 79 4.2.1. Support Fragmentation . . . . . . . . . . . . . . . . 7 80 4.2.2. Support IPSEC ESP . . . . . . . . . . . . . . . . . . 7 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 84 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 85 Appendix A. List of Solutions . . . . . . . . . . . . . . . . . 9 86 A.1. Integrated mode approach . . . . . . . . . . . . . . . . 9 87 A.2. Independent model approach . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 Bit Index Explicit Replication (BIER) [RFC8279] is an architecture 93 that provides optimal multicast forwarding, without requiring 94 intermediate routers to maintain per-flow state, through the use of a 95 multicast-specific BIER header. [RFC8296] defines two types of BIER 96 encapsulation: one is BIER MPLS encapsulation for MPLS environments, 97 the other is non-MPLS BIER encapsulation to run without MPLS. This 98 document describes non-MPLS BIER encapsulation in IPv6 environments. 99 We explain the requirements of transporting IPv4/IPv6 multicast 100 overlay payload through an IPv6 network underlay using BIER. The 101 solutions may require the use of IPv6 forwarding plane and may 102 include IPv6 encapsulation and/or generic IPv6 tunnelling. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 1.2. Terminology 112 o BIER: Bit Index Explicit Replication. Provides optimal multicast 113 forwarding through adding a BIER header and removing state in 114 intermediate routers. 116 2. Problem Statement 118 The problem is how to transport multicast packets, with non-MPLS BIER 119 encapsulation, in an IPv6 environment. We need to determine where to 120 put the BIER header in this IPv6 environment. With IPv6 121 encapsulation being increasingly used for unicast services, such as 122 VPN or L2VPN, it may be desirable to have IPv6 encapsulation also 123 used in BIER deployments for multicast services such as MVPN. It may 124 also be desirable to not use IPv6 encapsulation except when IPv6 125 tunneling (native or GRE/UDP-like) is used to transport BIER packets 126 over BIER-incapable routers. 128 Below is a simple scenario that needs BIER IPv6-based forwarding: 130 +--------------------------------------------+ 131 | | 132 | +------+ 133 | | BFER | 134 +------+ +-------+ +-----+ +------+ 135 | BFIR | |Non-BFR| | BFR | | 136 +------+ +-------+ +-----+ +------+ 137 | | BFER | 138 | IPv6 Network +------+ 139 | | 140 +--------------------------------------------+ 142 This scenario depicts the need to replicate BIER packets from a BFIR 143 to BFERs across an IPv6 Service Provider core. Inside the IPv6 144 network, the BIER header is used to direct the packet from one BFR to 145 the next BFRs, and either a IPv6 header or an L2/tunnel header is 146 used to provide reachability between BFRs. The IPv6 environment may 147 include a variety of link types, may be entirely IPv6, or may be dual 148 stack. There may be cases where not all routers are BFR capable in 149 the IPv6 environment but still want to deploy BIER. Regardless of 150 the environment, the problem is to deploy BIER, with non-MPLS BIER 151 encapsulation, in an IPv6 network. 153 3. Conceptual Models For BIER IPv6 Encapsulation and Forwarding 155 This analysis introduces two conceptual models for BIER in IPv6 156 networks based on the experience and solutions discussed in the IETF 157 community. 159 3.1. Independent Model 161 The first conceptual model is an Independent Model, where IPv6 is 162 nothing special to BIER but a transportation means that may be used 163 just like other transportation means, and BIER is nothing special to 164 IPv6 but a payload type just like other payload types. 166 |<<-----(BIER-based multicast overlay)----->>| 167 | | 168 |<---------(L2.5 BIER(P2MP) Tunnel)--------->| 169 | | 170 | TEP TEP TEP TEP | 171 | +~~~~~~~~~~~~~~~~~~+ +BIER+ | 172 | / \ / \ | 173 +------+ +-------+ +-----+ or +------+ 174 | BFIR |-------|Non-BFR|-------| BFR |--BIER--| BFER | 175 +------+ +-------+ +-----+ +------+ 176 ------- L2 link 178 ~~~~~~~ IPv6(P2P) tunnel (TEP = Tunnel EndPoint) 180 <-----> BIER(P2MP) tunnel 182 In this model, an IPv6 tunnel works as a link-layer of BIER, and BIER 183 works as a layer-2.5 over tunnels or L2 links. Between two BFRs, 184 either a L2 link can be used directly or any tunnel (IPv6 or not) can 185 be used for BIER transport. In the tunnel case, the transmitting BFR 186 adds tunnel encapsulation (e.g. IPv6 header) and the receiving BFR 187 removes the tunnel encapsulation. 189 General consideration of this model is to keep BIER and IPv6 190 independent of each other. The BIER header is not part of the IPv6 191 header but comes after the transport header (L2 or tunnel header) and 192 before BIER payload. 194 3.2. Integrated Model 196 The second conceptual model is an Integrated Model that integrates 197 BIER as part of the IPv6 data plane, making it a "Layer-3 BIER" 198 approach. 200 |<<-----(BIER-based multicast overlay)----->>| 201 | | 202 |<----------(L3 BIER(P2MP) tunnel)---------->| 203 | | 204 | SEP SEP SEP SEP | 205 | +~~~~~~~~~~~~~~~~~~+ +~~~~+ | 206 | / \ / \ | 207 +------+ +-------+ +-----+ +------+ 208 | BFIR |-------|Non-BFR|-------| BFR |--------| BFER | 209 +------+ +-------+ +-----+ +------+ 211 ------- L2 link 213 ~~~~~~~ IPv6(P2P) segment (SEP = Segment EndPoint) 215 <-----> BIER(P2MP) tunnel 217 In this model, BIER works as part of the IPv6 data plane. The BFIR 218 and BFERs work as IPv6 (P2MP) tunnel endpoints, and BFRs work as IPv6 219 segment endpoints. The BIER header is processed on each segment 220 endpoint and there is no decapsulation, or re-encapsulation, on the 221 segment endpoints. 223 This model typically needs an IPv6 extension header to carry the BIER 224 header. and processing of the BIER header (e.g., the BitString) will 225 be implemented as part of the IPv6 extension header processing. The 226 IPv6 source address is the BIER packet source-origin identifier, and 227 is unchanged through the BIER domain from BFIR to BFERs. 229 General consideration of this model is to use the IPv6 capabilities 230 integrated, in addition to normal BIER function, to facilitate new 231 requirements that may emerge in an IPv6 network. 233 4. Requirements 235 There are several suggested requirements for BIER IPv6 solutions. 237 In this document, the requirements are divided into two levels: 238 Mandatory and Optional. The requirement levels are determined based 239 on the following factors: 241 If the requirement is required for a feature that is likely to be 242 a potential deployment, the requirement level will be considered 243 mandatory. 245 If the impact of not implementing the requirement may block BIER 246 from been deployed, the requirement level will be considered 247 mandatory. 249 4.1. Mandatory Requirements 251 Considering that these mandatory requirements are all well-known to 252 the working group, and practical in normal deployment, they will be 253 listed without a detailed description. 255 4.1.1. Support various L2 link types 257 The solution should support various kinds of L2 data link types. 259 4.1.2. Support BIER architecture 261 The solution must support the BIER architecture. 263 Supporting different multicast flow overlays, multiple sub-domains, 264 multi-topologies, multiple sets, multiple Bit String Lengths, and 265 deterministic ECMP are considered essential functions of BIER and 266 need to be supported. 268 4.1.3. Support deployment with Non-BFR routers 270 The solution must support deployments with BIER-incapable routers. 271 This is beneficial to the deployment of BIER, especially in early 272 deployments when some routers do not support BIER forwarding but 273 support IPv6 forwarding. 275 4.1.4. Support OAM 277 BIER OAM should be supported, either directly using existing methods, 278 or by specifying a new method for the same functionality. It may be 279 considered essential as part of the BIER architecture in some cases. 281 4.2. Optional Requirements 283 The requirements in this section are listed as optional, and each 284 requirement is explained with a detailed scenario. Note that 285 fragmentation and IPSEC ESP are not BIER functions, they are provided 286 by the upper IP layer. 288 4.2.1. Support Fragmentation 290 There are some cases where the Fragmentation/Assembly function is 291 needed for BIER to work in an IPv6 network. 293 For example, a customer IPv6 multicast packet may be 1280 bytes and 294 is required to be transported through an IPv6 network using BIER. 295 Every link of the IPv6 network is no less than the requisite 1280 296 bytes [RFC8200], but the size of the payload that can be encapsulated 297 in BIER (BIER-MTU) is less than 1280 bytes. In this case, it is not 298 the appropriate action for a BFIR to drop the packet and advertise an 299 MTU to the source [RFC8296]. Instead, the IPv6 transport mechanism, 300 either integrated with or independent to BIER, need to provide the 301 fragmentation and assembly function. 303 4.2.2. Support IPSEC ESP 305 There are some cases where the IPSEC ESP function may be needed to 306 transport c-multicast packets through an IPv6 network with 307 confidentiality using BIER technology. 309 A service provider may want to provide additional security SLA to its 310 customer to ensure that the unencrypted c-multicast packet is not 311 altered in the service provider's network. In this case, if the BIER 312 technology is preferred for the multicast service, BIER with IPSEC 313 ESP support may be a candidate solution. On the other hand, the 314 traffic protection may be better provided via IPSEC or MACSEC at 315 multicast flow overlay over and beyond the BIER domain. 317 5. IANA Considerations 319 Some BIER IPv6 encapsulation proposals do not require any action from 320 IANA while other proposals require new IPv6 Option codepoints from 321 IPv6 sub-registries, new "Next header" values, or require new IP 322 Protocol codes. This document, however, does not require anything 323 from IANA. 325 6. Security Considerations 327 There are no security issues introduced by this draft. 329 7. Acknowledgement 331 Thanks to Eric Rosen for his listed set of initial requirements on 332 the BIER WG mailing list. 334 8. Normative References 336 [I-D.pfister-bier-over-ipv6] 337 Pfister, P. and I. Wijnands, "An IPv6 based BIER 338 Encapsulation and Encoding", draft-pfister-bier-over- 339 ipv6-01 (work in progress), October 2016. 341 [I-D.xie-bier-ipv6-encapsulation] 342 Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., 343 Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, 344 "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- 345 xie-bier-ipv6-encapsulation-08 (work in progress), July 346 2020. 348 [I-D.zhang-bier-bierin6] 349 Zhang, Z., Zhang, Z., Wijnands, I., Bidgoli, H., and M. 350 McBride, "BIER in IPv6 (BIERin6)", draft-zhang-bier- 351 bierin6-07 (work in progress), July 2020. 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, 355 DOI 10.17487/RFC2119, March 1997, 356 . 358 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 359 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 360 December 1998, . 362 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 363 (IPv6) Specification", STD 86, RFC 8200, 364 DOI 10.17487/RFC8200, July 2017, 365 . 367 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 368 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 369 Explicit Replication (BIER)", RFC 8279, 370 DOI 10.17487/RFC8279, November 2017, 371 . 373 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 374 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 375 for Bit Index Explicit Replication (BIER) in MPLS and Non- 376 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 377 2018, . 379 Appendix A. List of Solutions 381 There have been some proposed solutions for BIER in IPv6 382 environments. Some solutions propose encoding while others propose 383 encapsulation. It is recommended for the wg to evaluate these 384 solutions, against the requirements listed previously, in order to 385 make informed decisions on solution readiness. 387 This section lists these solutions categorizing in the two conceptual 388 models. 390 A.1. Integrated mode approach 392 One example of this model is defined in [I-D.pfister-bier-over-ipv6], 393 where the information required for BIER forwarding, e.g., the 394 BitString, is encoded in the low-order bits of the IPv6 destination 395 address of each packet. The high-order bits of the IPv6 destination 396 address are used by intermediate routers for unicast forwarding, 397 deciding whether a packet is a BIER packet, and if so, to identify 398 the BIER Sub-Domain, Set Identifier and BitString length. The BIER 399 function is integrated in the IPv6 header and its forwarding 400 procedure, and the BIER payload is encapsulated as the IPv6 payload. 402 +---------------+------------------- 403 | IPv6 header | payload 404 | (BitString in | 405 | DA lower bits)| 406 | Next Header | 407 +---------------+------------------- 409 Another example of this model is defined in 410 [I-D.xie-bier-ipv6-encapsulation], where information required for 411 BIER forwarding, e.g., the BIER header, is encoded in an Option TLV 412 (indicated by an Option Type to be allocated by IANA) of the IPv6 413 Destination Option Header. The third-highest-order bit of the Option 414 Type is set to 1 to allow Option Data (e.g., the BitString) change en 415 route. The BIER function is integrated in IPv6 extension header and 416 its forwarding procedure, and the BIER payload is encapsulated as the 417 IPv6 payload. 419 +---------------+-----------------+------------------- 420 | IPv6 header | IPv6 Ext header | payload 421 | | (BIER header in | 422 | | TLV Type = X) | 423 | Next Header | Next Header | 424 +---------------+-----------------+------------------- 426 A.2. Independent model approach 428 One example of this model is defined in [I-D.zhang-bier-bierin6], 429 where the BIER header and the payload following it are L2 payload 430 when feasible (e.g. when two BFRs are directly connected) or IPv6 431 payload when IPv6 transport is needed/desired (e.g. when two BFRs are 432 not directly connected). This is indicated by either a 0xAB37 433 Ethertype allocated to BIER or a new IPv6 Next-Header value to be 434 allocated by IANA. 436 +---------------+-----------------+------------------- 437 | Ethernet | BIER header | payload 438 | (ethType = | (BIFT-id, ...) | 439 | 0xAB37) | | 440 | | Next Header | 441 +---------------+-----------------+------------------- 443 +---------------+-----------------+------------------- 444 | IPv6 header | IPv6 Ext header | BIER Hdr + payload 445 | | (optional) | as IPv6 payload 446 | | | 447 | Next Header | Next Header = X | 448 +---------------+-----------------+------------------- 450 While not specified in [I-D.zhang-bier-bierin6], any other tunnel 451 types supported by the IPv6 environment could be used, e.g. IPv6 452 GRE/UDP: 454 +---------------+-----------------+------------+---------------- 455 | IPv6 header | IPv6 Ext header | GRE header | 456 | | (optional) | | BIER Hdr + 457 | | | | payload as GRE 458 | Next Header | Next Header |Proto=0xAB37| Payload 459 +---------------+-----------------+------------+---------------- 461 +---------------+-----------------+------------+---------------- 462 | IPv6 header | IPv6 Ext header | UDP header | 463 | | (optional) | | BIER Hdr + 464 | | | | payload as UDP 465 | Next Header |Next Header =UDP | DPort=TBD | Payload 466 +---------------+-----------------+------------+---------------- 468 Authors' Addresses 470 Mike McBride 471 Futurewei 473 Email: michael.mcbride@futurewei.com 475 Jingrong Xie 476 Huawei 478 Email: xiejingrong@huawei.com 480 Xuesong Geng 481 Huawei 483 Email: gengxuesong@huawei.com 485 Senthil Dhanaraj 486 Huawei 488 Email: senthil.dhanaraj@huawei.com 490 Rajiv Asati 491 Cisco 493 Email: rajiva@cisco.com 495 Yongqing Zhu 496 China Telecom 498 Email: zhuyq8@chinatelecom.cn 500 Gyan Mishra 501 Verizon Inc. 503 Email: gyan.s.mishra@verizon.com 505 Zhaohui Zhang 506 Juniper 508 Email: zzhang@juniper.net