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

"Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com> Mon, 30 May 2016 03:44 UTC

Return-Path: <jorge.rabadan@nokia.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 6D51912B060 for <bess@ietfa.amsl.com>; Sun, 29 May 2016 20:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 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, 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 lUnqMehjxDds for <bess@ietfa.amsl.com>; Sun, 29 May 2016 20:44:42 -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 661DF12D14A for <bess@ietf.org>; Sun, 29 May 2016 20:44:42 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 6273596B86BE1; Mon, 30 May 2016 03:44:39 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u4U3id5b001882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 May 2016 03:44:39 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 u4U3ibIC032706 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 May 2016 05:44:37 +0200
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.163]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 30 May 2016 05:44:37 +0200
From: "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>
To: Sami Boutros <sboutros@vmware.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: AQHRuhOKG8VtWg0JJEywEXLIl6ccr5/QQAMA
Date: Mon, 30 May 2016 03:44:36 +0000
Message-ID: <AF21DB1B-E579-48FB-942E-E3C6BF6B8ADD@nokia.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> <C94AE040-60CA-448F-B740-E8920E31AECB@vmware.com>
In-Reply-To: <C94AE040-60CA-448F-B740-E8920E31AECB@vmware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.16.0.160506
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_AF21DB1BE57948FB942EE3C6BF6B8ADDnokiacom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/e4218u-J9Vqa67ZdClsd94Fh5gM>
Cc: John E Drake <jdrake@juniper.net>, "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 03:44:46 -0000

Sami,

I'm ok to remove it too.
Thanks.
Jorge

On 5/29/16, 6:35 PM, "Sami Boutros" <sboutros@vmware.com<mailto:sboutros@vmware.com>> wrote:

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.