idnits 2.17.00 (12 Aug 2021) /tmp/idnits42278/draft-liu-msr6-use-cases-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 document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (7 March 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-05) exists of draft-ietf-bess-bgp-sdwan-usage-04 == Outdated reference: A later version (-13) exists of draft-ietf-bier-te-arch-12 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 Y. Liu 3 Internet-Draft F. Yang 4 Intended status: Informational China Mobile 5 Expires: 8 September 2022 A. Wang 6 China Telecom 7 X. Zhang 8 China Unicom 9 X. Geng 10 Z. Li 11 Huawei 12 7 March 2022 14 MSR6(Multicast Source Routing over IPv6) Use Case 15 draft-liu-msr6-use-cases-00 17 Abstract 19 This document introduces the use cases for MSR6, inclusing DCN and 20 SD-WAN. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 8 September 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. MSR6 in DCN . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. MSR6 in SD-WAN . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 MSR6(multicast source routing over IPv6) 73 ([I-D.cheng-spring-ipv6-msr-design-consideration]) defines multicast 74 source routing over IPv6, just as SRv6 for unicast. 76 MSR6 encapsulation reuses IPv6 Header which could go thourgh non-MSR6 77 IPv6 node and easily be used with other existing IPv6 extension 78 headers. 80 Source routing brings no flow status in intermediate nodes and 81 efficient encapsulation expense, which guarantees scalability. IPv6 82 extension header can be used for indicating multicast replication 83 information. 85 MSR6 has two basic modes of forwarding: one is based on Shortest Path 86 First(SPF), which is called MSR6 BE mode; the other is based on 87 traffic engineered, which is called MSR6 TE mode. 89 When a multicast data packet enters an MSR6 domain, the ingress node 90 encapsulates the packet with an IPv6 header with MSR6 function. The 91 destination address of the IPv6 header steers the packet to the next 92 replication node and the replication node replicates the packet based 93 on MSR6 function, updates the destination address and iterates this 94 process. Similar as SRv6 process. There are multiple methods to 95 indicate multicast replication function and some of the potential 96 solutions have been defined in individual drafts, independent with 97 using bitstring or not. The existing multicast forwarding methods 98 have been defined in IETF could be reused , e.g., BIER, P2MP Tree 99 SID. 101 MSR6 could be used in the existing or potential multicast scenarios 102 with the following benefits: 1.Native IPv6 based design, to enable 103 multicast in an unified method with unicast. 2.Source Routing to 104 achieve high scalability. 106 This document focuses on 2 of the use cases: DCN and SD-WAN, where 107 MSR6 is more suitable comparted to other existing multicast solutions 108 defined in IETF. 110 2. MSR6 in DCN 112 An increasing number of organizations operate dual-stack IPv4/IPv6 113 networks. Adoption of IPv6 has been delayed, partly due to network 114 address translation (NAT) with IPv4, which takes private IP addresses 115 and turns them into public IP addresses. An increasing number of 116 organizations are adopting IPv6 in their clouds, driven by the public 117 IPv4 space exhaustion, private IPv4 scarcity, especially within 118 large-scale networks, and the need to provide connectivity to 119 IPv6-only clients. 121 There are applications in data center with point-to-multipoint 122 communication patterns that would benefit from native multicast. All 123 these applications, when migrating to public clouds, will use host- 124 based packet replication techniques. This leads to inefficiencies 125 for both tenants and providers, which inflates CPU load in 126 datacenters, but also prevents tenants from sustaining high 127 throughputs and low latencies for multicast workloads. 129 MSR6 could simiplify multicast deployment in Data Center Network(DCN) 130 with the capability of IPv6 based source routing. 132 The following figure shows an example of a data center network with 133 dual-homes hosts for reliability. There are about 10k swtiches, 9k 134 of which are leaves, and 100k adjacencies. 136 +-------+ +---------------+ +----------------+ +--------+ 137 | DC-GW +---+ CORE1 | | CORE2 | ...| COREn | 138 +---+---+ ++------+--+--+-+ ++-+--+----+-----+ +--------+ 139 | | | | | | | | | 140 +----+----+ | | | +-------------------------+ 141 | Server | | +-------------------+ | | | | 142 |(source1)| | | | | | | | | 143 +---------+ | | | | +--------+ | | | 144 | | | | | | | | 145 | | +----------------+ | | | 146 | | | | | | | | 147 ++---+-+ +------+ +-+----+ ++----++ +------+ 148 |SPINE1| |SPINE2| |SPINE3| |SPINE4| ...|SPINEn| 149 ++----++ ++---+-+ +-+--+-+ ++----++ +------+ 150 | | | | | | | | 151 | +-------+ | | +--------+ | 152 | | | | | | | | 153 | +-------+ | | | +------+ | | 154 | | | | | | | | 155 ++--+-+ ++-+--+ ++--+-+ ++--+-+ +-----+ 156 |LEAF1| |LEAF2| |LEAF3| |LEAF4| ...|LEAFn| 157 +-----+ +-----+ +-----+ +-----+ +-----+ 158 | | | | | 159 +- - - -+ +- - - -+ +- - - -+ +- - - -+ +- - - -+ 160 | Server| | Server| |Server3| |Server4|...| Server| 161 +- - - -+ +- - - -+ +- - - -+ +- - - -+ +- - - -+ 163 For multicast application in DCN, multicast source could be inside 164 DCN or outside DCN. 166 For example, a multicast stream could be from source1 to service 3 167 and server 4. The multicast tree is from DC-Gateway to LEAF3 and 168 LEAF4, which could be presented as: 170 DC-GW(ingress 171 node)-->CORE1---->SPINE3--[replicate]--->LEAF3(leaf)+LEAF4(leaf) 173 If BIER defined in [RFC8279] is used for P2MP tunnel in the network, 174 bit position should be allocated for all egress nodes, i.e., 9k bit 175 positions for all leaves a. Most of the bit positions are 0 and only 176 2 of them are set in the example. In this case, the BIER Header is 177 inefficient and the encapsulation expense is unacceptable. 178 Considering that the number of bit position also determines the the 179 BIFT entry size, forwarding speed may also be affected. 181 There are some possible methods to improve the situation in BIER. 182 For example "set" could be used to save the cost of bit position, but 183 multiple packets are supposed to be sent when the BFR-ID of the 184 receivers belong to different set. And when the network size is 185 large, the usefulness of set is not obvious. In the case showed 186 above, even 10 Sets are planned, there needs about 9 hundreds bit 187 positions for each packet and different set requests different BIFTs 188 in each node. 190 In BIER-TE, BitStrings need to carry bits to indicate not only the 191 receiving BFER but also the intermediate hops/links across which the 192 packet must be sent. For the most common case, bit position should 193 be allocated for all adjacencies. About 100k bit positions are 194 requested. The bit position representing adjacencies that the 195 multicast tree goes through are set and the rest of the bit positions 196 are set to 0. In the example above, 7 bit positions are set in the 197 bitstring. BIER-TE header is less efficient and the encapsulation 198 expense is more signicicant,even compared to BIER. Also controller 199 is supposed to allocate different BIFTs for 10k nodes; 201 Some methods introduced by [I-D.ietf-bier-te-arch] to improve the 202 situation. "Set" could also be used, but not enough as the analysis 203 above. There are some other methods for reducing the number of 204 required bits, such as unicast (forward_routed()), ECMP() or flood 205 (DNC) over "uninteresting" sub- parts of the topology, which brings 206 different kinds of limitation for path planning. 208 In MSR6, only the nodes/adjacencies in the multicast tree are 209 indicated in the packet just like the segment list in SRv6 used for 210 unicast. Packet encapsulation overhead is proportional to the number 211 of nodes or links through which the multicast tree passes (the 212 encapsulation overhead of the path indication is 3*segment length, 213 which is 3*128 bits in the example above). Local Bitstring (reduce 214 the number of segments in the segment list, since it is no longer 215 necessary to represent leaf nodes with segments, where the 216 encapsulation overhead of the path indication is 1*segment length, 217 which is 1*128 bits in the example above) and compression similar as 218 SRv6 (reduce the length of each segment, where the encapsulation 219 overhead of the path indication is 3*segment length, which is 3*32 220 bits, if the length of compressed segment is 32 bits, in the example 221 above) could be used to reduce header expense further. 223 MSR6 enhances the scalability for multicast: when the multicast 224 domain is large while the multicast tree is small, only the 225 information of the multicast tree could be encapsulated in the 226 packet. It means that the multicast packet encapsulation efficiency 227 is not affected by the number of nodes/adjacencies in the network, 228 which enhances the scalibility of multicast domain scale. 230 3. MSR6 in SD-WAN 232 [I-D.ietf-bess-bgp-sdwan-usage] discusses the usage and applicability 233 of BGP as the control plane for multiple SDWAN scenarios. 234 [I-D.dukes-sr-for-sdwan] and 235 [I-D.dunbar-sr-sdwan-over-hybrid-networks] describe how SR/SRv6 could 236 be used in SD-WAN senario. 238 Security is one of the fundamental requiremnt in SD-WAN network. 239 Multicast services for SD-WAN also request encryption. The following 240 figure shows an example of SD-WAN multicast. 242 IPv6 Network +-----+ +-----+ 243 | CPE1| | CPE2| 244 +-----+ +-----+ 245 ********** 246 **** **** 247 ** Internet ** 248 **** **** 249 ********** 250 +-----+ +-----+ +-----+ +-----+ 251 | CPE3| | CPE4| ... |CPE98| |CPE99| 252 +-----+ +-----+ +-----+ +-----+ 253 ********** | | 254 **** **** +---------+ 255 ** Internet ** | Server | 256 **** **** | (source)| 257 ********** +---------+ 258 +-----+ +-----+ 259 | CPE5| | CPE6| 260 +-----+ +-----+ 261 | | 262 +- - - - - - - - - -+ 263 | Server (Receiver) | 264 +- - - - - - - - - -+ 266 A multicast case in SD-WAN is from CE99 to CE3, CE5 and CE6. The 267 multicast tree could presented as: 269 CE99(ingress node)-->CPE2--[replicate]-->CE3(leaf)+CE4--[replicate]-- 270 ->CE5(leaf)+CE6(leaf) 271 IPv6 Network +-----+ +-----+ 272 | CPE1| | CPE2| 273 +-+---+ +-+---+ 274 | | 275 +-----+---+-------- | ---+ 276 | | | | 277 | +------ |-+-------+----|---------+ 278 | | | | | | 279 +-+-+-+ +-+-+-+ +--+--+ +--+--+ 280 | CPE3| | CPE4| ... |CPE98| |CPE99| 281 +--+--+ +--+--+ +--+--+ +--+--+ 282 | | | | 283 +----+----+ | +----+----+ 284 | +-------|-+--+ | 285 | | | | +----+----+ 286 +-+-+-+ +-+-+-+ | Server | 287 | CPE5| | CPE6| | (source)| 288 +-----+ +-----+ +---------+ 289 | | 290 +- - - - - - - - - -+ 291 | Server (Receiver) | 292 +- - - - - - - - - -+ 294 The independent layer design of BIER brings challenges to support 295 authentication and security over Internet: a new Security Header, 296 like IPsec, has to be defined in the BIER layer. If BIER is used in 297 this case, the packet is supposed to encapsulated as the following to 298 implement end to end multicast encryption: 300 +--------------------------------+ 301 | IPv6 Header | 302 +--------------------------------+ 303 | BIER Header | 304 +--------------------------------+ 305 | New Security Header | 306 +--------------------------------+ 307 | Payload | 308 +--------------------------------+ 310 For MSR6, which is designed based on native IPv6, it is allowed to 311 reuse IPv6 Authentication header and Encapsulating Security Payload 312 header. If MSR6 is used in this case, the packet is supposed to 313 encapsulated as the following to implement end to end multicast 314 security: 316 +--------------------------------+ 317 | IPv6 Header | 318 +--------------------------------+ 319 | IPv6 EH (MSR6 EH or Options) | 320 +--------------------------------+ 321 | IPSec Header (ESP & AH) | 322 +--------------------------------+ 323 | Payload | 324 +--------------------------------+ 326 Just as IPsec, there are other existing functionalities that have 327 been in IETF based on IPv6, for example fragmentation, network 328 slicing, IOAM etc, which could all be reused in MSR6 which is based 329 on IPv6 data plane. Comparingly, it has to be defined again if these 330 functions/header are supposed to be used in BIER, which brings 331 redundancy. 333 4. IANA Considerations 335 This document makes no request of IANA. 337 Note to RFC Editor: this section may be removed on publication as an 338 RFC. 340 5. Security Considerations 342 6. Acknowledgements 344 7. Normative References 346 [I-D.cheng-spring-ipv6-msr-design-consideration] 347 Cheng, W., Mishra, G., Li, Z., Wang, A., Qin, Z., and C. 348 Fan, "Design Consideration of IPv6 Multicast Source 349 Routing (MSR6)", Work in Progress, Internet-Draft, draft- 350 cheng-spring-ipv6-msr-design-consideration-01, 25 October 351 2021, . 354 [I-D.dukes-sr-for-sdwan] 355 Dukes, D., Filsfils, C., Dawra, G., Garvia, P. C., Clad, 356 F., and S. Salsano, "SR For SDWAN: VPN with Underlay SLA", 357 Work in Progress, Internet-Draft, draft-dukes-sr-for- 358 sdwan-01, 27 April 2018, . 361 [I-D.dunbar-sr-sdwan-over-hybrid-networks] 362 Dunbar, L. and M. Toy, "SRv6 across SDWAN paths", Work in 363 Progress, Internet-Draft, draft-dunbar-sr-sdwan-over- 364 hybrid-networks-07, 18 May 2021, 365 . 368 [I-D.ietf-bess-bgp-sdwan-usage] 369 Dunbar, L., Guichard, J., Sajassi, A., Drake, J., Najem, 370 B., and D. Carrel, "BGP Usage for SDWAN Overlay Networks", 371 Work in Progress, Internet-Draft, draft-ietf-bess-bgp- 372 sdwan-usage-04, 18 October 2021, 373 . 376 [I-D.ietf-bier-te-arch] 377 Eckert, T., Menth, M., and G. Cauchie, "Tree Engineering 378 for Bit Index Explicit Replication (BIER-TE)", Work in 379 Progress, Internet-Draft, draft-ietf-bier-te-arch-12, 28 380 January 2022, . 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, 385 DOI 10.17487/RFC2119, March 1997, 386 . 388 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 389 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 390 Explicit Replication (BIER)", RFC 8279, 391 DOI 10.17487/RFC8279, November 2017, 392 . 394 Authors' Addresses 396 Yisong Liu 397 China Mobile 398 Email: liuyisong@chinamobile.com 400 Feng Yang 401 China Mobile 402 Email: yangfeng@chinamobile.com 404 Aijun Wang 405 China Telecom 406 Email: wangaj3@chinatelecom.cn 407 Xueru Zhang 408 China Unicom 409 Email: zhangxr49@chinaunicom.cn 411 Xuesong Geng 412 Huawei 413 Email: gengxuesong@huawei.com 415 Zhenbin Li 416 Huawei 417 Email: lizhenbin@huawei.com