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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Thu, 12 May 2016 18:13 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 CC74E12D506 for <bess@ietfa.amsl.com>; Thu, 12 May 2016 11:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 EJ-uECMMg05B for <bess@ietfa.amsl.com>; Thu, 12 May 2016 11:13:48 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0123.outbound.protection.outlook.com [207.46.100.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F365C12D14B for <bess@ietf.org>; Thu, 12 May 2016 11:13:47 -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=u0H45MqM5SMscnIKoh/soQvr7zf7Vkw9LiEen1VF+GA=; b=i5K3Ec4muztE93UYOW4dKw6D+q7oST/IvkQTdwIpn2iT5iTg3A3F2vlU11ibhsw0zhwAGteA1G3b+pEPO2v3sWnJUcgLEs7vSkPfAEFd8T72nF+hjKevHDHPieJbEPEFb5i5Q+R7HrYYUaqbSGAPzB0tDPkrAGVcC0Kxkj9KBYk=
Received: from BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) by BLUPR0501MB1715.namprd05.prod.outlook.com (10.163.120.18) with Microsoft SMTP Server (TLS) id 15.1.492.11; Thu, 12 May 2016 18:13:46 +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.0492.019; Thu, 12 May 2016 18:13:46 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, BESS <bess@ietf.org>
Thread-Topic: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03
Thread-Index: AQHRqgOZUf2Jc4CuVk++VehXUPZTSJ+0A3aAgAEvuwCAABsloIAAS0CAgAABZGA=
Date: Thu, 12 May 2016 18:13:46 +0000
Message-ID: <BLUPR0501MB1715614BA316E6074D89ECBBD4730@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> <5104CBC4-8EB4-42A9-BDE8-6AC0F5B55848@alcatel-lucent.com> <BLUPR0501MB171553FF47FD1D6E368A6015D4730@BLUPR0501MB1715.namprd05.prod.outlook.com> <6995A832-0932-403E-A6A0-6604A64B8630@alcatel-lucent.com>
In-Reply-To: <6995A832-0932-403E-A6A0-6604A64B8630@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [66.129.241.12]
x-ms-office365-filtering-correlation-id: ac4af863-501a-4ced-e81e-08d37a9128c0
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB1715; 5:BFUyVHGRrpzjk0LYU39JfSCgafB64ymy0MQG8bZM6NDOc3Bp6pUTm86cZ/dAuQrFtsv4z/sC7ilXzC9sIk3r6tmIGdNMZHMr2jRtOeFx16FBT6Tj7qK+GFMfubiEY401cDtobh2jnvcITVqBJxCD/A==; 24:+nVB572xcfII88s94K/Zw5uuiydIq5bIPgofXSIoriGq0YQ/CtmAW4qoW61KBgjsfaxgtwDhLhH6JXgJww3JKcgtRl6eTKGz1PavpznI9II=; 7:TEJP1Ft4Rq0Z+BIpsCTXAkmnw2izkwlCmZcM8MWRkL9q7Se+VZM21l2aXE5BNVwO247AgfFAwODOCzL387Yg9GU9cO9NuImf56fQQfSoeIgGGi7yw8LN548Y7fEEdUka1I2UdaGAiHirh2mMUEv01DrXbiinzl6MgoLUxM3uZQ+fPPvWsqr8Hk5Jksa0rmP2
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1715;
x-microsoft-antispam-prvs: <BLUPR0501MB1715B363ADD5303C07647EDBD4730@BLUPR0501MB1715.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BLUPR0501MB1715; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1715;
x-forefront-prvs: 0940A19703
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(8936002)(86362001)(66066001)(92566002)(5002640100001)(87936001)(3280700002)(5008740100001)(2906002)(2900100001)(122556002)(3660700001)(2950100001)(5004730100002)(93886004)(106116001)(11100500001)(5001770100001)(99286002)(107886002)(77096005)(189998001)(102836003)(6116002)(3846002)(1220700001)(9686002)(76576001)(76176999)(54356999)(50986999)(586003)(81166006)(74316001)(10400500002)(5003600100002)(230783001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1715; H:BLUPR0501MB1715.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2016 18:13:46.0699 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1715
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/HGGuVVrkbCXDxm56b_FQhBYg3W4>
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: Thu, 12 May 2016 18:13:50 -0000

Hi Jorge,

> >If a PE sends a route w/o setting P-bit, wouldn't that indicate it is a
> backup? Why would it bother sending the route if it does not want to be
> the backup?
> 
> [JORGE] Let’s assume you have 3 PEs in ES-1 (PE1/2/3) that is a single-
> active ES. PE4 is a remote PE doing backup function.

I assume PE4 is not "doing backup function" but is just one end of the PW. Or perhaps you mean it needs to decide which of PE1/2/3 is the primary/backup.

> - PE1 is the primary - the winner of the DF election. PE1 sends P=1
> - PE2 is the backup - the winner of the DF election (without PE1). PE2
> sends B=1.

Hmm ... DF election is for BUM in RFC 7432 and never mentioned in this draft. If it is used for VPWS, it needs to be specified.

The draft says multiple PEs could all set the P/B bits:

   In multihoming single active scenario, a remote PE receiving P=1 from
   more than one PE will select only one 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 traffic.

And the decision is based on the receiving PE, not on DF election?

> - PE3 then sends P=B=0. This indicates that PE3 is neither primary nor
> backup, but the AC is active (if it was oper-down, it would withdraw the
> route).

What purpose does the route from PE3 serve?

> - In case of a failure on PE1, PE2 will activate its AC on ES-1 since he
> wins the new DF election.

What does "activate" involve exactly? Just re-advertise the route with P-bit set and B-bit cleared?

> At the same time, PE4 can immediately send
> traffic to PE2 as soon as PE1 withdraws the AD routes. PE4 does not even
> need to wait for the confirmation that PE2 is the new DF. This backup
> mechanism speeds up convergence big time.
> - The mechanism above does not work if PE2 and PE3 send both the same
> P=B=0, since it case of PE1 failure, PE4 could not send any traffic (it
> does not know who is the active one in the ES) and would need to wait for
> PE2 to send P=1.

I don't see any use of the route from PE3. The draft seems to say that both PE1 and PE2 can set the P bit initially and PE4 will pick one to send traffic to. If it picks PE1 and then PE1 withdraws the route, PE4 will then pick PE2?

Jeffrey