Subject: [bess] About draft-wang-bess-l3-accessible-evpn

From: "Wei Wang" <[email-masked]>
Date: Fri, 12 Mar 2021 16:13:59 +0800

Hi Linda and Jorge,
&nbsp; &nbsp; Thanks for your comments at IETF110 meeting, and I think I need to explain our considerations for the newly defined LSI (Logical Session Identifier) concept.

Question 1, from Linda Dunbar, "Is the usage of LSI same as the RD for VPN route distinguish?"
Answer: LSI(Logical Session Identifier) is mainly used for distinguishing the different logical sessions between CE and PE device. Such session can be established via Vxlan, IPsec, or other tunnel technologies that can span layer 3 network.&nbsp;
The LSI information should be transferred via the control plane and forwarding plane. In control plane, we try to use Ethernet Tag ID/newly defined ESI type to transfer, its purpose is to further distinguish the cusomer routes within one provider VRF. In forwarding plane, this information should be inserted into some place of the exising VxLAN encoding, as proposed in our draft:https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.1

Question 2, from Jorge Rabadan. "The ESI shouldn't be used to distinguish the route-type 5, it is mainly used for multi-homing purpose"
Answer: Currently, we are considering using two methods to identify the routes that associated different LSI:
&nbsp; &nbsp; &nbsp; &nbsp;Method 1: Ethernet Tag ID, which is similar with its usage in layer 2 vlan environment.
&nbsp; &nbsp; &nbsp; &nbsp;Method 2: Newly defined ESI type(type 6)

&nbsp; &nbsp; We think both methods are approachable:
&nbsp; &nbsp; Method 1 requires also the update of https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11(Ethernet Tag ID is set to 0 for route type 5), may arises some confuse with its original defintion.
&nbsp; &nbsp; Method 2 requires the extension of ESI type (as described in: https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.2). The original purpose of ESI (mulit-homing) can also be preserved.

&nbsp; &nbsp;&nbsp;I hope the above explanations help.
&nbsp; &nbsp; Comments and questions are always welcome.

Best Regards,
Wei
China Telecom

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 12 Mar 2021 09:55:08 +0000

Hi Wei,

Thanks for taking the time to reply.

The ESI type was conceived in RFC7432 to specify the format of the remaining 9 bytes and produce unique ESIs, in the case auto-derived ESIs and manual ESIs had to coexist in the same network.
Irrespective, on reception of the EVPN routes with non-zero ESI some implementations just compare the 10-byte identifier and process EVPN routes accordingly, including routes type 5. Using the ESI in this context will create an unnecessary number of interop issues. At least the Ethernet Tag ID would have no such issues.

My other comment would be that, when we created the IP Prefix route, we added the Ethernet Tag ID so that user groups could be created within the same IP-VRF, but ultimately we found no use case for it and left it at zero in all the cases in the IP Prefix advertisement draft.

I personally still think it is better and simpler to create a separate IP-VRF and VNI (or identifier) for each user group as people do today, rather than an ‘LSI’ per group withing the IP-VRF. With separate IP-VRFs:

  *   the data path is simpler (no need for a second lookup that is not supported by current chipsets), and
  *   you can still use all the BGP route dissemination tools that are based on route-targets.

I don’t see any benefit in the solution you are suggesting, but of course I may miss a lot of things.
Thanks.
Jorge

From: Wei Wang <[email-masked]>
Date: Friday, March 12, 2021 at 9:14 AM
To: linda.dunbar <[email-masked]>, Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>
Cc: bess <[email-masked]>
Subject: [bess] About draft-wang-bess-l3-accessible-evpn
Hi Linda and Jorge,
    Thanks for your comments at IETF110 meeting, and I think I need to explain our considerations for the newly defined LSI (Logical Session Identifier) concept.

Question 1, from Linda Dunbar, "Is the usage of LSI same as the RD for VPN route distinguish?"
Answer: LSI(Logical Session Identifier) is mainly used for distinguishing the different logical sessions between CE and PE device. Such session can be established via Vxlan, IPsec, or other tunnel technologies that can span layer 3 network.
The LSI information should be transferred via the control plane and forwarding plane. In control plane, we try to use Ethernet Tag ID/newly defined ESI type to transfer, its purpose is to further distinguish the cusomer routes within one provider VRF. In forwarding plane, this information should be inserted into some place of the exising VxLAN encoding, as proposed in our draft:https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.1

