Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Sami Boutros <sboutros@vmware.com> Fri, 24 February 2017 19:29 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 AADE91294E1; Fri, 24 Feb 2017 11:29:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.788
X-Spam-Level:
X-Spam-Status: No, score=-3.788 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, RCVD_IN_MSPIKE_H2=-1.887, 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=onevmw.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 wpXVVDzoQHow; Fri, 24 Feb 2017 11:29:45 -0800 (PST)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0064.outbound.protection.outlook.com [104.47.40.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBC91294E0; Fri, 24 Feb 2017 11:29:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2ZAFloa0Hjx0N6k1ULFfeGIwfd5pS0bJ9aejbrAW8bI=; b=dHEONJxF3UI3IpHh7omT5kT0HoWPdNleerScnDJiaAjzQB67XKKoB0Ra+875eDB7DNV9pq9hpNq96tjIkQyNXp+O6lg3W94Kjw25KqwuqAmXb4ZVxdXtYtt1EncUExHOWkSTupcW0N0tp39GfvL/MFSIqgafsgoYZzq0qgai58g=
Received: from BN6PR05MB3009.namprd05.prod.outlook.com (10.173.19.15) by BN6PR05MB3010.namprd05.prod.outlook.com (10.173.19.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Fri, 24 Feb 2017 19:29:43 +0000
Received: from BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) by BN6PR05MB3009.namprd05.prod.outlook.com ([10.173.19.15]) with mapi id 15.01.0933.010; Fri, 24 Feb 2017 19:29:43 +0000
From: Sami Boutros <sboutros@vmware.com>
To: "Shah, Himanshu" <hshah@ciena.com>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "draft-ietf-bess-evpn-vpws@ietf.org" <draft-ietf-bess-evpn-vpws@ietf.org>
Thread-Topic: [bess] AD Review of draft-ietf-bess-evpn-vpws-07
Thread-Index: AQHSjrENeHDnPiSdYEOjkNnPB7FdAaF4FlMA///u4YA=
Date: Fri, 24 Feb 2017 19:29:43 +0000
Message-ID: <A5DD3F84-14F9-4A46-B01E-7A0BF5C0F849@vmware.com>
References: <7BA49247-B24B-42FC-AAD8-85620F04E648@cisco.com> <EB4BD3E8-E5CF-4285-8ABB-2C422D883F1A@ciena.com>
In-Reply-To: <EB4BD3E8-E5CF-4285-8ABB-2C422D883F1A@ciena.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sboutros@vmware.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [208.91.2.4]
x-ms-office365-filtering-correlation-id: 5d2e7a23-26a7-4875-c8be-08d45ceb7c3a
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR05MB3010;
x-microsoft-exchange-diagnostics: 1; BN6PR05MB3010; 7:7guh8fACFf4SyYTwQs03esFf/NtRIkX/KT8RiEn241uIi4kbw2EUgQ2vp+x4856WQxSAEkuMP595WXcBX72v0WtXnOXnDufXVQ4XWcFXBEioSf9UHtHw9uqMBexcdl982QBMOHkx10ehqzKRIe50C6z4PbrrFVtRE+RTeJmV2a2YKrDgP5nZnFPKT+G7TMWRBPHpenzIctltvK7XPJ/cNMssiOWt97BCcM+4Tdd9S5LV27HgkdtJBnOfyi3c6rpQowEOC6mLShE6E3E71H8mvMPg31J35HJwkJiAke8OFraNSv9bGtW2yZQap+bwyDP4Sz8WGLr91rT959SYQ4wh1Q==; 20:Og7CZMlf6In5idEr/U+wMGE9ArnhpaNeD89q2rBbxCPfQkYNqMvNyKCnXJCRnTowxmFwSIWjsjkE02gCTNebthGLiwe0YCBs0L30gcHVHVth18Wc0G5a1GQQFhiU7xIWwlww72lQMYp+FgXQLXEARJaZVzD0kjnyqSq9V0GHl5c=
x-microsoft-antispam-prvs: <BN6PR05MB30106ECB81A5414D6FFA18A1BE520@BN6PR05MB3010.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123558025)(20161123564025)(6072148); SRVR:BN6PR05MB3010; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB3010;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(3280700002)(3846002)(97736004)(3660700001)(122556002)(189998001)(105586002)(54896002)(101416001)(33656002)(6512007)(106356001)(76176999)(50986999)(99286003)(106116001)(2906002)(6436002)(54356999)(8666007)(5890100001)(4326007)(2900100001)(2501003)(25786008)(6506006)(54906002)(5660300001)(229853002)(8676002)(7736002)(92566002)(82746002)(81156014)(8936002)(6486002)(83716003)(6116002)(2950100002)(38730400002)(86362001)(53936002)(230783001)(81166006)(68736007)(6246003)(36756003)(102836003)(77096006)(66066001)(104396002)(19623405001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR05MB3010; H:BN6PR05MB3009.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: vmware.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_A5DD3F8414F94A46B01E7A0BF5C0F849vmwarecom_"
MIME-Version: 1.0
X-OriginatorOrg: vmware.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 19:29:43.6579 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3010
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/bYoRdzMe5SwA23o_av4DaWBlV5I>
Cc: Jeffrey Zhang <zzhang@juniper.net>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07
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: Fri, 24 Feb 2017 19:29:49 -0000

Hi Himanshu,

Please see comments inline.



Hi Sami –

Some more comments for your consideration (based on -09- version) –
Many of the followings are either clarifications related or editorial.

1-

Overall comment : the draft uses long sentences, short sentences are more
favored (at least that is the feedback I used to get for my drafts).

For example:
--- original text --
Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for
   Port-based, vlan-based, and vlan-bundle interface mode and it is set
   to non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS,
   for all the four interface modes, Ethernet tag ID in the Ethernet A-D
   route MUST be set to a non-zero value in all the service interface
   types.
----
This could be written as –

Ethernet tag ID in Ethernet A-D route MUST be set to a non-zero value
irrespective of the service interface types. This is a deviation from
what is expected for EVPN. In EVPN, Ethernet Tag ID in EVPN routes are
set to zero for Port-based, vlan-based and vlan-bundle interface mode
while non-zero Ethernet tag ID only for vlan-aware bundle mode.
----

[Sami] We are defining new interface types in other drafts, so we can’t say in the above text
For all a service interface types for example, honestly I am not in favor to change the text.

2-

In section 2.1

Original text ---

If the VLAN is represented by different VIDs on different PEs.
(note there should not be a period here)
(e.g., a different VID per Ethernet segment per PE), then each PE needs to
perform VID translation for frames destined to its Ethernet segment.

Comment ---

This particular paragraph is somewhat confusing. The confusing part is
That text seems to indicate that multiple PEs connected to an ES may
see same VLAN as different VID (which I believe is not true).

[Sami] This is not what the text is indicating.

For
example, PE members PE1 and PE2 of same ESx, may see VID 100 for PE1
but 101 for PE2.

[Sami] This is simply not possible, since the source of traffic on the ES is one for both PE1 and PE2.

I believe what you are trying to convey is PEs on
local ES and PEs on remote ES may have different VIDs.

[Sami] I will add to the above text, on different PE (s) and different ES (es) instead of different PE (s)

It can be clarified as –

If the VLAN is represented by different VIDs on local PEs (connected
to local ES) and remote PEs (connected to remote ES), then each PE
needs to perform VID translation for frames destined to its Ethernet segment.

---
3- editorial

Original text for page 8 –

A remote PE SHOULD receive P=1 from only one Primary PE and a B-1 from only one Backup PE.

Comment –
B=1


[Sami] Sure will fix.

4- clarification

original text –

This allows an ingress PE to perform flow-based load-balancing
of traffic flows to all of the PEs attached to that ES.



Comment --

In multi-homed All-active configuration, this allows an ingress PE to perform
Flow-based load-balancing of traffic flows to all the PEs attached to that ES.

(I am assuming that in VPWS, single active multi-homing, there is load-balancing
from remote to local multi-homed PEs – Right??)

[Sami] Ok I will add that this is for all-active.


Thanks,

Sami