Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming
Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Thu, 07 March 2019 10:43 UTC
Return-Path: <muthu.arul@gmail.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 7BD5B13136C for <bess@ietfa.amsl.com>; Thu, 7 Mar 2019 02:43:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 xHs7Sc82h2iS for <bess@ietfa.amsl.com>; Thu, 7 Mar 2019 02:43:28 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27041130ED1 for <bess@ietf.org>; Thu, 7 Mar 2019 02:43:27 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id z23so11306437lfe.0 for <bess@ietf.org>; Thu, 07 Mar 2019 02:43:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3OJrSkSC2Z5DVoakPeCRKr2GWEoM47hBMk53rE345eE=; b=ObDVdB3W+ghYyUFvZkoVHn4LROTHJYdh8Uz+LedXmw6C4fsuITLsZhkVQZvHJAZX20 qSUdYGHdtmIlQ7kF6SQsb7a6uRc77EZ9HcJQjt52Gb50l5AJSybHXM48ile+45ZCJ0Uv WE/HVy0sWU4aqRP6FjEFurQYGfysp6Z5YlU7/2A6JO2Rhi0e4w8JsXfA26ogtXJBSx36 p7D9+o7TbSfnN4GZH9ojlqBOuj38SbnduKuRPO+2+FUyVcuM/VDBX0Zn4XLHo3iNrwQt jb3mqls73tcdU4ItoiC9c/oItInBSVLrJDdhzm26/tgTks8HLHAlX5jBY2zj8CPE7/S6 eiNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3OJrSkSC2Z5DVoakPeCRKr2GWEoM47hBMk53rE345eE=; b=DV1M1w+SEsFtT1WeuFSf44w5KPQR7fNmsHoydzFcSRmIhTKYvNknxD0FKp9/u449hI POmQcfJunRkofMgeloIAyauLSkI18egHe5jPAt+DMKXBHwBiobRQuDf9tcZnLrqLLFJV rVNvXoCZNzJmfvTd/B5dhAg6lHWJUauxSSzDD3PXNd4Gc4ihiwuAzmeuHTQ4C3ZuhW3j GFY/1WyV+xEYp+UB+zQSPH6HyLEkh8ubOTX0j8klFeUWz5crsXEDPS1f+Cb3ZNeEOv3a C//fzD/WRqHvqTt/pDG0J8NO2Veq7Uy3UjTEBTNTc82INP2WDUraDGstajSxrrDMsdVe EIhQ==
X-Gm-Message-State: APjAAAV8OtxstQKKzL+rk+HZ6FQEiGLjUPZm0Z1TAeeRAJMFivg87E82 BLTDH264HtTT4PtDf/xtYuDyMLQhSXp2K/9EFfQ=
X-Google-Smtp-Source: APXvYqw5dBF/aehPAsZ++rbrswzZm6nTGFa1IlND5iN6dEKgcBLuufuAu9Cfb09XyOtWvlkpsjba40srtL9KcxrxMzs=
X-Received: by 2002:a19:c94e:: with SMTP id z75mr6749911lff.33.1551955405142; Thu, 07 Mar 2019 02:43:25 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR07MB4462872475A375E50C33F4C8E2730@VI1PR07MB4462.eurprd07.prod.outlook.com> <VI1PR07MB44620DB939F1ABE51DDED5B6E2730@VI1PR07MB4462.eurprd07.prod.outlook.com> <CAP3Cv1beDHnU0oBheDiG4863QC8vcgMpNkOy9JjkfiFgAWuFkw@mail.gmail.com> <478004F5-9B6E-49F0-9203-57F4953520DB@cisco.com> <CAKz0y8xbMQgWqYk18+zG4_NBF2O+iFGE_+aOzd1LKkMgdNc-1Q@mail.gmail.com> <AM0PR03MB382895A563A69BE489B656319D4C0@AM0PR03MB3828.eurprd03.prod.outlook.com>
In-Reply-To: <AM0PR03MB382895A563A69BE489B656319D4C0@AM0PR03MB3828.eurprd03.prod.outlook.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Thu, 07 Mar 2019 16:07:15 +0530
Message-ID: <CAKz0y8xoq5H3pyj37znZY6R2YMs7AtZERqa+GJyE-0x_MOzE7g@mail.gmail.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: chalapathi andhe <chalu.ietf@gmail.com>, Sean Wu <sean.wu@ericsson.com>, Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>, "bess@ietf.org" <bess@ietf.org>, "chalapathi.andhe@ericsson.com" <chalapathi.andhe@ericsson.com>, "Luc Andre Burdet (lburdet)" <lburdet@cisco.com>
Content-Type: multipart/related; boundary="000000000000a19d1005837ec6a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/rW2JAlSg4fWaw1GZLbXzhi03P3o>
Subject: Re: [bess] FW: Regarding the Alias label usage in EVPN Multihoming
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: Thu, 07 Mar 2019 10:43:32 -0000
Thanks, Sasha. Is my understanding for the all-active case correct? It should be noted that in the scenario described by Chalapathi, only PE1 advertises the MAC/IP route for MAC1. PE2 and PE3 advertise only alias labels.. Regards, Muthu On Thu, Mar 7, 2019 at 3:40 PM Alexander Vainshtein < Alexander.Vainshtein@ecitele.com> wrote: > > > Muthu and all, > > Quoting from Section 14.1.1 “Single-Active Redundancy Mode” of RFC 7432: > > > > If the primary PE encounters a failure, it MAY withdraw its set of > > Ethernet A-D per ES routes for the affected ES prior to withdrawing > > its set of MAC/IP Advertisement routes. > > > > If there is only one backup PE for a given ES, the remote PE MAY use > > the primary PE's withdrawal of its set of Ethernet A-D per ES routes > > as a trigger to update its forwarding entries, for the associated MAC > > addresses, to point towards the backup PE. As the backup PE starts > > learning the MAC addresses over its attached ES, it will start > > sending MAC/IP Advertisement routes while the failed PE withdraws its > > routes. This mechanism minimizes the flooding of traffic during > > fail-over events. > > > > If there is more than one backup PE for a given ES, the remote PE > > MUST use the primary PE's withdrawal of its set of Ethernet A-D per > > ES routes as a trigger to start flooding traffic for the associated > > MAC addresses (as long as flooding of unknown unicast packets is > > administratively allowed), as it is not possible to select a single > > backup PE. > > > > So there are actually three sub-cases in the single-active redundancy mode > use case: > > 1. The single-active multi-homed ES has been advertised by exactly > two PEs. In this case withdrawal of the per-ES Ethernet A-D route by the > primary PE may result in other PEs sending the unicast traffic for MAC > addresses learned from this ES to the secondary PE using the alias labels > advertised for the corresponding EVI in the per-EVI Ethernet A-D routes. > > 2. The single-active multi-homed ES has been advertised by three > or more PEs, and flooding of unknown unicast is allowed. In this case > withdrawal of the per-ES Ethernet A-D route by the primary PE MUST result > in flooding of the unicast traffic with unlearned MAC addresses using the > common scheme for BUM traffic. The Aliasing labels are not relevant for > this use case. > > 3. The single-active multi-homed ES has been advertised by three > or more PEs, and flooding of unknown unicast is not allowed. In this case > withdrawal of the per-ES Ethernet A-D route by the primary PE MUST in just > local flooding of the unicast traffic with unlearned MAC addresses. > > > > Hope this helps. > > My 2c, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > *From:* BESS <bess-bounces@ietf.org> *On Behalf Of *Muthu Arul Mozhi > Perumal > *Sent:* Thursday, March 7, 2019 8:53 AM > *To:* Luc Andre Burdet (lburdet) <lburdet@cisco.com> > *Cc:* chalapathi andhe <chalu.ietf@gmail.com>; Sean Wu < > sean.wu@ericsson.com>; Jaikumar Somasundaram < > jaikumar.somasundaram@ericsson.com>; bess@ietf.org; > chalapathi.andhe@ericsson.com > *Subject:* Re: [bess] FW: Regarding the Alias label usage in EVPN > Multihoming > > > > My understanding: > > > > For the single-active case in the diagram below, when PE4 receives the A-D > per ES route withdraw it won't know whether PE2 or PE3 will become the new > primary/DF for the <ES, VLAN>, so it will start flooding the traffic > destined to MAC1. Then either PE2 or PE3 will become the new primary/DF for > the <ES, VLAN> and advertise the MAC/IP route for MAC1. PE4 will then start > sending the traffic destined to MAC1 to the new primary. > > > > For the all-active case, when PE4 receives the A-D per ES route withdraw > it will update the nexthop list for MAC1 by removing PE1 from that list. > PE4 will then load balance the traffic destined to MAC1 by send it to PE2 > and PE3 using alias label. > > > > Regards, > > Muthu > > > > On Wed, Mar 6, 2019 at 7:51 PM Luc Andre Burdet (lburdet) < > lburdet@cisco.com> wrote: > > Hi Chalu, > > > > Please read 7432 s.8.4: in single-active it is not an aliasing > label/procedure but a backup-path procedure. > > It will answer your questions (both, actually). > > > > There is no flooding once the MAC is learnt & distributed: cf. that’s the > point. > > > > > > [image: > http://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/09_standard_graphic.png] > > *Luc André Burdet* > > 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 chalapathi andhe < > chalu.ietf@gmail.com> > *Date: *Wednesday, March 6, 2019 at 04:15 > *To: *"bess@ietf.org" <bess@ietf.org> > *Cc: *Sean Wu <sean.wu@ericsson.com>, Jaikumar Somasundaram < > jaikumar.somasundaram@ericsson.com>, "chalapathi.andhe@ericsson.com" < > chalapathi.andhe@ericsson.com> > *Subject: *Re: [bess] FW: Regarding the Alias label usage in EVPN > Multihoming > > > > > > > > Hi All, > > > > Can you please help us on the following issue. > > In the following diagram, PE1, PE2, PE3 are connected to the same ES [ES1] > in Single active mode, and PE4 is a remote PE. > > Let’s say PE1 is advertising the MAC1 route, PE4 will install the MAC1 > with the PE1 as primary path with MAC Label, > > and PE2, PE3 as backup with the Alias Label. Now if the PE1 to CE1 link > goes down, then PE1 withdraw the EAD/ES route > > which will be processed by PE4. > > Now what should the forwarding state at PE4 ?, PE4 should update the > forwarding state of MAC1 with the PE2, PE3 Alias label > > and any traffic destined to MAC1 should be flooded to PE2, PE3 with the > Alias labels ? > > Or packet should be flooded to PE2, PE3 with the Flood labels ? Or should > it be some other method ? > > > > In similar if the ES is operating in all active mode, what should be the > forwarding state at PE4 ? > > PE4 should update the forwarding state of MAC1 with the PE2, PE3 Alias > label > > and any traffic destined to MAC1 should be sent to either PE2 or PE3 with > the Alias labels [ not flood to both] ? > > Or packet should be flooded to PE2, PE3 with the Flood labels or Alias > Label ? > > Or should it be some other method ? > > > > > > [image: cid:1695247dcc04ce8e91] > > > > > > Thanks, > > Chalapathi. > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess > > > ___________________________________________________________________________ > > 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. > ___________________________________________________________________________ >
- Re: [bess] FW: Regarding the Alias label usage in… chalapathi andhe
- Re: [bess] FW: Regarding the Alias label usage in… Luc Andre Burdet (lburdet)
- Re: [bess] FW: Regarding the Alias label usage in… Muthu Arul Mozhi Perumal
- Re: [bess] FW: Regarding the Alias label usage in… Alexander Vainshtein
- Re: [bess] FW: Regarding the Alias label usage in… Muthu Arul Mozhi Perumal