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]<mailto:[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]<mailto:[email protected]>> on behalf of Gyan Mishra <[email protected]<mailto:[email protected]>> Date: Wednesday, March 25, 2020 at 10:44 PM To: "UTTARO, JAMES" <[email protected]<mailto:[email protected]>> Cc: BESS <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> On Behalf Of Gyan Mishra Sent: Wednesday, March 25, 2020 1:37 AM To: BESS <[email protected]<mailto:[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]<mailto:[email protected]> -- Gyan Mishra Network Engineering & Technology Verizon Silver Spring, MD 20904 Phone: 301 502-1347 Email: [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
