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

[Martin Vigoureux <[e-mail]>]

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) <[e-mail]> 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)" <[e-mail]> 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 <[e-mail]>
> Date: Tuesday, October 20, 2015 at 5:39 AM
> To: Jorge Rabadan <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> 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 ;-)
> 
> 
> 
> <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. */
> 
> Sami: will update.
> [JORGE2] I don’t see anything changed in rev 02 ;-)
> 
> <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 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.
> 
> 
> <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? */
> 
> 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 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] 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 */
> 
> Sami:Can you please look at the updated version 01 and see what comments still apply?
> 
> [JORGE2] Rev 01 or 02 don’t really add much information about it. 
> 
> 
>    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] 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? */
> 
> Sami: Please have a look at 01.
> [JORGE2] no changes in 01 or 02. Again more details are needed:
> - How is the ES assigned to the service nodes. I suggest a system level ESI or/and a virtual ES per service on the service nodes. The former is defined in the dci-evpn-overlay draft. The latter should be stated here.
> - Once the ES and ESI is assigned to the service nodes, regular EVPN procedures should follow. If not, it has to be explicitly stated.
> 
> 
> 
>    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 */
> 
> Sure will do.
> [JORGE2] I think still there in rev 02.
> 
> 
>   <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---->
> 
> */
> 
> Sami: Exactly, regular EVPN VPWS should apply, and hence why do we need to mention it?
> [JORGE2] Because one may think that there are two ways of addressing this: a) no ES on ANs, the ANs just provide a wire and the ES really represents the CE or b) there are two ES in the diagram, one defined in the ANs and one defined on the SE nodes.
> I see that you mean (b) but it should be stated.
> 
> 
> Thanks,
> 
> 
> Sami 
> 
> 
> 
> 
> 
> 
> From:  BESS on behalf of Sami Boutros
> Date:  Wednesday, October 7, 2015 at 11:13 PM
> To:  "[e-mail]"
> 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.
> 
> https://tools.ietf.org/html/draft-boutros-bess-evpn-vpws-service-edge-gateway-01
> 
> 
> Thanks,
> 
> 
> Sami
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

--- End Message ---