idnits 2.17.1 draft-li-spring-ipv6-msr-gap-analysis-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 (July 12, 2021) is 1016 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-cheng-spring-ipv6-msr-design-consideration-00 Summary: 0 errors (**), 0 flaws (~~), 3 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 Huawei Technologies 4 Intended status: Informational G. Mishra 5 Expires: January 13, 2022 Verizon Inc. 6 Z. Qin 7 China Unicom 8 July 12, 2021 10 Gap Analysis of IPv6 Multicast Source Routing (MSR6) 11 draft-li-spring-ipv6-msr-gap-analysis-00 13 Abstract 15 This document analyses the gaps of the existing IPv6 multicast 16 solutions under discussion in IETF based on the requirements. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 13, 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. BIERin6 . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. BIERv6 . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Historical Review . . . . . . . . . . . . . . . . . . . . 5 63 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Multicast could provide efficient P2MP service without bandwidth 73 waste. The increasing amount of live video traffic in the network 74 bring new requirements for multicast solutions. The existing 75 multicast solutions request multicast tree-building on control plane 76 and maintaining end-to-end tree state per flow, which impacts router 77 state capacity and network convergence time. There has been a lot of 78 work in IETF to simplify service deployment, in which Source Routing 79 is a very important technology, including SRv6, BIER, etc. Source 80 routing is able to reduce the state of intermediate nodes and 81 indicate multicast forwarding in the ingress nodes, which could 82 simplify multicast deployment. Source routing requires sufficient 83 flexibility on the forwarding plane and IPv6 has the advantage with 84 good scalability. Therefore, it is important to simplify multicast 85 deployment and meet high quality service requirements with IPv6 86 Source Routing based multicast. 88 Based on the design consideration defined in 89 [I-D.cheng-spring-ipv6-msr-design-consideration], this document 90 analyses the gaps of the existing IPv6 multicast solutions under 91 discussion in IETF. The definition of the new IPv6 multicast source 92 routing solution is out of the scope of this document. 94 2. Gap Analysis 96 2.1. BIERin6 98 ipThe solution described in [I-D.zhang-bier-bierin6] is called 99 BIERin6. The encapsulation of BIERin6 is as follows: 101 +---------------+------------------+----------------------+ 102 | IPv6 header | BIER Header | X type of | 103 | | defined in | C-multicast packet | 104 | Ethertype= | RFC8296 | | 105 | 0xAB37 | Protocol = X | (IPv4/IPv6/Ethernet) | 106 +---------------+------------------+----------------------+ 107 | | | | 108 |<-IPv6 header->|<--BIER Header--->|<--BIERin6 Payload---->| 110 BIERin6 proposes to encapsulate the IPv6 header before the BIER 111 header in order to transit the BIER header through IPv6 nodes by 112 adding IPv6 header between BIER forwarding nodes. The "next header" 113 codepoint of the IPv6 header is set to the value that means that "the 114 next header is non-MPLS BIER". 116 BIERin6 implements P2MP forwarding follows the BIER architecture 117 defined in [RFC8279]. 119 There are some issues to be considered with the classic Layered 120 architecture of BIER used by BIERin6 in supporting IPv6 Multicast 121 Source Routing: 123 1. Support non-native IPv6 scenarios : In BIERin6, IPv6 is only used 124 as the transport tunnel to transit the IPv4 domain. In fact this 125 method can also be used in the IPv4 to traverse the IPv4 domain. 126 Moreover the service layer above the transport tunnel can be non- 127 IPv6. For example, in BIERin6 MVPN could use MPLS label for VPN 128 identification. Unlike BIERin6, IPv6 Multicast Source Routing is 129 supposed to be a native IPv6 solution. 131 2. Architecture Considerations: 133 1) When the BIER layer is treated as an independent layer to support 134 features mentioned in section 2, the new encapsulation for fragment, 135 security, network slicing, DetNet, IOAM has to be defined in the BIER 136 layer. Moreover, this will also cause redundancy and conflicts when 137 BIER is used with IPv6 layer or MPLS layer since the encapsulations 138 for these functionalities are also defined for the IPv6 layer and 139 MPLS layer; 140 2) When the BIER encapsulation is treated as a separate layer and the 141 rest of the functionalities are realized in the IPv6 layer, it also 142 causes problems. For example, if encryption is supported in the IPv6 143 data plane, it makes the contents of the BIER layer encrypted and 144 unprocessable; if IOAM and RH are supported in the IPv6 data plane 145 which cause the more overhead, it would make it difficult to get 146 information on the BIER layer and has much effect on the forwarding 147 performance. In addition, if IOAM is engaged, this leads to 148 information loss when IPv6 encapsulation is switched in the middle 149 nodes and cannot be implemented end-to-end. 151 3. BIERin6 is hard to complete end-to-end service to support host 152 initiating source routing. If BIERin6 is used in the host, the 153 source address information can be lost in the middle nodes. 154 Moreover, the BIER layer as an independent network layer above IPv6, 155 just as TCP or UDP, will cause conflictions with the transport layer, 156 and have more impact on the Internet architecture. 158 4. Maintenance of tunnel state: BIERin6 needs to maintain the state 159 of the tunnel in the middle nodes when traversing IPv6 domains, which 160 adds complexity to service deployment. When new functionalities 161 mentioned in the sectioned such as network slicing, Detnet,IOAM,etc. 162 are applied when traverse the IPv6 domains, it will cause more 163 complexity in service provisioning and more network state 164 maintenance. 166 5. Based on existing functionalities, MPVPN/TE/Fragmentation/ESP 167 need be supported by BIERin6. 169 2.2. BIERv6 171 The solution described in [I-D.xie-bier-ipv6-encapsulation] is called 172 BIERv6. The encapsulation of BIERv6 is as follows: 174 +---------------+------------------+----------------------+ 175 | IPv6 header | IPv6 DO Header | X type of | 176 | | with BIER Option | C-multicast packet | 177 | | | | 178 | Next Hdr = 60 | Nxt Hdr = X | (IPv4/IPv6/Ethernet) | 179 +---------------+------------------+----------------------+ 180 | | | 181 |<----------BIERv6 header--------->|<---BIERv6 payload--->| 183 BIERv6 proposes to define a new type of destination options header 184 for BIER. The destination address of the IPv6 header indicates the 185 BIER forwarding nodes and changed to the next BIER forwarding nodes 186 based on the result of BIER forwarding table lookup. 188 BIERv6 implements P2MP forwarding follows the BIER architecture 189 defined in [RFC8279]. 191 BIERv6 uses Native IPv6 extention header to carry BIER info. And 192 BIERv6 could support MVPN by defining MVPN indication in source 193 address of the outer IPv6 header, which doesn't change along the P2MP 194 tunnel. The MVPN mechanism for BIERv6 is defined in 195 [I-D.xie-bier-ipv6-mvpn]. BIERv6 is able to directly reuse the new 196 functionalities supported by IPv6 and SRv6 without the problems 197 associated with Layered Architecture. In addition, BIERv6 uses 198 Native IPv6 and can be started directly at the Host without conflicts 199 with the transport layer. 201 BIERv6 has the following challenges: 203 1. Non-MPLS BIER header defined in [RFC8296] is used, but the BIER 204 header is designed as a separate layer, leaving some fields unused 205 and redundant in IPv6. 207 2. BIERv6 needs to support MVPN and Traffic Engineering. 209 2.3. Historical Review 211 In the field of IPv6 unicast source routing, there has been SR over 212 IP([RFC8663]) and SRv6. SR over IP takes the layered architecture 213 while SRv6 adopts native IPv6 design. Both solutions has different 214 application scenarios though there is the common functionality to 215 traverse IPv6 domain. SR over IP controls the scope to support more 216 new functionalities in the IPv6 data plane. SRv6 is being developed 217 combing with the new functionalities based on the IPv6 extension. 219 3. Summary 221 MSR6 is supposed to have: 223 o Native IPv6 design to reduce header layers and enable unified 224 processing 226 o Reuse existing IPv6 capabilities and SRv6 capabilities for 227 multicast 229 o BIER is able to implement network programming at the ingress nodes 230 in Best Effort scenarios. MSR6 needs to take advantage of the 231 capabilities in the existing BIER mechanism 233 o MVPN and Traffic Engineering support are requested 234 The existing multicast solutions have their own limitations which 235 constrains the deployment and development of multicast. New 236 multicast solution is expected in IETF. 238 4. IANA Considerations 240 This document makes no request of IANA. 242 5. Security Considerations 244 TBD 246 6. Acknowledgements 248 TBD 250 7. Normative References 252 [I-D.cheng-spring-ipv6-msr-design-consideration] 253 Cheng, W., Mishra, G., Li, Z., Wang, A., Qin, Z., and C. 254 Fan, "Design Consideration of IPv6 Multicast Source 255 Routing (MSR6)", draft-cheng-spring-ipv6-msr-design- 256 consideration-00 (work in progress), July 2021. 258 [I-D.xie-bier-ipv6-encapsulation] 259 Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., 260 Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, 261 "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- 262 xie-bier-ipv6-encapsulation-10 (work in progress), 263 February 2021. 265 [I-D.xie-bier-ipv6-mvpn] 266 Xie, J., McBride, M., Dhanaraj, S., Geng, L., and G. 267 Mishra, "Use of BIER IPv6 Encapsulation (BIERv6) for 268 Multicast VPN in IPv6 networks", draft-xie-bier- 269 ipv6-mvpn-03 (work in progress), October 2020. 271 [I-D.zhang-bier-bierin6] 272 Zhang, Z., Zhang, Z., Wijnands, I., Mishra, M., Bidgoli, 273 H., and G. Mishra, "Supporting BIER in IPv6 Networks 274 (BIERin6)", draft-zhang-bier-bierin6-09 (work in 275 progress), February 2021. 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, 279 DOI 10.17487/RFC2119, March 1997, 280 . 282 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 283 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 284 Explicit Replication (BIER)", RFC 8279, 285 DOI 10.17487/RFC8279, November 2017, 286 . 288 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 289 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 290 for Bit Index Explicit Replication (BIER) in MPLS and Non- 291 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 292 2018, . 294 [RFC8663] Xu, X., Bryant, S., Farrel, A., Hassan, S., Henderickx, 295 W., and Z. Li, "MPLS Segment Routing over IP", RFC 8663, 296 DOI 10.17487/RFC8663, December 2019, 297 . 299 Authors' Addresses 301 Zhenbin Li 302 Huawei Technologies 304 Email: lizhenbin@huawei.com 306 Gyan Mishra 307 Verizon Inc. 309 Email: gyan.s.mishra@verizon.com 311 Zhuangzhuang Qin 312 China Unicom 314 Email: qinzhuangzhuang@chinaunicom.cn