idnits 2.17.1 draft-geng-bier-ipv6-inter-domain-02.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 == Line 311 has weird spacing: '...ponding to SD...' == Line 312 has weird spacing: '...ponding to SD...' == Line 313 has weird spacing: '...ponding to SD...' == Line 314 has weird spacing: '...ponding to SD...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 27, 2020) is 1274 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC8296' is mentioned on line 83, but not defined == Unused Reference: 'RFC8279' is defined on line 445, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-bier-ipv6-requirements (ref. 'I-D.ietf-bier-ipv6-requirements') == Outdated reference: A later version (-04) exists of draft-ietf-bier-non-mpls-bift-encoding-02 ** Downref: Normative reference to an Informational draft: draft-ietf-bier-non-mpls-bift-encoding (ref. 'I-D.ietf-bier-non-mpls-bift-encoding') == Outdated reference: A later version (-10) exists of draft-xie-bier-ipv6-encapsulation-08 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Downref: Normative reference to an Informational RFC: RFC 6770 Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Geng 3 Internet-Draft China Mobile 4 Intended status: Standards Track J. Xie 5 Expires: April 30, 2021 Huawei Technologies 6 M. McBride 7 Futurewei 8 G. Yan 9 X. Geng 10 Huawei Technologies 11 October 27, 2020 13 Inter-Domain Multicast Deployment using BIERv6 14 draft-geng-bier-ipv6-inter-domain-02 16 Abstract 18 Bit Index Explicit Replication IPv6 encapsulation (BIERv6) introduces 19 an approach to use IPv6 extension header to carry BIER header with 20 IPv6 unicast address as destination address. It provides the ability 21 to replicate a packet from one router to other routers in a different 22 domain as well as routers in the same domain. This document 23 introduces the techniques for multicast deployment across multiple 24 domains using BIERv6, and demonstrate how BIERv6 is beneficial for 25 such deployment. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119] and 32 [RFC8174]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 30, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Inter-domain Multicast Overview . . . . . . . . . . . . . . . 3 70 4. Inter-domain Multicast Deployment using BIERv6 . . . . . . . 4 71 4.1. Hierarchical Multicast . . . . . . . . . . . . . . . . . 4 72 4.2. Peering Multicast . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 8.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 Bit Index Explicit Replication [RFC8296] IPv6 encapsulation (BIERv6) 84 described in [I-D.xie-bier-ipv6-encapsulation] introduces an approach 85 to use IPv6 extension header to carry BIER header. One BIERv6 86 option, using IPv6 unicast address as destination address provides 87 the ability to replicate a packet from one router to other routers in 88 a different domain as well as routers in the same domain. This 89 document introduces the techniques for multicast deployment across 90 multiple domains using BIERv6, and demonstrates how BIERv6 is 91 beneficial for such deployment. 93 The word "domain" used in this document means a closely connected set 94 of nodes or simply "IGP domain" or "autonomous system (AS)". The 95 word "inter-domain" used in this document means interconnected IGP 96 domains or autonomous systems (ASes) belonging to a single "BIERv6 97 domain" as defined in [I-D.xie-bier-ipv6-encapsulation]. 99 There is no concept of MVPN segmentation [RFC6513] in this document. 100 Instead, It is a non-segmented MVPN or inter-domain stateless 101 multicast deployment in this document, and a single BIER Sub-domain 102 throughout the "inter-domain" scope of the BIERv6 domain is assumed. 104 2. Terminology 106 Readers of this document are assumed to be familiar with the 107 terminology and concepts of the documents listed as Normative 108 References. 110 3. Inter-domain Multicast Overview 112 It is common to deploy multicast services across multiple domains. 114 One typical scenario for this type of deployment is in a service- 115 provider network for MVPN service as described in 116 [I-D.ietf-bier-ipv6-requirements]. Service provider network tends to 117 be very heterogeneous with full-mesh backbone network, and metro 118 networks with fabric for dense area coverage or ring-shaped for 119 sparse area coverage. The backbone network and metro networks are 120 autonomous systems interconnected by border routers (BRs). 121 Multicast-based delivery of video need to be set up from a source 122 router on the backbone to each of the boundary routers of each metro 123 network. 125 This scenario may have some variant. For example, multicast source 126 router is a Top of Rack (TOR) switch in a service provider data 127 center(SPDC) connected to backbone with data center gateway(s) (DC- 128 GW), and multicast receiver is the home broadband subscribers 129 connected to boundary routers (e.g. BNG) of each metro network. 130 Operators may want to set up multicast-based delivery from TOR to 131 BNGs seamlessly without segmentation or stitching on DC-GW(s) or 132 BR(s). 134 It is described as hierachical multicast in this document. 136 Another typical scenario for inter-domain multicast deployment is in 137 peering network as described in [RFC8313] to set up multicast-based 138 delivery of content across inter-domain peering points. 140 This scenario may have some variant. For example, interconnected 141 content delivery networks (CDNs) (described in [RFC6770]) owned by 142 Network Service Providers (NSPs) or Enterprise Service Providers may 143 need to deliver multicast from one to others. 145 It is described as peering multicast in this document. 147 4. Inter-domain Multicast Deployment using BIERv6 149 4.1. Hierarchical Multicast 151 Following is an example of hierarchical deployment of multicast. 153 +---------------------+ 154 | Metro 2 (AS 65002) | 155 | +-----+ +------+ | 156 +-------| BR2 | | PE2x |---RCV 157 / | +-----+ +------+ | 158 / +---------------------+ 159 +---------------------+ / Bfr-id 1 to 256 160 | Backbone (AS 65001) | / 161 | +------+ +-----+ / 162 SRC---| PE1x | | BR1 | | 163 | +------+ +-----+ \ 164 +---------------------+ \ Bfr-id 257 to 512 165 | \ +---------------------+ 166 | \ | Metro 3 (AS 65003) | 167 | \ | +-----+ +------+ | 168 | +-------| BR3 | | PE3x |---RCV 169 | | +-----+ +------+ | 170 | +---------------------+ 171 | | 172 |<----------------- BIERv6 Domain --------------->| 174 BR = Border Router 175 SRC = Multicast Source 176 RCV = Multicast Receiver 178 Figure 1: Inter-Domain Hierarchical Multicast 180 Multicast source is connected to PE1x, and multicast receivers are 181 connected to PE2x and PE3x. 183 PE1x, PE2x, PE3x is located in Backbone (AS 65001), Metro 2 (AS 184 65002), and Metro 3 (AS 65003) respectively, and BR1, BR2, BR3 is 185 boarder of these three domains. They belong to a single 186 administrative domain. 188 IGP underlay for BIERv6 is deployed in Metro2, Metro3 respectively. 189 The bfr-ids in Metro2 and Metro 3 should be divided rationally. 191 PE1x, PE2x, PE3x uses 2001:DB8::E1, 2001:DB8::E2, 2001:DB8::E3 as 192 End.BIER IPv6 address respectively. 194 BR1, BR2, BR3 uses 2001:DB8::B1, 2001:DB8::B2, 2001:DB8::B3 as 195 End.BIER IPv6 address respectively. 197 All of them use the Non-MPLS static BSL-SD-SI BIFT encoding method 198 described in [I-D.ietf-bier-non-mpls-bift-encoding] as the auto- 199 generation method. 201 On BR1, static configuration can be used to construct inter-domain 202 BIERv6 forwarding table. 204 bier sub-domain 6 ipv6-underlay 205 bfr-prefix interface loopback0 206 end-bier 2001:DB8::B1 207 encapsulation ipv6 bsl 256 max-si 2 208 static-bift 209 nexthop end-bier 2001:DB8::B2 bfr-id 1 to 256 210 nexthop end-bier 2001:DB8::B3 bfr-id 257 to 512 212 Accordingly, the following BIFTs will be constructed: 214 BIFT correspond to SD<6>/BSL<256>/SI<0> 215 (neighbor = 2001:DB8::B2, F-BM = ffff....ffff) 216 BIFT correspond to SD<6>/BSL<256>/SI<1> 217 (neighbor = 2001:DB8::B3, F-BM = ffff....ffff) 219 On PE1x, static configuration can be used to construct inter-domain 220 BIERv6 forwarding table. Note that PE1x doesn't need to assign a 221 valid BFR-id uniquely among many. 223 bier sub-domain 6 ipv6-underlay 224 bfr-prefix interface loopback0 225 end-bier 2001:DB8::E1 226 encapsulation ipv6 bsl 256 max-si 2 227 static-bift 228 nexthop end-bier 2001:DB8::B1 bfr-id 1 to 512 230 Accordingly, the following BIFTs will be constructed: 232 BIFT correspond to SD<6>/BSL<256>/SI<0> 233 (neighbor = 2001:DB8::B1, F-BM = ffff....ffff) 234 BIFT correspond to SD<6>/BSL<256>/SI<1> 235 (neighbor = 2001:DB8::B1, F-BM = ffff....ffff) 237 Use of BGP as inter-domain underlay protocol to advertise the BIER 238 information from BR2 or BR2 to BR1, or from BR1 to PE1x is outside 239 the scope of this document. 241 On each domain, two redundant border routers may be deployed, and 242 anycase IPv6 address can be used on each pair of BRs as End.BIER IPv6 243 address. 245 Inter-Domain BIER will converge normally when unicast converge and 246 the BIFT will be reconstructed accordingly. 248 For multicast overlay layer, there are no extensions needed. MVPN is 249 deployed on PE1x, PE2x and PE3x using sub-domain 6 and bsl 256 250 without segmentation on border router(s). 252 Note: Use of the IPv6 address configured on PE1 to identify an MVPN 253 instance can eliminate the need for BFR-id configuration on PE1x, 254 which otherwise has to be configured from the space of a sub-domain. 256 4.2. Peering Multicast 258 Following is an example of peering deployment of multicast. 260 +---------------------+ 261 | AD-2 (AS 65002) | 262 +---+ | +-----+ +------+ | 263 / I \ | | BR2 | | PE2x |---RCV 264 (color 1) ( N ) | +-----+ +------+ | 265 Bfr-id 1 to 256 ( T ) +---------------------+ 266 +---------------------+ ( E ) Bfr-id 1 to 512 267 | AD-1 (AS 65001) | ( R ) (color 2) 268 | +------+ +-----+ | ( C ) 269 SRC---| PE1x | | BR1 | | ( O ) 270 | +------+ +-----+ | ( N ) 271 | +------+ | ( N ) 272 RCV---| PE1y | | ( E ) 273 | +------+ | ( C ) (color 3) 274 +---------------------+ ( T ) Bfr-id 1 to 256 275 ( I ) +---------------------+ 276 ( O ) | AD-3 (AS 65003) | 277 \ N / | +-----+ +------+ | 278 +---+ | | BR3 | | PE3x |---RCV 279 | +-----+ +------+ | 280 +---------------------+ 281 AD = Administrative Domain (independent autonomous system) 282 BR = Border Router 283 SRC = Multicast Source 284 RCV = Multicast Receiver 286 Figure 2: Inter-Domain Peering Multicast 288 Each Administrative Domain AD-1, AD-2 or AD-3 is configured a unique 289 color. Color 1, 2, 3 are used in this example. 291 For routing underlay layer, the ingress router uses IGP protocol (IS- 292 IS as example in this document) for the domain it belongs to, and 293 uses static configuration for the domain it doesn't belong to. 295 Below is an example of routing underlay configuration on PE1x. Note 296 that PE1x doesn't need to assign a valid BFR-id per color. 298 # PE1x routing underlay layer configuration 299 bier sub-domain 6 ipv6-underlay 300 bfr-prefix interface loopback0 301 end-bier 2001:DB8::E1 302 encapsulation ipv6 bsl 256 max-si 1 303 color 1 protocol isis 304 color 2 static-bift 305 nexthop end-bier 2001:DB8::B2 bfr-id 1 to 512 306 color 3 static-bift 307 nexthop end-bier 2001:DB8::B3 bfr-id 1 to 256 309 The following lists the BIFT that will be constructed on PE1x: 311 BIFT corresponding to SD<6>/BSL<256>/SI<0> for color 1 ;;Ref1 312 BIFT corresponding to SD<6>/BSL<256>/SI<0> for color 2 ;;Ref2 313 BIFT corresponding to SD<6>/BSL<256>/SI<1> for color 2 ;;Ref3 314 BIFT corresponding to SD<6>/BSL<256>/SI<0> for color 3 ;;Ref4 316 Ref1: BIFT constructed using IGP. 318 Ref2: BIFT constructed using static configuration, with BR2 a multi- 319 hop BFR neighbor of PE1x. 321 Ref3: BIFT constructed using static configuration, with BR2 a multi- 322 hop BFR neighbor of PE1x. 324 Ref3: BIFT constructed using static configuration, with BR3 a multi- 325 hop BFR neighbor of PE1x. 327 For multicast overlay layer, the color extended community defined in 328 [RFC5512] is carried in Leaf A-D route together with the PTA 329 attribute. 331 (1) PE in each domain gets the color it belongs to. This can be done 332 by configuration on each PE in each domain. 334 (2) PE carries a color attribute in BGP-MVPN Leaf A-D route when 335 advertising to Ingress PE as response to explicit-tracking initiated 336 by the Ingress PE. This can be done by configuration on MVPN 337 deployment. Refer to [I-D.xie-bier-ipv6-mvpn] for other attributes 338 needed to be used. 340 (3) The Ingress PE gets the Leaf A-D route, learns the BFERs of a 341 color (representing a domain) interested in a multicast flow, and 342 constructs the overlay forwarding table. Below is an example of the 343 overlay forwarding table on PE1x: 345 (VRF, S, G) 346 (Color<1>, SD<6>, BSL<256>, SI<0>, BitString<0001>) ;;Ref1 347 (Color<2>, SD<6>, BSL<256>, SI<0>, BitString<0001>) ;;Ref2 348 (Color<2>, SD<6>, BSL<256>, SI<1>, BitString<0001>) ;;Ref3 349 (Color<3>, SD<6>, BSL<256>, SI<0>, BitString<0001>) ;;Ref4 351 Ref1: packet will be replicated according to the BitString<0001> and 352 the BIFT constructed using the IGP for SD<6>/BSL<256>/SI<0> for color 353 1. 355 Ref2: packet will be replicated according to the BitString<0001> and 356 the BIFT constructed using the static-bift configuration for 357 SD<6>/BSL<256>/SI<0> for color 2. 359 Ref3: packet will be replicated according to the BitString<0001> and 360 the BIFT constructed using the static-bift configuration for 361 SD<6>/BSL<256>/SI<1> for color 2. 363 Ref3: packet will be replicated according to the BitString<0001> and 364 the BIFT constructed using the static-bift configuration for 365 SD<6>/BSL<256>/SI<1> for color 3. 367 Note: BFR-id configuration on PE1x is only necessary when PE1x will 368 act as BFER, for example, there is multicast packet from PE2x to 369 PE1x. The BFR-ids in color 1, 2, 3 is independent on each other. 371 5. Security Considerations 373 Section 5.1 of [I-D.xie-bier-ipv6-encapsulation] should be strictly 374 deployed as a basic security mechanism for BIERv6 deployment. 376 In case the inter-domain "domains" are connected directly, for 377 example, they may be connected to the same physical infrastructure 378 (e.g., a Service Provider's network), then the "edge node" and 379 "external interface of each edge node" are both clear. 381 In case the inter-domain "domains" are connected remotely by a secure 382 connection, for example, they may be connected by a kind of VPN 383 connection, then the "external interface of each edge node" excludes 384 the interface of the Customer Edge (CE) router connecting (through 385 VPN) to the Provider Edge(PE) router. 387 In case the inter-domain "domains" are connected remotely by an 388 insecure connection, for example, they may be connected by an 389 internet connection, then the "external interface of each edge node" 390 includes the interface of the Customer Edge (CE) router connecting 391 (through internet) to the Provider Edge(PE) router. 393 6. IANA Considerations 395 No IANA Allocation is required in this document. 397 7. Acknowledgements 399 TBD. 401 8. References 403 8.1. Normative References 405 [I-D.ietf-bier-ipv6-requirements] 406 McBride, M., Xie, J., Geng, X., Dhanaraj, S., Asati, R., 407 Zhu, Y., Mishra, G., and Z. Zhang, "BIER IPv6 408 Requirements", draft-ietf-bier-ipv6-requirements-09 (work 409 in progress), September 2020. 411 [I-D.ietf-bier-non-mpls-bift-encoding] 412 Wijnands, I., Xu, X., and H. Bidgoli, "An Optional 413 Encoding of the BIFT-id Field in the non-MPLS BIER 414 Encapsulation", draft-ietf-bier-non-mpls-bift-encoding-02 415 (work in progress), August 2019. 417 [I-D.xie-bier-ipv6-encapsulation] 418 Xie, J., Geng, L., McBride, M., Asati, R., Dhanaraj, S., 419 Zhu, Y., Qin, Z., Shin, M., Mishra, G., and X. Geng, 420 "Encapsulation for BIER in Non-MPLS IPv6 Networks", draft- 421 xie-bier-ipv6-encapsulation-08 (work in progress), July 422 2020. 424 [I-D.xie-bier-ipv6-mvpn] 425 Xie, J., McBride, M., Dhanaraj, S., Geng, L., and G. 426 Mishra, "Use of BIER IPv6 Encapsulation (BIERv6) for 427 Multicast VPN in IPv6 networks", draft-xie-bier- 428 ipv6-mvpn-03 (work in progress), October 2020. 430 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 431 Subsequent Address Family Identifier (SAFI) and the BGP 432 Tunnel Encapsulation Attribute", RFC 5512, 433 DOI 10.17487/RFC5512, April 2009, 434 . 436 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 437 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 438 2012, . 440 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 441 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 442 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 443 November 2012, . 445 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 446 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 447 Explicit Replication (BIER)", RFC 8279, 448 DOI 10.17487/RFC8279, November 2017, 449 . 451 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 452 Ed., and R. Krishnan, "Use of Multicast across Inter- 453 domain Peering Points", BCP 213, RFC 8313, 454 DOI 10.17487/RFC8313, January 2018, 455 . 457 8.2. Informative References 459 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 460 Requirement Levels", BCP 14, RFC 2119, 461 DOI 10.17487/RFC2119, March 1997, 462 . 464 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 465 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 466 May 2017, . 468 Authors' Addresses 470 Liang Geng 471 China Mobile 472 Beijing 10053 474 Email: gengliang@chinamobile.com 475 Jingrong Xie 476 Huawei Technologies 478 Email: xiejingrong@huawei.com 480 Mike McBride 481 Futurewei 483 Email: mmcbride7@gmail.com 485 Gang Yan 486 Huawei Technologies 488 Email: yangang@huawei.com 490 Xuesong Geng 491 Huawei Technologies 493 Email: gengxuesong@huawei.com