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) < [email protected]> 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 <[email protected]> *On Behalf Of * Wei Wang > *Sent:* Friday, March 12, 2021 12:14 AM > *To:* linda.dunbar <[email protected]>; jorge.rabadan < > [email protected]> > *Cc:* bess <[email protected]> > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/bess > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
