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