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