idnits 2.17.1 draft-geng-bier-ipv6-inter-domain-01.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 300 has weird spacing: '...ponding to SD...' == Line 301 has weird spacing: '...ponding to SD...' == Line 302 has weird spacing: '...ponding to SD...' == Line 303 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 (January 14, 2020) is 1565 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 411, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-bier-ipv6-requirements-03 ** 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-04 == Outdated reference: A later version (-03) exists of draft-xie-bier-ipv6-mvpn-01 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Downref: Normative reference to an Informational RFC: RFC 6770 Summary: 4 errors (**), 0 flaws (~~), 12 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: July 17, 2020 Huawei Technologies 6 M. McBride 7 Futurewei 8 G. Yan 9 Huawei Technologies 10 January 14, 2020 12 Inter-Domain Multicast Deployment using BIERv6 13 draft-geng-bier-ipv6-inter-domain-01 15 Abstract 17 Bit Index Explicit Replication IPv6 encapsulation (BIERv6) introduces 18 an approach to use IPv6 extension header to carry BIER header with 19 IPv6 unicast address as destination address. It provides the ability 20 to replicate a packet from one router to another router in a 21 different domain as well as in the same domain. This document 22 introduces the techniques for multicast deployment across multiple 23 domains using BIERv6, and demonstrate how BIERv6 is beneficial for 24 such deployment. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in [RFC2119] and 31 [RFC8174]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 17, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 69 3. Inter-domain Multicast Overview . . . . . . . . . . . . . . . 3 70 4. Inter-domain Multicast Deployment using BIERv6 . . . . . . . 3 71 4.1. Hierarchical Multicast . . . . . . . . . . . . . . . . . 3 72 4.2. Peering Multicast . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 another router 88 in a different domain as well as in the same domain. This document 89 introduces the techniques for multicast deployment across multiple 90 domains using BIERv6, and demonstrates how BIERv6 is beneficial for 91 such deployment. 93 2. Terminology 95 Readers of this document are assumed to be familiar with the 96 terminology and concepts of the documents listed as Normative 97 References. 99 3. Inter-domain Multicast Overview 101 It is common to deploy multicast services across multiple domains. 103 One typical scenario for this type of deployment is in a service- 104 provider network for MVPN service as described in 105 [I-D.ietf-bier-ipv6-requirements]. Service provider network tends to 106 be very heterogeneous with full-mesh backbone network, and metro 107 networks with fabric for dense area coverage or ring-shaped for 108 sparse area coverage. The backbone network and metro networks are 109 autonomous systems interconnected by border routers (BRs). 110 Multicast-based delivery of video need to be set up from a source 111 router on the backbone to each of the boundary routers of each metro 112 network. 114 This scenario may have some variant. For example, multicast source 115 router is a Top of Rack (TOR) switch in a service provider data 116 center(SPDC) connected to backbone with data center gateway(s) (DC- 117 GW), and multicast receiver is the home broadband subscribers 118 connected to boundary routers (e.g. BNG) of each metro network. 119 Operators may want to set up multicast-based delivery from TOR to 120 BNGs seamlessly without segmentation or stitching on DC-GW(s) or 121 BR(s). 123 It is described as hierachical multicast in this document. 125 Another typical scenario for inter-domain multicast deployment is in 126 peering network as described in [RFC8313] to set up multicast-based 127 delivery of content across inter-domain peering points. 129 This scenario may have some variant. For example, interconnected 130 content delivery networks (CDNs) (described in [RFC6770]) owned by 131 Network Service Providers (NSPs) or Enterprise Service Providers may 132 need to deliver multicast from one to others. 134 It is described as peering multicast in this document. 136 4. Inter-domain Multicast Deployment using BIERv6 138 4.1. Hierarchical Multicast 140 Following is an example of hierarchical deployment of multicast. 142 +---------------------+ 143 | Metro 2 (AS 65002) | 144 | +-----+ +------+ | 145 +-------| BR2 | | PE2x |---RCV 146 / | +-----+ +------+ | 147 / +---------------------+ 148 +---------------------+ / Bfr-id 1 to 256 149 | Backbone (AS 65001) | / 150 | +------+ +-----+ / 151 SRC---| PE1x | | BR1 | | 152 | +------+ +-----+ \ 153 +---------------------+ \ Bfr-id 257 to 512 154 | \ +---------------------+ 155 | \ | Metro 3 (AS 65003) | 156 | \ | +-----+ +------+ | 157 | +-------| BR3 | | PE3x |---RCV 158 | | +-----+ +------+ | 159 | +---------------------+ 160 | | 161 |<----------------- BIERv6 Domain --------------->| 163 BR = Border Router 164 SRC = Multicast Source 165 RCV = Multicast Receiver 167 Figure 1: Inter-Domain Hierarchical Multicast 169 Multicast source is connected to PE1x, and multicast receivers are 170 connected to PE2x and PE3x. 172 PE1x, PE2x, PE3x is located in Backbone (AS 65001), Metro 2 (AS 173 65002), and Metro 3 (AS 65003) respectively, and BR1, BR2, BR3 is 174 boarder of these three domains. They belong to a single 175 administrative domain. 177 IGP underlay for BIERv6 is deployed in Metro2, Metro3 respectively. 178 The bfr-ids in Metro2 and Metro 3 should be divided rationally. 180 PE1x, PE2x, PE3x uses 2001:DB8::E1, 2001:DB8::E2, 2001:DB8::E3 as 181 End.BIER IPv6 address respectively. 183 BR1, BR2, BR3 uses 2001:DB8::B1, 2001:DB8::B2, 2001:DB8::B3 as 184 End.BIER IPv6 address respectively. 186 All of them use the Non-MPLS static BSL-SD-SI BIFT encoding method 187 described in [I-D.ietf-bier-non-mpls-bift-encoding] as the auto- 188 generation method. 190 On BR1, static configuration can be used to construct inter-domain 191 BIERv6 forwarding table. 193 bier sub-domain 6 ipv6-underlay 194 bfr-prefix interface loopback0 195 end-bier 2001:DB8::B1 196 encapsulation ipv6 bsl 256 max-si 2 197 static-bift 198 nexthop end-bier 2001:DB8::B2 bfr-id 1 to 256 199 nexthop end-bier 2001:DB8::B3 bfr-id 257 to 512 201 Accordingly, the following BIFTs will be constructed: 203 BIFT correspond to SD<6>/BSL<256>/SI<0> 204 (neighbor = 2001:DB8::B2, F-BM = ffff....ffff) 205 BIFT correspond to SD<6>/BSL<256>/SI<1> 206 (neighbor = 2001:DB8::B3, F-BM = ffff....ffff) 208 On PE1x, static configuration can be used to construct inter-domain 209 BIERv6 forwarding table. Note that PE1x doesn't need to assign a 210 valid BFR-id uniquely among many. 212 bier sub-domain 6 ipv6-underlay 213 bfr-prefix interface loopback0 214 end-bier 2001:DB8::E1 215 encapsulation ipv6 bsl 256 max-si 2 216 static-bift 217 nexthop end-bier 2001:DB8::B1 bfr-id 1 to 512 219 Accordingly, the following BIFTs will be constructed: 221 BIFT correspond to SD<6>/BSL<256>/SI<0> 222 (neighbor = 2001:DB8::B1, F-BM = ffff....ffff) 223 BIFT correspond to SD<6>/BSL<256>/SI<1> 224 (neighbor = 2001:DB8::B1, F-BM = ffff....ffff) 226 Use of BGP as inter-domain underlay protocol to advertise the BIER 227 information from BR2 or BR2 to BR1, or from BR1 to PE1x is outside 228 the scope of this document. 230 On each domain, two redundant border routers may be deployed, and 231 anycase IPv6 address can be used on each pair of BRs as End.BIER IPv6 232 address. 234 Inter-Domain BIER will converge normally when unicast converge and 235 the BIFT will be reconstructed accordingly. 237 For multicast overlay layer, there are no extensions needed. MVPN is 238 deployed on PE1x, PE2x and PE3x using sub-domain 6 and bsl 256 239 without segmentation on border router(s). 241 Note: Use of the IPv6 address configured on PE1 to identify an MVPN 242 instance can eliminate the need for BFR-id configuration on PE1x, 243 which otherwise has to be configured from the space of a sub-domain. 245 4.2. Peering Multicast 247 Following is an example of peering deployment of multicast. 249 +---------------------+ 250 | AD-2 (AS 65002) | 251 +---+ | +-----+ +------+ | 252 / I \ | | BR2 | | PE2x |---RCV 253 (color 1) ( N ) | +-----+ +------+ | 254 Bfr-id 1 to 256 ( T ) +---------------------+ 255 +---------------------+ ( E ) Bfr-id 1 to 512 256 | AD-1 (AS 65001) | ( R ) (color 2) 257 | +------+ +-----+ | ( C ) 258 SRC---| PE1x | | BR1 | | ( O ) 259 | +------+ +-----+ | ( N ) 260 | +------+ | ( N ) 261 RCV---| PE1y | | ( E ) 262 | +------+ | ( C ) (color 3) 263 +---------------------+ ( T ) Bfr-id 1 to 256 264 ( I ) +---------------------+ 265 ( O ) | AD-3 (AS 65003) | 266 \ N / | +-----+ +------+ | 267 +---+ | | BR3 | | PE3x |---RCV 268 | +-----+ +------+ | 269 +---------------------+ 270 AD = Administrative Domain (independent autonomous system) 271 BR = Border Router 272 SRC = Multicast Source 273 RCV = Multicast Receiver 275 Figure 2: Inter-Domain Peering Multicast 277 Each Administrative Domain AD-1, AD-2 or AD-3 is configured a unique 278 color. Color 1, 2, 3 are used in this example. 280 For routing underlay layer, the ingress router uses IGP protocol (IS- 281 IS as example in this document) for the domain it belongs to, and 282 uses static configuration for the domain it doesn't belong to. 284 Below is an example of routing underlay configuration on PE1x. Note 285 that PE1x doesn't need to assign a valid BFR-id per color. 287 # PE1x routing underlay layer configuration 288 bier sub-domain 6 ipv6-underlay 289 bfr-prefix interface loopback0 290 end-bier 2001:DB8::E1 291 encapsulation ipv6 bsl 256 max-si 1 292 color 1 protocol isis 293 color 2 static-bift 294 nexthop end-bier 2001:DB8::B2 bfr-id 1 to 512 295 color 3 static-bift 296 nexthop end-bier 2001:DB8::B3 bfr-id 1 to 256 298 The following lists the BIFT that will be constructed on PE1x: 300 BIFT corresponding to SD<6>/BSL<256>/SI<0> for color 1 ;;Ref1 301 BIFT corresponding to SD<6>/BSL<256>/SI<0> for color 2 ;;Ref2 302 BIFT corresponding to SD<6>/BSL<256>/SI<1> for color 2 ;;Ref3 303 BIFT corresponding to SD<6>/BSL<256>/SI<0> for color 3 ;;Ref4 305 Ref1: BIFT constructed using IGP. 307 Ref2: BIFT constructed using static configuration, with BR2 a multi- 308 hop BFR neighbor of PE1x. 310 Ref3: BIFT constructed using static configuration, with BR2 a multi- 311 hop BFR neighbor of PE1x. 313 Ref3: BIFT constructed using static configuration, with BR3 a multi- 314 hop BFR neighbor of PE1x. 316 For multicast overlay layer, the color extended community defined in 317 [RFC5512] is carried in Leaf A-D route together with the PTA 318 attribute. 320 (1) PE in each domain gets the color it belongs to. This can be done 321 by configuration on each PE in each domain. 323 (2) PE carries a color attribute in BGP-MVPN Leaf A-D route when 324 advertising to Ingress PE as response to explicit-tracking initiated 325 by the Ingress PE. This can be done by configuration on MVPN 326 deployment. Refer to [I-D.xie-bier-ipv6-mvpn] for other attributes 327 needed to be used. 329 (3) The Ingress PE gets the Leaf A-D route, learns the BFERs of a 330 color (representing a domain) interested in a multicast flow, and 331 constructs the overlay forwarding table. Below is an example of the 332 overlay forwarding table on PE1x: 334 (VRF, S, G) 335 (Color<1>, SD<6>, BSL<256>, SI<0>, BitString<0001>) ;;Ref1 336 (Color<2>, SD<6>, BSL<256>, SI<0>, BitString<0001>) ;;Ref2 337 (Color<2>, SD<6>, BSL<256>, SI<1>, BitString<0001>) ;;Ref3 338 (Color<3>, SD<6>, BSL<256>, SI<0>, BitString<0001>) ;;Ref4 340 Ref1: packet will be replicated according to the BitString<0001> and 341 the BIFT constructed using the IGP for SD<6>/BSL<256>/SI<0> for color 342 1. 344 Ref2: packet will be replicated according to the BitString<0001> and 345 the BIFT constructed using the static-bift configuration for 346 SD<6>/BSL<256>/SI<0> for color 2. 348 Ref3: packet will be replicated according to the BitString<0001> and 349 the BIFT constructed using the static-bift configuration for 350 SD<6>/BSL<256>/SI<1> for color 2. 352 Ref3: packet will be replicated according to the BitString<0001> and 353 the BIFT constructed using the static-bift configuration for 354 SD<6>/BSL<256>/SI<1> for color 3. 356 Note: BFR-id configuration on PE1x is only necessary when PE1x will 357 act as BFER, for example, there is multicast packet from PE2x to 358 PE1x. The BFR-ids in color 1, 2, 3 is independent on each other. 360 5. Security Considerations 362 The procedures of this document do not, in themselves, provide 363 privacy, integrity, or authentication for the control plane or the 364 data plane. 366 6. IANA Considerations 368 No IANA Allocation is required in this document. 370 7. Acknowledgements 372 TBD. 374 8. References 375 8.1. Normative References 377 [I-D.ietf-bier-ipv6-requirements] 378 McBride, M., Xie, J., Dhanaraj, S., and R. Asati, "BIER 379 IPv6 Requirements", draft-ietf-bier-ipv6-requirements-03 380 (work in progress), November 2019. 382 [I-D.ietf-bier-non-mpls-bift-encoding] 383 Wijnands, I., Xu, X., and H. Bidgoli, "An Optional 384 Encoding of the BIFT-id Field in the non-MPLS BIER 385 Encapsulation", draft-ietf-bier-non-mpls-bift-encoding-02 386 (work in progress), August 2019. 388 [I-D.xie-bier-ipv6-encapsulation] 389 Xie, J., Geng, L., McBride, M., Asati, R., and S. 390 Dhanaraj, "Encapsulation for BIER in Non-MPLS IPv6 391 Networks", draft-xie-bier-ipv6-encapsulation-04 (work in 392 progress), December 2019. 394 [I-D.xie-bier-ipv6-mvpn] 395 Xie, J., McBride, M., Dhanaraj, S., and L. Geng, "Use of 396 BIER IPv6 Encapsulation (BIERv6) for Multicast VPN in IPv6 397 networks", draft-xie-bier-ipv6-mvpn-01 (work in progress), 398 July 2019. 400 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 401 Subsequent Address Family Identifier (SAFI) and the BGP 402 Tunnel Encapsulation Attribute", RFC 5512, 403 DOI 10.17487/RFC5512, April 2009, 404 . 406 [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, 407 P., Ma, K., and G. Watson, "Use Cases for Content Delivery 408 Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, 409 November 2012, . 411 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 412 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 413 Explicit Replication (BIER)", RFC 8279, 414 DOI 10.17487/RFC8279, November 2017, 415 . 417 [RFC8313] Tarapore, P., Ed., Sayko, R., Shepherd, G., Eckert, T., 418 Ed., and R. Krishnan, "Use of Multicast across Inter- 419 domain Peering Points", BCP 213, RFC 8313, 420 DOI 10.17487/RFC8313, January 2018, 421 . 423 8.2. Informative References 425 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 426 Requirement Levels", BCP 14, RFC 2119, 427 DOI 10.17487/RFC2119, March 1997, 428 . 430 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 431 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 432 May 2017, . 434 Authors' Addresses 436 Liang Geng 437 China Mobile 438 Beijing 10053 440 Email: gengliang@chinamobile.com 442 Jingrong Xie 443 Huawei Technologies 445 Email: xiejingrong@huawei.com 447 Mike McBride 448 Futurewei 450 Email: mmcbride7@gmail.com 452 Gang Yan 453 Huawei Technologies 455 Email: yangang@huawei.com