Question 2, from Jorge Rabadan. "The ESI shouldn't be used to distinguish the route-type 5, it is mainly used for multi-homing purpose"
Answer: Currently, we are considering using two methods to identify the routes that associated different LSI:
       Method 1: Ethernet Tag ID, which is similar with its usage in layer 2 vlan environment.
       Method 2: Newly defined ESI type(type 6)

    We think both methods are approachable:
    Method 1 requires also the update of https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11(Ethernet Tag ID is set to 0 for route type 5), may arises some confuse with its original defintion.
    Method 2 requires the extension of ESI type (as described in: https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.2). The original purpose of ESI (mulit-homing) can also be preserved.

    I hope the above explanations help.
    Comments and questions are always welcome.

Best Regards,
Wei
China Telecom

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Fri, 12 Mar 2021 19:49:31 +0000

Hi Wei,

On my side, I don’t understand the problem statement.
Would it be possible to clarify that aspect? The draft seems to provide a solution but there is no explicit text about the what you are trying to solve.
Regards,
Patrice Brissette, Principal Engineer
Cisco Systems

http://e-vpn.io
http://go2.cisco.com/evpn

From: BESS <[email-masked]> on behalf of Wei Wang <[email-masked]>
Date: Friday, March 12, 2021 at 03:14
To: "linda.dunbar" <[email-masked]>, "jorge.rabadan" <[email-masked]>
Cc: bess <[email-masked]>
Subject: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Linda and Jorge,

Best Regards,
Wei
China Telecom

---

From: "Fomin, Sergey (Nokia - US/Mountain View)" <[email-masked]>
Date: Fri, 12 Mar 2021 22:06:06 +0000

Hi Wei,

This draft presents a peculiar way of bringing something similar to bridge-domain/bridge-table concepts into IP-VRFs..

One significant problem, in my opinion, is that you not only introduce a new dataplane dependency; but also propose to _redefine_ VXLAN-GPE header semantics (instead of just using it, or GENEVE). I would assume you have to go to nvo3 WG for the proposed VXLAN-GPE format changes (either with the full draft or splitting it into 2 parts (control & data plane)).

Additionally, I would like to see more text on the motivation of the proposed solution. In the abstract you make a point that “This draft … proposes a new solution which can simplify the deployment of layer-3 accessible EVPN service.” -> this simplicity is not obvious at all, and one may argue that this solution is more complex compared to the existing ones (such as draft inter-subnet-forwarding with multiple IP-VRFs)

--
Sergey

From: BESS <[email-masked]> On Behalf Of Wei Wang
Sent: Friday, March 12, 2021 12:14 AM
To: linda.dunbar <[email-masked]>; jorge.rabadan <[email-masked]>
Cc: bess <[email-masked]>
Subject: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Linda and Jorge,

Best Regards,
Wei
China Telecom

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 13 Mar 2021 21:18:30 -0500

Dear Authors

I am trying to understand the purpose of this document.

Is the goal for EVPN to be L3 accessible?

The way this has been done the past in a DC fabric environment using EVPN
ESI single or all active multi home is from the DC fabric  from the Border
leaf or Border spine that terminates the NVO3 overlay
vxlan/vxlan-gpe/Geneve the DC core L3 box for DCI inter connect can act as
a “fusion” router and terminate both tenant VRF and underlay peer and fuse
the VRF overlay and global table underlay routing to provide access between
overlay and underlay as well as external L3 reachability out of the
fabric.  All the Type-2 Mac-IP and Type-5 prefix can be converted imported
as IPv4 AFI SAFI-1 so the Type-2 in SAFI-1 BGP RIB as host route and Type-5
shows as subnet prefix.

I am not sure if that is what you are trying to accomplish?

If you are trying to achieve EVPN to IPVPN interworking see draft below:

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

DCI EVPN overlay

https://tools.ietf.org/html/draft-ietf-bess-dci-evpn-overlay-10

Kind Regards

Gyan

On Fri, Mar 12, 2021 at 5:06 PM Fomin, Sergey (Nokia - US/Mountain View) <
[email-masked]> wrote:

