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

Sami Boutros <sboutros@vmware.com> Tue, 07 February 2017 23:06 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 36D40129519; Tue, 7 Feb 2017 15:06:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kaeCHjyBdnKg; Tue, 7 Feb 2017 15:06:20 -0800 (PST)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0069.outbound.protection.outlook.com [104.47.33.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0723E1294EE; Tue, 7 Feb 2017 15:06:19 -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=yoWoUhsVJ0hgGKkQ+2gRPQGhA51nOQmz0n1KmA6eM6M=; b=XwRWeQEWAZfAT3CTgrwZF7o0/TuEIMFDS/kkYsa8mJ54UOaAuV+M9get2k8lOAJayBr+9Im0tCy16YGJSvDsjjP5MoTQgEz/z0s5o0IYlI0SXzeiQmpF/xYsGaz8ob16hc5+wZzoMfTGT73oYUEgZuSblCjZNda9Urh9XKJGBU8=
Received: from CY4PR05MB3013.namprd05.prod.outlook.com (10.169.184.22) by CY4PR05MB3014.namprd05.prod.outlook.com (10.169.184.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Tue, 7 Feb 2017 23:06:17 +0000
Received: from CY4PR05MB3013.namprd05.prod.outlook.com ([10.169.184.22]) by CY4PR05MB3013.namprd05.prod.outlook.com ([10.169.184.22]) with mapi id 15.01.0888.026; Tue, 7 Feb 2017 23:06:17 +0000
From: Sami Boutros <sboutros@vmware.com>
To: "Shah, Himanshu" <hshah@ciena.com>, Sami Boutros <boutros.sami@gmail.com>, Iftekhar Hussain <IHussain@infinera.com>
Thread-Topic: [bess] AD Review of draft-ietf-bess-evpn-vpws-07
Thread-Index: AQHSd44kA2pNPLQMm0qn/KFCiMDXR6FLXEkAgAwAsgCAAJrIgIAAKsgAgAVSt4CAAIrdoP//uDcA
Date: Tue, 07 Feb 2017 23:06:17 +0000
Message-ID: <3002D2F1-01A3-42EF-AED3-8E47D0A0CD4C@vmware.com>
References: <71E62DB5-32E4-441D-9D22-290CFFC5BAD1@cisco.com> <f57c905ca5884767a3e0a0c2369426c2@sv-ex13-prd2.infinera.com> <315CCD29-0FBB-44A9-B623-E7DACAD827B6@vmware.com> <c6499d5277df4419b4e4798df62ce72a@sv-ex13-prd1.infinera.com> <F366D42B-9EF6-467E-AC0C-C1D910AA0374@gmail.com> <84E69C61-927B-4B48-A50F-8D710EB131D4@vmware.com> <DM5PR04MB02343C5342BFF283E8372B94AF430@DM5PR04MB0234.namprd04.prod.outlook.com>
In-Reply-To: <DM5PR04MB02343C5342BFF283E8372B94AF430@DM5PR04MB0234.namprd04.prod.outlook.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: 5a80df86-35c0-4bc1-bc87-08d44fadec0d
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR05MB3014;
x-microsoft-exchange-diagnostics: 1; CY4PR05MB3014; 7:PBJTwRe9334F3QrutC5Flz1Dz5Y/TKYyE7CO14bfvKIgn+wl6d7O35pZ4CuNMerjdhY8Q8BpFbA+2fR5bS6RkL2TVH4AdXHsTeXcmmWAsjVYfe1G9hrWUXTVcCLwncXExdMR3aLKqhW4pa7Wpcj5SAU2SOvrCxSKeu7+B0ElEK8XC+PLj6gr3+C+ed4H8CM01Nmmntfggl+Y/6deBPJtHlW1P9rEvYChw5C9N0dCo5o/m8CGjTDlNaWKrlWCDGiWoS5mpH6yNWfPPzHXgY1Srx4GM9Gj8H+j1KNLovKcFk/qOKl67nRuY1s9oj55ZBysFsYsIYlLI8g+CzjHUURZ92wzcIpRorXboYYRJv2/k3AbYdp7rpZ+F8ETO9AtfEiYrSZRCMEo6tbiLrhAygoxyuAJRystmQHEfxK1AxFeUA8UEkbw6sXppkhDlB/VerKOT4gHnKhLXUAsBldqsp9KNJo8P5ESO70C/tQhiWDOUML/fhS8RWuvqzglJSzDRtJm7rDd21JbOC1RU1HMpMh6uA==; 20:okEY/AN2Xk/eNhL4bpNVUc08NkCojUphct9P9+J0D0zBkQT7TS1UtveqVZaSHlzea0m+7HkOs8twr2dslZHiG/vaW9a2Q1jDmgLgDh/LKdimweSC+Zg3lzsZE2qL4SD6Zlrm6WYLVrSeopiBw3AB1NCBlh1nTbyXrv6lVITqKPI=
x-microsoft-antispam-prvs: <CY4PR05MB3014AAA2F85F6D813D851D9DBE430@CY4PR05MB3014.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(61668805478150)(138986009662008)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(2017020603029)(8121501046)(20170203043)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(20161123558025)(6072148); SRVR:CY4PR05MB3014; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3014;
x-forefront-prvs: 0211965D06
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(377454003)(199003)(189002)(5660300001)(2900100001)(66066001)(53936002)(36756003)(97736004)(230783001)(189998001)(2950100002)(122556002)(6512007)(68736007)(6306002)(82746002)(50986999)(54906002)(5890100001)(3280700002)(236005)(25786008)(8666007)(6436002)(54896002)(6506006)(99286003)(83716003)(76176999)(77096006)(39060400001)(6246003)(6486002)(3660700001)(38730400002)(3846002)(7736002)(33656002)(6116002)(102836003)(790700001)(81166006)(229853002)(8676002)(86362001)(4326007)(92566002)(8936002)(54356999)(2906002)(93886004)(101416001)(81156014)(106116001)(106356001)(105586002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3014; H:CY4PR05MB3013.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_3002D2F101A342EFAED38E47D0A0CD4Cvmwarecom_"
MIME-Version: 1.0
X-OriginatorOrg: vmware.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2017 23:06:17.2380 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3014
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/OzW4199_0WPQeMDrdJUfCaJH9eU>
Cc: Jeffrey Zhang <zzhang@juniper.net>, "Alvaro Retana (aretana)" <aretana@cisco.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-vpws@ietf.org" <draft-ietf-bess-evpn-vpws@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: Tue, 07 Feb 2017 23:06:23 -0000

Hi Himanshu,

Please see comments inline.

From: "Shah, Himanshu" <hshah@ciena.com<mailto:hshah@ciena.com>>
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros <sboutros@vmware.com<mailto:sboutros@vmware.com>>, Sami Boutros <boutros.sami@gmail.com<mailto:boutros.sami@gmail.com>>, Iftekhar Hussain <IHussain@infinera.com<mailto:IHussain@infinera.com>>
Cc: Jeffrey Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>, "Alvaro Retana (aretana)" <aretana@cisco.com<mailto:aretana@cisco.com>>, "bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>" <bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>>, "draft-ietf-bess-evpn-vpws@ietf.org<mailto:draft-ietf-bess-evpn-vpws@ietf.org>" <draft-ietf-bess-evpn-vpws@ietf.org<mailto:draft-ietf-bess-evpn-vpws@ietf.org>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

It seems to me that single-active multihoming case could use some more clarification text.

I think there should be an additional field in L2 extended community
as (for example) “election priority” so that each multi-homed member can definitely tell
to each other as well as to remote PE who/what primary election order would be.

[Sami] In single active, there would be only one primary as per definition below in this e-mail.

Thus, when ESI link to primary fails, remote PE can quickly change the next hop
to next priority PE multi-home member.

[Sami] Extending the DF election is not in scope for the draft and I doubt we will include it, however there are other drafts extending DF election like rabadan-evpn-pref-df.

The text in VPWS draft is not very clear.

It seems to suggest there could be multiple primaries and backups.
But if that is true how would remote PE can independently switchover to backup PE
(i.e. which backup PE?).

[Sami] As per draft, "A remote PE receiving B=1 from more than one PE will select only one backup PE."

If there are multiple primary PEs, and if one of them fail, why not switchover to other
primary PE, so on and so forth..

[Sami] In single active there should be only one primary, having more than one primary will be transit in this case.

So what is the intent?

[Sami] As per EVPN, the intent is to support A/A in which all will be primary, or A/S in which only one primary and one backup.

One primary, one backup
Multiple primary, one backup
Or (one or) multiple primaries, multiple backups?

[Sami] We are not redefining what single active or all active mean, this is as per EVPN RFC7432

Single-Active Redundancy Mode: When only a single PE, among all the
      PEs attached to an Ethernet segment, is allowed to forward traffic
      to/from that Ethernet segment for a given VLAN, then the Ethernet
      segment is defined to be operating in Single-Active redundancy
      mode.


I.e. One primary and one/multiple backup.


   All-Active Redundancy Mode: When all PEs attached to an Ethernet
      segment are allowed to forward known unicast traffic to/from that
      Ethernet segment for a given VLAN, then the Ethernet segment is
      defined to be operating in All-Active redundancy mode.

 I.e. Multiple Primary


Also, there has to be corresponding understanding/configuration in CE as well.
So if the CE+multi-hommed-PEs configuration is consistent and if all the parties,
(CE, multi-homed PEs and remote PE) are aware of this, selection algorithm would work better?

[Sami] Again, we are not redefining EVPN multihoming or DF election, those are following base EVPN.

Thanks,

Sami

Thanks,
Himanshu

From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Sami Boutros
Sent: Tuesday, February 07, 2017 2:06 PM
To: Sami Boutros <boutros.sami@gmail.com<mailto:boutros.sami@gmail.com>>; Iftekhar Hussain <IHussain@infinera.com<mailto:IHussain@infinera.com>>
Cc: Jeffrey Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; Alvaro Retana (aretana) <aretana@cisco.com<mailto:aretana@cisco.com>>; bess-chairs@ietf.org<mailto:bess-chairs@ietf.org>; bess@ietf.org<mailto:bess@ietf.org>; draft-ietf-bess-evpn-vpws@ietf.org<mailto:draft-ietf-bess-evpn-vpws@ietf.org>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Are you ok with what I added to the doc? For presenting the entity for Management.

VPWS Service Instance: It is represented by a pair of EVPN service labels associated with a pair of endpoints. Each label is downstream assigned and advertised by the disposition PE through an Ethernet A-D per-EVI route. The downstream label identifies the endpoint on the disposition PE. A VPWS service instance can be associated with only one VPWS service identifier.

Thanks,

Sami