idnits 2.17.1 draft-xie-bess-mvpn-segmented-updates-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 : ---------------------------------------------------------------------------- ** 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 (January 8, 2019) is 1936 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 284, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Xie 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track Z. Zhang 5 Expires: July 12, 2019 Juniper Networks 6 L. Geng 7 China Mobile 8 M. McBride 9 G. Yan 10 Huawei 11 January 8, 2019 13 Use of Per-Flow Explicit Tracking and IP Lookup for Segmented MVPN 14 draft-xie-bess-mvpn-segmented-updates-00 16 Abstract 18 This document specifies an alternative of the control plane and data 19 plane procedures that allow segmented MVPN using the more efficient 20 LIR-pF explicit-tracking when BIER is used as the upstream or 21 downstream or both segments. It requires a segmentation point BFR 22 doing an IP header lookup, which is common for the forwarding 23 procedure on BFER, or the forwarding procedure on ABR with local VPN 24 CEs connected. This document updates [I-D.ietf-bier-mvpn]. 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]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on July 12, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Problem Statement and Considerations . . . . . . . . . . . . 4 69 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Considerations . . . . . . . . . . . . . . . . . . . . . 5 71 4. Upstream BIER and Downstream BIER (BIER-BIER) . . . . . . . . 6 72 4.1. Explicit Tracking using LIR-pF . . . . . . . . . . . . . 6 73 4.2. Forwarding using IP lookup on Segmentation Point . . . . 8 74 5. Upstream P2MP and Downstream BIER (P2MP-BIER) . . . . . . . . 9 75 5.1. Explicit Tracking using LIR-pF . . . . . . . . . . . . . 9 76 5.2. Forwarding using IP lookup on Segmentation Point . . . . 10 77 6. Upstream BIER and Downstream P2MP (BIER-P2MP) . . . . . . . . 10 78 6.1. Explicit Tracking using LIR-pF . . . . . . . . . . . . . 10 79 6.2. Forwarding on Segmentation Point . . . . . . . . . . . . 11 80 7. Summary and Recommendations . . . . . . . . . . . . . . . . . 12 81 8. Appendix A - Comparison of Solutions . . . . . . . . . . . . 13 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 85 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 86 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 87 12.2. Informative References . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 90 1. Introduction 92 When using BIER to transport an MVPN data packet through a BIER 93 domain, an ingress PE functions as a BFIR (see [RFC8279]). The BFIR 94 must determine the set of BFERs to which the packet needs to be 95 delivered. This can be done through an explicit-tracking function 96 using a LIR and/or LIR-pF flag in BGP MVPN routes, per the 98 [RFC6513],[RFC6514],[RFC6625],[I-D.ietf-bess-mvpn-expl-track], and 99 [I-D.ietf-bier-mvpn]. 101 Using a LIR-pF Flag will bring some extra benefits, as [I-D.ietf- 102 bier-mvpn] and [I-D.ietf-bess-mvpn-expl-track] have stated. But 103 unfortunately, the LIR-pF explicit tracking for a segmented MVPN 104 deployment is not allowed in the current draft [I-D.ietf-bier-mvpn], 105 because the draft requires a per-flow upstream-assigned label to do 106 the data-plane per-flow lookup on the segmentation point BFR. 108 This document specifies an alternative of the control plane and data 109 plane procedures that allow segmented MVPN using the more efficient 110 LIR-pF explicit-tracking when BIER is used as the upstream or 111 downstream or both segments. It requires a segmentation point BFR 112 doing an IP header lookup, which is common for the forwarding 113 procedure on BFER, or the forwarding procedure on ABR with local VPN 114 CEs connected. This will bring some significant benefits to the 115 segmented MVPN deployment, including: 117 o Getting a much better multicast join latency by eliminating the 118 round trip interaction of S-PMSI AD routes and Leaf AD routes. 119 Especially, the S-PMSI A-D routes may need a data-driven procedure 120 to trigger, and make the multicast join latency even worse. 122 o Greatly reducing the number of S-PMSI A-D routes that BFIR and 123 BFERs need to save. 125 o Consolidated forwarding procedure of IP lookup for every BIER 126 Overlay functioning routers, such as BFIR, BFER, segmentation 127 point BFR, and segmentation point BFR with BFER function. 129 2. Terminology 131 Readers of this document are assumed to be familiar with the 132 terminology and concepts of the documents listed as Normative 133 References. 135 P2MP: This document uses the term "P2MP" for "mLDP P2MP, RSVP-TE 136 P2MP, or IR P2MP". 138 BIER tunnel: An unidirectional tunnel indicated by an upstream- 139 assigned VpnLabel and the according context such as the RootIP where 140 the VpnLabel is generated. In control plane the BIER tunnel is the 141 PTA of type including the MPLS Label of the PTA. One BIER 142 tunnel is bound to an BGP-MVPN SPMSI route. There are no two BGP- 143 MVPN SPMSI routes of different VPN binding the same BIER tunnel, but 144 there are possibly two BGP-MVPN SPMSI routes of the same VPN binding 145 the same BIER tunnel. 147 P2MP tunnel: An unidirectional tunnel indicated by an downstream 148 label. In control plane the P2MP tunnel is the PTA of type or 149 type or type . The MPLS Label of the PTA is zero in 150 real implementation. One P2MP tunnel is bound to an BGP-MVPN SPMSI 151 route. There are no two BGP-MVPN SPMSI routes in different VPNs 152 binding the same BIER tunnel, but there are possibly two BGP-MVPN 153 SPMSI routes in the same VPN binding the same P2MP tunnel. 155 BGP-MVPN FEC: Either a (OrigIP, RD) tuple indicating by an 156 SPMS(OrigIP, RD, *, *), or a (OrigIP, RD, S, G) tuple indicating by 157 an SPMSI(OrigIP, RD, S, G). The BGP-MVPN FEC is used for control 158 plane to build some form of forwarding state on an segment point ABR 159 node. One example of such forwarding state is to use the upstream 160 P2MP tunnel bound to an SPMSI route, and the downstream P2MP 161 tunnel(s) bound to an SPMSI route, with the same BGP-MVPN FEC. 162 Another example of such forwarding state is to use the upstream BIER 163 tunnel bound to an SPMSI route, and the downstream P2MP tunnel(s) 164 and/or BIER tunnel(s). 166 VRF: Virtual Routing Forwarding. It is usually a number to indicate 167 a VPN/MVPN instance locally when L3VPN is configured. It is also 168 called local VRF. 170 Pseudo VRF: a Pseudo VRF indicates a VPN/MVPN instance locally on the 171 segment point ABR when downstream BIER forwarding using IP lookup is 172 required. The segment point ABR can be a PE of a VPN/MVPN instance 173 at the same time, and then there would have VRF and Pseudo VRF(s) 174 simultaneously. Note that the Pseudo VRF(s) is per the tunnel (BIER 175 tunnel or P2MP tunnel). Numbers of RootIP per a VPN/MVPN, and 176 numbers of tunnels per a VPN/MVPN and a RootIP, in the BGP-MVPN 177 FEC(s), will cause numbers of the Pseudo VRF allocated. 179 Local VpnLabel: a Local VpnLabel indicates a upstream-assigned MPLS 180 Label locally on the segment point ABR when downstream BIER 181 forwarding using IP lookup is required. Local VpnLabel is 1:1 to 182 Pseudo VRF, and it is assumed that a Pseudo VRF always indicates a 183 Local VpnLabel within it. 185 3. Problem Statement and Considerations 187 3.1. Problem Statement 189 BIER is a stateless multicast forwarding by introducing a multicast- 190 specific BIER header in the data plane. The maximal number of BFERs 191 a packet can reach is limited by the bit string length of a BIER 192 header. For a network with many routers in multiple IGP areas 193 (typically an Inter-Area network), it may be expected to use a 194 segmented MVPN when deploying BIER because operators don't want to 195 replicate packets to many BIER Sets. It is also possible for an 196 incremental deployment of BIER on one area (e.g. one Metro network 197 area) while keeping the P2MP in other areas (e.g. the Core network 198 area, and the other Metro network areas). 200 However, it is not allowed in the [I-D.ietf-bier-mvpn] to use a LIR- 201 pF explicit-tracking when deploying a segmented MVPN. This will lead 202 to a low efficiency of explicit-tracking, and cause a worse multicast 203 join latency. Here we first take a scenario of inter-area segmented 204 MVPN with both segments using BIER in section 4 for a generic 205 description. The second scenario is inter-area segmented MVPN with 206 upstream segment using P2MP and downstream segment using BIER in 207 section 5. The third scenario is inter-area segmented MVPN with 208 upstream segment using BIER and downstream segment using P2MP in 209 section 6. 211 3.2. Considerations 213 A BFIR always need to know the BFERs interested in a specific flow. 214 This is a function of a BIER overlay defined in [RFC8279]. A 215 segmentation point BFR in a segmented MVPN deployment, saying ABR, 216 will play similar roles of both BFIR and BFER. It needs to do a 217 disposition of a BIER Header, and then do an imposition of a new BIER 218 Header. It requires the ABR router to maintain per-flow states, and 219 especially, such per-flow states always include a set of BFERs who 220 are intrested in a specific flow by using an explicit-tracking 221 procedure. 223 This behavior is completely different from a traditional segmented 224 MVPN deployment, e.g, with both of the two segments using P2MP label 225 switch. In a traditional segmented MVPN with both segments using 226 P2MP label switch, it is expected to receive a MPLS packet and 227 replicate to downstream routers after swap the MPLS Label. A lookup 228 of IP packet is not expected. Also, in a traditional segmented MVPN 229 deployment, an MPLS label represents a P-tunnel, which may carry one, 230 many or even all multicast flow(s) of a VPN, so it is not always a 231 per-flow state on the segmentation point router. 233 In conclusion, the pattern of forwarding packets on segmentation 234 points only by lookup of MPLS label mapped from multicast flow(s) is 235 significantly unnecessary when BIER is introduced. Instead, doing a 236 per-flow lookup of IP header on segmentation points is more efficient 237 and consolidated. 239 4. Upstream BIER and Downstream BIER (BIER-BIER) 241 4.1. Explicit Tracking using LIR-pF 243 In a scenario of Inter-area Segmented MVPN with both segments using 244 BIER, the determination of the set of BFERs that need to receive a 245 specific multicast flow of (C-S1,C-G1) in each segment, can be 246 obtained by using a LIR-pF flag. 248 Suppose a topology of this: 250 (Ingress PE)PE1-------P1-------ABR-------P2------PE2(Egress PE) 251 | | | 252 | Ingress Area | Egress Area | 253 | ( BIER SD ) | ( BIER SD ) | 255 Figure 1: Example topology 257 PE1 is Ingress PE, and the area of { PE1 -- P1 -- ABR } is called an 258 Ingress Area. 260 PE2 is Egress PE, and the area of { ABR -- P2 -- PE2 } is called an 261 Egress Area. 263 The Ingress PE is configured to use a BIER tunnel type for an MVPN 264 instance for the Ingress Area, and the ABR is configured to use a 265 BIER tunnel type for the MVPN instance for the Egress Area. 267 The Ingress PE originates a wildcard S-PMSI A-D route (C-*,C-*) and 268 the PTA of that route has the following settings: 270 o The LIR-pF and LIR flags be set. 272 o The tunnel type be set to "BIER". 274 o A non-zero MPLS label be specified. 276 ABR receives the S-PMSI A-D route from the Ingress PE, and re- 277 advertises the route to the Egress PE, with a PTA type "BIER", and 278 PTA flags of LIR and LIR-pF, and a new non-zero upstream-assigned 279 MPLS label allocated by ABR per-VPN. 281 Egress PE receives the S-PMSI A-D route from the ABR, and checks if 282 it need to response with a Leaf A-D route to this S-PMSI A-D route 283 using the process of the "match for reception" and "match for 284 tracking" as defined in [I-D.bess-mvpn-expl-track]. In this example, 285 for a C-flow of (C-S1, C-G1), the checking result of "matched for 286 tracking" is the S-PMSI(C-*, C-*), and the checking result of 287 "matched for reception" is also the S-PMSI(C-*, C-*). Egress PE will 288 then send a Leaf A-D route (RD, C-S1, C-G1, Root=PE1, Leaf=PE2) to 289 the ABR with a PTA flag LIR-pF, and a Leaf A-D route (RD, C-*, C-*, 290 Root=PE1, Leaf=PE2) without a PTA flag LIR-pF. 292 ABR then has an explicit-tracking result of a new per-flow 293 information of (RD, C-S1, C-G1, Root=PE1) with Egress PE as its leaf 294 or BFER. ABR's "matched for tracking" result to this flow(RD, C-S1, 295 C-G1, PE1) will then be updated with a new record, and ABR then sends 296 a Leaf A-D route (RD, C-S1, C-G1, Root=PE1, Leaf=ABR) to Ingress PE. 298 Ingress PE then has an explicit-tracking result of a new per-flow 299 information of (RD, C-S1, C-G1, Root=PE1) with ABR as its leaf or 300 BFER. 302 From this procedure description one can see that: 304 1. The S-PMSI A-D(C-*, C-*) route is functioning as a per-VPN anchor 305 of the upstream and the downstream(s), which can be called an 306 BGP-MVPN FEC in this document, saying BGP-MVPN FEC(OrigIP, RD). 308 2. The Leaf A-D(S,G) routes are functioning as a per-flow anchor of 309 the downstream(s) and the upstream, which are also BGP-MVPN FECs 310 accordingly, saying BGP-MVPN FEC(OrigIP, RD, S,G). 312 3. The Tuple of (Root=PE1, RD) in S-PMSI (C-*, C-*) or Leaf AD(C-*, 313 C-*) or Leaf AD(C-S, C-G) represents an VRF on the ABR 314 implicitly. 316 ABR knows the per-vpn infmation of a (Root=PE1, RD) tuple when 317 receiving and re-advertising the S-PMSI A-D(*,*) route bound with a 318 PTA, where: 320 o Inbound SD (InSD): in PTA of the received S-PMSI(*,*) route. 322 o Inbound VpnLabel (InVpnLabel): in PTA of the received S-PMSI(*,*) 323 route. 325 o Inbound BfirId (InBfirId): in PTA of the received S-PMSI(*,*) 326 route. 328 o Outbound SD(OutSD): in PTA of the re-advertised S-PMSI(*,*) route. 330 o Outbound VpnLabel (OutVpnLabel): in PTA of the re-advertised 331 S-PMSI(*,*) route. 333 o Outbound BfirId (OutBfirId): in PTA of the re-advertised 334 S-PMSI(*,*) route. 336 ABR establishs a per-flow control-plane state accordingly like this: 338 o Per-flow upstream state, according to the Leaf A-D (C-S, C-G) 339 route send to the Ingress PE: (PE1, RD, C-S1, C-G1, InSD, 340 InBfirId, InVpnLabel). 342 o Per-flow downstream state(s), according to the Leaf A-D(C-S, C-G) 343 route(s) received by the ABR from Egress PE(s): (PE1, RD, C-S1, 344 C-G1, Leaf, OutSD, OutBfirId, OutVpnLabel). 346 ABR knows the BIER Label(s) it allocated for InSD and OutSD, saying 347 InBierLabel for InSD and OutBierLabel for OutSD, and thus it 348 can establish the per-flow forwarding state: 350 o Per-flow upstream forwarding state: (InBierLabel, InBfirId, 351 InVpnLabel, C-S1, C-G1). 353 o Per-flow downstream(s) forwarding state: (InBierLabel, InBfirId, 354 InVpnLabel, C-S1, C-G1, Leaf, OutBfirId, OutVpnLabel, 355 OutBitString) 357 4.2. Forwarding using IP lookup on Segmentation Point 359 The Forwarding procedure of a segmentation point, ABR, have the 360 following steps: 362 1. Do a disposition of BIER tunnel to get the Pseudo-VRF, and a 363 following IP lookup in the Pseudo-VRF to get the appropriate BIER 364 encapsulation for Area, including the Local-VpnLabel indicated 365 by the Pseudo-VRF. 367 2. Do a disposition of BIER tunnel to get the VRF, and a following 368 IP lookup to get the appropriate local VRF interfaces if ABR has 369 local VPN CEs. 371 3. The said "disposition of BIER tunnel" requires a lookup of 372 upstream-assigned VpnLabel in special context. 374 For Step 1 and step 2, One can think them as one-to-many swapping of 375 a big 'BIER header' instead of a small 'Label' in P2MP case: 377 o swapping the InBierLabel with an OutBierLabel. 379 o swapping the InBfirId with an OutBfirId. 381 o swapping the InVpnLabel with an OutVpnLabel. 383 o swapping the InBitString with an OutBitString. 385 The key of a per-flow lookup on ABR is a tuple of (InBierLabel, 386 InBfirId, InVpnLabel) and a tuple of (C-S1, C-G1), representing a 387 BIER tunnel and a flow respectively. All the elements are from a 388 BIER packet, and such an IP lookup is very similar to an MFIB lookup, 389 if the (InBierLabel, InBfirId, InVpnLabel) tuple is mapped to a 390 Pseudo-VRF locally on the ABR per the upstream tunnel (a BIER tunnel 391 in this example). The ABR can be configured as PE of an MVPN 392 instance as well, and then there would be an MFIB lookup of the real 393 VRF, and an MFIB lookup of the Pseudo-VRF, independently, without any 394 impact to each other when configuration is changed. The MFIB lookup 395 of the Pseudo-VRF is not required to do RPF check. 397 5. Upstream P2MP and Downstream BIER (P2MP-BIER) 399 5.1. Explicit Tracking using LIR-pF 401 The procedures described in chapter 4.1 is also suitable for this 402 case, provided the LIR-pF explicit-tracking is used appropriately. 404 Suppose a topology of this: 406 | Egress Area | 407 | (P2MP) | 408 | | 409 +-------P3------PE3(Egress PE) 410 / 411 (Ingress PE)PE1-------P1-------ABR 412 | \ 413 | +-------P2------PE2(Egress PE) 414 | | | 415 | Ingress Area | Egress Area | 416 | ( P2MP ) | ( BIER SD ) | 418 Figure 2: Example topology 420 The Ingress PE is configured to use an P2MP tunnel type for a MVPN 421 instance for the Ingress Area, and the ABR is configured to use a 422 BIER tunnel type for the MVPN instance for the Egress Area , and 423 ABR may be configured to use a P2MP tunnel type for another Egress 424 Area. 426 Example 1: Use Inclusive P-tunnel for traditional areas. 428 PE1 may configure to use one SPMSI (*,*,PTA) 429 route , for one unidirectional Inclusive mLDP P2MP tunnel. 431 ABR may configure to reflect only the SPMSI(*,*) route with the PTA 432 type changed to BIER for Area, and reflect the SPMSI(*,*) route 433 with the PTA type changed to mLDP, RSVP-TE or IR for Area. 435 Example 2: Use Selective P-tunnel for traditional areas. 437 PE1 may configure to use one SPMSI (*,*,PTA) 438 route and a number of SPMSI (S,G,PTA) routes, 439 for one unidirectional Inclusive mLDP P2MP tunnel and a number of 440 Selective mLDP P2MP tunnels respectively. The different P2MP tunnels 441 bound in the SPMSI routes enable the ABR to initialize the different 442 downstream P2MP tunnels for Area or BIER-P2MP tunnels for area 443 , per the upstream P2MP tunnels. 445 ABR may configure to reflect only the SPMSI(*,*) route with the PTA 446 type changed to BIER for Area, and reflect the SPMSI(*,*) route 447 and SPMSI(S,G) routes with the PTA type changed to mLDP, RSVP-TE or 448 IR for Area. 450 5.2. Forwarding using IP lookup on Segmentation Point 452 The Forwarding procedure of a segmentation point, ABR, have 3 453 conditions: 455 1. Do a disposition of P2MP tunnel to get the Pseudo-VRF, and a 456 following IP lookup in Pseudo-VRF to get the appropriate BIER 457 encapsulation for Area, including the Local-VpnLabel indicated 458 by the Pseudo-VRF. 460 2. Do a lookup of P2MP tunnel to get the appropriate P2MP 461 downstreams for Area. 463 3. Do a disposition of P2MP tunnel to get the VRF, and a following 464 IP lookup to get the appropriate local VRF interfaces if ABR has 465 local VPN CEs. 467 4. The said "lookup/disposition of P2MP tunnel" requires a lookup of 468 downstream-assigned P2MP Label lookup. 470 6. Upstream BIER and Downstream P2MP (BIER-P2MP) 472 6.1. Explicit Tracking using LIR-pF 474 The procedures described in chapter 4.1 is also suitable for this 475 case, provided the LIR-pF explicit-tracking is used appropriately. 477 Suppose a topology of this: 479 | Egress Area | 480 | (P2MP) | 481 | | 482 +-------P3------PE3(Egress PE) 483 / 484 (Ingress PE)PE1-------P1-------ABR 485 | \ 486 | +-------P2------PE2(Egress PE) 487 | | | 488 | Ingress Area | Egress Area | 489 | ( BIER SD ) | ( BIER SD ) | 491 Figure 3: Example topology 493 The Ingress PE is configured to use a BIER tunnel type for an MVPN 494 instance for the Ingress Area, and the ABR is configured to use a 495 BIER tunnel type for the MVPN instance for the Egress Area , and 496 ABR may be configured to use a P2MP tunnel type for another Egress 497 Area. 499 Example 1: Use Inclusive P-tunnel for traditional areas. 501 PE1 may configure to use one SPMSI (*,*,PTA) 502 route , for one BIER tunnel. 504 ABR may configure to reflect only the SPMSI(*,*) route with the PTA 505 type unchanged for Area, and reflect the SPMSI(*,*) route with the 506 PTA type changed to mLDP, RSVP-TE or IR for Area. 508 Example 2: Use Selective P-tunnel for traditional areas. 510 PE1 may configure to use one SPMSI (*,*,PTA) route and a number of SPMSI (S,G,PTA, VpnLabelX) routes. The different VpnLabels 513 represent different BIER tunnels, and thus enable the ABR to 514 initialize the different downstream P2MP tunnels for Area or BIER- 515 P2MP tunnels for area , per the upstream BIER tunnels. 517 ABR may configure to reflect only the SPMSI(*,*) route with the PTA 518 type changed to BIER for Area, and reflect the SPMSI(*,*) route 519 and SPMSI(S,G) routes with the PTA type changed to mLDP, RSVP-TE or 520 IR for Area. 522 6.2. Forwarding on Segmentation Point 524 The Forwarding procedure of a segmentation point, ABR, have the 525 following conditions: 527 1. Do a disposition of BIER tunnel to get the Pseudo-VRF, and a 528 following IP lookup in the Pseudo-VRF to get the appropriate BIER 529 encapsulation for Area, including the Local-VpnLabel indicated 530 by the Pseudo-VRF. 532 2. Do a disposition of BIER tunnel to get the appropriate P2MP 533 downstreams for Area. 535 3. Do a disposition of BIER tunnel to get the VRF, and a following 536 IP lookup to get the appropriate local VRF interfaces if ABR has 537 local VPN CEs. 539 4. The said "disposition of BIER tunnel" requires a lookup of 540 upstream-assigned VpnLabel in special context. 542 7. Summary and Recommendations 544 Summary: 546 1. When BIER is used as the tunnel of the upstream segment, then a 547 upstream-assigned VpnLabel lookup in a special context is 548 required, instead of a downstream-assigned label lookup. 550 2. When BIER is used as the tunnel of the downstream segment, then a 551 per-flow IP lookup is required to get the BIER encapsulation, 552 following the label lookup to map 1:1 from the upstream tunnel 553 (BIER tunnel or P2MP tunnel) to the downstream BIER tunnel. 555 3. It is possible to require a per-flow VpnLabel allocation for the 556 whole Segmented MVPN, then a per-flow IP lookup can be the same 557 result as the per-tunnel VpnLabel lookup, and then one can 558 optimize not to use IP lookup. But this may not be allowed when 559 BIER-P2MP or P2MP-BIER deployed and the P2MP part can not support 560 per-flow tunnels. One obvious example is when the P2MP segment 561 uses Inclusive P2MP tunnel for all or for part of the multicast 562 flows. 564 4. An IP lookup following a VpnLabel lookup in special context is a 565 mandatory capability for a BFER function, and an IP lookup 566 following a P2MP label lookup is a mandatory capability for a 567 P2MP BUD function. Use of IP lookup on ABR for downstream BIER 568 segment can leverage the already required IP lookup capability. 570 5. Use of LIR-pF explicit-tracking in segmented MVPN deployment can 571 make the same benefits as in non segmented MVPN deployment. Both 572 can make the tunnel allocation (P2MP Label or VpnLabel 573 allocation) and the per-flow states decoupled. 575 Recommendations are: 577 1. that implementations support the IP lookup for Segmented MVPN 578 when downstream segment using BIER. 580 2. that implementations support the LIR-pF explicit tracking for 581 Segmented MVPN when BIER being deployed in any one segment. 583 3. that implementations support the optimization of not using IP 584 lookup on segmentation point ABR when end to end distinct tunnels 585 (P2MP tunnels or BIER tunnels) for distinct C-flows is not a 586 limit. 588 8. Appendix A - Comparison of Solutions 590 The table below provides a side-by-side comparison of explicit 591 tracking recommended, for non segmented MVPN and segmented MVPN 592 cases. 594 +------------------+-------------------------+-----------------------+ 595 | | draft-ietf-bier-mvpn | this draft | 596 +------------------+-------------------------+-----------------------+ 597 |Non segmented MVPN| LIR-pF | LIR-pF | 598 | | Per-flow Label NotReq | Per-flow Label NotReq | 599 +------------------+-------------------------+-----------------------+ 600 | | LIR | LIR-pF | 601 | Segmented MVPN | Per-flow Label Required | Per-flow Label NotReq | 602 +------------------+-------------------------+-----------------------+ 603 | (BIER-BIER) | LIR | LIR-pF | 604 +------------------+-------------------------+-----------------------+ 605 | (BIER-P2MP) | Not specified | LIR-pF | 606 +------------------+-------------------------+-----------------------+ 607 | (BIER-BIER) | Not specified | LIR-pF | 608 +------------------+-------------------------+-----------------------+ 610 Figure 4: Comparison of Segmented and non segmented MVPN 612 The table below provides a side-by-side comparison of forwarding 613 procedure on BFER/segmentation point ABR about whether to use IP 614 Lookup, for BFER, BIER-BIER, P2MP-BIER and BIER-P2MP cases. 616 +---------------+----------------------+-----------------------+ 617 | | draft-ietf-bier-mvpn | this draft | 618 +---------------+----------------------+-----------------------+ 619 | BFER | VpnLabel Lookup | VpnLabel Lookup | 620 | | + IP Lookup | + IP Lookup | 621 +---------------+----------------------+-----------------------+ 622 | ABR(BIER-BIER)| VpnLabel lookup | VpnLabel lookup | 623 | | | + IP Lookup | 624 +---------------+----------------------+-----------------------+ 625 | ABR(P2MP-BIER)| P2MP-Label Lookup | P2MP-Label Lookup | 626 | | | + IP Lookup | 627 +---------------+----------------------+-----------------------+ 628 | ABR(BIER-P2MP)| VpnLabel lookup | VpnLabel Lookup | 629 +---------------+----------------------+-----------------------+ 630 | ABR(P2MP-P2MP)| P2MP-Label lookup | P2MP-Label Lookup | 631 +---------------+----------------------+-----------------------+ 633 Figure 5: Comparison of Various Forwarding cases 635 The table below provides a list of the forwarding on ABR in a 3 636 segments deployment cases. 638 +----------------------------------------------+------------+ 639 | Topology Deployed | Forwarding | 640 | PE1--(Tnl1)--ABR1--(Tnl2)--ABR2--(Tnl3)--PE2 | on ABR1 | 641 +----------------------------------------------+------------+ 642 | BIER | BIER | ANY | *(1) | 643 | BIER | IR | ANY | *(2) | 644 | BIER | MLDP | ANY | *(2) | 645 | BIER | RSVP-TE | ANY | *(2) | 646 +----------------------------------------------+------------+ 647 | IR | BIER | ANY | *(3) | 648 | IR | IR | ANY | P2MP Swap | 649 | IR | MLDP | ANY | P2MP Swap | 650 | IR | RSVP-TE | ANY | P2MP Swap | 651 +----------------------------------------------+------------+ 652 | MLDP | BIER | ANY | *(3) | 653 | MLDP | IR | ANY | P2MP Swap | 654 | MLDP | MLDP | ANY | P2MP Swap | 655 | MLDP | RSVP-TE | ANY | P2MP Swap | 656 +----------------------------------------------+------------+ 657 | RSVP-TE | BIER | ANY | *(3) | 658 | RSVP-TE | IR | ANY | P2MP Swap | 659 | RSVP-TE | MLDP | ANY | P2MP Swap | 660 | RSVP-TE | RSVP-TE | ANY | P2MP Swap | 661 +----------------------------------------------+------------+ 662 *(1) VpnLabel Lookup for PseudoVRF, and IP Lookup for per-flow encapsulation. 663 *(2) VpnLabel Lookup for per-tunnel P2MP downstreams. 664 *(3) P2MP-Label Lookup for PseudoVRF, and IP Lookup for per-flow encapsulation. 665 *(4) P2MP-Label Lookup for per-tunnel P2MP downstreams. 667 Figure 6: Comparison of Various segmented combinations 669 9. Security Considerations 671 The procedures of this document do not, in themselves, provide 672 privacy, integrity, or authentication for the control plane or the 673 data plane. 675 10. IANA Considerations 677 No IANA allocation is required. 679 11. Acknowledgements 681 TBD. 683 12. References 685 12.1. Normative References 687 [I-D.ietf-bess-mvpn-expl-track] 688 Dolganow, A., Kotalwar, J., Rosen, E., and Z. Zhang, 689 "Explicit Tracking with Wild Card Routes in Multicast 690 VPN", draft-ietf-bess-mvpn-expl-track-13 (work in 691 progress), November 2018. 693 [I-D.ietf-bier-mvpn] 694 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 695 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 696 mvpn-11 (work in progress), March 2018. 698 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 699 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 700 2012, . 702 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 703 Encodings and Procedures for Multicast in MPLS/BGP IP 704 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 705 . 707 [RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. 708 Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", 709 RFC 6625, DOI 10.17487/RFC6625, May 2012, 710 . 712 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 713 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 714 Explicit Replication (BIER)", RFC 8279, 715 DOI 10.17487/RFC8279, November 2017, 716 . 718 12.2. Informative References 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, 723 . 725 Authors' Addresses 727 Jingrong Xie 728 Huawei Technologies 730 Email: xiejingrong@huawei.com 731 Zhaohui Zhang 732 Juniper Networks 734 Email: zzhang@juniper.net 736 Liang Geng 737 China Mobile 738 Beijing 10053 740 Email: gengliang@chinamobile.com 742 Mike McBride 743 Huawei 745 Email: mmcbride7@gmail.com 747 Gang Yan 748 Huawei 750 Email: yangang@huawei.com