> Hi Wei,
>
>
>
> This draft presents a peculiar way of bringing something similar to
> bridge-domain/bridge-table concepts into IP-VRFs..
>
>
>
> One significant problem, in my opinion, is that you not only introduce a
> new dataplane dependency; but also propose to _*redefine*_ VXLAN-GPE
> header semantics (instead of just using it, or GENEVE). I would assume you
> have to go to nvo3 WG for the proposed VXLAN-GPE format changes (either
> with the full draft or splitting it into 2 parts (control & data plane)).
>
>
>
> Additionally, I would like to see more text on the motivation of the
> proposed solution. In the abstract you make a point that “*This draft …
> proposes a new solution which can simplify the deployment of layer-3
> accessible EVPN service*.” -> this simplicity is not obvious at all, and
> one may argue that this solution is more complex compared to the existing
> ones (such as draft inter-subnet-forwarding with multiple IP-VRFs)
>
>
>
> --
>
> Sergey
>
>
>
> *From:* BESS <[email-masked]> *On Behalf Of * Wei Wang
> *Sent:* Friday, March 12, 2021 12:14 AM
> *To:* linda.dunbar <[email-masked]>; jorge.rabadan <
> [email-masked]>
> *Cc:* bess <[email-masked]>
> *Subject:* [bess] About draft-wang-bess-l3-accessible-evpn
>
>
>
> Hi Linda and Jorge,
>
>     Thanks for your comments at IETF110 meeting, and I think I need to
> explain our considerations for the newly defined LSI (Logical Session
> Identifier) concept.
>
>
>
> Answer: LSI(Logical Session Identifier) is mainly used for distinguishing
> the different logical sessions between CE and PE device. Such session can
> be established via Vxlan, IPsec, or other tunnel technologies that can span
> layer 3 network.
>
> The LSI information should be transferred via the control plane and
> forwarding plane. In control plane, we try to use Ethernet Tag ID/newly
> defined ESI type to transfer, its purpose is to further distinguish the
> cusomer routes within one provider VRF. In forwarding plane, this
> information should be inserted into some place of the exising VxLAN
> encoding, as proposed in our draft:
> https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.1
>
>
>
> Question 2, from Jorge Rabadan. "The ESI shouldn't be used to distinguish
> the route-type 5, it is mainly used for multi-homing purpose"
>
>     Method 1 requires also the update of
> https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11(Ethernet
> Tag ID is set to 0 for route type 5), may arises some confuse with its
> original defintion.
>
>     Method 2 requires the extension of ESI type (as described in:
> https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#section-6.2).
> The original purpose of ESI (mulit-homing) can also be preserved.
>
>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 16 Mar 2021 11:41:56 +0800

Hi, Jorge:

Thanks for your comments, please see detail replies inline.

Wish to hear more suggestions from you.

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Rabadan,
Jorge (Nokia - US/Mountain View)
Sent: Friday, March 12, 2021 5:55 PM
To: Wei Wang <[email-masked]>; linda.dunbar
<[email-masked]>
Cc: bess <[email-masked]>
Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Wei,

The ESI type was conceived in RFC7432 to specify the format of the remaining
9 bytes and produce unique ESIs, in the case auto-derived ESIs and manual
ESIs had to coexist in the same network.

Irrespective, on reception of the EVPN routes with non-zero ESI some
implementations just compare the 10-byte identifier and process EVPN routes
accordingly, including routes type 5. 

[WAJ] Should we require such implementation to follow the requirements of
the RFC?

Using the ESI in this context will create an unnecessary number of interop
issues. At least the Ethernet Tag ID would have no such issues.

[WAJ] Some implementations may also ignore the value of Ethernet Tag ID,
especially for the type-5 route. You have also mentioned this below.

My other comment would be that, when we created the IP Prefix route, we
added the Ethernet Tag ID so that user groups could be created within the
same IP-VRF, but ultimately we found no use case for it and left it at zero
in all the cases in the IP Prefix advertisement draft. 

[WAJ] Reusing the Ethernet Tag ID to classify the type-5 route is possible,
but I prefer to defining the new ESI type, because the new ESI type can
still preserve the "Multihoming Functions" , as described in RFC7432.

I personally still think it is better and simpler to create a separate
IP-VRF and VNI (or identifier) for each user group as people do today,
rather than an 'LSI' per group withing the IP-VRF. With separate IP-VRFs:

-   the data path is simpler (no need for a second lookup that is not
supported by current chipsets), and 

-   you can still use all the BGP route dissemination tools that are based
on route-targets.

I don't see any benefit in the solution you are suggesting, but of course I
may miss a lot of things.

[WAJ] Using separate IP-VRFs solution can accomplish the LSI-Based
Service(similar with VLAN-Based service) effect, but can't achieve the
LSI-Aware Service(similar with VLAN-aware service). The benefit of LSI-Aware
service is similar with the VLAN-Aware service, which it simplifies the
deployment of IP-VRF within the backbone network. The enhancement to the PE
device is necessary.

Thanks.

Jorge

From: Wei Wang <[email-masked] <mailto:[email-masked]> >
Date: Friday, March 12, 2021 at 9:14 AM
To: linda.dunbar <[email-masked]
<mailto:[email-masked]> >, Rabadan, Jorge (Nokia - US/Mountain
View) <[email-masked] <mailto:[email-masked]> >
Cc: bess <[email-masked] <mailto:[email-masked]> >
Subject: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Linda and Jorge,

Question 1, from Linda Dunbar, "Is the usage of LSI same as the RD for VPN
route distinguish?"

Answer: LSI(Logical Session Identifier) is mainly used for distinguishing
the different logical sessions between CE and PE device. Such session can be
established via Vxlan, IPsec, or other tunnel technologies that can span
layer 3 network. 

The LSI information should be transferred via the control plane and
forwarding plane. In control plane, we try to use Ethernet Tag ID/newly
defined ESI type to transfer, its purpose is to further distinguish the
cusomer routes within one provider VRF. In forwarding plane, this
information should be inserted into some place of the exising VxLAN
encoding, as proposed in our
draft:https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-ev
pn-04#section-6.1

Answer: Currently, we are considering using two methods to identify the
routes that associated different LSI:

       Method 1: Ethernet Tag ID, which is similar with its usage in layer 2
vlan environment.

    Method 1 requires also the update of
https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement-11(Eth
ernet Tag ID is set to 0 for route type 5), may arises some confuse with its
original defintion.

    Method 2 requires the extension of ESI type (as described in:
https://datatracker.ietf.org/doc/html/draft-wang-bess-l3-accessible-evpn-04#
section-6.2). The original purpose of ESI (mulit-homing) can also be
preserved.

Best Regards,

Wei

China Telecom

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 16 Mar 2021 06:53:39 +0000

Hi Aijun,

Thanks for replying.

Why do you want to “preserve the multi-homing functions” if the solution you are building has nothing to do with multi-homing?
Also why do you want to introduce a double lookup (based on VNI and then LSI) on the PE if the VNI gives you 16M different values and VNI lookup is something that all chipsets support?

Thanks.
Jorge

From: Aijun Wang <[email-masked]>
Date: Tuesday, March 16, 2021 at 4:42 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]>, 'Wei Wang' <[email-masked]>, 'linda.dunbar' <[email-masked]>
Cc: 'bess' <[email-masked]>
Subject: RE: [bess] About draft-wang-bess-l3-accessible-evpn
Hi, Jorge:

