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

[Sami Boutros <[e-mail]>]

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.

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


> <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."
> */
>
>
Sami: will update.

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

>
> <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 <
> 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 */
>
>
Sami:Can you please look at the updated version 01 and see what comments
still apply?

>
>
>
>
>    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? */
>
>
>
Sami: Please have a look at 01.


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


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

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