Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Thu, 04 October 2018 15:37 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 8CAAF130E48 for <bess@ietfa.amsl.com>; Thu, 4 Oct 2018 08:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 Ym3MB5CtYcGP for <bess@ietfa.amsl.com>; Thu, 4 Oct 2018 08:37:23 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 C14A812008A for <bess@ietf.org>; Thu, 4 Oct 2018 08:37:22 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id o21-v6so7142649lfe.0 for <bess@ietf.org>; Thu, 04 Oct 2018 08:37:22 -0700 (PDT)
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=pfUjq99dNz/hoBRIbhNiX5MRVfecCNea1ZbbcaNNn/Y=; b=EvC6T0kbEGmaTZUtES+h9RDi4Yk4RTBAVXkAoYyHfXVyft8pjbUqxdmX3Z3e+fTOR/ ENBchudSqoMjgbJgYWFiBBZTz+CbDCphJlpTqzJnX8/aPnJeRI80gp9YMW1sjlAabqE9 d5Lsx+831MSQBEvN4gm65YZqqxdy5Xp9k4DbYrCkL2goOkblKPhXGsUO7e6Y+e84i3g5 bR4YGQzZjhQ9EXqp9Zhr40ISa9fcDCpQ+bOTexbNVaFPjHD9ChfEqd3QQdO6HT23C8uW 8B4hRxz/1uI6txY5VrLAp9DEOWG38oi9kzxr0rGxw9HeYJRC0O0kqVUA3PsDRYSGjGHM Mvrw==
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=pfUjq99dNz/hoBRIbhNiX5MRVfecCNea1ZbbcaNNn/Y=; b=AvdGaXRopqiYWpSk750Pnpfot4n8xOpp8zdu1ujt0Vc3QfS9YgtBHIMTxKZZ35aapE agxLAGK5oiDbgS7F6RrBCgFJJaw1lsZ6lZdCCXKRhS4LGQJ/2H3zpyG/vLJm/d6bUp5V PRmFsKpnm37VtiJt7rOT4GevNOAx9FbpEMqdfEDZT498REcTZLrt/lKHtQRdlOHCbEHH 4I00ak/k/CTC6KSygPHt10QKfBQR+J1pt0aY4bkjcJ9leOfvhE7G9BHj0U9rgCYnoeU6 TkvFnFUOBMl8fXFhiuUIlz+r6dyAHEsG2GF9yVqf7L7s6Ef5mEF5rxew6hLkekDFXJwu Omig==
X-Gm-Message-State: ABuFfojtspz23AYV3zzbKR9yEDFXJMAt+ZlASii+PgxPEmPUnV251xKe gGyyRBFFip/A2PungdG+s9wKWdrLE5rHgilgmis=
X-Google-Smtp-Source: ACcGV62ZutS/lnIARX4ZOJsjQ/w2tWPOB5L1bAQ8Eu+e1FGCGF5O18z3QyWOcA8fASImu9zTsDYmNhuf6E+RlZMEGQA=
X-Received: by 2002:a19:7709:: with SMTP id s9-v6mr232317lfc.84.1538667440771; Thu, 04 Oct 2018 08:37:20 -0700 (PDT)
MIME-Version: 1.0
References: <067ED9A1-F8D0-4C53-97A0-3E6FA7E063EC@nokia.com> <VI1PR07MB4302D68B2828F10E49C834A486EA0@VI1PR07MB4302.eurprd07.prod.outlook.com> <D4979895-D9D9-434D-A247-62682E678853@nokia.com> <CAKz0y8zP+h+=tvEiiM=5MZxzdtk43_jOJ8BxtgENs5D-Orx98Q@mail.gmail.com> <19D6CCFE-183E-4BF7-A7D2-7D5F9DA96D7A@nokia.com>
In-Reply-To: <19D6CCFE-183E-4BF7-A7D2-7D5F9DA96D7A@nokia.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Thu, 04 Oct 2018 21:07:08 +0530
Message-ID: <CAKz0y8xzxNv2EBuCmUC2r5=tDozc1th41Ao0dbdVXcAbEQLJRw@mail.gmail.com>
To: jorge.rabadan@nokia.com
Cc: jaikumar.somasundaram@ericsson.com, bess@ietf.org, jiang.he@ericsson.com, p.muthu.arul.mozhi@ericsson.com
Content-Type: multipart/alternative; boundary="0000000000003c24c6057768ee03"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/b-qNFbjihMKzEYq3C4n8LKhQNxQ>
Subject: Re: [bess] EVPN MH: Backup node behavior in Primary Path Failure
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, 04 Oct 2018 15:37:27 -0000

Thanks, Jorge. This is inline with my thinking. So, in single-active
multihoming, once the primary is dead we don't need to wait for the DF
election to happen for the backup (or some other PE in the ES) to become
active and start forwarding traffic over the ES, instead it only requires
the remote PEs and backup to realize that the primary is dead (thru' NH
tracking / BFD) and start forwarding over the ES, right?

Regards,
Muthu

On Thu, Oct 4, 2018 at 8:10 PM Rabadan, Jorge (Nokia - US/Mountain View) <
jorge.rabadan@nokia.com> wrote:

