From chensiyu27@huawei.com Sun Mar 17 19:01:15 2024 Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46138C14F5F3 for ; Sun, 17 Mar 2024 19:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.205 X-Spam-Level: X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 022WZrUT5sIU for ; Sun, 17 Mar 2024 19:01:10 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91E4C14F689 for ; Sun, 17 Mar 2024 19:01:10 -0700 (PDT) Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TydNq3svWz6K5m2 for ; Mon, 18 Mar 2024 10:00:43 +0800 (CST) Received: from lhrpeml100001.china.huawei.com (unknown [7.191.160.183]) by mail.maildlp.com (Postfix) with ESMTPS id C7C41140FF1 for ; Mon, 18 Mar 2024 10:01:07 +0800 (CST) Received: from dggpemd200001.china.huawei.com (7.185.36.224) by lhrpeml100001.china.huawei.com (7.191.160.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Mon, 18 Mar 2024 02:01:06 +0000 Received: from dggpemd500002.china.huawei.com (7.185.36.7) by dggpemd200001.china.huawei.com (7.185.36.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Mon, 18 Mar 2024 10:01:04 +0800 Received: from dggpemd500002.china.huawei.com ([7.185.36.7]) by dggpemd500002.china.huawei.com ([7.185.36.7]) with mapi id 15.02.1258.028; Mon, 18 Mar 2024 10:01:04 +0800 From: "Chensiyu (Susie)" To: "Jeffrey (Zhaohui) Zhang" , 'BESS' CC: duanfanghong , "Songbo (songbo, MULTICAST)" Thread-Topic: Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00 Thread-Index: Adoj/5EWRRJj0pHxTPy9WoO8XxGeAwEcUR2QFBmuQfA= Date: Mon, 18 Mar 2024 02:01:04 +0000 Message-ID: <51534dbb5738442ea8d6f119494d944e@huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.128.228] Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [bess] Comments about https://datatracker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00 X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2024 02:01:15 -0000 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-a= nd-ir/ Segmentation scenario will be updated later. Q2. Are we talking the same or different scenario? =20 We think I-PMSI tunnel is no longer needed and we'd like to construct S-PMS= I tunnel directly.=20 In your draft section-1.2.1, you still maintain the procedure of establishi= ng I-PMSI tunnel and then switch to S-PMSI tunnel without using s-pmsi ad a= nd leaf ad route. Q2. In order to merge type4/6/7, which way do we want to perform explicit t= racking? 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) b= ecause 'BGP update mechanism does not provide +ACI-explicit tracking+ACI-.'= (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 supp= orted in BIER and IR, so (S,G,RPT) flag can be set and used. Best wishes, Siyu -----Original Message----- From: Jeffrey (Zhaohui) Zhang +AFs-mailto:zzhang+AD0-40juniper.net+AEA-dmar= c.ietf.org+AF0-=20 Sent: Thursday, December 7, 2023 4:11 AM To: Chensiyu (Susie) +ADs- 'BESS'=20 Cc: duanfanghong=20 Subject: RE: Comments about https://datatracker.ietf.org/doc/html/draft-dua= n-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 selectiv= e 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 share= d tree across the provider network - Type 6/7: For (+ACo-,g) or (s,g) joins To compare against Rosen/PIM-MVPN: - Type-1 route is comparable to the static configuration of per-VPN group f= or the default MDT - Type-2 route is irrelevant because there is no concept of per-AS aggregat= ion 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 tun= nels - Type-5 is for the control plane based assert procedure and (s,g,rpt) prun= e - Type 6/7 is comparable for PIM (+ACo-,g)/(s,g) joins but w/o the explicit= tracking functionality Please see zzh+AD4- below. Juniper Business Use Only -----Original Message----- From: Chensiyu (Susie) Sent: Thursday, November 30, 2023 10:23 PM To: Jeffrey (Zhaohui) Zhang +ADs- 'BESS' Cc: duanfanghong Subject: RE: Comments about https://datatracker.ietf.org/doc/html/draft-dua= n-bess-simplified-mvpn-for-bier-and-ir-00 +AFs-External Email. Be cautious of content+AF0- Hi Jeffrey, Your summary about our method is great. I've also read your draft about exp= licit tracking. Explicit tracking is realized by our new procedure, but it'= s not the only goal we'd like to achieve. Zzh+AD4- 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 exi= sting type-6/7 routes and in draft-duan it is into a new route. The questio= n is, which way do we want to go for explicit tracking. Our goal is to provide the simplest MVPN signaling interaction when the tun= nel type is BIER or IR. Previous 8 routes are simplified to 2 routes. Zzh+AD4- 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+AD4- About +ACI-simplification of Type 1 to Type 4+ACI-, I don't think = your proposal handles segmentation and per-AS aggregation, so it is only ab= out +ACI-simplification of Type 1/3/4+ACI-. Specifically, the Type 1/3 func= tionality is folded into the UMH routes while the Type 4 functionality is f= olded into your new route type (a merge of Type 6/7 and Type 4). My previou= s email pointed out the issue with using UMH routes, and in draft-zzhang, t= he 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+AD4- My argument is that the solution in draft-zzhang is better. Zzh+AD4- Now about +ACI-Simplification of Type 6 to Type 7 NLRI+ACI- - it's= basically the explicit tracking plus (s,g,rpt) prune. We talked about expl= icit 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 route= s and exchanging procedures are designed based on BGP because BGP is widely= deployed. Zzh+AD4- draft-zzhang covers many different use cases with different soluti= ons. In case of BIER/IR tunnel, it extends Type-6/7 routes with explicit tr= acking and removes the need for type-3 route. With that, it achieves the sa= me goals you listed above except the (s,g,rpt) prune. Zzh+AD4- 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 work= ing on solution for tunnel segmentation scenario and it will be updated in = later version. Zzh+AD4- As explained above, I don't agree that your draft focus on differe= nt 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+AD4- Jeffrey Best wishes, Siyu -----Original Message----- From: Jeffrey (Zhaohui) Zhang +AFs-mailto:zzhang+AD0-40juniper.net+AEA-dmar= c.ietf.org+AF0- Sent: Friday, November 10, 2023 9:59 PM To: Chensiyu (Susie) +ADs- 'BESS' Subject: RE: Comments about https://urldefense.com/v3/+AF8AXw-https://datat= racker.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bie+AF8AXwA7AC= EAIQ-NEt6yMaO-gk+ACE-C-8cQW0OFpih26MIPj-4DM-0r9gcgqIlrU-xeWnnIqr1ZxgCb1ye7x= x+AF8-umTLp4nBpJZMD13OaK-9faUF0-gtnV660i89wRT7+ACQ- r-and-ir-00 Actually, we don't need the extended community even in the case of tunnel s= egmentation, because the C-multicast route used for explicit tracking purpo= ses should not be sent to the UMH but to the local upstream segmentation po= int (and the next hop of the route would not change so it can be used to id= entify 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 th= ey're just unicast routes not MVPN routes. The existing x-PMSI route proced= ures 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) +ADw-chensiyu27+AD0-40huawei.com+AEA-dmarc.ietf.org+AD= 4AOw- 'BESS' +ADw-bess+AEA-ietf.org+AD4- Subject: Comments about https://urldefense.com/v3/+AF8AXw-https://datatrack= er.ietf.org/doc/html/draft-duan-bess-simplified-mvpn-for-bier-and-ir-00+AF8= AXwA7ACEAIQ-NEt6yMaO-gk+ACE-C-8cQW0OFpih26MIPj-4DM-0r9gcgqIlrU-xeWnnIqr1Zxg= Cb1ye7xx+AF8-umTLp4nBpJZMD13OaK-9faUF0-gtnV660mxN9-rT+ACQ- 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/B= IER, 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 Lea= f route, for leaf tracking purposes For leaf tracking purposes, an alternative is also proposed in https://urld= efense.com/v3/+AF8AXw-https://datatracker.ietf.org/doc/html/draft-zzhang-be= ss-mvpn-evpn-cmcast-enhancements-01+ACo-section-1.2.1+AF8AXwA7-Iw+ACEAIQ-NE= t6yMaO-gk+ACE-C-8cQW0OFpih26MIPj-4DM-0r9gcgqIlrU-xeWnnIqr1ZxgCb1ye7xx+AF8-u= mTLp4nBpJZMD13OaK-9faUF0-gtnV660pidHM8N+ACQ- . Notice that the (C-+ACo-,C-G-BIDIR) C-Multicast routes from different PE= s 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 l= eaf 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 sin= gle 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 comm= unity is only needed in case of tunnel segmentation). To announce the PTA, we don't need to attach the PTA (info) to the UMH rout= es (which could be a lot). A single I-PMSI or (+ACo-,+ACo-) S-PMSI can be u= sed, 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 so= me other subdomains). Thanks. Jeffrey