IETF Logo Mail Archive

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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 23 May 2016 20:10 UTC

Return-Path: <zzhang@juniper.net>
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 788A312DB45 for <bess@ietfa.amsl.com>; Mon, 23 May 2016 13:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
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 wLDAm5rIGKuH for <bess@ietfa.amsl.com>; Mon, 23 May 2016 13:10:51 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908C912DB40 for <bess@ietf.org>; Mon, 23 May 2016 13:10:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qnPNEsNA9zEfj2ZnxC2ZnBu/Ilqm1HNZzSrmHp8nLmY=; b=CekCJyzzx9+BH9LGqdNfrxcAbfp/VLH+fRlGQYYvlo4nq+pLf41bkXXBlNW+HF84VmafCjC/ipI6pwTxTN6PdeNoCK1gwf4zDdTB7EjcXCpIRbTADrMXjMGrjKdm7kxAAF2jsgMlZzslGf+J0qkroF1VMI+OGyllwk3yg5Tb+ko=
Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1716.namprd05.prod.outlook.com (10.163.120.19) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 23 May 2016 20:10:28 +0000
Received: from BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) by BLUPR0501MB1715.namprd05.prod.outlook.com ([10.163.120.18]) with mapi id 15.01.0497.019; Mon, 23 May 2016 20:10:28 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Sami Boutros <sboutros@vmware.com>
Thread-Topic: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03
Thread-Index: AQHRqgOZUf2Jc4CuVk++VehXUPZTSJ+4z9qAgALM/yCAA10LAIAAAi0ggAA2KwCAB9QfQA==
Date: Mon, 23 May 2016 20:10:27 +0000
Message-ID: <BLUPR0501MB1715FEE3F2F32584A31B14A7D44E0@BLUPR0501MB1715.namprd05.prod.outlook.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>
In-Reply-To: <600118F7-222D-4C0A-A573-C1FFE56F251B@vmware.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: vmware.com; dkim=none (message not signed) header.d=none;vmware.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.10]
x-ms-office365-filtering-correlation-id: 38a4e7c3-89dc-477d-044b-08d3834648d9
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1716; 5:WGJP2bTTcHd6NwPneGTTXIZY+EgspbJ+WJvmkc5bxwicdePfOLPen3HP1Prt64oi2v0mWbPoUkTK278D8mCjNJBHUG9LERXAnSiyIns0USRavp8kunFEG0cJGZ/ve2Yz2klmrezktvE87H9s1RvVng==; 24:YinSe+/PLs5TMyw1CvkK35qGXHn/bitH1jXmKrEPdRfEpEngD9ZBG6G6k7mh29gYeA6JKbfEHPnZ/xz37UISIdARoyN56p7bv97qikEVEy8=; 7:U6q2l8WvDDYOmO4KR1yTFm4YsBmB29MrP1n/dNPzejrrXmwy2wWqJM8aIfqkqNJNxG29kb0cejcz5euqmRRxBTnIprIk9/QPhmzPSqV0j3fztaJTnUSdTcBgn1CwxGCStrZVOzp86hFmqSvk9FP5vemxPd15jtv9rVFzcwj3RW2OUVjRR9EUPaj/alFJVuVY
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1716;
x-microsoft-antispam-prvs: <BLUPR0501MB171669631EFD61F75F887FCED44E0@BLUPR0501MB1716.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB1716; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1716;
x-forefront-prvs: 0951AB0A30
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(19300405004)(8936002)(92566002)(586003)(110136002)(5008740100001)(86362001)(106116001)(4326007)(16236675004)(790700001)(2950100001)(6116002)(1220700001)(5002640100001)(102836003)(3846002)(99286002)(19625215002)(122556002)(189998001)(3660700001)(50986999)(76576001)(15975445007)(8676002)(3280700002)(19580395003)(5003600100002)(76176999)(19580405001)(54356999)(74316001)(66066001)(2900100001)(230783001)(77096005)(5004730100002)(81166006)(9686002)(93886004)(10400500002)(87936001)(11100500001)(33656002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1716; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB1715FEE3F2F32584A31B14A7D44E0BLUPR0501MB1715_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2016 20:10:28.1565 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1716
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/GlNi_Gcf8rwv8WYIPsw1J6f-oA0>
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: Mon, 23 May 2016 20:10:53 -0000

Sami,

Please see zzh3> below. I’ve trimmed some text.

From: Sami Boutros [mailto:sboutros@vmware.com]
Sent: Wednesday, May 18, 2016 4:23 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: bess@ietf.org
Subject: Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Hi Jeffrey,

Few comments inline next to Sami2:

Zzh2> Because RFC7432 is not clear about “remain tagged” (for example, see my above questions), it would be good to spell out the details, not just “at least one VID should be present”?

Sami2: Can you please suggest some text? Not sure what extra details needed?

Zzh3> Let me do more digging to confirm my understanding and see if I could come up with some text.

Sami2: We can suggest to the authors of the idr BW draft adding the shaping aspect.

Zzh3> The use case in draft-ietf-idr-link-bandwidth seems to be unrelated to shaping at all, so it may be better to define it in this document to reduce the dependency?

Zzh2> RFC7432 only says it’s withdrawn when a tag is “decommissioned”; if the intention is to withdraw when the AC goes down, it should be explicitly spelled out (it’s not in RFC 7432 but should be added to this draft if that’s the right behavior). However, isn’t it better to keep those routes around so that they don’t need to be re-advertised when the link comes back up?

Sami2: Sure, I will not need to add any text then, since we will not be changing any behavior, no?

Zzh3> Given the following two facts:

- I had to do a search to be sure that RFC 7432 did not require the withdraw when the ES goes down
- You for a moment thought that RFC 7432 required that

It would be better to explicitly call it out in this document. But this is just a suggestion and it does not block the progress.

Thanks!
Jeffrey

v2.23.0 | Report a Bug | By Email