Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
"Rabadan, Jorge (Jorge)" <jorge.rabadan@alcatel-lucent.com> Thu, 08 October 2015 08:02 UTC
Return-Path: <jorge.rabadan@alcatel-lucent.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E301A8A23 for <bess@ietfa.amsl.com>; Thu, 8 Oct 2015 01:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLOqPBoCGj0O for <bess@ietfa.amsl.com>; Thu, 8 Oct 2015 01:02:38 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDAA1A8749 for <bess@ietf.org>; Thu, 8 Oct 2015 01:02:37 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 0429AB3FAB3CA; Thu, 8 Oct 2015 08:02:34 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t98823eO020708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Oct 2015 10:02:34 +0200
Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.183]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Thu, 8 Oct 2015 10:01:58 +0200
From: "Rabadan, Jorge (Jorge)" <jorge.rabadan@alcatel-lucent.com>
To: Sami Boutros <boutros.sami@gmail.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
Thread-Index: AQHRAUUsWm2xRgSmQUqXFeY+jQylkZ5hPKsA
Date: Thu, 08 Oct 2015 08:01:58 +0000
Message-ID: <1EDE9B87-E9DB-4BBA-A41C-AB138380E451@alcatel-lucent.com>
References: <CAFKBPj5X4qp0BfEJTn8wQV4bcvRd9XyyiHefxvv92WgzVw2xLQ@mail.gmail.com>
In-Reply-To: <CAFKBPj5X4qp0BfEJTn8wQV4bcvRd9XyyiHefxvv92WgzVw2xLQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/0.0.0.150923
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E08D90C94EFF324D86F461A2137908AA@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/29e16iV-zQT8SryGLqbYybrBjuY>
Subject: Re: [bess] Seeking Comments for EVPN-VPWS Service Edge Gateway
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2015 08:02:40 -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: "bess@ietf.org" 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] Seeking Comments for EVPN-VPWS Service Edg… Sami Boutros
- Re: [bess] Seeking Comments for EVPN-VPWS Service… Rabadan, Jorge (Jorge)
- Re: [bess] Seeking Comments for EVPN-VPWS Service… UTTARO, JAMES
- Re: [bess] Seeking Comments for EVPN-VPWS Service… Ali Sajassi (sajassi)
- Re: [bess] Seeking Comments for EVPN-VPWS Service… UTTARO, JAMES
- Re: [bess] Seeking Comments for EVPN-VPWS Service… Sami Boutros
- Re: [bess] Seeking Comments for EVPN-VPWS Service… Ali Sajassi (sajassi)
- Re: [bess] Seeking Comments for EVPN-VPWS Service… Sami Boutros