Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03
"Ali Sajassi (sajassi)" <sajassi@cisco.com> Thu, 12 May 2016 19:06 UTC
Return-Path: <sajassi@cisco.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 2158312D0DC for <bess@ietfa.amsl.com>; Thu, 12 May 2016 12:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1lzc0gVsgbdW for <bess@ietfa.amsl.com>; Thu, 12 May 2016 12:06:28 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D02A12B054 for <bess@ietf.org>; Thu, 12 May 2016 12:06:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5099; q=dns/txt; s=iport; t=1463079987; x=1464289587; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bh9UtpeNRxQ3mP6rGgCp0JRYvvmv4Y5M3pD5TH2J4lQ=; b=BQoQg/qGYjk1O7H/IKtVFXiPNsoUT714GAtvRZ6/6Lu1qBXUsyM2bKzg G0LgsI9mKGIJDZR0zlzl5WhA9FdjF3QFMk1mN5y7X9w2slCsNztBSYgQA aSNvJ4OPu1bhx1b+kZC8XpDmvr/+MHVREA6VHyNeFAu54tqNvc67KmKb9 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D1AQAz0zRX/5tdJa1egzhVfga5TwENgXYXC4VyAoE5OBQBAQEBAQEBZSeEQgEBAQQBAQFrGwIBCBguJwscCQIEARKILw69PQEBAQEBAQEBAgEBAQEBAQEbBYpxhAg3hVkFmCcBjh2PGY9AAR4BAUKCNoE1boZzBzh/AQEB
X-IronPort-AV: E=Sophos;i="5.24,610,1454976000"; d="scan'208";a="271351509"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 May 2016 19:06:26 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4CJ6Q8R009859 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 May 2016 19:06:26 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 May 2016 15:06:25 -0400
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1104.009; Thu, 12 May 2016 15:06:26 -0400
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: "Rabadan, Jorge (Nokia - US)" <jorge.rabadan@nokia.com>, "EXT Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, BESS <bess@ietf.org>
Thread-Topic: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03
Thread-Index: AQHRqgOigs1vmDHL7ke56MFH0t6l15+0UJ6AgAElogCAACFugIAARPaAgAAGbwCAAAPkAP//lXaA
Date: Thu, 12 May 2016 19:06:25 +0000
Message-ID: <D35A1CAC.1993D7%sajassi@cisco.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> <BLUPR0501MB1715614BA316E6074D89ECBBD4730@BLUPR0501MB1715.namprd05.prod.outlook.com> <D87BD154-EAD0-4635-9BF3-81233984EE87@alcatel-lucent.com>
In-Reply-To: <D87BD154-EAD0-4635-9BF3-81233984EE87@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.76.60]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <6176B7C2C4777848AF1BE94B3DB63765@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/Nj-kTV9SCHdZhbPm29Bwpy73EIs>
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 19:06:30 -0000
Hi Jeffrey, This is a draft based on RF7432 and as such we are expecting tag manipulation wrt vlan-based service to be consistent with RFC 7432. Additional comments below Š On 5/12/16, 11:27 AM, "BESS on behalf of Rabadan, Jorge (Nokia - US)" <bess-bounces@ietf.org on behalf of jorge.rabadan@nokia.com> wrote: >HI Jeffrey, > > >On 5/12/16, 8:13 PM, "BESS on behalf of EXT Jeffrey (Zhaohui) Zhang" ><bess-bounces@ietf.org on behalf of zzhang@juniper.net> wrote: > >>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. > >[JORGE2] by ³doing backup function² I mean that PE4 sets up a destination >to PE1 with a backup to PE2. Aliasing and Backup functions are >effectively done by the remote PEs based on the information advertised by >the PEs in the ES, right? Just as in RFC7432, Eth A-D per ES indicates what kind of multi-homing is associated with this ES (all-active versus single-active). The P/B bits in Eth A-D per EVI, indicates active/backup role per instance and its usage is recommended for multi-homing but not needed for dual-homing. > >> >>> - 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. > >[JORGE2] In VPWS DF election is needed for single-active. The NDF will >block the AC for the service. For all-active there is no DF, of course, >since there is no BUM ;-) Yes, forwarding decision is based on VLAN tag and not based on MAC addressses, so there is no notion of known unicast versus BUM traffic here. > >> >>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? > >[JORGE] This is BGP, there are always transient situations, so it may >happen that even in single active you get more than one P=1 or B=1, so >you need to say what to do in that case, right? In a steady situation, in >single-active MH, only the DF MUST send the P=1 since it is only the DF >the one unblocking the AC in the ES. We should add some text to the draft to indicate ³reception of multiple P=1² is for transient situation. > >> >>> - 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? > >[JORGE] since the AC is oper-up on PE3, PE3 needs to send the route. At >PE4 you know that PE3¹s AC in the ES is good, but simply neither primary >nor backup. E.g., it can be considered as 2nd backup. -Ali > >> >>> - 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? > >[JORGE] unblock Tx/Rx on the ACŠ and later readvertise the route with the >new bits. > >> >>> 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? > >[JORGE] This is single active, so only one can transmit/receive to/from >the CE. So only that one should send P=1. > >> >>Jeffrey >>_______________________________________________ >>BESS mailing list >>BESS@ietf.org >>https://www.ietf.org/mailman/listinfo/bess > >_______________________________________________ >BESS mailing list >BESS@ietf.org >https://www.ietf.org/mailman/listinfo/bess
- [bess] WG Last Call (including implem status & sh… Martin Vigoureux
- Re: [bess] WG Last Call (including implem status … Rabadan, Jorge (Nokia - US)
- Re: [bess] WG Last Call (including implem status … UTTARO, JAMES
- Re: [bess] WG Last Call (including implem status … Nabeel Cocker
- Re: [bess] WG Last Call (including implem status … Patrice Brissette (pbrisset)
- Re: [bess] WG Last Call (including implem status … Ali Sajassi (sajassi)
- Re: [bess] WG Last Call (including implem status … Thomas Morin
- Re: [bess] WG Last Call (including implem status … thomas.morin
- [bess] FW: WG Last Call (including implem status … John E Drake
- Re: [bess] WG Last Call (including implem status … John E Drake
- Re: [bess] FW: WG Last Call (including implem sta… Jeffrey (Zhaohui) Zhang
- Re: [bess] FW: WG Last Call (including implem sta… Rabadan, Jorge (Nokia - US)
- Re: [bess] FW: WG Last Call (including implem sta… Jeffrey (Zhaohui) Zhang
- Re: [bess] FW: WG Last Call (including implem sta… Rabadan, Jorge (Nokia - US)
- Re: [bess] FW: WG Last Call (including implem sta… Jeffrey (Zhaohui) Zhang
- Re: [bess] FW: WG Last Call (including implem sta… Rabadan, Jorge (Nokia - US)
- Re: [bess] FW: WG Last Call (including implem sta… Ali Sajassi (sajassi)
- Re: [bess] FW: WG Last Call (including implem sta… Jeffrey (Zhaohui) Zhang
- Re: [bess] FW: WG Last Call (including implem sta… Ali Sajassi (sajassi)
- Re: [bess] FW: WG Last Call (including implem sta… Sami Boutros
- Re: [bess] FW: WG Last Call (including implem sta… Jeffrey (Zhaohui) Zhang
- Re: [bess] FW: WG Last Call (including implem sta… Sami Boutros
- Re: [bess] FW: WG Last Call (including implem sta… Jeffrey (Zhaohui) Zhang
- Re: [bess] FW: WG Last Call (including implem sta… Sami Boutros
- Re: [bess] FW: WG Last Call (including implem sta… Jeffrey (Zhaohui) Zhang
- Re: [bess] WG Last Call (including implem status … Martin Vigoureux
- Re: [bess] WG Last Call (including implem status … Jeff Tantsura
- Re: [bess] FW: WG Last Call (including implem sta… Jeffrey (Zhaohui) Zhang
- Re: [bess] WG Last Call (including implem status … Sami Boutros
- Re: [bess] FW: WG Last Call (including implem sta… Sami Boutros
- Re: [bess] FW: WG Last Call (including implem sta… Rabadan, Jorge (Nokia - US)
- Re: [bess] FW: WG Last Call (including implem sta… Jeff Tantsura
- Re: [bess] FW: WG Last Call (including implem sta… UTTARO, JAMES
- Re: [bess] FW: WG Last Call (including implem sta… Sami Boutros
- Re: [bess] WG Last Call (including implem status … Thomas.Beckhaus
- Re: [bess] WG Last Call (including implem status … Martin Vigoureux
- Re: [bess] WG Last Call (including implem status … Sami Boutros