Hi Siyu, Let me list some high-level summary of BGP-MVPN protocol mechanisms before going into response to your comments.
BGP-MVPN has 7 route types: - Type 1: To announce non-segmented inclusive tunnels - Type 2: To announce segmented inter-as tunnels and for per-AS aggregation - Type 3: To announce binding of flows to selective tunnels - Type 4: For egress PEs to tell ingress PEs they're leaves of the selective tunnels in response to type 2/3. Needed for RSVP P2MP, IR/BIER - Type 5: For source discovery, assert and (s,g,rpt) prune in case of shared tree across the provider network - Type 6/7: For (*,g) or (s,g) joins To compare against Rosen/PIM-MVPN: - Type-1 route is comparable to the static configuration of per-VPN group for the default MDT - Type-2 route is irrelevant because there is no concept of per-AS aggregation and inter-AS segmentation - Type-3 route is comparable to the data MDT route - Type-4 is for explicit tracking, and not needed for PIM/mLDP provider tunnels - Type-5 is for the control plane based assert procedure and (s,g,rpt) prune - Type 6/7 is comparable for PIM (*,g)/(s,g) joins but w/o the explicit tracking functionality Please see zzh> below. Juniper Business Use Only -----Original Message----- From: Chensiyu (Susie) Sent: Thursday, November 30, 2023 10:23 PM To: Jeffrey (Zhaohui) Zhang ; 'BESS' Cc: duanfanghong Subject: RE: Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00 [External Email. Be cautious of content] Hi Jeffrey, Your summary about our method is great. I've also read your draft about explicit tracking. Explicit tracking is realized by our new procedure, but it's not the only goal we'd like to achieve. Zzh> Explicit tracking is an important aspect in both drafts - separate type-6/7 and type-4 routes are merged. In draft-zzhang, it is into the existing type-6/7 routes and in draft-duan it is into a new route. The question is, which way do we want to go for explicit tracking. Our goal is to provide the simplest MVPN signaling interaction when the tunnel type is BIER or IR. Previous 8 routes are simplified to 2 routes. Zzh> The draft talks about the following: 3.1. Simplification of Type 1 to Type 4 NLRI . . . . . . . . . 4 3.2. Simplification of Type 6 to Type 7 NLRI . . . . . . . . . 5 Zzh> About "simplification of Type 1 to Type 4", I don't think your proposal handles segmentation and per-AS aggregation, so it is only about "simplification of Type 1/3/4". Specifically, the Type 1/3 functionality is folded into the UMH routes while the Type 4 functionality is folded into your new route type (a merge of Type 6/7 and Type 4). My previous email pointed out the issue with using UMH routes, and in draft-zzhang, the Type 3 functionality is folded into type 1 in case of BIER/IR (but still allow to use Type 3 when more granularity is needed, e.g., different flows may use different BIER sub-domains) and the Type 4 functionality (explicit tracking) is folded into Type 6/7 itself. Zzh> My argument is that the solution in draft-zzhang is better. Zzh> Now about "Simplification of Type 6 to Type 7 NLRI" - it's basically the explicit tracking plus (s,g,rpt) prune. We talked about explicit tracking already. We don't aim at all existing tunnels and would like to construct a PIM-like procedure which consists of RPF route and J/P/SG-RPT route exchanging. The J/P/SG-RPT route can either be a new route or a modified one based on the existing C-multicast route. The new route will carry (S,G,RPT) information which weren't carried by the old C-multicast routes in RFC6514. These routes and exchanging procedures are designed based on BGP because BGP is widely deployed. Zzh> draft-zzhang covers many different use cases with different solutions. In case of BIER/IR tunnel, it extends Type-6/7 routes with explicit tracking and removes the need for type-3 route. With that, it achieves the same goals you listed above except the (s,g,rpt) prune. Zzh> When BGP-MVPN was designed, a deliberate decision was made to use type-5 routes for (s,g,rpt) prune instead of using explicit (s,g,rpt) prune flag/route. I can't articulate the detailed reasons, but we don't have to rush to a change. Therefore, we think that our draft actually focus on different scenario and problems and we'd like to continue our work on our draft. We are also working on solution for tunnel segmentation scenario and it will be updated in later version. Zzh> As explained above, I don't agree that your draft focus on different scenarios and problems. You can say that you use different solutions for the same problem (for which there are already proposed solutions w/o using new route types), and the WG can debate and decide which way to go. Zzh> Jeffrey Best wishes, Siyu -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper....@dmarc.ietf.org] Sent: Friday, November 10, 2023 9:59 PM To: Chensiyu (Susie) ; 'BESS' Subject: RE: Comments about https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bie__;!!NEt6yMaO-gk!C-8cQW0OFpih26MIPj-4DM-0r9gcgqIlrU-xeWnnIqr1ZxgCb1ye7xx_umTLp4nBpJZMD13OaK-9faUF0-gtnV660i89wRT7$ r-and-ir-00 Actually, we don't need the extended community even in the case of tunnel segmentation, because the C-multicast route used for explicit tracking purposes should not be sent to the UMH but to the local upstream segmentation point (and the next hop of the route would not change so it can be used to identify the leaf PE). Additionally, if the UMH route is used to advertise the PTA info, then the segmentation points need to update that info, which is not desired since they're just unicast routes not MVPN routes. The existing x-PMSI route procedures work very well with tunnel segmentation. Juniper Business Use Only -----Original Message----- From: Jeffrey (Zhaohui) Zhang Sent: Friday, November 10, 2023 2:30 PM To: Chensiyu (Susie) <chensiyu27=40huawei....@dmarc.ietf.org>; 'BESS' <bess@ietf.org> Subject: Comments about https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00__;!!NEt6yMaO-gk!C-8cQW0OFpih26MIPj-4DM-0r9gcgqIlrU-xeWnnIqr1ZxgCb1ye7xx_umTLp4nBpJZMD13OaK-9faUF0-gtnV660mxN9-rT$ Hi Siyu, To follow up my comments in the BESS session, it is indeed good to optimize provider tunnel procedures based on PMSI/Leaf AD route in the case of IR/BIER, but there are alternatives. Essentially, draft-duan replaces the PMSI/Leaf AD routes with the following: - Announce the PTA info in the UMH routes instead of PMSI routes - Use a new route type, which is a variant of C-Multicast route instead Leaf route, for leaf tracking purposes For leaf tracking purposes, an alternative is also proposed in https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-zzhang-bess-mvpn-evpn-cmcast-enhancements-01*section-1.2.1__;Iw!!NEt6yMaO-gk!C-8cQW0OFpih26MIPj-4DM-0r9gcgqIlrU-xeWnnIqr1ZxgCb1ye7xx_umTLp4nBpJZMD13OaK-9faUF0-gtnV660pidHM8N$ . Notice that the (C-*,C-G-BIDIR) C-Multicast routes from different PEs all have their own RDs so Route Reflectors (RRs) will reflect every one of them, and they already serve explicit tracking purpose (the BGP Next Hop identifies the originator of the route in non- segmentation case) - there is no need to use Leaf A-D routes triggered by the LIR bit in S-PMSI A-D routes. In case of RSVP-TE P2MP tunnel, the S-PMSI A-D routes are still needed to announce the tunnel but the LIR bit does not need to be set. In case of IR/BIER, there is no need for S-PMSI A-D routes at all. Although that is in the context of the MVPN-RPL Method of C-BIDIR support, the same idea can be used in general: instead of using the UMH's RD, each leaf PE just uses its own RD. While in RFC6514 the UMH's RD is used, that is for exactly the opposite purpose - the RRs only need to re-advertise a single C-Multicast route to the UMH while here we want each C-Multicast route to reach the UMH for leaf tracking purposes. This method does not need a new route type - just use the leaf PE's own RD and attach an extended community to identify the leaf PE (the extended community is only needed in case of tunnel segmentation). To announce the PTA, we don't need to attach the PTA (info) to the UMH routes (which could be a lot). A single I-PMSI or (*,*) S-PMSI can be used, or additional S-PMSI routes can also be used when more granularity is needed (e.g., some flows use some sub-domains while some other flows use some other subdomains). Thanks. Jeffrey _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