> Muthu,
>
>
>
> About this:
>
>
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> No, not in the implementations I know of. Next Hop tracking will
> immediately detect that the PE is not in the network anymore and the routes
> will be invalidated. You can also bootstrap the BGP sessions to BFD.
>
> But that has nothing to do with EVPN!.. it’s regular BGP.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
> *Date: *Thursday, October 4, 2018 at 1:14 PM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com
> >
> *Cc: *"jaikumar.somasundaram@ericsson.com" <
> jaikumar.somasundaram@ericsson.com>, "bess@ietf.org" <bess@ietf.org>, "
> jiang.he@ericsson.com" <jiang.he@ericsson.com>, "
> p.muthu.arul.mozhi@ericsson.com" <p.muthu.arul.mozhi@ericsson.com>
> *Subject: *Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Please see inline..
>
>
>
> On Thu, Oct 4, 2018 at 3:33 PM Rabadan, Jorge (Nokia - US/Mountain View) <
> jorge.rabadan@nokia.com> wrote:
>
> In-line.
>
>
>
> Thx
>
> Jorge
>
>
>
> *From: *Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>
> *Date: *Thursday, October 4, 2018 at 11:28 AM
> *To: *"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>,
> "bess@ietf.org" <bess@ietf.org>
> *Cc: *Jiang He <jiang.he@ericsson.com>, P Muthu Arul Mozhi <
> p.muthu.arul.mozhi@ericsson.com>
> *Subject: *RE: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Thanks Jorge for the quick reply.
>
> Please find further question below.
>
>
>
> *From:* Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>
>
> *Sent:* Thursday, October 4, 2018 1:52 PM
> *To:* Jaikumar Somasundaram <jaikumar.somasundaram@ericsson.com>;
> bess@ietf.org
> *Cc:* Jiang He <jiang.he@ericsson.com>; P Muthu Arul Mozhi <
> p.muthu.arul.mozhi@ericsson.com>
> *Subject:* Re: [bess] EVPN MH: Backup node behavior in Primary Path
> Failure
>
>
>
> Hi,
>
>
>
> Questions:
>
> 1.       Will the node in backup mode forward the packet to CE?
>
> [JORGE] as soon as it becomes DF it can forward packets to the CE. The
> backup node will have to run DF election upon the ES route withdrawal from
> the primary. If AC-DF is enabled, it can also react to the withdrawal of AD
> routes from the primary PE.
>
> *[Jai] Does that mean if any packet comes to a node that is still in the
> backup mode will get dropped, before the new DF election is complete? Why
> cant this be used as FRR? Or what is the use case of having backup node(s)?*
>
> *[JORGE2] when the primary node fails, ES and AD routes are withdrawn. *
>
> Suppose we have a full mesh of iBGP sessions b/w the PEs, then who would
> withdraw the routes if the primary PE / DF itself fails? Instead, the BGP
> session would timeout causing the primary PE's neighbors to flush out the
> A-D routes received from the primary PE, right? This can take several
> seconds, isn't it?
>
>
>
> Regards,
>
> Muthu
>
> *The AD route withdrawal is an indication for remote nodes that they have
> to send traffic to the backup (for a given MAC) or to flush the MACs if
> there are more than 2 PEs in the ES. Around the same time or maybe earlier,
> the ES route withdrawal will make the backup PE take over as DF. So the
> overall convergence time will depend on how/when those two things happen in
> time. Only the DF PE can forward traffic. A non-DF can never forward
> traffic or there will be risk of duplicate packets.*
>
>
>
> 2.       Will all the nodes in backup mode forward the packet before DF
> election?
>
> [JORGE] Only the new DF can forward.
>
>
>
> 3. If they forward, how is duplicate packets handled, in this case?
>
> [JORGE] see above.
>
>
>
> My two cents..
>
>
>
> Thanks.
>
> Jorge
>
>
>
>
>
>
>
> *From: *BESS <bess-bounces@ietf.org> on behalf of Jaikumar Somasundaram <
> jaikumar.somasundaram@ericsson.com>
> *Date: *Thursday, October 4, 2018 at 10:03 AM
> *To: *"bess@ietf.org" <bess@ietf.org>
> *Cc: *Jiang He <jiang.he@ericsson.com>, P Muthu Arul Mozhi <
> p.muthu.arul.mozhi@ericsson.com>
> *Subject: *[bess] EVPN MH: Backup node behavior in Primary Path Failure
>
>
>
> Hello Everyone,
>
>
>
> Sorry if it is a duplicate. I repost this query as I did not receive any
> response yet.
>
> (I was wondering if this mail already reached the group or not)
>
>
>
> I have a question on Primary PE encountering a failure in EVPN multihoming
>
> in single active mode.
>
>
>
> RFC7432, section 14.1.1:
>
> <snip>
>
>    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.
>
> </snip>
>
>
>
> Questions:
>
> 1. Will the node in backup mode forward the packet to CE?
>
> 2. Will all the nodes in backup mode forward the packet before DF election?
>
> 3. If they forward, how is duplicate packets handled, in this case?
>
>
>
> Please help me anwere these questions.
>
>
>
> Thanks & Regards
>
> Jaikumar S
>
>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>