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

Sami Boutros <sboutros@vmware.com> Mon, 30 May 2016 01:35 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 3528E12D0A6 for <bess@ietfa.amsl.com>; Sun, 29 May 2016 18:35:19 -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 qgE0IekmU7sd for <bess@ietfa.amsl.com>; Sun, 29 May 2016 18:35:16 -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 C91C912D133 for <bess@ietf.org>; Sun, 29 May 2016 18:35:16 -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 EE59D9809F; Sun, 29 May 2016 18:35:15 -0700 (PDT)
Received: from EX13-CAS-008.vmware.com (ex13-cas-008.vmware.com [10.113.191.58]) by sc9-mailhost1.vmware.com (Postfix) with ESMTP id EB568183C9; Sun, 29 May 2016 18:35:15 -0700 (PDT)
Received: from EX13-MBX-029.vmware.com (10.113.191.49) by EX13-MBX-000.vmware.com (10.113.191.20) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Sun, 29 May 2016 18:35:15 -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; Sun, 29 May 2016 18:35:15 -0700
From: Sami Boutros <sboutros@vmware.com>
To: "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/8gIAC8MQA
Date: Mon, 30 May 2016 01:35:15 +0000
Message-ID: <C94AE040-60CA-448F-B740-E8920E31AECB@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>
In-Reply-To: <BLUPR0501MB171500F62DCF2AD58ABE9BAFD4420@BLUPR0501MB1715.namprd05.prod.outlook.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_C94AE04060CA448FB740E8920E31AECBvmwarecom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/2JIEG9lM2sUHz750v7SG1_FpwbU>
Cc: John E Drake <jdrake@juniper.net>, "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "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: Mon, 30 May 2016 01:35:19 -0000

Hi Jeff,

I am ok to remove the BW section, adding other authors for their I/p.

Thanks,

Sami
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Date: Friday, May 27, 2016 at 2:41 PM
To: 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

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.