Best Regards

Aijun Wang
China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View)
Sent: Friday, March 12, 2021 5:55 PM
To: Wei Wang <[email-masked]>; linda.dunbar <[email-masked]>
Cc: bess <[email-masked]>
Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Wei,

The ESI type was conceived in RFC7432 to specify the format of the remaining 9 bytes and produce unique ESIs, in the case auto-derived ESIs and manual ESIs had to coexist in the same network.
Irrespective, on reception of the EVPN routes with non-zero ESI some implementations just compare the 10-byte identifier and process EVPN routes accordingly, including routes type 5.
[WAJ] Should we require such implementation to follow the requirements of the RFC?

Using the ESI in this context will create an unnecessary number of interop issues. At least the Ethernet Tag ID would have no such issues.
[WAJ] Some implementations may also ignore the value of Ethernet Tag ID, especially for the type-5 route. You have also mentioned this below.

My other comment would be that, when we created the IP Prefix route, we added the Ethernet Tag ID so that user groups could be created within the same IP-VRF, but ultimately we found no use case for it and left it at zero in all the cases in the IP Prefix advertisement draft.
[WAJ] Reusing the Ethernet Tag ID to classify the type-5 route is possible, but I prefer to defining the new ESI type, because the new ESI type can still preserve the “Multihoming Functions” , as described in RFC7432.

I personally still think it is better and simpler to create a separate IP-VRF and VNI (or identifier) for each user group as people do today, rather than an ‘LSI’ per group withing the IP-VRF. With separate IP-VRFs:
-    the data path is simpler (no need for a second lookup that is not supported by current chipsets), and
-    you can still use all the BGP route dissemination tools that are based on route-targets.

