Re: [bess] EVPN-VPWS Service Edge Gateway rev03

[Rabadan, Jorge (Nokia - US)]

Hi Sami,

Yes, I think there is a bit of hand-waving about the S-PE discovery and this DF 
election ☺ so clarification would be appreciated.
Also, if the ES is manually set, couldn’t the following work instead of the 
described text?:
- The S-PEs send an ES route for the configured ESI, with RT= ES-import RT
- The S-PEs run regular DF election that could be based on RFC7432, HRW or 
Preference (draft-rabadan-bess-evpn-pref-df) or any future algorithm. I don’t 
see why the DF election should be different than this.
- The DF S-PE also sends this AD per-ES route as you describe, including the 
RT= L2, L3 or EVPN overlay (or Jeffrey’s suggestion with I guess the VRF route 
import EC)
- Then the A-PEs reply with the “directed” AD per-EVI route, that is imported 
and replied by the S-PE with an AD per-EVI route.

If this is not the intend, please let me know.
Thank you.

Jorge

On 11/28/16, 6:58 PM, "Sami Boutros" 
> wrote:

Hi Jorge,

The ES is that case will be set manually by the operator for the group of 
service routers that are in the same redundancy group. Will make sure this 
clarification is in the next Rev.

Thanks,

Sami
From: "Rabadan, Jorge (Nokia - US)" 
>
Date: Saturday, November 26, 2016 at 3:44 AM
To: Sami Boutros >
Cc: "EXT Ali Sajassi (sajassi)" >, 
"Patrice Brissette (pbrisset)" >, 
Sami Boutros >, 
"bess@ietf.org" >
Subject: Re: EVPN-VPWS Service Edge Gateway rev03

Hi Sami,

Thank you.

I still fail to see this:
“The DF election between the service edge nodes will follow RFC 7432 using the 
per ES Ethernet AD route, however will use the HRW algorithm.”

RFC7432’s DF election is purely based on the ES route and not the per ES AD 
route. What do you mean with the sentence above? You don’t use the ES route 
whatsoever? How is the ESI value figured out?
IMHO those things are not straight forward to figure out just by reading the 
text.

Thanks.
Jorge



On 11/24/16, 10:14 PM, "Sami Boutros" 
> wrote:

Hi Jorge,

Sorry for the delay, I will be addressing the comments below in the next rev, 
and will be clarifying the DF election too.

The DF election between the service edge nodes will follow RFC 7432 using the 
per ES Ethernet AD route, however will use the HRW algorithm.

The election will be performed to decide on who will be the primary responding 
to the EVPN VPWS Ethernet AD routes imported by the service edge nodes from the 
access nodes by applying the HRW algorithm.

I will clarify the text to reflect the above.

Thanks,

Sami

On Nov 21, 2016, at 6:05 AM, Rabadan, Jorge (Nokia - US) 
> wrote:
Sami,
I looked at your Service Edge Gateway draft, and since my comments/questions 
were not addressed in rev 03, I’m resending our last exchange.
Besides the comments below (please see the thread from earlier this year), the 
most confusing part to me is still the multi-homing on the Service Edge nodes. 
After reading the text, still not sure if the intend is a DF election based out 
of the AD per-EVI routes or if the DF election follows regular RFC7432 
procedures. This is a blurry area in the draft and I would personally 
appreciate a clarification.
Thank you.
Jorge
On 4/8/16, 3:37 PM, "Rabadan, Jorge (Nokia - US)" 
> 
wrote:
Hi Sami,
As discussed, this is the email. The new comments are tagged as [JORGE2].
Please see in-line.
Thanks.
Jorge
--
From: Sami Boutros >
Date: Tuesday, October 20, 2015 at 5:39 AM
To: Jorge Rabadan 
>
Cc: "bess@ietf.org" >
Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
Hi Jorge,
--
Abstract
This document describes how a service node can dynamically terminate
EVPN virtual private wire transport service (VPWS) from access nodes
and offer Layer 2, Layer 3 and Ethernet VPN overlay services to
Customer edge devices connected to the access nodes. Service nodes
using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN
overlay services it can offer for the terminated EVPN VPWS transport
service. On an access node an operator can specify the L2 or L3 or
Ethernet VPN overlay service needed by the customer edge device
connected to the access node that will be transported over the EVPN-
  

Re: [bess] EVPN-VPWS Service Edge Gateway rev03

