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

Muthu Arul Mozhi Perumal <muthu.arul@gmail.com> Thu, 04 October 2018 11:14 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 D9477130E16 for <bess@ietfa.amsl.com>; Thu, 4 Oct 2018 04:14:28 -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 96oCqYTfPUVr for <bess@ietfa.amsl.com>; Thu, 4 Oct 2018 04:14:26 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 D0DE6130DFB for <bess@ietf.org>; Thu, 4 Oct 2018 04:14:25 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id 63-v6so8002484ljs.4 for <bess@ietf.org>; Thu, 04 Oct 2018 04:14:25 -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=imceggmc/pn8ALwSK+WVvrX9BJ8EFqbnHcjONwqrvRk=; b=mlxUxBV+XX9ZbmVg+Ferh3BklCMQuODflC9Tysn5g24a8i3bPDCNAiFRLS9tUvZ3/O bm6UOL2/DddKfCfxS0uctiOJ11US7DdSFLVPrqrg1Em0zTBJSA3M7fyZ5yYNzUFceVQ6 EyotZ+SRI7tCIIWiD1HIUYLMwTW0odxJXprJeSIK2VRBc/2YQYNyzxtF4xlxy+9EBMEF 73EvjrjK0uJg5KkI/u94IZSTPyLK1/bk4tVMYa3pvrQuNLrAnyRzHSbHGRulPZaa+WZC arAC0rLatZyupFyOEpfBoq0eEuBYCCfcHBdEWfoSv2BsVK697kr7pasjIbA+2bTk/f2A 8nwg==
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=imceggmc/pn8ALwSK+WVvrX9BJ8EFqbnHcjONwqrvRk=; b=edBWAiU8UuJiKY/V1fhj1nOK2hryQ/Kw0pdyGrwufZ9W7paco87GcXANl4jZL4mYvU bdJsHJ1a6erae8VQOpDn/GsZSNxB15yLkWiWUlUKZS3wUHK6qOUxwIq3vP3/LgzLoYK8 XOVWU6yRaWXFqlyK0Gw/I8Fpo3h56h+8osk4Av3E7rXMA4cVgFH1cLTO79MlG/XMMQsL Y96yZZvrtZq+cTaDdJn2gHCP/Sw2PpGV3IrsKhCCoj5MRwLXzNPxIuqf983SFHWrXPWH oihStHpcniT+J7BO21mHmDLC5xZAQ2RxgyB7jeJe+wzbSwFwobF268iliUyl8BgJZP0s +/8Q==
X-Gm-Message-State: ABuFfogU1TCSS2J3MfqDpbYcSiMziI/Aa65TM+ZU9U2iwroo6fiOPpJN yKTCwG0BcWHvMluHJHz0o7zYgwnh6jBG7ePL8qY=
X-Google-Smtp-Source: ACcGV63hknLFCCBrkuJEYXuDJIDwkTWElEPeMfzTQMOVbuzKvJZPT55Wf8ltDSrueq6SYbpKV9AYUR74NxlEH6rcE8o=
X-Received: by 2002:a2e:20f:: with SMTP id 15-v6mr3827618ljc.141.1538651663966; Thu, 04 Oct 2018 04:14:23 -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>
In-Reply-To: <D4979895-D9D9-434D-A247-62682E678853@nokia.com>
From: Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
Date: Thu, 04 Oct 2018 16:44:11 +0530
Message-ID: <CAKz0y8zP+h+=tvEiiM=5MZxzdtk43_jOJ8BxtgENs5D-Orx98Q@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="000000000000dd2747057765413f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/_oxlhsGvuh5LJT1z0axvzdycKFc>
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 11:14:29 -0000

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
>