Subject: [bess] vxlan evpn and L3 vpn interworking standard

From: Gyan Mishra <[email-masked]>
Date: Wed, 25 Mar 2020 01:37:24 -0400

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/

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

Kind regards 

Gyan
Verizon 
cell 301 502-1347

Sent from my iPhone

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 25 Mar 2020 07:30:29 +0000

Hi Gyan,

The evpn ipvpn interworking draft was adopted as:

https://tools.ietf.org/html/draft-ietf-bess-evpn-ipvpn-interworking-02

Thx
Jorge

From: BESS <[email-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Wednesday, March 25, 2020 at 6:38 AM
To: BESS <[email-masked]>
Subject: [bess] vxlan evpn and L3 vpn interworking standard

Dear BESS,

https://tools.ietf..org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-08<https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-08>

Kind regards

Gyan
Verizon
cell 301 502-1347

Sent from my iPhone

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 25 Mar 2020 12:15:57 +0000

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-masked]> On Behalf Of Gyan Mishra
Sent: Wednesday, March 25, 2020 1:37 AM
To: BESS <[email-masked]>
Subject: [bess] vxlan evpn and L3 vpn interworking standard

Dear BESS,

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=>

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

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 25 Mar 2020 17:17:24 -0400

Thank you!!

Gyan

On Wed, Mar 25, 2020 at 3:30 AM Rabadan, Jorge (Nokia - US/Mountain View) <
[email-masked]> wrote:

> *From: *BESS <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Wednesday, March 25, 2020 at 6:38 AM
> *To: *BESS <[email-masked]>
> *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.
>
>
>
> 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://tools.ietf.org/html/draft-ietf-bess-evpn-inter-subnet-forwarding-08>
>
>
>
>
>
> 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-masked]

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 25 Mar 2020 17:42:14 -0400

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-masked]> 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-masked]> *On Behalf Of * Gyan Mishra
> *Sent:* Wednesday, March 25, 2020 1:37 AM
> *To:* BESS <[email-masked]>
> *Subject:* [bess] vxlan evpn and L3 vpn interworking standard
>
>
>
>
> Dear BESS,
>
>
>
> <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=>
>
>
>
> <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

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 26 Mar 2020 07:22:46 +0000

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-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Wednesday, March 25, 2020 at 10:44 PM
To: "UTTARO, JAMES" <[email-masked]>
Cc: BESS <[email-masked]>
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

                         +------+       +------+

           |             +------+       +------+             |

                         +------+       +------+

                            +--------------+

Kind regards

Gyan
Verizon
Cell 301 502-1347

On Wed, Mar 25, 2020 at 8:16 AM UTTARO, JAMES <[email-masked]<mailto:[email-masked]>> wrote:
Gyan,

Thanks,
              Jim Uttaro

From: BESS <[email-masked]<mailto:[email-masked]>> On Behalf Of Gyan Mishra
Sent: Wednesday, March 25, 2020 1:37 AM
To: BESS <[email-masked]<mailto:[email-masked]>>
Subject: [bess] vxlan evpn and L3 vpn interworking standard

Dear BESS,

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-masked]<mailto:[email-masked]>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 26 Mar 2020 03:50:44 -0400

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-masked]> 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 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
>
>
>
>
>
> *Date: *Wednesday, March 25, 2020 at 10:44 PM
> *To: *"UTTARO, JAMES" <[email-masked]>
> *Cc: *BESS <[email-masked]>
> *Subject: *Re: [bess] vxlan evpn and L3 vpn interworking standard
>
>
>
> Hi Jim
>
>
>
> function to the IPVPN PE for core to data center reachability..
>
>
>
> 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.
>
>
>
> 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
> 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??
>
>
>
> *From:* BESS <[email-masked]> *On Behalf Of *Gyan Mishra
-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 26 Mar 2020 09:11:35 +0000

Hi Gyan,

In-line, please.
Thanks,
Jorge

From: Gyan Mishra <[email-masked]>
Date: Thursday, March 26, 2020 at 8:50 AM
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Cc: BESS <[email-masked]>, "UTTARO, JAMES" <[email-masked]>
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-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Hope it helps.
Thanks.
Jorge

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 25, 2020 at 10:44 PM
To: "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Cc: BESS <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] vxlan evpn and L3 vpn interworking standard

Hi Jim

                                BGP-LU

                          ASBR------------ASBR

                         +------+       +------+

           |             +------+       +------+             |

                         +------+       +------+

                            +--------------+

Kind regards

Gyan
Verizon
Cell 301 502-1347

Thanks,
              Jim Uttaro

Dear BESS,

Kind regards

Gyan
Verizon
cell 301 502-1347

Sent from my iPhone

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 26 Mar 2020 18:14:05 -0400

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-masked]> wrote:

> Hi Gyan,
>
>
>
> In-line, please.
>
> Thanks,
>
> Jorge
>
>
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Thursday, March 26, 2020 at 8:50 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]
> >
> *Cc: *BESS <[email-masked]>, "UTTARO, JAMES" <[email-masked]>
> [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.
>
>
>

-- 

Gyan  Mishra

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347