[Sami Boutros]

Hi Jorge,

The ES is that case will be set manually by the operator for the group of 
service routers that are in the same redundancy group. Will make sure this 
clarification is in the next Rev.

Thanks,

Sami
From: "Rabadan, Jorge (Nokia - US)" 
>
Date: Saturday, November 26, 2016 at 3:44 AM
To: Sami Boutros >
Cc: "EXT Ali Sajassi (sajassi)" >, 
"Patrice Brissette (pbrisset)" >, 
Sami Boutros >, 
"bess@ietf.org" >
Subject: Re: EVPN-VPWS Service Edge Gateway rev03

Hi Sami,

Thank you.

I still fail to see this:
“The DF election between the service edge nodes will follow RFC 7432 using the 
per ES Ethernet AD route, however will use the HRW algorithm.”

RFC7432’s DF election is purely based on the ES route and not the per ES AD 
route. What do you mean with the sentence above? You don’t use the ES route 
whatsoever? How is the ESI value figured out?
IMHO those things are not straight forward to figure out just by reading the 
text.

Thanks.
Jorge



On 11/24/16, 10:14 PM, "Sami Boutros" 
> wrote:

Hi Jorge,

Sorry for the delay, I will be addressing the comments below in the next rev, 
and will be clarifying the DF election too.

The DF election between the service edge nodes will follow RFC 7432 using the 
per ES Ethernet AD route, however will use the HRW algorithm.

The election will be performed to decide on who will be the primary responding 
to the EVPN VPWS Ethernet AD routes imported by the service edge nodes from the 
access nodes by applying the HRW algorithm.

I will clarify the text to reflect the above.

Thanks,

Sami

On Nov 21, 2016, at 6:05 AM, Rabadan, Jorge (Nokia - US) 
> wrote:
Sami,
I looked at your Service Edge Gateway draft, and since my comments/questions 
were not addressed in rev 03, I’m resending our last exchange.
Besides the comments below (please see the thread from earlier this year), the 
most confusing part to me is still the multi-homing on the Service Edge nodes. 
After reading the text, still not sure if the intend is a DF election based out 
of the AD per-EVI routes or if the DF election follows regular RFC7432 
procedures. This is a blurry area in the draft and I would personally 
appreciate a clarification.
Thank you.
Jorge
On 4/8/16, 3:37 PM, "Rabadan, Jorge (Nokia - US)" 
> 
wrote:
Hi Sami,
As discussed, this is the email. The new comments are tagged as [JORGE2].
Please see in-line.
Thanks.
Jorge
--
From: Sami Boutros >
Date: Tuesday, October 20, 2015 at 5:39 AM
To: Jorge Rabadan 
>
Cc: "bess@ietf.org" >
Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
Hi Jorge,
--
Abstract
This document describes how a service node can dynamically terminate
EVPN virtual private wire transport service (VPWS) from access nodes
and offer Layer 2, Layer 3 and Ethernet VPN overlay services to
Customer edge devices connected to the access nodes. Service nodes
using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN
overlay services it can offer for the terminated EVPN VPWS transport
service. On an access node an operator can specify the L2 or L3 or
Ethernet VPN overlay service needed by the customer edge device
connected to the access node that will be transported over the EVPN-
VPWS service between access node and service node.
/* [JORGE] it would be good to clearly state the benefit of doing this.
The main advantages that I see are service extension with single-side
provisioning (no need to provision new ACs at the service node). */
Sami: will update the abstract.
[JORGE2] I don’t see anything changed in rev 02 ;-)

1  Introduction
/* [JORGE] maybe this level of detail at the introduction is a bit
confusing. I think it would be better to state what the goal and
advantages are in the introduction and leave the details for the solution
description. */
Sami: will update.
[JORGE2] I don’t see anything changed in rev 02 ;-)

...
2.2  Scalability
(R2a) A single service node PE can be associated with many access
node PEs. The following requirements give a quantitative measure.
(R2b) A service node PE MUST support thousand(s) head-end connections
for a a given access node PE connecting to different overlay VRF
services on 

Re: [bess] EVPN-VPWS Service Edge Gateway rev03

[Rabadan, Jorge (Nokia - US)]

Hi Sami,

Thank you.

I still fail to see this:
“The DF election between the service edge nodes will follow RFC 7432 using the 
per ES Ethernet AD route, however will use the HRW algorithm.”

