idnits 2.17.1 draft-ietf-bier-ipv6-requirements-09.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 28, 2020) is 1305 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-bier-ping-07 == Outdated reference: A later version (-15) exists of draft-ietf-bier-pmmm-oam-08 Summary: 0 errors (**), 0 flaws (~~), 4 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: April 1, 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 28, 2020 18 BIER IPv6 Requirements 19 draft-ietf-bier-ipv6-requirements-09 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 and detail solution 27 requirements, thereby assisting the working group in the development 28 of acceptable solutions. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 1, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Mandatory Requirements . . . . . . . . . . . . . . . . . 4 70 3.1.1. Support various L2 link types . . . . . . . . . . . . 4 71 3.1.2. Support BIER architecture . . . . . . . . . . . . . . 4 72 3.1.3. Support deployment with Non-BFR routers . . . . . . . 4 73 3.1.4. Support OAM . . . . . . . . . . . . . . . . . . . . . 5 74 3.2. Optional Requirements . . . . . . . . . . . . . . . . . . 5 75 3.2.1. Support Fragmentation . . . . . . . . . . . . . . . . 5 76 3.2.2. Support IPSEC ESP . . . . . . . . . . . . . . . . . . 5 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 79 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 6 80 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 per-flow state, through the use of a 88 multicast-specific BIER header. [RFC8296] defines two types of BIER 89 encapsulation: one is BIER MPLS encapsulation for MPLS environments, 90 the other is non-MPLS BIER encapsulation to run without MPLS. This 91 document describes non-MPLS BIER encapsulation in IPv6 environments. 92 We explain the requirements of transporting multicast flow overlay 93 payload through an IPv6 network underlay using BIER. The solutions 94 may use IPv6 forwarding plane and may include IPv6 encapsulation and/ 95 or generic IPv6 tunnelling. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 1.2. Terminology 105 o BIER: Bit Index Explicit Replication. Provides optimal multicast 106 forwarding through adding a BIER header and removing state in 107 intermediate routers. 109 2. Problem Statement 111 The problem is how to transport multicast packets, with non-MPLS BIER 112 encapsulation, in an IPv6 environment. We need to determine where to 113 put the BIER header in this IPv6 environment. With IPv6 114 encapsulation being increasingly used for unicast services, such as 115 VPN or L2VPN, it may be desirable to have IPv6 encapsulation also 116 used in BIER deployments for multicast services such as MVPN. It may 117 also be desirable to not use IPv6 encapsulation except when IPv6 118 tunneling (native or GRE/UDP-like) is used to transport BIER packets 119 over BIER-incapable routers. 121 Below is a simple scenario that needs BIER IPv6-based forwarding: 123 +--------------------------------------------+ 124 | | 125 | +------+ 126 | | BFER | 127 +------+ +-------+ +-----+ +------+ 128 | BFIR | |Non-BFR| | BFR | | 129 +------+ +-------+ +-----+ +------+ 130 | | BFER | 131 | IPv6 Network +------+ 132 | | 133 +--------------------------------------------+ 135 This scenario depicts the need to replicate BIER packets from a BFIR 136 to BFERs across an IPv6 Service Provider core. Inside the IPv6 137 network, the BIER header is used to direct the packet from one BFR to 138 the next BFRs, and either a IPv6 header or an L2/tunnel header is 139 used to provide reachability between BFRs. The IPv6 environment may 140 include a variety of link types, may be entirely IPv6, or may be dual 141 stack. There may be cases where not all routers are BFR capable in 142 the IPv6 environment but still want to deploy BIER. Regardless of 143 the environment, the problem is to deploy BIER, with non-MPLS BIER 144 encapsulation, in an IPv6 network. 146 3. Requirements 148 There are several suggested requirements for BIER IPv6 solutions. 150 In this document, the requirements are divided into two levels: 151 Mandatory and Optional. The requirement levels are determined based 152 on the following factors: 154 If the requirement is required for a feature that is likely to be 155 a potential deployment, the requirement level will be considered 156 mandatory. 158 If the impact of not implementing the requirement may block BIER 159 from been deployed, the requirement level will be considered 160 mandatory. 162 3.1. Mandatory Requirements 164 Considering that these mandatory requirements are all well-known to 165 the working group, and practical in normal deployment, they will be 166 listed without a detailed description. 168 3.1.1. Support various L2 link types 170 The solution should support various kinds of L2 data link types. 172 3.1.2. Support BIER architecture 174 The solution must support the BIER architecture. 176 Supporting different multicast flow overlays, multiple sub-domains, 177 multi-topologies, multiple sets, multiple Bit String Lengths, and 178 deterministic ECMP are considered essential functions of BIER and 179 need to be supported. 181 3.1.3. Support deployment with Non-BFR routers 183 The solution must support deployments with BIER-incapable routers. 184 This is beneficial to the deployment of BIER, especially in early 185 deployments when some routers do not support BIER forwarding but 186 support IPv6 forwarding. 188 3.1.4. Support OAM 190 BIER OAM tools like [I-D.ietf-bier-ping] and [I-D.ietf-bier-pmmm-oam] 191 should be supported, either directly using existing methods, or by 192 specifying a new method for the same functionality. They are likely 193 to be needed in normal BIER deployment for diagnostics. 195 3.2. Optional Requirements 197 The requirements in this section are listed as optional, and each 198 requirement is explained with a detailed scenario. Note that 199 fragmentation and IPSEC ESP are not BIER functions, they are provided 200 by the upper IP layer. 202 3.2.1. Support Fragmentation 204 There are some cases where the Fragmentation/Assembly function is 205 needed for BIER to work in an IPv6 network. 207 For example, a customer IPv6 multicast packet may be 1280 bytes and 208 is required to be transported through an IPv6 network using BIER. 209 Every link of the IPv6 network is no less than the requisite 1280 210 bytes [RFC8200], but the size of the payload that can be encapsulated 211 in BIER (BIER-MTU) is less than 1280 bytes. In this case, it is not 212 the appropriate action for a BFIR to drop the packet and advertise an 213 MTU to the source [RFC8296]. Instead, some transport mechanism needs 214 to provide the fragmentation and assembly function. 216 3.2.2. Support IPSEC ESP 218 There are some cases where the IPSEC ESP function may be needed to 219 transport c-multicast packets through an IPv6 network with 220 confidentiality using BIER technology. 222 A service provider may want to provide additional security SLA to its 223 customer to ensure that the unencrypted c-multicast packet is not 224 altered in the service provider's network. In this case, if the BIER 225 technology is preferred for the multicast service, BIER with IPSEC 226 ESP support may be a candidate solution. On the other hand, the 227 traffic protection may be better provided via IPSEC or MACSEC at 228 multicast flow overlay over and beyond the BIER domain. 230 4. IANA Considerations 232 Some BIER IPv6 encapsulation proposals do not require any action from 233 IANA while other proposals require new IPv6 Option codepoints from 234 IPv6 sub-registries, new "Next header" values, or require new IP 235 Protocol codes. This document, however, does not require anything 236 from IANA. 238 5. Security Considerations 240 There are no security issues introduced by this draft. 242 6. Acknowledgement 244 Thanks to Eric Rosen for his listed set of initial requirements on 245 the BIER WG mailing list. 247 7. Normative References 249 [I-D.ietf-bier-ping] 250 Nainar, N., Pignataro, C., Akiya, N., Zheng, L., Chen, M., 251 and G. Mirsky, "BIER Ping and Trace", draft-ietf-bier- 252 ping-07 (work in progress), May 2020. 254 [I-D.ietf-bier-pmmm-oam] 255 Mirsky, G., Zheng, L., Chen, M., and G. Fioccola, 256 "Performance Measurement (PM) with Marking Method in Bit 257 Index Explicit Replication (BIER) Layer", draft-ietf-bier- 258 pmmm-oam-08 (work in progress), May 2020. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, 262 DOI 10.17487/RFC2119, March 1997, 263 . 265 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 266 (IPv6) Specification", STD 86, RFC 8200, 267 DOI 10.17487/RFC8200, July 2017, 268 . 270 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 271 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 272 Explicit Replication (BIER)", RFC 8279, 273 DOI 10.17487/RFC8279, November 2017, 274 . 276 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 277 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 278 for Bit Index Explicit Replication (BIER) in MPLS and Non- 279 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 280 2018, . 282 Authors' Addresses 284 Mike McBride 285 Futurewei 287 Email: michael.mcbride@futurewei.com 289 Jingrong Xie 290 Huawei 292 Email: xiejingrong@huawei.com 294 Xuesong Geng 295 Huawei 297 Email: gengxuesong@huawei.com 299 Senthil Dhanaraj 300 Huawei 302 Email: senthil.dhanaraj@huawei.com 304 Rajiv Asati 305 Cisco 307 Email: rajiva@cisco.com 309 Yongqing Zhu 310 China Telecom 312 Email: zhuyq8@chinatelecom.cn 314 Gyan Mishra 315 Verizon Inc. 317 Email: gyan.s.mishra@verizon.com 319 Zhaohui Zhang 320 Juniper 322 Email: zzhang@juniper.net