Hi Wei Thanks for the clarification.
So this draft addresses situation where the VNI is not globally unique and so overlapping VNI name space in which case you allocate a VRF per customer. So with this draft you eliminate the resources overhead of 1-1 mapping VRF to Customer and with VSI analogous to ESI MAC VRF you can group customers based on criteria and group their Mac tables as sub tables into a common group VRF. How does that provide customers VRF type isolation requirements by customers? Thanks Gyan On Thu, Mar 18, 2021 at 3:36 AM Wei Wang <weiwan...@foxmail.com> wrote: > Hi Gyan, > > Thanks for your reply. Please see in-line [WW]. > > Best Regards, > Wei > ------------------ Original ------------------ > *From:* "Gyan Mishra" <hayabusa...@gmail.com>; > *Date:* Thu, Mar 18, 2021 09:27 AM > *To:* "Wei Wang"<weiwan...@foxmail.com>; > *Cc:* "Patrice Brissette (pbrisset)"<pbrisset=40cisco....@dmarc.ietf.org > >;"jorge.rabadan"<jorge.raba...@nokia.com>;"bess@ietf.org"<bess@ietf.org>;"Fomin, > Sergey (Nokia - US/Mountain View)"<sergey.fo...@nokia.com>; > *Subject:* Re: [bess] About draft-wang-bess-l3-accessible-evpn > > > Hi Wei > > If you are stretching EVPN DCI over SR or MPLS core and not doing any IP > VPN to EVPN gateway translation function, then you don’t need define any > VRFs on the PEs unless the PE is terminating the NVO3 overlay which usually > is not the case. > > The DCI core box border spine / border leaf / shared border box would > terminate the NVO3 tunnel within the DC. > [WW] Do you mean to build NVO3 tunnel directly between MSEs in different > MANs? It obviously works, but it requires VNIs in MAN1-3 to be globally > unique, and the scenario we are considering does not meet this requirement > (VNIs in MAN1-3 are independently allocated, which may lead to the overlap > of VNI in different customer sites). > > Kind Regards > > Gyan > > On Tue, Mar 16, 2021 at 2:25 AM Wei Wang <weiwan...@foxmail.com> wrote: > >> Hi Gyan, Sergey, Patrice and Jorge, >> >> In fact, we are considering the following scenario: >> >> >> where Backbone is EVPN domain, and MAN1-3 are Layer-3 network. VNIs in >> MAN1-3 are independently allocated, which may lead to the overlap of VNI in >> different customer sites. >> >> If there are 3 customers who need cross domain networking: A, B, C. >> In general, we allocate 3 VNIs for the 3 customers in each MAN, and >> configure 3 VRFs on each PE to maintain the VPN routes of them. >> In our solution, we allocate one VNI for all customers in each MAN, and >> configure only one VRF on each PE, which can simplify the configuration >> work during deployment. On PEs, the VRF can be divided into 3 sub-tables >> according to LSI information to maintain the VPN routes of customers. >> >> To Gyan: in the two documents you mentioned, a device (Interworking PE / >> GW) is needed for routing conversion and redistribution, which is not >> needed in our solution. >> >> Best Regards, >> Wei >> China Telecom >> >> ------------------ Original ------------------ >> *From:* "Gyan Mishra" <hayabusa...@gmail.com>; >> *Date:* Sun, Mar 14, 2021 10:18 AM >> *To:* "Fomin, Sergey (Nokia - US/Mountain View)"<sergey.fo...@nokia.com>; >> *Cc:* "Wei Wang"<weiwan...@foxmail.com>;"bess"<bess@ietf.org>; >> *Subject:* Re: [bess] About draft-wang-bess-l3-accessible-evpn >> >> >> Dear Authors >> >> I am trying to understand the purpose of this document. >> >> Is the goal for EVPN to be L3 accessible? >> >> The way this has been done the past in a DC fabric environment using EVPN >> ESI single or all active multi home is from the DC fabric from the Border >> leaf or Border spine that terminates the NVO3 overlay >> vxlan/vxlan-gpe/Geneve the DC core L3 box for DCI inter connect can act as >> a “fusion” router and terminate both tenant VRF and underlay peer and fuse >> the VRF overlay and global table underlay routing to provide access between >> overlay and underlay as well as external L3 reachability out of the >> fabric. All the Type-2 Mac-IP and Type-5 prefix can be converted imported >> as IPv4 AFI SAFI-1 so the Type-2 in SAFI-1 BGP RIB as host route and Type-5 >> shows as subnet prefix. >> >> I am not sure if that is what you are trying to accomplish? >> >> >> If you are trying to achieve EVPN to IPVPN interworking see draft below: >> >> https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02 >> >> DCI EVPN overlay >> >> https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10 >> >> >> Kind Regards >> >> Gyan >> >> On Fri, Mar 12, 2021 at 5:06 PM Fomin, Sergey (Nokia - US/Mountain View) < >> sergey.fo...@nokia.com> wrote: >> >>> Hi Wei, >>> >>> >>> >>> This draft presents a peculiar way of bringing something similar to >>> bridge-domain/bridge-table concepts into IP-VRFs.. >>> >>> >>> >>> One significant problem, in my opinion, is that you not only introduce a >>> new dataplane dependency; but also propose to _*redefine*_ VXLAN-GPE >>> header semantics (instead of just using it, or GENEVE). I would assume you >>> have to go to nvo3 WG for the proposed VXLAN-GPE format changes (either >>> with the full draft or splitting it into 2 parts (control & data plane)). >>> >>> >>> >>> Additionally, I would like to see more text on the motivation of the >>> proposed solution. In the abstract you make a point that “*This draft … >>> proposes a new solution which can simplify the deployment of layer-3 >>> accessible EVPN service*.” -> this simplicity is not obvious at all, >>> and one may argue that this solution is more complex compared to the >>> existing ones (such as draft inter-subnet-forwarding with multiple IP-VRFs) >>> >>> >>> >>> -- >>> >>> Sergey >>> >>> >>> >>> *From:* BESS <bess-boun...@ietf.org> *On Behalf Of * Wei Wang >>> >> *Sent:* Friday, March 12, 2021 12:14 AM >>> *To:* linda.dunbar <linda.dun...@futurewei.com>; jorge.rabadan < >>> jorge.raba...@nokia.com> >>> *Cc:* bess <bess@ietf.org> >>> *Subject:* [bess] About draft-wang-bess-l3-accessible-evpn >>> >> >>> >>> Hi Linda and Jorge, >>> >> Thanks for your comments at IETF110 meeting, and I think I need to >>> explain our considerations for the newly defined LSI (Logical Session >>> Identifier) concept. >>> >>> >>> >>> Question 1, from Linda Dunbar, "Is the usage of LSI same as the RD for >>> VPN route distinguish?" >>> >>> Answer: LSI(Logical Session Identifier) is mainly used for >>> distinguishing the different logical sessions between CE and PE device. >>> Such session can be established via Vxlan, IPsec, or other tunnel >>> technologies that can span layer 3 network. >>> >>> The LSI information should be transferred via the control plane and >>> forwarding plane. In control plane, we try to use Ethernet Tag ID/newly >>> defined ESI type to transfer, its purpose is to further distinguish the >>> cusomer routes within one provider VRF. In forwarding plane, this >>> information should be inserted into some place of the exising VxLAN >>> encoding, as proposed in our draft: >>> https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.1 >>> >>> >>> >>> Question 2, from Jorge Rabadan. "The ESI shouldn't be used to >>> distinguish the route-type 5, it is mainly used for multi-homing purpose" >>> >>> Answer: Currently, we are considering using two methods to identify the >>> routes that associated different LSI: >>> >>> Method 1: Ethernet Tag ID, which is similar with its usage in >>> layer 2 vlan environment. >>> >>> Method 2: Newly defined ESI type(type 6) >>> >>> >>> >>> We think both methods are approachable: >>> >>> Method 1 requires also the update of >>> https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11(Ethernet >>> Tag ID is set to 0 for route type 5), may arises some confuse with its >>> original defintion. >>> >>> Method 2 requires the extension of ESI type (as described in: >>> https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.2). >>> The original purpose of ESI (mulit-homing) can also be preserved. >>> >>> >>> >>> I hope the above explanations help. >>> >>> Comments and questions are always welcome. >>> >>> >>> >>> Best Regards, >>> >>> Wei >>> >>> China Telecom >>> _______________________________________________ >>> BESS mailing list >>> BESS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bess >>> >> -- >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> >> >> *M 301 502-134713101 Columbia Pike >> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> >> *Silver Spring, MD >> >> _______________________________________________ >> BESS mailing list >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike > <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> > *Silver Spring, MD > > > ------------------------------ > Wei Wang > China Telecom > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