RFC7432’s DF election is purely based on the ES route and not the per ES AD 
route. What do you mean with the sentence above? You don’t use the ES route 
whatsoever? How is the ESI value figured out?
IMHO those things are not straight forward to figure out just by reading the 
text.

Thanks.
Jorge



On 11/24/16, 10:14 PM, "Sami Boutros" 
> wrote:

Hi Jorge,

Sorry for the delay, I will be addressing the comments below in the next rev, 
and will be clarifying the DF election too.

The DF election between the service edge nodes will follow RFC 7432 using the 
per ES Ethernet AD route, however will use the HRW algorithm.

The election will be performed to decide on who will be the primary responding 
to the EVPN VPWS Ethernet AD routes imported by the service edge nodes from the 
access nodes by applying the HRW algorithm.

I will clarify the text to reflect the above.

Thanks,

Sami

On Nov 21, 2016, at 6:05 AM, Rabadan, Jorge (Nokia - US) 
> wrote:
Sami,
I looked at your Service Edge Gateway draft, and since my comments/questions 
were not addressed in rev 03, I’m resending our last exchange.
Besides the comments below (please see the thread from earlier this year), the 
most confusing part to me is still the multi-homing on the Service Edge nodes. 
After reading the text, still not sure if the intend is a DF election based out 
of the AD per-EVI routes or if the DF election follows regular RFC7432 
procedures. This is a blurry area in the draft and I would personally 
appreciate a clarification.
Thank you.
Jorge
On 4/8/16, 3:37 PM, "Rabadan, Jorge (Nokia - US)" 
> 
wrote:
Hi Sami,
As discussed, this is the email. The new comments are tagged as [JORGE2].
Please see in-line.
Thanks.
Jorge
--
From: Sami Boutros >
Date: Tuesday, October 20, 2015 at 5:39 AM
To: Jorge Rabadan 
>
Cc: "bess@ietf.org" >
Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
Hi Jorge,
--
Abstract
This document describes how a service node can dynamically terminate
EVPN virtual private wire transport service (VPWS) from access nodes
and offer Layer 2, Layer 3 and Ethernet VPN overlay services to
Customer edge devices connected to the access nodes. Service nodes
using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN
overlay services it can offer for the terminated EVPN VPWS transport
service. On an access node an operator can specify the L2 or L3 or
Ethernet VPN overlay service needed by the customer edge device
connected to the access node that will be transported over the EVPN-
VPWS service between access node and service node.
/* [JORGE] it would be good to clearly state the benefit of doing this.
The main advantages that I see are service extension with single-side
provisioning (no need to provision new ACs at the service node). */
Sami: will update the abstract.
[JORGE2] I don’t see anything changed in rev 02 ;-)

1  Introduction
/* [JORGE] maybe this level of detail at the introduction is a bit
confusing. I think it would be better to state what the goal and
advantages are in the introduction and leave the details for the solution
description. */
Sami: will update.
[JORGE2] I don’t see anything changed in rev 02 ;-)

