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: "[email protected]" > 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 > >
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
