Hi Jeffrey, Sorry for our late response. Let me explain about each question below. Q1. Type 1 to 7's functions and simplification? We've uploaded a new version of draft and functions of each NLRIs has been modified. https://datatracker.ietf.org/doc/draft-duan-bess-simplified-mvpn-for-bier-and-ir/ Segmentation scenario will be updated later.
Q2. Are we talking the same or different scenario? We think I-PMSI tunnel is no longer needed and we'd like to construct S-PMSI tunnel directly. In your draft section-1.2.1, you still maintain the procedure of establishing I-PMSI tunnel and then switch to S-PMSI tunnel without using s-pmsi ad and leaf ad route. Q2. In order to merge type4/6/7, which way do we want to perform explicit tracking? Existing C-multicast route or new BGP route? The key difference between your and our method is that the parameters used to perform explicit tracking. You use distinct Route-distinguishers and we uses BIER PTA such as sub-domain, BFR-ID. For BIER and IR, explicit tracking is important because Ingress PE needs to distinguish different receiver sets of I-PMSI and S-PMSI. Different BitString or routable IR addresses can represent the difference, and they are all underlay tunnel parameters. We think PTA carried by leaf A-D route can be carried by the existed C-multicast route or creating a new BGP route. I think RDs cannot perform explicit tracking directly because transit nodes cannot recognize RD. Ingress PE needs to translate RDs into underlay. The translation still needs leaf PE to send their underlay BIER parameters by certain MVPN routes, such as C-multicast route. Q3. How to deal with (s,g,rpt) flag? We think RFC6513 and RFC6514 use Source-Active route to perform (S,G,RPT) because 'BGP update mechanism does not provide "explicit tracking".' (S,G,RPT)s from different leaf PEs will be merged into one so that root PE won't know specific leaf PEs. But explicit tracking will be naturally supported in BIER and IR, so (S,G,RPT) flag can be set and used. Best wishes, Siyu -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang=40juniper....@dmarc.ietf.org] Sent: Thursday, December 7, 2023 4:11 AM To: Chensiyu (Susie) ; 'BESS' Cc: duanfanghong Subject: RE: Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00 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
