idnits 2.17.1 draft-xie-bier-mvpn-segmented-06.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 : ---------------------------------------------------------------------------- ** There are 17 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-bier-mvpn]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (October 22, 2018) is 2010 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) == Missing Reference: 'I-D.bess-mvpn-expl-track' is mentioned on line 283, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-bess-mvpn-expl-track-12 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track L. Geng 5 Expires: April 25, 2019 L. Wang 6 China Mobile 7 M. McBride 8 G. Yan 9 Huawei 10 October 22, 2018 12 Segmented MVPN Using IP Lookup for BIER 13 draft-xie-bier-mvpn-segmented-06 15 Abstract 17 This document specifies an alternative of the control plane and data 18 plane procedures that allow segmented MVPN using the more efficient 19 LIR-pF explicit-tracking when BIER is used as the upstream or 20 downstream or both segments. It requires a segmentation point BFR 21 doing an IP header lookup, which is common for the forwarding 22 procedure on BFER, or the forwarding procedure on ABR with local VPN 23 CEs connected. This document updates [I-D.ietf-bier-mvpn]. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 25, 2019. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Problem Statement and Considerations . . . . . . . . . . . . 4 68 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 4. Upstream BIER and Downstream BIER (BIER-BIER) . . . . . . . . 6 71 4.1. Explicit Tracking using LIR-pF . . . . . . . . . . . . . 6 72 4.2. Forwarding using IP lookup on Segmentation Point . . . . 8 73 5. Upstream P2MP and Downstream BIER (P2MP-BIER) . . . . . . . . 9 74 5.1. Explicit Tracking using LIR-pF . . . . . . . . . . . . . 9 75 5.2. Forwarding using IP lookup on Segmentation Point . . . . 10 76 6. Upstream BIER and Downstream P2MP (BIER-P2MP) . . . . . . . . 10 77 6.1. Explicit Tracking using LIR-pF . . . . . . . . . . . . . 10 78 6.2. Forwarding on Segmentation Point . . . . . . . . . . . . 11 79 7. Summary and Recommendations . . . . . . . . . . . . . . . . . 12 80 8. Appendix A - Comparison of Solutions . . . . . . . . . . . . 13 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 82 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 83 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 12.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 When using BIER to transport an MVPN data packet through a BIER 92 domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR 93 must determine the set of BFERs to which the packet needs to be 94 delivered. This can be done through an explicit-tracking function 95 using a LIR and/or LIR-pF flag in BGP MVPN routes, per the 97 [RFC6513],[RFC6514],[RFC6625],[I-D.ietf-bess-mvpn-expl-track], and 98 [I-D.ietf-bier-mvpn]. 100 Using a LIR-pF Flag will bring some extra benefits, as [I-D.ietf- 101 bier-mvpn] and [I-D.ietf-bess-mvpn-expl-track] have stated. But 102 unfortunately, the LIR-pF explicit tracking for a segmented MVPN 103 deployment is not allowed in the current draft [I-D.ietf-bier-mvpn], 104 because the draft requires a per-flow upstream-assigned label to do 105 the data-plane per-flow lookup on the segmentation point BFR. 107 This document specifies an alternative of the control plane and data 108 plane procedures that allow segmented MVPN using the more efficient 109 LIR-pF explicit-tracking when BIER is used as the upstream or 110 downstream or both segments. It requires a segmentation point BFR 111 doing an IP header lookup, which is common for the forwarding 112 procedure on BFER, or the forwarding procedure on ABR with local VPN 113 CEs connected. This will bring some significant benefits to the 114 segmented MVPN deployment, including: 116 o Getting a much better multicast join latency by eliminating the 117 round trip interaction of S-PMSI AD routes and Leaf AD routes. 118 Especially, the S-PMSI A-D routes may need a data-driven procedure 119 to trigger, and make the multicast join latency even worse. 121 o Greatly reducing the number of S-PMSI A-D routes that BFIR and 122 BFERs need to save. 124 o Consolidated forwarding procedure of IP lookup for every BIER 125 Overlay functioning routers, such as BFIR, BFER, segmentation 126 point BFR, and segmentation point BFR with BFER function. 128 2. Terminology 130 Readers of this document are assumed to be familiar with the 131 terminology and concepts of the documents listed as Normative 132 References. 134 P2MP: This document uses the term "P2MP" for "mLDP P2MP, RSVP-TE 135 P2MP, or IR P2MP". 137 BIER tunnel: An unidirectional tunnel indicated by an upstream- 138 assigned VpnLabel and the according context such as the RootIP where 139 the VpnLabel is generated. In control plane the BIER tunnel is the 140 PTA of type including the MPLS Label of the PTA. One BIER 141 tunnel is bound to an BGP-MVPN SPMSI route. There are no two BGP- 142 MVPN SPMSI routes of different VPN binding the same BIER tunnel, but 143 there are possibly two BGP-MVPN SPMSI routes of the same VPN binding 144 the same BIER tunnel. 146 P2MP tunnel: An unidirectional tunnel indicated by an downstream 147 label. In control plane the P2MP tunnel is the PTA of type or 148 type or type . The MPLS Label of the PTA is zero in 149 real implementation. One P2MP tunnel is bound to an BGP-MVPN SPMSI 150 route. There are no two BGP-MVPN SPMSI routes in different VPNs 151 binding the same BIER tunnel, but there are possibly two BGP-MVPN 152 SPMSI routes in the same VPN binding the same P2MP tunnel. 154 BGP-MVPN FEC: Either a (OrigIP, RD) tuple indicating by an 155 SPMS(OrigIP, RD, *, *), or a (OrigIP, RD, S, G) tuple indicating by 156 an SPMSI(OrigIP, RD, S, G). The BGP-MVPN FEC is used for control 157 plane to build some form of forwarding state on an segment point ABR 158 node. One example of such forwarding state is to use the upstream 159 P2MP tunnel bound to an SPMSI route, and the downstream P2MP 160 tunnel(s) bound to an SPMSI route, with the same BGP-MVPN FEC. 161 Another example of such forwarding state is to use the upstream BIER 162 tunnel bound to an SPMSI route, and the downstream P2MP tunnel(s) 163 and/or BIER tunnel(s). 165 VRF: Virtual Routing Forwarding. It is usually a number to indicate 166 a VPN/MVPN instance locally when L3VPN is configured. It is also 167 called local VRF. 169 Pseudo VRF: a Pseudo VRF indicates a VPN/MVPN instance locally on the 170 segment point ABR when downstream BIER forwarding using IP lookup is 171 required. The segment point ABR can be a PE of a VPN/MVPN instance 172 at the same time, and then there would have VRF and Pseudo VRF(s) 173 simultaneously. Note that the Pseudo VRF(s) is per the tunnel (BIER 174 tunnel or P2MP tunnel). Numbers of RootIP per a VPN/MVPN, and 175 numbers of tunnels per a VPN/MVPN and a RootIP, in the BGP-MVPN 176 FEC(s), will cause numbers of the Pseudo VRF allocated. 178 Local VpnLabel: a Local VpnLabel indicates a upstream-assigned MPLS 179 Label locally on the segment point ABR when downstream BIER 180 forwarding using IP lookup is required. Local VpnLabel is 1:1 to 181 Pseudo VRF, and it is assumed that a Pseudo VRF always indicates a 182 Local VpnLabel within it. 184 3. Problem Statement and Considerations 186 3.1. Problem Statement 188 BIER is a stateless multicast forwarding by introducing a multicast- 189 specific BIER header in the data plane. The maximal number of BFERs 190 a packet can reach is limited by the bit string length of a BIER 191 header. For a network with many routers in multiple IGP areas 192 (typically an Inter-Area network), it may be expected to use a 193 segmented MVPN when deploying BIER because operators don't want to 194 replicate packets to many BIER Sets. It is also possible for an 195 incremental deployment of BIER on one area (e.g. one Metro network 196 area) while keeping the P2MP in other areas (e.g. the Core network 197 area, and the other Metro network areas). 199 However, it is not allowed in the [I-D.ietf-bier-mvpn] to use a LIR- 200 pF explicit-tracking when deploying a segmented MVPN. This will lead 201 to a low efficiency of explicit-tracking, and cause a worse multicast 202 join latency. Here we first take a scenario of inter-area segmented 203 MVPN with both segments using BIER in section 4 for a generic 204 description. The second scenario is inter-area segmented MVPN with 205 upstream segment using P2MP and downstream segment using BIER in 206 section 5. The third scenario is inter-area segmented MVPN with 207 upstream segment using BIER and downstream segment using P2MP in 208 section 6. 210 3.2. Considerations 212 A BFIR always need to know the BFERs interested in a specific flow. 213 This is a function of a BIER overlay defined in [RFC8279]. A 214 segmentation point BFR in a segmented MVPN deployment, saying ABR, 215 will play similar roles of both BFIR and BFER. It needs to do a 216 disposition of a BIER Header, and then do an imposition of a new BIER 217 Header. It requires the ABR router to maintain per-flow states, and 218 especially, such per-flow states always include a set of BFERs who 219 are intrested in a specific flow by using an explicit-tracking 220 procedure. 222 This behavior is completely different from a traditional segmented 223 MVPN deployment, e.g, with both of the two segments using P2MP label 224 switch. In a traditional segmented MVPN with both segments using 225 P2MP label switch, it is expected to receive a MPLS packet and 226 replicate to downstream routers after swap the MPLS Label. A lookup 227 of IP packet is not expected. Also, in a traditional segmented MVPN 228 deployment, an MPLS label represents a P-tunnel, which may carry one, 229 many or even all multicast flow(s) of a VPN, so it is not always a 230 per-flow state on the segmentation point router. 232 In conclusion, the pattern of forwarding packets on segmentation 233 points only by lookup of MPLS label mapped from multicast flow(s) is 234 significantly unnecessary when BIER is introduced. Instead, doing a 235 per-flow lookup of IP header on segmentation points is more efficient 236 and consolidated. 238 4. Upstream BIER and Downstream BIER (BIER-BIER) 240 4.1. Explicit Tracking using LIR-pF 242 In a scenario of Inter-area Segmented MVPN with both segments using 243 BIER, the determination of the set of BFERs that need to receive a 244 specific multicast flow of (C-S1,C-G1) in each segment, can be 245 obtained by using a LIR-pF flag. 247 Suppose a topology of this: 249 (Ingress PE)PE1-------P1-------ABR-------P2------PE2(Egress PE) 250 | | | 251 | Ingress Area | Egress Area | 252 | ( BIER SD ) | ( BIER SD ) | 254 Figure 1: Example topology 256 PE1 is Ingress PE, and the area of { PE1 -- P1 -- ABR } is called an 257 Ingress Area. 259 PE2 is Egress PE, and the area of { ABR -- P2 -- PE2 } is called an 260 Egress Area. 262 The Ingress PE is configured to use a BIER tunnel type for an MVPN 263 instance for the Ingress Area, and the ABR is configured to use a 264 BIER tunnel type for the MVPN instance for the Egress Area. 266 The Ingress PE originates a wildcard S-PMSI A-D route (C-*,C-*) and 267 the PTA of that route has the following settings: 269 o The LIR-pF and LIR flags be set. 271 o The tunnel type be set to "BIER". 273 o A non-zero MPLS label be specified. 275 ABR receives the S-PMSI A-D route from the Ingress PE, and re- 276 advertises the route to the Egress PE, with a PTA type "BIER", and 277 PTA flags of LIR and LIR-pF, and a new non-zero upstream-assigned 278 MPLS label allocated by ABR per-VPN. 280 Egress PE receives the S-PMSI A-D route from the ABR, and checks if 281 it need to response with a Leaf A-D route to this S-PMSI A-D route 282 using the process of the "match for reception" and "match for 283 tracking" as defined in [I-D.bess-mvpn-expl-track]. In this example, 284 for a C-flow of (C-S1, C-G1), the checking result of "matched for 285 tracking" is the S-PMSI(C-*, C-*), and the checking result of 286 "matched for reception" is also the S-PMSI(C-*, C-*). Egress PE will 287 then send a Leaf A-D route (RD, C-S1, C-G1, Root=PE1, Leaf=PE2) to 288 the ABR with a PTA flag LIR-pF, and a Leaf A-D route (RD, C-*, C-*, 289 Root=PE1, Leaf=PE2) without a PTA flag LIR-pF. 291 ABR then has an explicit-tracking result of a new per-flow 292 information of (RD, C-S1, C-G1, Root=PE1) with Egress PE as its leaf 293 or BFER. ABR's "matched for tracking" result to this flow(RD, C-S1, 294 C-G1, PE1) will then be updated with a new record, and ABR then sends 295 a Leaf A-D route (RD, C-S1, C-G1, Root=PE1, Leaf=ABR) to Ingress PE. 297 Ingress PE then has an explicit-tracking result of a new per-flow 298 information of (RD, C-S1, C-G1, Root=PE1) with ABR as its leaf or 299 BFER. 301 From this procedure description one can see that: 303 1. The S-PMSI A-D(C-*, C-*) route is functioning as a per-VPN anchor 304 of the upstream and the downstream(s), which can be called an 305 BGP-MVPN FEC in this document, saying BGP-MVPN FEC(OrigIP, RD). 307 2. The Leaf A-D(S,G) routes are functioning as a per-flow anchor of 308 the downstream(s) and the upstream, which are also BGP-MVPN FECs 309 accordingly, saying BGP-MVPN FEC(OrigIP, RD, S,G). 311 3. The Tuple of (Root=PE1, RD) in S-PMSI (C-*, C-*) or Leaf AD(C-*, 312 C-*) or Leaf AD(C-S, C-G) represents an VRF on the ABR 313 implicitly. 315 ABR knows the per-vpn infmation of a (Root=PE1, RD) tuple when 316 receiving and re-advertising the S-PMSI A-D(*,*) route bound with a 317 PTA, where: 319 o Inbound SD (InSD): in PTA of the received S-PMSI(*,*) route. 321 o Inbound VpnLabel (InVpnLabel): in PTA of the received S-PMSI(*,*) 322 route. 324 o Inbound BfirId (InBfirId): in PTA of the received S-PMSI(*,*) 325 route. 327 o Outbound SD(OutSD): in PTA of the re-advertised S-PMSI(*,*) route. 329 o Outbound VpnLabel (OutVpnLabel): in PTA of the re-advertised 330 S-PMSI(*,*) route. 332 o Outbound BfirId (OutBfirId): in PTA of the re-advertised 333 S-PMSI(*,*) route. 335 ABR establishs a per-flow control-plane state accordingly like this: 337 o Per-flow upstream state, according to the Leaf A-D (C-S, C-G) 338 route send to the Ingress PE: (PE1, RD, C-S1, C-G1, InSD, 339 InBfirId, InVpnLabel). 341 o Per-flow downstream state(s), according to the Leaf A-D(C-S, C-G) 342 route(s) received by the ABR from Egress PE(s): (PE1, RD, C-S1, 343 C-G1, Leaf, OutSD, OutBfirId, OutVpnLabel). 345 ABR knows the BIER Label(s) it allocated for InSD and OutSD, saying 346 InBierLabel for InSD and OutBierLabel for OutSD, and thus it 347 can establish the per-flow forwarding state: 349 o Per-flow upstream forwarding state: (InBierLabel, InBfirId, 350 InVpnLabel, C-S1, C-G1). 352 o Per-flow downstream(s) forwarding state: (InBierLabel, InBfirId, 353 InVpnLabel, C-S1, C-G1, Leaf, OutBfirId, OutVpnLabel, 354 OutBitString) 356 4.2. Forwarding using IP lookup on Segmentation Point 358 The Forwarding procedure of a segmentation point, ABR, have the 359 following steps: 361 1. Do a disposition of BIER tunnel to get the Pseudo-VRF, and a 362 following IP lookup in the Pseudo-VRF to get the appropriate BIER 363 encapsulation for Area, including the Local-VpnLabel indicated 364 by the Pseudo-VRF. 366 2. Do a disposition of BIER tunnel to get the VRF, and a following 367 IP lookup to get the appropriate local VRF interfaces if ABR has 368 local VPN CEs. 370 3. The said "disposition of BIER tunnel" requires a lookup of 371 upstream-assigned VpnLabel in special context. 373 For Step 1 and step 2, One can think them as one-to-many swapping of 374 a big 'BIER header' instead of a small 'Label' in P2MP case: 376 o swapping the InBierLabel with an OutBierLabel. 378 o swapping the InBfirId with an OutBfirId. 380 o swapping the InVpnLabel with an OutVpnLabel. 382 o swapping the InBitString with an OutBitString. 384 The key of a per-flow lookup on ABR is a tuple of (InBierLabel, 385 InBfirId, InVpnLabel) and a tuple of (C-S1, C-G1), representing a 386 BIER tunnel and a flow respectively. All the elements are from a 387 BIER packet, and such an IP lookup is very similar to an MFIB lookup, 388 if the (InBierLabel, InBfirId, InVpnLabel) tuple is mapped to a 389 Pseudo-VRF locally on the ABR per the upstream tunnel (a BIER tunnel 390 in this example). The ABR can be configured as PE of an MVPN 391 instance as well, and then there would be an MFIB lookup of the real 392 VRF, and an MFIB lookup of the Pseudo-VRF, independently, without any 393 impact to each other when configuration is changed. The MFIB lookup 394 of the Pseudo-VRF is not required to do RPF check. 396 5. Upstream P2MP and Downstream BIER (P2MP-BIER) 398 5.1. Explicit Tracking using LIR-pF 400 The procedures described in chapter 4.1 is also suitable for this 401 case, provided the LIR-pF explicit-tracking is used appropriately. 403 Suppose a topology of this: 405 | Egress Area | 406 | (P2MP) | 407 | | 408 +-------P3------PE3(Egress PE) 409 / 410 (Ingress PE)PE1-------P1-------ABR 411 | \ 412 | +-------P2------PE2(Egress PE) 413 | | | 414 | Ingress Area | Egress Area | 415 | ( P2MP ) | ( BIER SD ) | 417 Figure 2: Example topology 419 The Ingress PE is configured to use an P2MP tunnel type for a MVPN 420 instance for the Ingress Area, and the ABR is configured to use a 421 BIER tunnel type for the MVPN instance for the Egress Area , and 422 ABR may be configured to use a P2MP tunnel type for another Egress 423 Area. 425 Example 1: Use Inclusive P-tunnel for traditional areas. 427 PE1 may configure to use one SPMSI (*,*,PTA) 428 route , for one unidirectional Inclusive mLDP P2MP tunnel. 430 ABR may configure to reflect only the SPMSI(*,*) route with the PTA 431 type changed to BIER for Area, and reflect the SPMSI(*,*) route 432 with the PTA type changed to mLDP, RSVP-TE or IR for Area. 434 Example 2: Use Selective P-tunnel for traditional areas. 436 PE1 may configure to use one SPMSI (*,*,PTA) 437 route and a number of SPMSI (S,G,PTA) routes, 438 for one unidirectional Inclusive mLDP P2MP tunnel and a number of 439 Selective mLDP P2MP tunnels respectively. The different P2MP tunnels 440 bound in the SPMSI routes enable the ABR to initialize the different 441 downstream P2MP tunnels for Area or BIER-P2MP tunnels for area 442 , per the upstream P2MP tunnels. 444 ABR may configure to reflect only the SPMSI(*,*) route with the PTA 445 type changed to BIER for Area, and reflect the SPMSI(*,*) route 446 and SPMSI(S,G) routes with the PTA type changed to mLDP, RSVP-TE or 447 IR for Area. 449 5.2. Forwarding using IP lookup on Segmentation Point 451 The Forwarding procedure of a segmentation point, ABR, have 3 452 conditions: 454 1. Do a disposition of P2MP tunnel to get the Pseudo-VRF, and a 455 following IP lookup in Pseudo-VRF to get the appropriate BIER 456 encapsulation for Area, including the Local-VpnLabel indicated 457 by the Pseudo-VRF. 459 2. Do a lookup of P2MP tunnel to get the appropriate P2MP 460 downstreams for Area. 462 3. Do a disposition of P2MP tunnel to get the VRF, and a following 463 IP lookup to get the appropriate local VRF interfaces if ABR has 464 local VPN CEs. 466 4. The said "lookup/disposition of P2MP tunnel" requires a lookup of 467 downstream-assigned P2MP Label lookup. 469 6. Upstream BIER and Downstream P2MP (BIER-P2MP) 471 6.1. Explicit Tracking using LIR-pF 473 The procedures described in chapter 4.1 is also suitable for this 474 case, provided the LIR-pF explicit-tracking is used appropriately. 476 Suppose a topology of this: 478 | Egress Area | 479 | (P2MP) | 480 | | 481 +-------P3------PE3(Egress PE) 482 / 483 (Ingress PE)PE1-------P1-------ABR 484 | \ 485 | +-------P2------PE2(Egress PE) 486 | | | 487 | Ingress Area | Egress Area | 488 | ( BIER SD ) | ( BIER SD ) | 490 Figure 3: Example topology 492 The Ingress PE is configured to use a BIER tunnel type for an MVPN 493 instance for the Ingress Area, and the ABR is configured to use a 494 BIER tunnel type for the MVPN instance for the Egress Area , and 495 ABR may be configured to use a P2MP tunnel type for another Egress 496 Area. 498 Example 1: Use Inclusive P-tunnel for traditional areas. 500 PE1 may configure to use one SPMSI (*,*,PTA) 501 route , for one BIER tunnel. 503 ABR may configure to reflect only the SPMSI(*,*) route with the PTA 504 type unchanged for Area, and reflect the SPMSI(*,*) route with the 505 PTA type changed to mLDP, RSVP-TE or IR for Area. 507 Example 2: Use Selective P-tunnel for traditional areas. 509 PE1 may configure to use one SPMSI (*,*,PTA) route and a number of SPMSI (S,G,PTA, VpnLabelX) routes. The different VpnLabels 512 represent different BIER tunnels, and thus enable the ABR to 513 initialize the different downstream P2MP tunnels for Area or BIER- 514 P2MP tunnels for area , per the upstream BIER tunnels. 516 ABR may configure to reflect only the SPMSI(*,*) route with the PTA 517 type changed to BIER for Area, and reflect the SPMSI(*,*) route 518 and SPMSI(S,G) routes with the PTA type changed to mLDP, RSVP-TE or 519 IR for Area. 521 6.2. Forwarding on Segmentation Point 523 The Forwarding procedure of a segmentation point, ABR, have the 524 following conditions: 526 1. Do a disposition of BIER tunnel to get the Pseudo-VRF, and a 527 following IP lookup in the Pseudo-VRF to get the appropriate BIER 528 encapsulation for Area, including the Local-VpnLabel indicated 529 by the Pseudo-VRF. 531 2. Do a disposition of BIER tunnel to get the appropriate P2MP 532 downstreams for Area. 534 3. Do a disposition of BIER tunnel to get the VRF, and a following 535 IP lookup to get the appropriate local VRF interfaces if ABR has 536 local VPN CEs. 538 4. The said "disposition of BIER tunnel" requires a lookup of 539 upstream-assigned VpnLabel in special context. 541 7. Summary and Recommendations 543 Summary: 545 1. When BIER is used as the tunnel of the upstream segment, then a 546 upstream-assigned VpnLabel lookup in a special context is 547 required, instead of a downstream-assigned label lookup. 549 2. When BIER is used as the tunnel of the downstream segment, then a 550 per-flow IP lookup is required to get the BIER encapsulation, 551 following the label lookup to map 1:1 from the upstream tunnel 552 (BIER tunnel or P2MP tunnel) to the downstream BIER tunnel. 554 3. It is possible to require a per-flow VpnLabel allocation for the 555 whole Segmented MVPN, then a per-flow IP lookup can be the same 556 result as the per-tunnel VpnLabel lookup, and then one can 557 optimize not to use IP lookup. But this may not be allowed when 558 BIER-P2MP or P2MP-BIER deployed and the P2MP part can not support 559 per-flow tunnels. One obvious example is when the P2MP segment 560 uses Inclusive P2MP tunnel for all or for part of the multicast 561 flows. 563 4. An IP lookup following a VpnLabel lookup in special context is a 564 mandatory capability for a BFER function, and an IP lookup 565 following a P2MP label lookup is a mandatory capability for a 566 P2MP BUD function. Use of IP lookup on ABR for downstream BIER 567 segment can leverage the already required IP lookup capability. 569 5. Use of LIR-pF explicit-tracking in segmented MVPN deployment can 570 make the same benefits as in non segmented MVPN deployment. Both 571 can make the tunnel allocation (P2MP Label or VpnLabel 572 allocation) and the per-flow states decoupled. 574 Recommendations are: 576 1. that implementations support the IP lookup for Segmented MVPN 577 when downstream segment using BIER. 579 2. that implementations support the LIR-pF explicit tracking for 580 Segmented MVPN when BIER being deployed in any one segment. 582 3. that implementations support the optimization of not using IP 583 lookup on segmentation point ABR when end to end distinct tunnels 584 (P2MP tunnels or BIER tunnels) for distinct C-flows is not a 585 limit. 587 8. Appendix A - Comparison of Solutions 589 The table below provides a side-by-side comparison of explicit 590 tracking recommended, for non segmented MVPN and segmented MVPN 591 cases. 593 +------------------+-------------------------+-----------------------+ 594 | | draft-ietf-bier-mvpn | this draft | 595 +------------------+-------------------------+-----------------------+ 596 |Non segmented MVPN| LIR-pF | LIR-pF | 597 | | Per-flow Label NotReq | Per-flow Label NotReq | 598 +------------------+-------------------------+-----------------------+ 599 | | LIR | LIR-pF | 600 | Segmented MVPN | Per-flow Label Required | Per-flow Label NotReq | 601 +------------------+-------------------------+-----------------------+ 602 | (BIER-BIER) | LIR | LIR-pF | 603 +------------------+-------------------------+-----------------------+ 604 | (BIER-P2MP) | Not specified | LIR-pF | 605 +------------------+-------------------------+-----------------------+ 606 | (BIER-BIER) | Not specified | LIR-pF | 607 +------------------+-------------------------+-----------------------+ 609 Figure 4: Comparison of Segmented and non segmented MVPN 611 The table below provides a side-by-side comparison of forwarding 612 procedure on BFER/segmentation point ABR about whether to use IP 613 Lookup, for BFER, BIER-BIER, P2MP-BIER and BIER-P2MP cases. 615 +---------------+----------------------+-----------------------+ 616 | | draft-ietf-bier-mvpn | this draft | 617 +---------------+----------------------+-----------------------+ 618 | BFER | VpnLabel Lookup | VpnLabel Lookup | 619 | | + IP Lookup | + IP Lookup | 620 +---------------+----------------------+-----------------------+ 621 | ABR(BIER-BIER)| VpnLabel lookup | VpnLabel lookup | 622 | | | + IP Lookup | 623 +---------------+----------------------+-----------------------+ 624 | ABR(P2MP-BIER)| P2MP-Label Lookup | P2MP-Label Lookup | 625 | | | + IP Lookup | 626 +---------------+----------------------+-----------------------+ 627 | ABR(BIER-P2MP)| VpnLabel lookup | VpnLabel Lookup | 628 +---------------+----------------------+-----------------------+ 629 | ABR(P2MP-P2MP)| P2MP-Label lookup | P2MP-Label Lookup | 630 +---------------+----------------------+-----------------------+ 632 Figure 5: Comparison of Various Forwarding cases 634 The table below provides a list of the forwarding on ABR in a 3 635 segments deployment cases. 637 +----------------------------------------------+------------+ 638 | Topology Deployed | Forwarding | 639 | PE1--(Tnl1)--ABR1--(Tnl2)--ABR2--(Tnl3)--PE2 | on ABR1 | 640 +----------------------------------------------+------------+ 641 | BIER | BIER | ANY | *(1) | 642 | BIER | IR | ANY | *(2) | 643 | BIER | MLDP | ANY | *(2) | 644 | BIER | RSVP-TE | ANY | *(2) | 645 +----------------------------------------------+------------+ 646 | IR | BIER | ANY | *(3) | 647 | IR | IR | ANY | P2MP Swap | 648 | IR | MLDP | ANY | P2MP Swap | 649 | IR | RSVP-TE | ANY | P2MP Swap | 650 +----------------------------------------------+------------+ 651 | MLDP | BIER | ANY | *(3) | 652 | MLDP | IR | ANY | P2MP Swap | 653 | MLDP | MLDP | ANY | P2MP Swap | 654 | MLDP | RSVP-TE | ANY | P2MP Swap | 655 +----------------------------------------------+------------+ 656 | RSVP-TE | BIER | ANY | *(3) | 657 | RSVP-TE | IR | ANY | P2MP Swap | 658 | RSVP-TE | MLDP | ANY | P2MP Swap | 659 | RSVP-TE | RSVP-TE | ANY | P2MP Swap | 660 +----------------------------------------------+------------+ 661 *(1) VpnLabel Lookup for PseudoVRF, and IP Lookup for per-flow encapsulation. 662 *(2) VpnLabel Lookup for per-tunnel P2MP downstreams. 663 *(3) P2MP-Label Lookup for PseudoVRF, and IP Lookup for per-flow encapsulation. 664 *(4) P2MP-Label Lookup for per-tunnel P2MP downstreams. 666 Figure 6: Comparison of Various segmented combinations 668 9. Security Considerations 670 The procedures of this document do not, in themselves, provide 671 privacy, integrity, or authentication for the control plane or the 672 data plane. 674 10. IANA Considerations 676 No IANA allocation is required. 678 11. Acknowledgements 680 TBD. 682 12. References 684 12.1. Normative References 686 [I-D.ietf-bess-mvpn-expl-track] 687 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 688 "Explicit Tracking with Wild Card Routes in Multicast 689 VPN", draft-ietf-bess-mvpn-expl-track-12 (work in 690 progress), October 2018. 692 [I-D.ietf-bier-mvpn] 693 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 694 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 695 mvpn-11 (work in progress), March 2018. 697 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 698 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 699 2012, . 701 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 702 Encodings and Procedures for Multicast in MPLS/BGP IP 703 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 704 . 706 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 707 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 708 RFC 6625, DOI 10.17487/RFC6625, May 2012, 709 . 711 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 712 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 713 Explicit Replication (BIER)", RFC 8279, 714 DOI 10.17487/RFC8279, November 2017, 715 . 717 12.2. Informative References 719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 720 Requirement Levels", BCP 14, RFC 2119, 721 DOI 10.17487/RFC2119, March 1997, 722 . 724 Authors' Addresses 726 Jingrong Xie 727 Huawei Technologies 729 Email: xiejingrong@huawei.com 730 Liang Geng 731 China Mobile 732 Beijing 10053 734 Email: gengliang@chinamobile.com 736 Lei Wang 737 China Mobile 738 Beijing 10053 740 Email: wangleiyjy@chinamobile.com 742 Mike McBride 743 Huawei 745 Email: mmcbride7@gmail.com 747 Gang Yan 748 Huawei 750 Email: yangang@huawei.com