...
2.2  Scalability
(R2a) A single service node PE can be associated with many access
node PEs. The following requirements give a quantitative measure.
(R2b) A service node PE MUST support thousand(s) head-end connections
for a a given access node PE connecting to different overlay VRF
services on that service node.
(R2c) A service node PE MUST support thousand(s) head-end connections
to many access node PEs.
/* [JORGE] It is hard to understand... should the following be better?:
“ (R2b) A service node PE MUST support head-end functionality for
thousands of access node PEs that are connected to different VRFs on the
service node.
   (R2c) A service node PE MUST support thousands of CE
connections through the attached access nodes."
*/
Sami: will update.
[JORGE2] I don’t see anything changed in rev 02 ;-)
2.5 Multi-homing
TBD
/* [JORGE] The solution should describe how to handle multi-homing at two
levels:
- Access node multi-homed to 2 or more Service nodes
- CE node multi-homed to 2 or more access nodes (this one should be
aligned with the EVPN-VPWS 

Re: [bess] EVPN-VPWS Service Edge Gateway rev03

[Martin Vigoureux]

sent to list as admin. message had bounced.
--- Begin Message ---
Hi Jorge,

Sorry for the delay, I will be addressing the comments below in the next rev, 
and will be clarifying the DF election too.

The DF election between the service edge nodes will follow RFC 7432 using the 
per ES Ethernet AD route, however will use the HRW algorithm.

The election will be performed to decide on who will be the primary responding 
to the EVPN VPWS Ethernet AD routes imported by the service edge nodes from the 
access nodes by applying the HRW algorithm.

I will clarify the text to reflect the above.

Thanks,

Sami

> On Nov 21, 2016, at 6:05 AM, Rabadan, Jorge (Nokia - US) 
>  wrote:
> 
> Sami,
> 
> I looked at your Service Edge Gateway draft, and since my comments/questions 
> were not addressed in rev 03, I’m resending our last exchange.
> Besides the comments below (please see the thread from earlier this year), 
> the most confusing part to me is still the multi-homing on the Service Edge 
> nodes. After reading the text, still not sure if the intend is a DF election 
> based out of the AD per-EVI routes or if the DF election follows regular 
> RFC7432 procedures. This is a blurry area in the draft and I would personally 
> appreciate a clarification.
> 
> Thank you.
> Jorge
> 
> 
> 
> On 4/8/16, 3:37 PM, "Rabadan, Jorge (Nokia - US)" 
>  wrote:
> 
> Hi Sami,
> 
> As discussed, this is the email. The new comments are tagged as [JORGE2].
> Please see in-line.
> Thanks.
> Jorge
> 
> 
> 
> --
> From: Sami Boutros 
> Date: Tuesday, October 20, 2015 at 5:39 AM
> To: Jorge Rabadan 
> Cc: "bess@ietf.org" 
> Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
> 
> 
> Hi Jorge,
> 
> 
> 
> --
> 
> 
> Abstract
> 
>This document describes how a service node can dynamically terminate
>EVPN virtual private wire transport service (VPWS) from access nodes
>and offer Layer 2, Layer 3 and Ethernet VPN overlay services to
>Customer edge devices connected to the access nodes. Service nodes
>using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN
>overlay services it can offer for the terminated EVPN VPWS transport
>service. On an access node an operator can specify the L2 or L3 or
>Ethernet VPN overlay service needed by the customer edge device
>connected to the access node that will be transported over the EVPN-
>VPWS service between access node and service node.
> 
> /* [JORGE] it would be good to clearly state the benefit of doing this.
> The main advantages that I see are service extension with single-side
> provisioning (no need to provision new ACs at the service node). */
> 
> 
> 
> 
> Sami: will update the abstract. 
> [JORGE2] I don’t see anything changed in rev 02 ;-)
> 
> 
> 
> 
> 
> 1  Introduction
> 
> 
> /* [JORGE] maybe this level of detail at the introduction is a bit
> confusing. I think it would be better to state what the goal and
> advantages are in the introduction and leave the details for the solution
> description. */
> 
> Sami: will update.
> [JORGE2] I don’t see anything changed in rev 02 ;-)
> 
> 
> ...
> 2.2  Scalability
> 
>(R2a) A single service node PE can be associated with many access
>node PEs. The following requirements give a quantitative measure.
> 
>(R2b) A service node PE MUST support thousand(s) head-end connections
>for a a given access node PE connecting to different overlay VRF
>services on that service node.
> 
>(R2c) A service node PE MUST support thousand(s) head-end connections
>to many access node PEs.
> 
> 
> /* [JORGE] It is hard to understand... should the following be better?:
> 
> “ (R2b) A service node PE MUST support head-end functionality for
> thousands of access node PEs that are connected to different VRFs on the
> service node.
>   (R2c) A service node PE MUST support thousands of CE
> connections through the attached access nodes."
> */
> 
> 
> Sami: will update. 
> [JORGE2] I don’t see anything changed in rev 02 ;-)
> 
> 
> 2.5 Multi-homing
> 
>TBD
> 
> /* [JORGE] The solution should describe how to handle multi-homing at two
> levels:
> - Access node multi-homed to 2 or more Service nodes
> - CE node multi-homed to 2 or more access nodes (this one should be
> aligned with the EVPN-VPWS draft)
> */
> 
> Sami: Please have a look at the updated section in 01, as for the CE node 
> agreed that it should be aligned with EVPN-VPWS, and hence no need to mention 
> anything about it in the draft.
> 
> [JORGE2] OK, please see below.
> 
> 
> 
> 
> 
> 4 Solution Overview
> 
> 
>+-+ +-+
>| | | |
>   ++   +-+ | IP/MPLS | +-+ | 

[bess] EVPN-VPWS Service Edge Gateway rev03

