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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Wed, 26 September 2018 08:58 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 57915130E1A; Wed, 26 Sep 2018 01:58:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.78
X-Spam-Level:
X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 n1qrjLX8gzLy; Wed, 26 Sep 2018 01:57:58 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D9A130DC2; Wed, 26 Sep 2018 01:57:57 -0700 (PDT)
Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-central-1.aws.symcld.net id CA/DC-29604-E0A4BAB5; Wed, 26 Sep 2018 08:57:50 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA2VTe0xTVxzm3DeOOw8F5QfDRWtMdNpKg5HOV9y yJWxqfMTn8LFbubRdyqVry6xGExKnGxSDy5gRgoKGIAKCAopBlFCSVcTNUdhIUEREklHjI3vo HIt6b09xLvvnl+/3fd/vcU7OEWhdJ58kyF6P7FIkh56bxCx4q9lrED+uzUjx9ZnN1YES2uz3L TYHQmWcue55PWV++MN+ZjmbXjx+jk2vrHxGraE+Ye2KJcf7KWvLr6hmnWdf0N7HRXV0Hmr8iy 5AkwQGn6Thq2ADpyU6XExBb96PDElGEAzfv6Em0QKHl0Jj7SCn4Xhsgbvf9/GaicY3Kfjp8RV aE+LwRmg9dIchpk3Q3n1QxYKK34fLg8s0msGzoLF1CGlYxBKcqxqhyLBOBPerCllNiFaHVT96 EjYhPBWeXqujNEzjBBi4Vx7GgONhuKebI3gKjI08Z4nfAkOjJxDhZ0BT2+8R/zQIlvuQNgxwB w8dZ/6JCCYInG6nCV4F/oaG8NKAZ0Lzr9uIvwJBWW8o4pkHY/kDkVon3B5v4ompCMHplksR09 tQc2iYIYKfhv5QO0+6JsORtr2EH+LgxaX91GFkKH3tdKXha81HMP5NL1UavqdY6Cq5xxCTAv3 Nv6BStReN50BD63xCz4Bi3zBP8Gw4UHaM/z8/D8afFHAT/M2fv2MJrkTwZ88HE57LvVXo9doK JNagdy0uu9XmyZbsDoMpJcVgMqUaFqpxoVHaY7AY5VzDTlnxuCRVNUq73Eb37uydjkyjInsak fpwMz/nPBfRyVNWP0oUKP0UcXthTYbuTUtO5m6b5LbtcOU6ZLcfJQuCHsSsj2ozdLEu2Sp7s+ wO9fVPyCDE6OPF1Zosup1StttuJdI19KFw9+jXR2nhYTjeKdHihev5auzToo5RchQ5KUFM1Yq xVmzLVV61nvhbQTQtKU5EUVFRuhin7Mq2e/6rh1CCgPRx4matS4xd8bzaIKQuR6nLHS6s1pbz SP9KSXlo9apF/B/pZeuvzjy/AiduYKZbKxPfuEGNrk1Z+ZmzpfzKOv3BfW0J9VuPpMrKQGfan D24fnK33vibD29iinP73+vqWDI2eVvPhpY04e+9gfmBzuNzHcv5Wwe6Rgu+WB/7LHnq9I5lac Gtp7JODC5OfxpMjP7ywbFv17JN9becuiJ2S4uecdsk0zu0yy29BMkUlUdWBAAA
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-24.tower-245.messagelabs.com!1537952265!408415!1
X-Originating-IP: [52.27.180.120]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.14.24; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 19364 invoked from network); 26 Sep 2018 08:57:48 -0000
Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR04-VI1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-24.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 26 Sep 2018 08:57:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SlaQeLIWZ9yy1U+ITkuLfmUkkdttYLxm1CNWPFXBo+8=; b=XoOv+/4Jws8ihsmR3Xrhou0g1xfxGd9Ak6iPBpteGrz7GkH3Om++2SiXUzAYPFnMlrLx21kAoB7v2sDuvPgpkxKPhADO+h26InuaxINY9kNd6Vf8PHwzZuHfpI8oVMwiSGr1Pu25PgnOv7dqz7SZn8Ae0qVgY+GZodrPjwDuy+0=
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com (10.167.226.155) by DB5PR0301MB1912.eurprd03.prod.outlook.com (10.167.227.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1164.25; Wed, 26 Sep 2018 08:57:44 +0000
Received: from DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::ec47:67c7:fbff:4125]) by DB5PR0301MB1909.eurprd03.prod.outlook.com ([fe80::ec47:67c7:fbff:4125%3]) with mapi id 15.20.1164.024; Wed, 26 Sep 2018 08:57:43 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: "Luc Andre Burdet (lburdet)" <lburdet@cisco.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>
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>, "draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org" <draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Thread-Topic: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question
Thread-Index: AQHUVN55tl8Un8AnaEm9/Y0wrUsuuaUBFDUA///jUoCAAUyohA==
Date: Wed, 26 Sep 2018 08:57:41 +0000
Message-ID: <DB5PR0301MB1909191E45A877E32D0F36539D150@DB5PR0301MB1909.eurprd03.prod.outlook.com>
References: <955DFADF-91C5-48F9-90C6-79C4AB5FB46C@cisco.com> <DB5PR0301MB190912073C9741CDF573A5209D160@DB5PR0301MB1909.eurprd03.prod.outlook.com>, <1BB94F7F-521D-4AC8-8CD7-4CCBC681B1F9@cisco.com>
In-Reply-To: <1BB94F7F-521D-4AC8-8CD7-4CCBC681B1F9@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [40.67.250.143]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR0301MB1912; 6:GTWDAc/AqmIgowXlMHxeKiwJV8Vm+v4JjYZH9bsf9mByWmj6FHHEl3aY+YQ8enTdZeX8k70Ec/a2umZ4jUf1e9TKb0yEtS/VmOYto4YNDbZA//sEOhW0YfKMZ1y6b2GTDYY4vwHpuzV9JSrONIbglgwqdExHBRbKo/d4yNIG5fnYQOa8ZVijbKB6lS7NGA1fp57AtBQ7guYtKCioUNlLRArSOmvR8OqqNLLUjDtfAGuDXv83mOtKW7+GpVb/tPw2Nuznrj0l0Ev/OZYNCFc6NjdD1s+H3ijxjj9K1BwuMUqMdhyzLaiC7OFUeirlDjB5UNC6T/CVrqmQ6j2azSpmwDfErGxzBwegzwnjlqS1dCwwPSnV+xEjTANAO5ONjD8cS69iU2q5XrGBLPojS3QCk2UgF0mm8w6SaTPmIh1A8B8PX4eGOFUpiWRLfGwRCJOSrQbBeDYbkqCK0B6/RIACVw==; 5:l+zvwrVnjm1b4LpGOiIpR0SSf6dhwJhTJRbx3zj2iH9haxPKdpNpSfcYMujeUu4Lmdjx1Ouz2oKFApmu02WjUPELhJ2Ik6a+UW6hRo+YAnbobuea3+7TtQ1KAEHD4paXcY0ILeregTfW7IFz88pjrQVsVJ4MpK4v46Gii7XQRUI=; 7:ToNmGTfxQaxzAxRGCvKuBuj6RNHOrrFdlFGpFNO+LO14z+I9648EfxxlDX7+fW9YyJpk1BvUlfw65w6kHsm88Mu+jITfKsLVLHbrj2zyXfOh/oXgAk06BTUQmMvTfh7818t8zNeWmfMRy+y0UL8ONhPjPPXi/BhlX/3euLEz+S6PWTXlLvs4lpP+U928zHR9Wm8N4CB3o+xb62Gjh1f7mkn06CMfBRh4Gf0W1i6dcCJscuYa7TJM0AHXKthMcu7Q
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-ms-office365-filtering-correlation-id: 13fe364d-c543-4386-a636-08d6238e1ef9
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB5PR0301MB1912;
x-ms-traffictypediagnostic: DB5PR0301MB1912:
x-microsoft-antispam-prvs: <DB5PR0301MB1912D93DAA782D209816FC249D150@DB5PR0301MB1912.eurprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(95692535739014)(279101305709854)(154440410675630)(138986009662008)(21532816269658)(114627819485645);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231355)(944501410)(52105095)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051); SRVR:DB5PR0301MB1912; BCL:0; PCL:0; RULEID:; SRVR:DB5PR0301MB1912;
x-forefront-prvs: 08076ABC99
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(346002)(136003)(376002)(39860400002)(189003)(199004)(252514010)(51444003)(6116002)(54896002)(99936001)(6306002)(3846002)(7736002)(229853002)(33656002)(5250100002)(97736004)(68736007)(561944003)(5660300001)(6436002)(74316002)(733005)(55016002)(66066001)(76176011)(11346002)(476003)(316002)(446003)(486006)(25786009)(106356001)(4326008)(26005)(2900100001)(99286004)(34290500001)(71190400001)(71200400001)(7696005)(256004)(14444005)(5024004)(2906002)(6246003)(14454004)(236005)(9686003)(86362001)(53936002)(54556002)(606006)(102836004)(6506007)(8676002)(53546011)(81166006)(105586002)(478600001)(81156014)(110136005)(8936002)(72206003)(54906003)(16866105001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR0301MB1912; H:DB5PR0301MB1909.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: xQHk8GkVsR1ld8rHrBbAUjyJiOKKBMF00fATo1VcJbV02Q1ZNMaOxZEV4Sb91oO5TPe2oMazt81XuKibhakjBEk7TlhSgo1IP3WJhFeQks6bUpSuhNxBNF332uV94MFstx5l9NNBEAeLP+E8wMOuxCMJZrLIYxf7tB1/G9xzjaZjorAU9/0nDtzMFZFcJIykrWi9uaGFx0CStLpHByf6AFMAGmx4UmZXn8fNPqbPIA2qCvexO0BoefFdxbcnwG+Ms6mRQSFwNUhpNIDoe4aos/vL/Ji0TMx96t97BaPnJQYIqYV07KlXl0L6qEjlqbS9qGf4y4eTB+Xn2/R7d88QhXElKU8SyawcrZyPJyYW57U=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/related; boundary="_004_DB5PR0301MB1909191E45A877E32D0F36539D150DB5PR0301MB1909_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 13fe364d-c543-4386-a636-08d6238e1ef9
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2018 08:57:42.9017 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR0301MB1912
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/fMAUvEjfqt0bB8jOyKeLfsBnGb8>
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: Wed, 26 Sep 2018 08:58:02 -0000

Ali,
Lots of thanks for a prompt response.

I fully understand how the scheme described by Luc could work.
But I have some doubts regarding it matching the standard PW architecture.

First of all, tbis scheme mandates usage of static PW labels - I do not think this is common, not even with MPLS-TP (where, at least nominally, you could still advertise PW labels using targeted LDP session between the pair of PEs).

There are some generic PW mechanisms that cannot be used (e.g., sequencing). This may be a minor issue because "fat PWs" (RFC 6391) also do not allow sequencing.

And there may be more - e.g., I doubt you could use static PW status messages (RFC 6478) with this construct...

So I think that asking the PALS WG (that, from my POV, is the body that has the authority to decide what is and what is not a PW) position on this construct  makes sense.



Thumb typed by Sasha Vainshtein

________________________________
From: Ali Sajassi (sajassi) <sajassi@cisco.com>
Sent: Tuesday, September 25, 2018 7:07:00 PM
To: Alexander Vainshtein; Luc Andre Burdet (lburdet)
Cc: Michael Gorokhovsky; Alexander Ferdman; Shell Nakash; bess@ietf.org; draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org; pals@ietf.org
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

Hi Sasha,

What Luc mentioned below can work with any of the existing model supporting static PW because the pair of EVPN PEs terminating vES (with PW termination) act and look like a single logical PE to the CE. Therefore, the CE sees its PW being terminated by a single logical PE. EVPN provides the synch mechanism between the pair of PEs running vES. I agree with Luc that an example can be provided in the draft to describe how All-Active vES can be supported with PWs.

Cheers,
Ali

From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Date: Tuesday, September 25, 2018 at 8:09 AM
To: "Luc Andre Burdet (lburdet)" <lburdet@cisco.com>
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>, "draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org" <draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: RE: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question
Resent-From: <alias-bounces@ietf.org>
Resent-To: Cisco Employee <sajassi@cisco.com>, <pbrisset@cisco.com>, <richard.schell@verizon.com>, <jdrake@juniper.net>, <jorge.rabadan@alcatel-lucent.com>
Resent-Date: Tuesday, September 25, 2018 at 8:09 AM

Luc,
Lots of thanks for a prompt and highly informative response.

I am adding the PALS WG to the CC list since, from my POV, your proposal goes beyond the PW network reference model as shown in Figure 2 of RFC 3985<https://tools.ietf.org/html/rfc3985>.
While this model has been extended to cover multi-segment PWs (RFC 6073<https://tools.ietf.org/html/rfc6073>) PW redundancy (RFC 6718<https://tools.ietf.org/html/rfc6718>) and ICCP (RFC 7275<https://tools.ietf.org/html/rfc7275>)  none of these extensions seem to be directly applicable to the proposed scheme.

My 2c,
Sasha

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

From: Luc Andre Burdet (lburdet) [mailto:lburdet@cisco.com]
Sent: Tuesday, September 25, 2018 5:46 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; 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
Subject: Re: [bess] All-Active Multi-homing and Virtual Ethernet Segments: A Question

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<mailto:bess-bounces@ietf.org>> on behalf of Alexander Vainshtein <Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>>
Date: Tuesday, September 25, 2018 at 06:25
To: "draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org<mailto:draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org>" <draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org<mailto:draft-sajassi-bess-evpn-virtual-eth-segment.authors@ietf.org>>
Cc: Michael Gorokhovsky <Michael.Gorokhovsky@ecitele.com<mailto:Michael.Gorokhovsky@ecitele.com>>, Alexander Ferdman <Alexander.Ferdman@ecitele.com<mailto:Alexander.Ferdman@ecitele.com>>, Shell Nakash <Shell.Nakash@ecitele.com<mailto:Shell.Nakash@ecitele.com>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto: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<mailto: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.
___________________________________________________________________________

___________________________________________________________________________

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.
___________________________________________________________________________


___________________________________________________________________________

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.
___________________________________________________________________________