Subject: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

From: Sami Boutros <[email-masked]>
Date: Wed, 7 Oct 2015 17:13:59 -0400

Hi,

The draft proposes a dynamic mechanism to terminate the VPWS transport
service at a service PE into an overlay L2 or L3 service based on a single
side provisioning at the access PE.

https://tools.ietf.org/html/draft-boutros-bess-evpn-vpws-service-edge-gateway-01

Thanks,

Sami

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 8 Oct 2015 08:01:58 +0000

Sami,

I already sent you a few comments for rev 0. 
I’ll paste them here (with /*[JORGE]*/) for this version too.
Thanks.
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). */

<snip>

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. */

<snip>
...

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 hundreds of thousands of CE
connections through the attached access nodes."
*/

<snip>

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)
*/

<snip>

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? */

   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 0xFFFFFFF). 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 corresponding to the L2,
   L3 or EVPN overlay service.

   At the access nodes, the EVPN per-EVI Ethernet A-D routes will be
   advertised as described in [draft-ietf-bess-evpn-vpws <https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws>] with the ESI
   field is set to 0 and for single homed CEs and to the CE's ESI for
   multi-homed CE's and the Ethernet Tag field will be set to the VPWS
   service instance identifier that identifies the EVPL or EPL service.
   The Ethernet-AD route will have a unique RD and will be associated
   with one BGP RT corresponding to the L2, L3 or EVPN overlay service
   that will be transported over this EVPN VPWS transport service.

/* [JORGE] What do you mean by EVPN overlay service in this context? why
is it different from L2 or L3 service? should this be clarified in the
introduction? 
Also by L2 and L3 are you referring to the encapsulation? i.e. L2 means
ethernet over the EVI label and L3 IP over the EVI label? */

