Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Sami Boutros <sboutros@vmware.com> Tue, 31 May 2016 16:02 UTC

Return-Path: <sboutros@vmware.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9712D7FB for <bess@ietfa.amsl.com>; Tue, 31 May 2016 09:02:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.346
X-Spam-Level:
X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 gByEagInU_Nb for <bess@ietfa.amsl.com>; Tue, 31 May 2016 09:02:26 -0700 (PDT)
Received: from smtp-outbound-2.vmware.com (smtp-outbound-2.vmware.com [208.91.2.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C837112D7FA for <bess@ietf.org>; Tue, 31 May 2016 09:02:25 -0700 (PDT)
Received: from sc9-mailhost1.vmware.com (sc9-mailhost1.vmware.com [10.113.161.71]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 8E7D79852A; Tue, 31 May 2016 09:02:24 -0700 (PDT)
Received: from EX13-CAS-005.vmware.com (ex13-cas-005.vmware.com [10.113.191.55]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id 2DBCA18744; Tue, 31 May 2016 09:02:25 -0700 (PDT)
Received: from EX13-MBX-029.vmware.com (10.113.191.49) by EX13-MBX-027.vmware.com (10.113.191.47) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Tue, 31 May 2016 09:02:24 -0700
Received: from EX13-MBX-029.vmware.com ([fe80::1846:2003:39f8:8a33]) by EX13-MBX-029.vmware.com ([fe80::1846:2003:39f8:8a33%15]) with mapi id 15.00.1156.000; Tue, 31 May 2016 09:02:25 -0700
From: Sami Boutros <sboutros@vmware.com>
To: "UTTARO, JAMES" <ju1738@att.com>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
Thread-Topic: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03
Thread-Index: AQHRrgTJ1XbDGXV9VEKztuPSaZn3Jp+4z9qAgAO6eQCAAmeWAIAAlfEA//+iZwCADq/8gIAFzWWA//+n94A=
Date: Tue, 31 May 2016 16:02:24 +0000
Message-ID: <3D0D4E6B-CC4B-4E63-BC92-078320249AC9@vmware.com>
References: <572B2655.3020605@alcatel-lucent.com> <D3095B2F-072B-42CA-B160-DB4888DA02A7@alcatel-lucent.com> <57303CEE.8040104@orange.com> <7A432DD5-E28B-4670-B53E-2137A0A6E445@alcatel-lucent.com> <57309395.8090408@orange.com> <SN1PR0501MB1709149BA36C410EF7E46E52C7700@SN1PR0501MB1709.namprd05.prod.outlook.com> <SN1PR0501MB1709DD24B90B52F014AA58CFC7700@SN1PR0501MB1709.namprd05.prod.outlook.com> <BLUPR0501MB17151371F2D0A16368B63FFAD4720@BLUPR0501MB1715.namprd05.prod.outlook.com> <CAFKBPj58Q_cDi3GhAtgCQ0XfAaYtdNeCzzuWN3eJURc47y5sWg@mail.gmail.com> <0D4E38AC-C11C-4DB9-8D61-8778FA2852B4@vmware.com> <BLUPR0501MB1715DB345CF2E66870572148D4770@BLUPR0501MB1715.namprd05.prod.outlook.com> <67A01B47-48C4-4899-9D87-F64E379DA174@vmware.com> <BLUPR0501MB1715BE626403CF88E10F9488D4490@BLUPR0501MB1715.namprd05.prod.outlook.com> <600118F7-222D-4C0A-A573-C1FFE56F251B@vmware.com> <BLUPR0501MB171500F62DCF2AD58ABE9BAFD4420@BLUPR0501MB1715.namprd05.prod.outlook.com> <B17A6910EEDD1F45980687268941550F1FED5B13@MISOUT7MSGUSRCD.ITServices.sbc.com>
In-Reply-To: <B17A6910EEDD1F45980687268941550F1FED5B13@MISOUT7MSGUSRCD.ITServices.sbc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.113.170.11]
Content-Type: multipart/alternative; boundary="_000_3D0D4E6BCC4B4E63BC92078320249AC9vmwarecom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/-JMq-tQVzn1OWgk9f_0GKX_EsA8>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 31 May 2016 16:02:28 -0000

Thanks Jim and Jeffrey for the comments,

We will move the BW section to the service-edge-gateway draft specially for the single side signaling and we will mention that the BW can be handled orthogonally too.

Thanks,

Sami
From: "UTTARO, JAMES" <ju1738@att.com<mailto:ju1738@att.com>>
Date: Tuesday, May 31, 2016 at 7:17 AM
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net<mailto:zzhang@juniper.net>>, Sami Boutros <sboutros@vmware.com<mailto:sboutros@vmware.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>
Subject: RE: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Sami,

                My two cents ;) These constraints will most likely be managed by the SP in an orthogonally from the creating of PWs.. At least that would be my approach.. So, goes something like, service requested, check available resources ( BW, Ports, latency, etc… ) select endpoints that meet the criteria.

Jim Uttaro

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, May 27, 2016 5:41 PM
To: Sami Boutros <sboutros@vmware.com<mailto:sboutros@vmware.com>>
Cc: bess@ietf.org<mailto:bess@ietf.org>
Subject: Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Hi Sami,

I thought about this BW topic further, and have the following question:

- Even for the originally stated purpose, i.e. for PE1 to request PE2 to request BW reservation in the network, why does it have to be signaled from PE1? Why can’t you provision PE2 to request that BW reservation? You need to provision service identifier on both PE1 and PE2 anyway, so you might as well add BW provisioning on PE2.



I understand that draft-boutros-bess-evpn-vpws-service-edge-gateway-02 does specify that the service node could skip the service identifier configuration and automatically signals the one that it receives from the access node. In that case, signaling qos/bw parameters from the access node makes sense (in that there is no need for configuration on the service node side).



So, perhaps the entire BW or shaping signaling stuff could be moved from the base EVPN-VPWS draft to draft-boutros-bess-evpn-vpws-service-edge-gateway?



Jeffrey

Sami: The issue here is that we are using the BW idr draft, and there is no shaping defined there, and we don’t plan to define a new attribute for this, perhaps we can add that to a new draft?
 Zzh2> Good point that BW is not equal to shaping parameters; however, existing PW specifications do not seem to have BW related stuff and one actual customer use case I am aware of with EVPN VPWS actually does involve shaping; so maybe it’s better to take care of this in the base spec? It’s just a new attribute anyway.