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

Anush Mohan <anush.iitm@gmail.com> Thu, 04 October 2018 15:47 UTC

Return-Path: <anush.iitm@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 F2D77130EA7 for <bess@ietfa.amsl.com>; Thu, 4 Oct 2018 08:47:46 -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 Vma9WfDEysIq for <bess@ietfa.amsl.com>; Thu, 4 Oct 2018 08:47:43 -0700 (PDT)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (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 181FA130E8D for <bess@ietf.org>; Thu, 4 Oct 2018 08:47:43 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id r9-v6so3426135pff.11 for <bess@ietf.org>; Thu, 04 Oct 2018 08:47:43 -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=L3X6CAvbjuf1RiD3VByir2WOmxBXN+R4YWLubPVTrVk=; b=KjDTiKrHxho7aeeP+t7rat4boD1W7EWLKNbz0qyh+YeghnRvPzFqC+vjXtKwklMLOZ HfqQ2fZTZ5XqCf9mV6uJPTcuIAGbR9fj4ypZ6xh6nnolSeK/3C6W52B8hRSCc5hwfM7o fa9Ly+RxefkBIGfHFzR4DC0FLQcgXxjU4QTxUGXoIQWbkFHXaa8L97nd3sUc7K0m+X/9 Pwd5et9JuRLaP6M2O6rHQZp6ryqGduCYzJ0qPYySZqgL+/efWdIh+o1iN/hv8dUWDdEA S4gNjMRDN+GXWcmhDjy0l76sWSCeQAjCjGkx4SAwh3BDCSMOXRpiDfXW95rQuRU62d+R lUAQ==
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=L3X6CAvbjuf1RiD3VByir2WOmxBXN+R4YWLubPVTrVk=; b=iiz7QLVPMZQVSekgPKN2/2nBYY/5e57aE5Z7L2/JvCDdaQYBICwKsO6ZzTdE1YMBys LB2vFyY8gObSFhae7BeObKrVLKstZWfyQC07sBdD9K33S4IPPbrqrjTrhjBJzvikV+h5 2qFRXaB4NuDY+8qxTx3Uz2ka8Lj8MotQMiXT4XEKxZZe9IqCh7hWri/96bRdinBtXp1e qLm4fdObXiNB4ik+DPB5zvL+zph4F5kybhZNe0nFBNwKLbcMUBuqFmaXHasLbM+OIikS a0aZUEFA2G/sDpZ4nSfLhL3w4+TKTvtHcznduGTggjZ7nwJNd42Y12oTkHs0tOzKmlKY +Bmg==
X-Gm-Message-State: ABuFfogXuhkTMLUvq8aTyTiOxnf47N0QNJfsI0CLLQyxBagqlGyrSZ83 wMTcLeyYJhK8k9r68aSxyrRW7cYbrdGVFv+dRmc=
X-Google-Smtp-Source: ACcGV62747QAo/tz2joC49AESqv1SiXwvNBmVfDo87BHKrncRWRFDzXTPEuRv28mI9Fo9p8oBEacB5jQ5ZMRw8JmqrM=
X-Received: by 2002:a62:5c03:: with SMTP id q3-v6mr7480007pfb.182.1538668062417; Thu, 04 Oct 2018 08:47:42 -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: Anush Mohan <anush.iitm@gmail.com>
Date: Thu, 04 Oct 2018 21:17:30 +0530
Message-ID: <CAO76cfXrtZxKYHURwVaxTW47ZXdT+cx8_krx15MgxqO6Ocy-4g@mail.gmail.com>
To: jorge.rabadan@nokia.com
Cc: muthu.arul@gmail.com, jiang.he@ericsson.com, p.muthu.arul.mozhi@ericsson.com, bess@ietf.org, jaikumar.somasundaram@ericsson.com
Content-Type: multipart/alternative; boundary="00000000000049aa7e05776913d8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/nYrCCWfyHmT6U1t-lQC-vOuFicg>
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:47:55 -0000

Hi Jorge,

      Related to this topic, I had couple of queries as well. Could you
please clarify.

1.  I hope the section of RFC pasted by Jai is superceded by the particular
DF algorithm used. If all PEs can decide one particular backup PE for
Ethernet-segment based on HRW (for e.g),
     only that particular backup-PE can be used for unicasting traffic. We
can avoid flushing mac-entry in this case.

2.  If 'all-active' multihoming is used and a particular MAC is learnt from
multiple PEs on an Ethernet-segment, should we use 'mac-ip' route label for
load-balancing traffic or alias-label from
     'EAD/ESI' route. Or it doesn't matter.

Regards
Anush


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
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>