/* [JORGE] If the service RTs are the same in the access and core network,
PE2 should have two different peering sessions, one to the RR in the
access network and one to the core RR. Is that the intend? if so, it may
be good to clarify */

   Service edge nodes on the underlay EVI will determine the primary
   service node terminating the VPWS transport service and offering the
   L2, L3 or Ethernet VPN service by running the on HWR algorithm as
   described in [draft-mohanty-l2vpn-evpn-df-election <https://tools.ietf.org/html/draft-mohanty-l2vpn-evpn-df-election>] using weight
   [VPWS service identifier, Service Edge Node IP address]. This ensure
   that service node(s) will consistently pick the primary service node
   even after service node failure. Upon primary service node failure,
   all other remaining services nodes will choose another service node
   correctly and consistently.

/*[JORGE] Following EVPN, the DF election is based on the exchange of ES
routes. Hence the assumption is that the two service nodes should
advertise ES routes with a system-level ESI and an AD route per ES with
the same ESI? The service node DF for a given service should send an AD per-EVI route with the P indication in the new EC defined in EVPN-VPWS. I believe all the
existing procedures should be used, are you defining new ones? */

   Single-sided signaling mechanism is used. The Service PE node that is
   a DF for accepts to terminate the VPWS transport service from an
   access node, the primary service edge node shall:- Dynamically create
   an interface to terminate the service and shall attach this interface
   to the overlay VPN service required by the access node to service its
   customer edge device.- Responds to the Eth A-D route per EVI from the
   access node by sending its own Eth A-D per EVI route by setting the
   same VPWS service instance ID and downstream assigned MPLS label to
   be used by the access node.

/* [JORGE] Need to correct the format: the two bullets must go in
different lines */

  <snip>

4.1 Multi-homing

/* [JORGE] how bout the following scenario:

Here AN1 and AN2 have a ESI for the CE. Regular EVPN-VPWS procedures
should apply.

                 +---------+         +---------+
+----+   +-----+ |         | +-----+ |         |
| CE +---+ AN1 +-+         +-+ SE2 +-+         |
+--+-+   +-----+ | IP/MPLS | +-----+ | IP/MPLS |
   |             | Access  |         | Core    |
   |     +-----+ | Network | +-----+ | Network |
   +-----+ AN2 +-+         +-+ SE3 +-+         |
         +-----+ |         | +-----+ |         |
                 +---------+         +---------+
            <-----EVPN-VPWS-----><-----IP/MAC VRF---->

*/

From:  BESS on behalf of Sami Boutros
Date:  Wednesday, October 7, 2015 at 11:13 PM
To:  "[email-masked]"
Subject:  [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

Hi,

The draft proposes a dynamic mechanism to terminate the VPWS transport service at a service PE into an overlay L2 or L3 service based on a single side provisioning at the access PE.

Thanks,

Sami

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 8 Oct 2015 10:07:48 +0000

Sami,

In what way is this different from the work we have been doing on creating the flexible cross connect table which enables thousands of PWs to be “landed” on a L3/L2/Internet PE? Is this specific to always using EVPN on the service PE to facilitate L2/L3 closed user groups?

Thanks,
                Jim Uttaro

From: BESS [mailto:[email-masked]] On Behalf Of Sami Boutros
Sent: Wednesday, October 07, 2015 5:14 PM
To: [email-masked]
Subject: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

Hi,

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 8 Oct 2015 16:23:44 +0000

Hi Jim,

This work in a nutshell is about single-sided provisioning where you only need to provision the P2P EVC on the Access-PE (and not on the service PE). The Service-PE (S-PE) figures out (via EVPN signaling) what endpoint (e.g., VRF) the P2P EVC is intended for. Thus cutting network-wide provisioning for setting up P2P EVC in half.

Cheers,
Ali

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 8, 2015 at 3:07 AM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

Sami,

Thanks,
                Jim Uttaro

From: BESS [mailto:[email-masked]] On Behalf Of Sami Boutros
Sent: Wednesday, October 07, 2015 5:14 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

Hi,

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 8 Oct 2015 16:25:21 +0000

Thanks...

From: Ali Sajassi (sajassi) [mailto:[email-masked]]
Sent: Thursday, October 08, 2015 12:24 PM
To: UTTARO, JAMES; Sami Boutros; [email-masked]
Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

Hi Jim,

Cheers,
Ali

Sami,

In what way is this different from the work we have been doing on creating the flexible cross connect table which enables thousands of PWs to be "landed" on a L3/L2/Internet PE? Is this specific to always using EVPN on the service PE to facilitate L2/L3 closed user groups?

Thanks,
                Jim Uttaro

Hi,

---

From: Sami Boutros <[email-masked]>
Date: Thu, 8 Oct 2015 12:32:53 -0400

Hi Jim,

You bring a good point in how we can extend this single sided provisioning
at access PE, with the muxing of thousands of L2/L3 services to the same
VPWS instance at the access, given that we don't provision anything at the
service PE.

We need to think more about this.

Thanks,

Sami

On Thu, Oct 8, 2015 at 6:07 AM, UTTARO, JAMES <[email-masked]> wrote:

> *Sami,*
>
>
>
> *In what way is this different from the work we have been doing on
> creating the flexible cross connect table which enables thousands of PWs to
> be “landed” on a L3/L2/Internet PE? Is this specific to always using EVPN
> on the service PE to facilitate L2/L3 closed user groups?*
>
>
>
> *Thanks,*
>
> *                Jim Uttaro*
>
>
>
> *From:* BESS [mailto:[email-masked]] *On Behalf Of *Sami Boutros
> *Sent:* Wednesday, October 07, 2015 5:14 PM
> *To:* [email-masked]
> *Subject:* [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
>
>
>
> Hi,
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 8 Oct 2015 16:59:56 +0000

Just a word of caution. The main value proposition of muxing tens of thousands of VLANs/ACs within a single EVPN-VPWS service instance, was to have transparency  with respect to BGP - i.e., just setup  a single EVPN-VPWS service instance. If we try to signal the VLANs in BGP for single-sided provisioning, then we lose this transparency.

Cheers,
Ali

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of Sami Boutros <[email-masked]<mailto:[email-masked]>>
Date: Thursday, October 8, 2015 at 9:32 AM
To: "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

Hi Jim,

You bring a good point in how we can extend this single sided provisioning at access PE, with the muxing of thousands of L2/L3 services to the same VPWS instance at the access, given that we don't provision anything at the service PE.

Thanks,

Sami

On Thu, Oct 8, 2015 at 6:07 AM, UTTARO, JAMES <[email-masked]<mailto:[email-masked]>> wrote:
Sami,

Thanks,
                Jim Uttaro

From: BESS [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Sami Boutros
Sent: Wednesday, October 07, 2015 5:14 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway

Hi,

---

From: Sami Boutros <[email-masked]>
Date: Mon, 19 Oct 2015 13:39:00 -0700

Hi Jorge,

Sami: will update the abstract.

> advantages are in the introduction and leave the details for the solution
Sami: will update.

> connections through the attached access nodes."
Sami: will update.

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

> 4 Solution Overview

Sami: sure will do.

>    advertised as described in [draft-ietf-bess-evpn-vpws <
> https://tools.ietf.org/html/draft-ietf-bess-evpn-vpws>] with the ESI
Sami:Can you please look at the updated version 01 and see what comments
still apply?

>    described in [draft-mohanty-l2vpn-evpn-df-election <
> https://tools.ietf.org/html/draft-mohanty-l2vpn-evpn-df-election>] using
> weight
> the same ESI? The service node DF for a given service should send an AD
> per-EVI route with the P indication in the new EC defined in EVPN-VPWS. I
> believe all the
Sami: Please have a look at 01.

> /* [JORGE] Need to correct the format: the two bullets must go in
Sure will do.

> Sami: Exactly, regular EVPN VPWS should apply, and hence why do we need to
mention it?

Thanks,

Sami