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

"Shah, Himanshu" <hshah@ciena.com> Wed, 08 February 2017 23:04 UTC

Return-Path: <hshah@ciena.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 3F8C412A0C8; Wed, 8 Feb 2017 15:04:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cienacorp.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 DoCkw4ydnYeI; Wed, 8 Feb 2017 15:04:47 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0088.outbound.protection.outlook.com [104.47.34.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B32C129609; Wed, 8 Feb 2017 15:04:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cienacorp.onmicrosoft.com; s=selector1-ciena-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yfM0zOh8GrrJGbHavOMz8aJkUZJMascHLIJSP4BhZCc=; b=HzfZ3GYbko9c5VtrAROEu8Sc7zr6D2CbjCCp1SnkxDtro/pxr5WdufgP7CAmrhvUDP8gllUKzs0+7hUkZFE6VlVx/SQFG8Fritn/7qxkfUll+aiMQLv9LVhZcY0uPOE/TZ2D0eSPF1QmTk7O4RQNvo8VPfc85TAGEb5zctdVZGk=
Received: from DM5PR04MB0234.namprd04.prod.outlook.com (10.168.234.135) by DM5PR04MB0236.namprd04.prod.outlook.com (10.168.234.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 8 Feb 2017 23:04:45 +0000
Received: from DM5PR04MB0234.namprd04.prod.outlook.com ([10.168.234.135]) by DM5PR04MB0234.namprd04.prod.outlook.com ([10.168.234.135]) with mapi id 15.01.0888.026; Wed, 8 Feb 2017 23:04:45 +0000
From: "Shah, Himanshu" <hshah@ciena.com>
To: Sami Boutros <sboutros@vmware.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//uDcAgAHvJcA=
Date: Wed, 08 Feb 2017 23:04:45 +0000
Message-ID: <DM5PR04MB0234FAB6C3C76DC46B5F6BEDAF420@DM5PR04MB0234.namprd04.prod.outlook.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> <3002D2F1-01A3-42EF-AED3-8E47D0A0CD4C@vmware.com>
In-Reply-To: <3002D2F1-01A3-42EF-AED3-8E47D0A0CD4C@vmware.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=hshah@ciena.com;
x-originating-ip: [63.118.37.72]
x-ms-office365-filtering-correlation-id: 8d2f03cd-4458-495f-c6c6-08d45076df8d
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR04MB0236;
x-microsoft-exchange-diagnostics: 1; DM5PR04MB0236; 7:qF7eUV7ast/y1s5vIet3UwQnjWZ8j2vj9botyFViebOkbvCpZ+GMHbAPEyfmSedP3KMspPiEer6etMuzJx7tBWAxBpvN5/R/ZKeKOyvmnMGuvTMHjbuDHYUBxjM64b4zcml+q4pWDJ++ls8wlzSGxKQ319SisQKZJ/R0rpDybcdoIogp/o7hQqvv/0c8KoAwkPztGhpw6gs7Zv3OH19JIpCZ/qoKEKV/nBwp5+fWMw6lqd3+NljK2HISGHkGSMuE5jE8rIWAKjwI8ur8Zrox9jAbtWqoYNcZfid1gEknmmfXiorr0WCqRAGH0I8FACNnfKofBkmDHNW/FQt71EoSinMDL2tF3onXMY/TRAuTdJMePb0yg1SV8u/WaEj4V+3ILqCF3SEZ6uw2NKLVxspXkZk1m3f4h8VMHv48/xCGJIyixQgcrqseeBn2r0Tj6IQp0la6hC952veVx6HtqFmraYmFEwZ0dnuAdBWXKiNCH0fX6BnVRXwwfcaxJ/DIg6+zbycNxvhX08I7IKK67xw3nQ==
x-microsoft-antispam-prvs: <DM5PR04MB0236E7CAF0E5722D100A96B6AF420@DM5PR04MB0236.namprd04.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)(2017020702029)(8121501046)(5005006)(20170203043)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:DM5PR04MB0236; BCL:0; PCL:0; RULEID:; SRVR:DM5PR04MB0236;
x-forefront-prvs: 0212BDE3BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(199003)(377454003)(54906002)(86362001)(8666007)(33656002)(4326007)(8676002)(102836003)(6116002)(92566002)(5660300001)(790700001)(54896002)(38730400002)(55016002)(74316002)(189998001)(6246003)(97736004)(81166006)(3846002)(101416001)(99286003)(3280700002)(236005)(7736002)(5890100001)(8936002)(6306002)(81156014)(105586002)(6506006)(7696004)(9686003)(122556002)(230783001)(53936002)(76176999)(54356999)(66066001)(229853002)(77096006)(2906002)(2950100002)(93886004)(6436002)(2900100001)(39060400001)(106116001)(25786008)(68736007)(50986999)(3660700001)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR04MB0236; H:DM5PR04MB0234.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ciena.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DM5PR04MB0234FAB6C3C76DC46B5F6BEDAF420DM5PR04MB0234namp_"
MIME-Version: 1.0
X-OriginatorOrg: ciena.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2017 23:04:45.2485 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 457a2b01-0019-42ba-a449-45f99e96b60a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR04MB0236
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/Lp7QNaEtkXeIUhCNK33Bk6keC18>
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: Wed, 08 Feb 2017 23:04:50 -0000

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not know about it...)

Following text from the draft –

   In multihoming single-active scenario, the DF election will determine
   who the primary and the backup PEs are, and only those PEs will set
   the P bit and B bit respectively. A remote PE will forward the
   traffic to the primary PE and switch over to the backup PE as soon as
   it receives an Ethernet A-D route withdrawal from the primary PE in
   the Ethernet Segment.
----
[Himanshu] the highlighted text is somewhat confusing in the context of
multiple backups (in single-active redundancy). How would remote PE know
which backup to switch over to.
----
   In multihoming single-active scenario, during transient situations, a
   remote PE receiving P=1 from more than one PE will select the last
   advertising PE as the primary PE when forwarding traffic. A remote PE
  receiving B=1 from more than one PE will select only one backup PE. A
   remote PE MUST receive P=1 from at least one PE before forwarding
----
[Himanshu] the above highlighted text seems to suggest that only one backup
is supported, contrary to what you suggest below that one primary
and one or more backups are supported.
---

It would be better if the draft clearly states that it will only support
One primary and one backup in single-active redundancy and one primary
and multiple backups are NOT supported (unlike EVPN..)

Also, for single-active redundancy, DF election is relegated to selection of
the role of multi-homed PEs to be primary or backup. Is this role determined
in the context of VLANs (bundled VLAN case), I am guessing NOT.
Clarifying text in this area would also be helpful.


Thanks,
Himanshu

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

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