idnits 2.17.1 draft-geng-bier-sr-multicast-deployment-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 2, 2018) is 2124 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8200' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC8296' is defined on line 380, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-bier-use-cases-06 ** Downref: Normative reference to an Informational draft: draft-ietf-bier-use-cases (ref. 'I-D.ietf-bier-use-cases') == Outdated reference: A later version (-02) exists of draft-xie-bier-6man-encapsulation-00 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Geng 3 Internet-Draft L. Wang 4 Intended status: Standards Track China Mobile 5 Expires: January 3, 2019 J. Xie 6 M. McBride 7 G. Yan 8 Huawei Technologies 9 July 2, 2018 11 MVPN using Segment Routing and BIER for High Reachability Multicast 12 Deployment 13 draft-geng-bier-sr-multicast-deployment-00 15 Abstract 17 Bit Index Explicit Replication (BIER) introduces a stateless 18 multicast approach for a specific IGP area. Segment Routing 19 introduces an approach for end-to-end stateless deployment for both 20 inter-area and inter-as scenarios. This document proposes a MVPN 21 using Segment Routing and BIER for a high reachability multicast 22 deployment. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in [RFC2119]. 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 January 3, 2019. 47 Copyright Notice 49 Copyright (c) 2018 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Problem Statement and Considerations . . . . . . . . . . . . 3 67 3.1. Problem Statement and Considerations . . . . . . . . . . 3 68 4. MVPN Using SR-MPLS and BIER-MPLS Encapsulation . . . . . . . 4 69 4.1. Anchor information Advertisement and Usage . . . . . . . 4 70 4.2. MVPN Forwarding State and Forwarding Procedure . . . . . 6 71 5. MVPN Using SRv6 and BIER-IPv6 Encapsulation . . . . . . . . . 7 72 5.1. Anchor information Advertisement and Usage . . . . . . . 7 73 5.2. MVPN Forwarding State and Forwarding Procedure . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 9.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 Bit Index Explicit Replication (BIER) [RFC8279] introduces a 85 stateless multicast approach for a specific IGP area. Segment 86 Routing [I-D.ietf-spring-segment-routing] introduces an approach for 87 end-to-end stateless deployment for both inter-area and inter-as 88 scenario. An end-to-end VPN deployment may benefit from the 89 combination of this two technology in which the stateless nature can 90 be maintained. This document proposes an MVPN deployment with high 91 reachability in such scenario using both Segment Routing and BIER. 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. Problem Statement and Considerations 101 3.1. Problem Statement and Considerations 103 In a BIER deployment in multi-area or multi-AS network, a segmented 104 MVPN has to be used. As a result, multicast states are created at 105 the segment boundary. The per-flow multicast states are maintained 106 on the routers which are considered beyond of the "MVPN service" 107 sites. This significant disadvantage for multicast service 108 deployment is due to the poor reachability of BIER and is hard to 109 solve solely by BIER itself. 111 Segment Routing, however, has high reachability for both multi-area 112 and multi-as deployment. VPN services can use pre-defined Segments 113 (SIDs) on the area boundary routers (ABR) or AS boundary routers 114 (ASBR) for end-to-end deployment, without requiring such boundary 115 routers to include per-vpn or per-flow states, or per-vpn or per-flow 116 signaling to establish the end-to-end connection. 118 BIER and Segment Routing can be used for different partition of an 119 end-to-end MVPN service deployment. A packet with BIER encapsulation 120 is carried by Segment Routing to a boundary router. When reaching 121 the boundary router, it is replicated according to the BitString in 122 the BIER encapsulation to destination routers. Hence, the whole 123 multicast deployment can be stateless end-to-end. 125 A typical scenario for this type of deployment is in a service- 126 provider network for business L3VPN service with multicast as defined 127 in [I-D.ietf-bier-use-cases]. Service provider network tends to be 128 very heterogeneous with full-mesh backbone network, ring-shaped metro 129 networks for sparse area coverage, and sometime a fabric for dense 130 area coverage. A source router can send multicast packets to each of 131 the boundary routers of each metro network, with a loose path 132 selection in the full-mesh core network to avoid overloading by using 133 Segment Routing. The boundary router or boundary routers replicate 134 the packets to its own metro network according to the BIER 135 encapsulation. 137 To achieve the end-to-end statelessness, the boundary router will not 138 proxy any per-vpn or per-flow state. Instead, each of the edge 139 routers, in a specific metro network, directly tell the interest of 140 some multicast flow to the ingress edge router. This is the same as 141 the L3VPN deployed end-to-end on Option-C style or SR style. For 142 MVPN service, this can be done by the current BGP MVPN signaling. 143 While for MVPN using Segment Routing and BIER, it is required to 144 include the information of boundary router(s) of the area the egress 145 edge router belongs to. The boundary router(s) can be thought as 146 anchor(s) of the area for BIER replication. 148 Below is an example of end-to-end MVPN deployment on a simple network 149 containing one ABR in each of the edge network area. 151 +------+ +------+ +------+ +------+ 152 SRC---| PE11 | | ABR1 | | ABR2 | | PE21 |---RCV 153 +------+ +------+ +------+ +------+ 154 |<--- Area 1--->|<--- Area 0--->|<--- Area 2--->| 155 | | | | 156 |---------- BIER in SR -------->|----- BIER --->| 157 | | | 158 |<------------ MVPN E2E Deployment ------------>| 160 Figure 1: MVPN using BIER and SR for E2E deployment 162 A more realistic network may contain two ABRs in each metro network 163 area for realibility. 165 +------+ +------+ 166 | ABR1a| | ABR2a| 167 +------+ +------+ +------+ +------+ 168 SRC---| PE11 | | PE21 |---RCV 169 +------+ +------+ +------+ +------+ 170 | | ABR1b| | ABR2b| | 171 | +------+ +------+ | 172 | | | | 173 |<--- Area 1--->|<--- Area 0--->|<--- Area 2 --->| 174 | (Metro) | (CORE) | (Metro) | 175 | | | | 176 |---------- BIER in SR -------->|----- BIER ---->| 177 | | | 178 |<------------ MVPN E2E Deployment ------------->| 180 Figure 2: MVPN using BIER and SR for E2E deployment and protection 182 4. MVPN Using SR-MPLS and BIER-MPLS Encapsulation 184 4.1. Anchor information Advertisement and Usage 186 In an area of the receiver side, the anchor router or routers 187 advertise the BIER Label, the router IP, and the associated Sub- 188 domain, BSL and SI. The egress edge routers receive this information 189 accordingly. When an egress edge router advertiseing MVPN Leaf A-D 190 routes to the ingress edge router at the sender side, it includes the 191 anchor router IP, the anchor router BIER Label, together with the 192 egress edge router's Sub-domain, BFR-prefix and BFR-id, just as the 193 PTA defined in [I-D.ietf-bier-mvpn]. 195 For a deployment where more than one (typically two) anchor routers 196 exist in the area, it is expected to use only one BIER sub-domain for 197 the ease of configuration, while supporting the anchor routers with 198 different BIER labels or with same BIER label (anycast label). The 199 BIER label of an anchor is selected from SRGB and called a BIER SRGB- 200 label. Each of the routers in the area do not have to allocate a 201 local label (from SRLB) for a specific (Sub-domain, BSL, SI) tuple 202 when building the BIER forwarding table. Instead, it uses the BIER 203 SRGB-label for building the BIER forwarding table of the BIER label 204 itself. More than one BIER SRGB labels for the same (Sub-domain, 205 BSL, SI) tuple are allowed, each forming a forwarding table, and the 206 local-allocated (from SRLB) BIER label forwarding table of the same 207 (Sub-domain, BSL, SI) tuple can coexist as well. 209 Procedures of building the BIER SRGB label forwarding table are 210 outside the scope of this document. 212 For many areas, it is not required to have a universe-unique sub- 213 domain number or same sub-domain with universe-unique SI number from 214 0 to 255. For example, it is allowed for area 2 having a sub-domain 215 0 and SI from 0 to 10, while area 3 having a sub-domain 0 and SI from 216 0 to 10 too, only if their anchor routers are not the same. 218 The anchor information of Hybird SR and BIER MPLS is carried in a 219 specific PTA as below. 221 +------------------------------------+ 222 | Flags (1 octet) | 223 +------------------------------------+ 224 | Tunnel Type = TBD (1 octet) | 225 +------------------------------------+ 226 | MPLS Label (3 octets) | 227 +------------------------------------+ ------+ 228 | Sub-domain-id (1 octet) | | 229 +------------------------------------+ | 230 | BFR-id (2 octets) | | 231 +------------------------------------+ | 232 | BFR-prefix (4 or 16 octets) | Tunnel Identifier 233 +------------------------------------+ | 234 | Anchor BIER Label ( 3 octets) | | 235 +------------------------------------+ | 236 | Anchor Node IP ( 4 or 16 octets) | | 237 +------------------------------------+ ------+ 239 Figure 3: PTA for Hybird SR and BIER MPLS Tunnel 241 4.2. MVPN Forwarding State and Forwarding Procedure 243 Ingress edge router has a per-flow forwarding state, indicating 244 forwarding to every anchor router(s) of an egress area, and a 245 BitString representing the final egress edge routers. 247 o (VRF, S, G, Anchor Node SID, Anchor BIER Label of a , 248 SD, BSL, SI, BitString of a ). 250 Ingress edge router can have its own policy about how to reach some 251 anchor router. 253 Each of the anchor router(s) has a per-SRGB-label BIER forwarding 254 state, but don't have any per-VPN or per-flow state. When an anchor 255 router receives a BIER packet encapsulated in the Segment Routing 256 label, it pops the Segment Routing label, sees the BIER SRGB-label, 257 and performs hop-by-hop BIER replication with BIER SRGB-label MPLS 258 encapsulation. The hop-by-hop BIER forwarding can further change to 259 on-hop replications directly to the egress edge routers over Segment 260 Routing tunnels, by building BIER forwarding table over Segment 261 Routing on anchar router(s) and egress edge routers only. 263 Each egress edge router has a per-flow forwarding state, indicating 264 forwarding a packet to its interfaces connected to CE or receivers. 265 Egress edge router can use the upstream-assigned vpnlabel to 266 differentiate the local VRF. 268 5. MVPN Using SRv6 and BIER-IPv6 Encapsulation 270 MVPN service using SRv6 and BIER IPv6 Encapsulation is also possible 271 by using the [I-D.xie-bier-6man-encapsulation], which allows BIER 272 packets to run on a SRv6 tunnel. 274 Procedures of building the BIER IPv6 BIFT-ID forwarding table are 275 outside the scope of this document. 277 5.1. Anchor information Advertisement and Usage 279 The anchor information of Hybird SPv6 and BIER IPv6 is carried in a 280 specific PTA as below. 282 +------------------------------------+ 283 | Flags (1 octet) | 284 +------------------------------------+ 285 | Tunnel Type = TBD (1 octet) | 286 +------------------------------------+ 287 | MPLS Label (3 octets) | 288 +------------------------------------+ ------+ 289 | Sub-domain-id (1 octet) | | 290 +------------------------------------+ | 291 | BFR-id (2 octets) | | 292 +------------------------------------+ | 293 | BFR-prefix (16 octets) | Tunnel Identifier 294 +------------------------------------+ | 295 | Anchor BIER BIFT-ID ( 3 octets) | | 296 +------------------------------------+ | 297 | Anchor Node BIER SID ( 16 octets) | | 298 +------------------------------------+ ------+ 300 Figure 4: PTA for Hybird SRv6 and BIER IPv6 Tunnel 302 5.2. MVPN Forwarding State and Forwarding Procedure 304 Ingress edge router has a per-flow forwarding state, indicating 305 forwarding to every anchor router(s) of an egress area. 307 o (VRF, S, G, Anchor Node BIER SID, Anchor BIER BIFT-ID of a 308 , SD, BSL, SI, BitString of a ). 310 Ingress edge router can have its own policy about how to reach some 311 anchor router. 313 Each of the anchor router(s) has a per-BIFT-ID BIER forwarding state, 314 but doesn't have any per-VPN or per-flow state. When an anchor 315 router receives a BIER packet encapsulated in the SRv6 SRH header, it 316 first pops the SRH, and then sees the BIER specific Multicast 317 address, and then performs the hop-by-hop BIER replication by using 318 the BIFT-ID and other BIER header fields as described in [I-D.xie- 319 bier-6man-encapsulation]. 321 Egress edge router has a per-flow forwarding state, indicating 322 forwarding a packet to its interfaces connected to CE or receivers. 323 Egress edge router can use the upstream-assigned vpnlabel to 324 differentating the local VRF. 326 6. Security Considerations 328 The procedures of this document do not, in themselves, provide 329 privacy, integrity, or authentication for the control plane or the 330 data plane. 332 7. IANA Considerations 334 Allocation is expected from IANA for two new tunnel type codepoints 335 for "Hybird SR-MPLS and BIER MPLS Tunnel" and "Hybird SRv6 and BIER 336 IPv6 Tunnel" from the "P-Multicast Service Interface Tunnel (PMSI 337 Tunnel) Tunnel Types" registry. 339 8. Acknowledgements 341 TBD. 343 9. References 345 9.1. Normative References 347 [I-D.ietf-bier-mvpn] 348 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 349 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 350 mvpn-11 (work in progress), March 2018. 352 [I-D.ietf-bier-use-cases] 353 Kumar, N., Asati, R., Chen, M., Xu, X., Dolganow, A., 354 Przygienda, T., Gulko, A., Robinson, D., Arya, V., and C. 355 Bestler, "BIER Use Cases", draft-ietf-bier-use-cases-06 356 (work in progress), January 2018. 358 [I-D.ietf-spring-segment-routing] 359 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 360 Litkowski, S., and R. Shakir, "Segment Routing 361 Architecture", draft-ietf-spring-segment-routing-15 (work 362 in progress), January 2018. 364 [I-D.xie-bier-6man-encapsulation] 365 Xie, J., Yan, G., McBride, M., and Y. Xia, "Encapsulation 366 for BIER in Non-MPLS IPv6 Networks", draft-xie-bier-6man- 367 encapsulation-00 (work in progress), April 2018. 369 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 370 (IPv6) Specification", STD 86, RFC 8200, 371 DOI 10.17487/RFC8200, July 2017, 372 . 374 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 375 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 376 Explicit Replication (BIER)", RFC 8279, 377 DOI 10.17487/RFC8279, November 2017, 378 . 380 [RFC8296] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 381 Tantsura, J., Aldrin, S., and I. Meilik, "Encapsulation 382 for Bit Index Explicit Replication (BIER) in MPLS and Non- 383 MPLS Networks", RFC 8296, DOI 10.17487/RFC8296, January 384 2018, . 386 9.2. Informative References 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, 390 DOI 10.17487/RFC2119, March 1997, 391 . 393 Authors' Addresses 395 Liang Geng 396 China Mobile 397 Beijing 10053 399 Email: gengliang@chinamobile.com 401 Lei Wang 402 China Mobile 403 Beijing 10053 405 Email: wangleiyjy@chinamobile.com 406 Jingrong Xie 407 Huawei Technologies 409 Email: xiejingrong@huawei.com 411 Mike McBride 412 Huawei Technologies 414 Email: mmcbride7@gmail.com 416 Gang Yan 417 Huawei Technologies 419 Email: yangang@huawei.com