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? 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. 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]
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