I don’t see any benefit in the solution you are suggesting, but of course I may miss a lot of things.
[WAJ] Using separate IP-VRFs solution can accomplish the LSI-Based Service(similar with VLAN-Based service) effect, but can’t achieve the LSI-Aware Service(similar with VLAN-aware service). The benefit of LSI-Aware service is similar with the VLAN-Aware service, which it simplifies the deployment of IP-VRF within the backbone network. The enhancement to the PE device is necessary.

Thanks.
Jorge

From: Wei Wang <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 12, 2021 at 9:14 AM
To: linda.dunbar <[email-masked]<mailto:[email-masked]>>, Rabadan, Jorge (Nokia - US/Mountain View) <[email-masked]<mailto:[email-masked]>>
Cc: bess <[email-masked]<mailto:[email-masked]>>
Subject: [bess] About draft-wang-bess-l3-accessible-evpn
Hi Linda and Jorge,
    Thanks for your comments at IETF110 meeting, and I think I need to explain our considerations for the newly defined LSI (Logical Session Identifier) concept.

Best Regards,
Wei
China Telecom

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 18 Mar 2021 09:22:01 +0800

Hi，Jorge:

From: [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> > On Behalf Of
Rabadan, Jorge (Nokia - US/Mountain View)
Sent: Tuesday, March 16, 2021 2:54 PM
To: Aijun Wang <[email-masked] <mailto:[email-masked]>
>; 'Wei Wang' <[email-masked] <mailto:[email-masked]> >;
'linda.dunbar' <[email-masked]
<mailto:[email-masked]> >
Cc: 'bess' <[email-masked] <mailto:[email-masked]> >
Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Aijun,

Thanks for replying.

Why do you want to “preserve the multi-homing functions” if the solution
you are building has nothing to do with multi-homing?

[WAJ] There are situations that ASBR in MAN(Metro-Area-Network) may
multi-homing to different PEs in Backbone. I think this is similar with the
CE multi-homing to PE in layer-2 environment.

Also why do you want to introduce a double lookup (based on VNI and then
LSI) on the PE if the VNI gives you 16M different values and VNI lookup is
something that all chipsets support? 

[WAJ] It is not applicable to deploy 16M VRFs within the backbone, even the
VNI field has the abundant space.  For implementation on device, I think the
double lookup is not necessary, just only find the right forwarding table
based on both the VNI and LSI value. 

Thanks.

Jorge

From: Aijun Wang < <mailto:[email-masked]>
[email-masked]>
Date: Tuesday, March 16, 2021 at 4:42 AM
To: Rabadan, Jorge (Nokia - US/Mountain View) < <mailto:jorge.rabadan@nokia.
com> [email-masked]>, 'Wei Wang' < <mailto:[email-masked]>
[email-masked]>, 'linda.dunbar' < <mailto:[email-masked]>
[email-masked]>
Cc: 'bess' < <mailto:[email-masked]> [email-masked]>
Subject: RE: [bess] About draft-wang-bess-l3-accessible-evpn

Hi, Jorge:

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <mailto:[email-masked]>
<[email-masked] <mailto:[email-masked]> > On Behalf Of
Rabadan, Jorge (Nokia - US/Mountain View)
Sent: Friday, March 12, 2021 5:55 PM
To: Wei Wang <[email-masked] <mailto:[email-masked]> >; linda.
dunbar <[email-masked] <mailto:[email-masked]> >
Cc: bess <[email-masked] <mailto:[email-masked]> >
Subject: Re: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Wei,

[WAJ] Reusing the Ethernet Tag ID to classify the type-5 route is possible,
but I prefer to defining the new ESI type, because the new ESI type can
still preserve the “Multihoming Functions” , as described in RFC7432.

I personally still think it is better and simpler to create a separate
IP-VRF and VNI (or identifier) for each user group as people do today,
rather than an ‘LSI’ per group withing the IP-VRF. With separate IP-VRFs:

I don’t see any benefit in the solution you are suggesting, but of course I
may miss a lot of things.

Service(similar with VLAN-Based service) effect, but can’t achieve the

Thanks.

Jorge

From: Wei Wang < <mailto:[email-masked]> [email-masked]>
Date: Friday, March 12, 2021 at 9:14 AM
To: linda.dunbar < <mailto:[email-masked]>
[email-masked]>, Rabadan, Jorge (Nokia - US/Mountain View) <
<mailto:[email-masked]> [email-masked]>
Cc: bess < <mailto:[email-masked]> [email-masked]>
Subject: [bess] About draft-wang-bess-l3-accessible-evpn

Hi Linda and Jorge,

Best Regards,

Wei

China Telecom