[Martin Vigoureux]

sent to list as admin. message had bounced.
--- Begin Message ---
Sami,

I looked at your Service Edge Gateway draft, and since my comments/questions 
were not addressed in rev 03, I’m resending our last exchange.
Besides the comments below (please see the thread from earlier this year), the 
most confusing part to me is still the multi-homing on the Service Edge nodes. 
After reading the text, still not sure if the intend is a DF election based out 
of the AD per-EVI routes or if the DF election follows regular RFC7432 
procedures. This is a blurry area in the draft and I would personally 
appreciate a clarification.

Thank you.
Jorge



On 4/8/16, 3:37 PM, "Rabadan, Jorge (Nokia - US)" 
 wrote:

Hi Sami,

As discussed, this is the email. The new comments are tagged as [JORGE2].
Please see in-line.
Thanks.
Jorge



--
From: Sami Boutros 
Date: Tuesday, October 20, 2015 at 5:39 AM
To: Jorge Rabadan 
Cc: "bess@ietf.org" 
Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway


Hi Jorge,



--


Abstract

   This document describes how a service node can dynamically terminate
   EVPN virtual private wire transport service (VPWS) from access nodes
   and offer Layer 2, Layer 3 and Ethernet VPN overlay services to
   Customer edge devices connected to the access nodes. Service nodes
   using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN
   overlay services it can offer for the terminated EVPN VPWS transport
   service. On an access node an operator can specify the L2 or L3 or
   Ethernet VPN overlay service needed by the customer edge device
   connected to the access node that will be transported over the EVPN-
   VPWS service between access node and service node.

/* [JORGE] it would be good to clearly state the benefit of doing this.
The main advantages that I see are service extension with single-side
provisioning (no need to provision new ACs at the service node). */




Sami: will update the abstract. 
[JORGE2] I don’t see anything changed in rev 02 ;-)





1  Introduction


/* [JORGE] maybe this level of detail at the introduction is a bit
confusing. I think it would be better to state what the goal and
advantages are in the introduction and leave the details for the solution
description. */

Sami: will update.
[JORGE2] I don’t see anything changed in rev 02 ;-)


...
2.2  Scalability

   (R2a) A single service node PE can be associated with many access
   node PEs. The following requirements give a quantitative measure.

   (R2b) A service node PE MUST support thousand(s) head-end connections
   for a a given access node PE connecting to different overlay VRF
   services on that service node.

   (R2c) A service node PE MUST support thousand(s) head-end connections
   to many access node PEs.


/* [JORGE] It is hard to understand... should the following be better?:

“ (R2b) A service node PE MUST support head-end functionality for
thousands of access node PEs that are connected to different VRFs on the
service node.
  (R2c) A service node PE MUST support thousands of CE
connections through the attached access nodes."
*/


Sami: will update. 
[JORGE2] I don’t see anything changed in rev 02 ;-)


2.5 Multi-homing

   TBD

/* [JORGE] The solution should describe how to handle multi-homing at two
levels:
- Access node multi-homed to 2 or more Service nodes
- CE node multi-homed to 2 or more access nodes (this one should be
aligned with the EVPN-VPWS draft)
*/

Sami: Please have a look at the updated section in 01, as for the CE node 
agreed that it should be aligned with EVPN-VPWS, and hence no need to mention 
anything about it in the draft.

[JORGE2] OK, please see below.





4 Solution Overview


   +-+ +-+
   | | | |
  ++   +-+ | IP/MPLS | +-+ | IP/MPLS |
  | CE |---| PE1 |-| Access  |-| PE2 |-| Core|
  ++   +-+ | Network | +-+ | Network |
   | | | |
   +-+ +-+
  < EVPN-VPWS >< IP/MAC VRF --->


   Figure 1: EVPN-VPWS Service Edge Gateway.
   AN: Access node
   SE: Service Edge node.

   EVPN-VPWS Service Edge Gateway Operation

/* [JORGE] Should this be section 4.1 on its own? */

Sami: sure will do.




   At the service edge node, the EVPN Per-EVI Ethernet A-D routes will
   be advertised with the ESI set to 0 and the Ethernet tag-id set to
   (wildcard 0xFFF). The Ethernet A-D routes will have a unique RD
   and will be associated with 2 BGP RT(s), one RT corresponding to the
   underlay EVI i.e. the EVPN VPWS transport service that's configured
   only among the service edge nodes, and one