Hi Jorge & Jim Thanks you for your responses. I am all set.
In summary this is exactly what I am looking for as are many other customers and the Gateway PE inter-working the the primary use case or other alternative is to stretch EVPN AFI/SAFI over the core and keep EVPN & IVPN separate. As you said as more customers start moving to EVPN and start using the inter-working features a composite PE may become more popular down the road. Kind regards, Gyan On Thu, Mar 26, 2020 at 5:11 AM Rabadan, Jorge (Nokia - US/Mountain View) < [email protected]> wrote: > Hi Gyan, > > > > In-line, please. > > Thanks, > > Jorge > > > > *From: *Gyan Mishra <[email protected]> > *Date: *Thursday, March 26, 2020 at 8:50 AM > *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <[email protected] > > > *Cc: *BESS <[email protected]>, "UTTARO, JAMES" <[email protected]> > *Subject: *Re: [bess] vxlan evpn and L3 vpn interworking standard > > > > > > Hi Jorge > > > > Thank you for the correction I did mean type 2 so that’s good the host > routes can be blocked. > > > > What are your thoughts on the placement of the gateway or composite PE > inter-working function on the core or DC side? > > [Jorge] as you can see we wrote procedures for the gateway and composite > cases, and even for the gateway+composite case. With those three cases I > think we can address most use-cases. My thoughts? Today I mostly see the > gateway use-case, where the gateway function is placed into the DCGW. Jim > was also showing his use-case, that it uses gateways connecting the EVPN > domains into the ipvpn one. But as more features are added to EVPN, I can > see evpn and ipvpn PEs in the same domain and the composite function being > used more and more. > > > > Understood on eve BGP LU tunnel to stitch the domain together so it’s > contiguous. Could you also just extend and overlay the BGP EVPN AFI/SAFI > over the MPLS core domains as an option for DCI. > > [Jorge] yup > > > > Thanks > > > > Gyan > > > > On Thu, Mar 26, 2020 at 3:22 AM Rabadan, Jorge (Nokia - US/Mountain View) < > [email protected]> wrote: > > Hi Gyan, > > > > “Is it possible in either gateway or composite PE interworking function > that we can only export out the type 5 routes and block the type 4 host > routes from being exported into IPVPN. In most all cases there would be a > L3 VNI tenant VRF prefix which would be represented by the Type 5 which is > sufficient of reachability. “ > > > > I think you mean EVPN type 2 routes. Yes, you should be able to do that. > > > > “I did notice at the bottom of page 6 & top of page 7 single domain > scenario depicted. I was curious to understand in that scenario how does > BGP-LU come into play??” > > > > Note that a “domain” is defined as follows: “Two PEs are in the same > domain if they are attached to the same tenant and the packets between them > do not require a data path IP lookup (in the tenant space) in any > intermediate router.” In figure 3 we wanted to illustrate an example where > PE1 and PE2 belong to the same domain, no ip-lookups in between. For that, > you need to connect PE1 and PE2 by a tunnel that can cross different ASNs, > and BGP-LU can do that. > > > > Hope it helps. > > Thanks. > > Jorge > > > > > > *From: *BESS <[email protected]> on behalf of Gyan Mishra < > [email protected]> > *Date: *Wednesday, March 25, 2020 at 10:44 PM > *To: *"UTTARO, JAMES" <[email protected]> > *Cc: *BESS <[email protected]> > *Subject: *Re: [bess] vxlan evpn and L3 vpn interworking standard > > > > Hi Jim > > > > I read through the draft. This is exactly what I was looking for. So in > our scenario we would use the gateway PE option where we are exporting the > EVPN routes & importing VPNv4 & VPNv6 and vice versa and would use the "D > Path" attribute for loop avoidance between domains. Our DCI scenario would > be like your drawing depicted where our Data Center core "router server" > box that inter-connects all the PODs vxlan fabrics via BGP EVPN in the Data > Center - This box would act as the demark between the "DC" and "Core" and > would be the one doing the import/export "gateway PE" inter-working > function to the IPVPN PE for core to data center reachability.. > > > > I noticed in section 4.3 the aggregation of routes option as we would not > want the host routes to be propagated into IPVPN. > > > > In the ineterworking option if we wanted to extend each tenant VRF > natively 1-1 mapping into unique L3 VPN VRF or take all the EVPN tenant > VRFs ISF SAFI and import all into a single IPVPN VRF do we have that > flexibility to map as desired. Also if the Gateway PE was our DC route > server box and we wanted to extend to the core natively each tenant VRF > 1-1 mapping into different unique IPVPN VRFs - since this is now an > inter-AS LSP -exiting the DC to the PE the DC PE & Core PE would be acting > as "inter-as" ASBRs in that case and would have to do an inter-as opt > a,b,c,ab style. > > > > I think the tricky part is where the Demark "Gateway PE" resides -- on the > Core side or DC side. If it ends up being the DC box the DC to Core is > eBGP peering and then you would need to do inter-as L3 vpn option to extend > the LSP. However, if the "Gateway PE" function resides on the Core PE then > you would extend EVPN AFI to the core PE and then perform the gateway > function where now its iBGP in the core and use can use the core RR for > your LSP and now the edge inter-as LSP complexity does not occur. > > > > Is it possible in either gateway or composite PE interworking function > that we can only export out the type 5 routes and block the type 4 host > routes from being exported into IPVPN. In most all cases there would be a > L3 VNI tenant VRF prefix which would be represented by the Type 5 which is > sufficient of reachability. > > > > Our other scenario for DCI interconnect would be extending EVPN AFI/SAFI > over the mpls core. This scenario keeps IPVPN & EVPN separate. > > > > I did notice at the bottom of page 6 & top of page 7 single domain > scenario depicted. I was curious to understand in that scenario how does > BGP-LU come into play?? > > > > <-------------------------------------------------> > > BGP-LU > > <-------------------------------------------------> > > > > ASBR------------ASBR > > +------+ +------+ > > +-------------| | | |-------------+ > > PE1 +------+ +--+---+ PE2 > > +------+ DC1 | WAN | DC2 +------+ > > TS1-|IP-VRF| EVPN | | EVPN |IP-VRF|-TS2 > > +------+ ASBR ASBR +---+--+ > > | +------+ +------+ | > > +-------------| | | |-------------+ > > +------+ +------+ > > +--------------+ > > > > <--------------------DOMAIN-1---------------------> > > > > Kind regards > > > > Gyan > > Verizon > > Cell 301 502-1347 > > > > On Wed, Mar 25, 2020 at 8:16 AM UTTARO, JAMES <[email protected]> wrote: > > *Gyan,* > > > > * Does the attached slide correlate with your requirement? My > thoughts are that the interworking needs to support both intra WAN and WAN > connectivity to DCs.. The introduction of D-PATH is required to ensure that > a path p can traverse multiple signaling domains i.e EVPN<->L3VPN<->EVPN... > I would be interested in your use cases..* > > > > *Thanks,* > > * Jim Uttaro* > > > > *From:* BESS <[email protected]> *On Behalf Of *Gyan Mishra > *Sent:* Wednesday, March 25, 2020 1:37 AM > *To:* BESS <[email protected]> > *Subject:* [bess] vxlan evpn and L3 vpn interworking standard > > > > > Dear BESS, > > > > Does anyone know if this draft has been picked up in another draft or is > on its way to become standardized. Please provide data tracker if so. > > > > This is a much needed feature for operators for DC for mpls core > connectivity DCI extension. > > > > > https://datatracker.ietf.org/doc/draft-rabadan-sajassi-bess-evpn-ipvpn-interworking/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Drabadan-2Dsajassi-2Dbess-2Devpn-2Dipvpn-2Dinterworking_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=Q5Qb9X0Q_fH2abLb-9fPBNqCki_KBGPuOaZeJsigPGA&s=g_SDL98eh20_aja820tdFnjy-_G79Zekfvd3t5YTEoQ&e=> > > > > I see this draft is close to being published but is intra DC integration > with IP mpls vpn. I am not completely clear if the inter working function > by the draft above is completely picked up by this draft. > > > > > https://tools.ietf..org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-08 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Dinter-2Dsubnet-2Dforwarding-2D08&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=s7ZzB4JbPv3nYuoSx5Gy8Q&m=Q5Qb9X0Q_fH2abLb-9fPBNqCki_KBGPuOaZeJsigPGA&s=Bv-Oy0p0_u2EDBbejfuQYIoR8hOUinTQS0CF-Y_DpfU&e=> > > > > > > Kind regards > > > > Gyan > > Verizon > > cell 301 502-1347 > > > > Sent from my iPhone > > > > > -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: [email protected] > > > > > > -- > > Gyan Mishra > > Network Engineering & Technology > > Verizon > > Silver Spring, MD 20904 > > Phone: 301 502-1347 > > Email: [email protected] > > > > > -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: [email protected]
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
