Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

"Luc Andre Burdet (lburdet)" <lburdet@cisco.com> Tue, 25 September 2018 14:46 UTC

Return-Path: <lburdet@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 385701312DA; Tue, 25 Sep 2018 07:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 p0H05OLamMaF; Tue, 25 Sep 2018 07:46:15 -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 773D2131011; Tue, 25 Sep 2018 07:46:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47724; q=dns/txt; s=iport; t=1537886762; x=1539096362; h=from:to:cc:subject:date:message-id:mime-version; bh=GYc5DNotJXZ/7ikCzCRDf2CzzaGmRwEososgntMbxKA=; b=R8UHT1R+x0tAGhsvyYSGbN+rL/4ffd8v9OJHBH4zTizqMaqhJO+hH99X kvtlKmttg9t37y1vGH9WBG4YFXweDlDKNQFZu8ngOS32lm6CSO+R0m9OH 5Xop91RBYrjm1aK9BtfVx2ZMgXC6gS0mDBjJ048+BcubSPm0BilhsU2X2 o=;
X-Files: image001.png : 11763
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAAB3Sapb/4kNJK1ZAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVGBF3dlfygKg2qIFYwtgg2WThSBZggBAiUHg3pGAhe?= =?us-ascii?q?DTCE0GAEDAQECAQECbRwMhTgBAgEDBR4CCAE4BwwOBAEGAhEDAQIGAQEBGAc?= =?us-ascii?q?DAgQFDwEBDgwUCQoEDgQBBggGgw0BggEPh3ubTYEuigsPBYp1F4FBP4ESJx+?= =?us-ascii?q?CTIMbAQEBAQGBJgUBEgEmBwkJAQsKAgYJgjoxgiYCiCyFPoV1g0yBR4QNCQK?= =?us-ascii?q?FZAFcfIhqF4FFSoQHgwaGEIcbgVSDC4hoAhEUgSUdOGRxcBVlAYJBCYV5hRS?= =?us-ascii?q?FPm8BgRWKRYEfAYEdAQE?=
X-IronPort-AV: E=Sophos;i="5.54,302,1534809600"; d="png'150?scan'150,208,217,150";a="176488856"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Sep 2018 14:46:01 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id w8PEk18U002470 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Sep 2018 14:46:01 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 25 Sep 2018 09:46:00 -0500
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Tue, 25 Sep 2018 09:46:00 -0500
From: "Luc Andre Burdet (lburdet)" <lburdet@cisco.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org" <draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org>
CC: Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Alexander Ferdman <Alexander.Ferdman@ecitele.com>, Shell Nakash <Shell.Nakash@ecitele.com>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question
Thread-Index: AQHUVN55tl8Un8AnaEm9/Y0wrUsuuQ==
Date: Tue, 25 Sep 2018 14:46:00 +0000
Message-ID: <955DFADF-91C5-48F9-90C6-79C4AB5FB46C@cisco.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.2.180910
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.155]
Content-Type: multipart/related; boundary="_004_955DFADF91C548F990C679C4AB5FB46Cciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/5IS243f4SIsUZn72dv7159hrw_I>
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
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, 25 Sep 2018 14:46:18 -0000

Hi Sasha,

I agree the vES draft does not go in great detail about A/A PWs.

For A/A PWs terminating at peering PEs, the concept is similar to LAG, using static label at peering PEs:

  *   The CE sets up a single PW to remote endpoint to anycast IP1, Label1.
  *   PE1, PE2 set up a PW each to CE, using local static label Label1.
  *   PE1,PE2 adv IP1 as anycast IP towards CE-side
There will not be excessive MAC-moves since the CE sees only one pseudowire to a single remote—very similar to what is done for LAG on “real” links.

We can update the draft to be more descriptive—that draft needs a re-read anyways, the header on each page still reads “PBB-EVPN” ☺

HTH,
Luc André

[http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png]




Luc André Burdet
lburdet@cisco.com<mailto:lburdet@cisco.com>
Tel: +1 613 254 4814






Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Cisco.com<http://www.cisco.com/web/CA/>







From: BESS <bess-bounces@ietf.org> on behalf of Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Date: Tuesday, September 25, 2018 at 06:25
To: "draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org" <draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org>
Cc: Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com>, Alexander Ferdman <Alexander.Ferdman@ecitele.com>, Shell Nakash <Shell.Nakash@ecitele.com>, "bess@ietf.org" <bess@ietf.org>
Subject: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Dear authors of the EVPN Virtual Ethernet Segment<https://tools.ietf.org/html/draft-sajassi-bess-evpn-virtual-eth-segment-03> draft,
My colleagues and I have a question pertaining to support of All-Active redundancy mode in EVPN that uses virtual Ethernet Segments.

Section 8.5 of RFC 7432<https://tools.ietf.org/html/rfc7432#section-8.5> says:

   If a bridged network is multihomed to more than one PE in an EVPN
   network via switches, then the support of All-Active redundancy mode
   requires the bridged network to be connected to two or more PEs using
   a LAG.

   If a bridged network does not connect to the PEs using a LAG, then
   only one of the links between the bridged network and the PEs must be
   the active link for a given <ES, VLAN> or <ES, VLAN bundle>.  In this
   case, the set of Ethernet A-D per ES routes advertised by each PE
   MUST have the "Single-Active" bit in the flags of the ESI Label
   extended community set to 1.

This restriction is easy to understand, since, with the All-Active multi-homing mode of an Ethernet Segment, a CE attached to such a segment potentially would receive traffic from all the PEs attached to this  segment. Since A CE that is part of a bridged network must learn MAC addresses of the received traffic, it would potentially experience continuous MAC Move events – with undesirable consequences.

The EVPN Virtual Ethernet Segment draft replaces Ethernet links (forming a “real” ES) with Ethernet PWs, and claims support of both Single-homed and multi-homed multi-homing modes. When I compare these claims with the quoted above statement from RFC 7432, I see two possibilities:

  *   Either a CE that is connected to an All-Active vES cannot be part of a bridged network (and thus would not do any MAC learning)
  *   Or  an extension of LAG that deals with Ethernet PWs instead of Ethernet links is required.

Could you please clarify which of these two options is correct?

Note: The draft includes Informative references to the two drafts that have been published as RFC 7432 and RFC 7623.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________