Re: [bess] EVPN VPWS BDF forwarding behavior at MH site

gangadhara reddy chavva <meetgangadhara@gmail.com> Sat, 10 August 2019 11:29 UTC

Return-Path: <meetgangadhara@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 69F51120100 for <bess@ietfa.amsl.com>; Sat, 10 Aug 2019 04:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 64C3Rfhz-_P4 for <bess@ietfa.amsl.com>; Sat, 10 Aug 2019 04:29:24 -0700 (PDT)
Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) (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 A96971200DF for <bess@ietf.org>; Sat, 10 Aug 2019 04:29:24 -0700 (PDT)
Received: by mail-ot1-x334.google.com with SMTP id j11so42230284otp.10 for <bess@ietf.org>; Sat, 10 Aug 2019 04:29:24 -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=a6FaQcwG0h8gTzlDB8FSWrbMrocCTIZB83kIOo++VF8=; b=hwINxzXrGQURe/IRexFWczjtKz8cKRHlxTuO3BJZO5+ooEKDL8V00dpBlJ8BYDZuGe B92ZfWlWtJCiYuB52qKgvDMpfZVNzCrfhpeSw23IZu81RoME4f/6CNXZVn2enCgdOHiV 7t4wfhHlzHdkRMlV3nXz+EZTqVlx1irZimjkTqS9u+KU4Mbg71dOZbjuIHbcUXAArYbI bLT5fdt6zzBTNCSOQyda9ap4jwMMd9Grapmdea56WyfIJR2M5wt4VXGBkGX4awSQ6bR7 NLn49LAS33Ql9fcw1YcA/4h4QJXSYOa6rwPWz2jKDtPjgQQeX2NVakPWfiAP6PmIE5jc uoNg==
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=a6FaQcwG0h8gTzlDB8FSWrbMrocCTIZB83kIOo++VF8=; b=a4MiES0gc4MBwkEbxOBScVKZCj2Mj+ezYVavIkCr4YuYoE59xZSizU4UlEaLzxDoe9 xkpyTWTQ4J2YUnRnJoM8tTcb6+KJj3NJg0c5ewDn7P8QAch10qQAq/zOsouDFLYNp/8Q ULYkSSp8xtCq8AtGsl4BlLZYYWKXbaxzgv7QVO4+X6Pwm7B7lcqdybmHuLmVgcHxXgR4 NNbi53rwv6vwu7s6VmDw91KCInkXd2dy1Zjf64FI/z0LcqRr4c6aEVBfw9XKNAANiYyd 4NK2wcog91wtAm3OoLIPnbWxjuzO/nRkinzK3ID1yuEEI8ZqBgrg8qMMMmGznJ05lOSV NkUA==
X-Gm-Message-State: APjAAAUR60tBNILapR++OyVDOsGLbU4yFV3kb9PABSadIPzc+hlnv8iW 1r6ezmj798HZXs1P5SOKb0mjg2NRADEhwun/Y00=
X-Google-Smtp-Source: APXvYqyKH4Ri/aOto9mxYPweNyjSgjyehcA5byZw4SZ3J1tR+aS9BXxrd9O8Whfjr5PF2gpB5751TlWfDk4O7vqFONM=
X-Received: by 2002:a02:c6b8:: with SMTP id o24mr28030729jan.80.1565436563800; Sat, 10 Aug 2019 04:29:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAAG_SC_gizf5nRVGOL1XJ4nSHg_7RwP92wcgjqi9MCTMMiUA7A@mail.gmail.com> <3A8DD12F-E9CF-4B91-8B28-05344A82E752@cisco.com>
In-Reply-To: <3A8DD12F-E9CF-4B91-8B28-05344A82E752@cisco.com>
From: gangadhara reddy chavva <meetgangadhara@gmail.com>
Date: Sat, 10 Aug 2019 16:59:12 +0530
Message-ID: <CAAG_SC8HrpfcvNM-jpbPb2TYsgUvuyc=9FboQJ8MsE7tVVQihg@mail.gmail.com>
To: "Thirumavalavan Periyannan (thiperiy)" <thiperiy@cisco.com>
Cc: "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004dc619058fc19aa9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/wu2JAQINlqCyi7SASoCjYsPwO8o>
Subject: Re: [bess] EVPN VPWS BDF forwarding behavior at MH site
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: Sat, 10 Aug 2019 11:29:27 -0000

Hi Thiru,

here is the clarifications for your questions.

this is basically primary PE reach ability /  availability can be
determined through BFD/Multihop BFD, in this case FRR switch can happen
very quickly at the remote PE, control plane convergence later.

please see in line answers for the below questions:

for faster convergence if we can install the route such that BDF can allow
the traffic from remote PE towards to multi homed segment, we can forward
the traffic received from the remote PE.

Gangadhar >> this explains the route programming at multi homed site, if
elected PE is BDF, program the label path, so that traffic received from
remote PE will be send to multi homed CE.

at the same time we shouldn't allow the traffic from multi homed site this
leads to duplicate traffic on the remote PE. to achieve this we should not
program the path from multi home site towards remote PE until this PE
elected as DF for that VPWS instance.

Gangadhar >> again this is at BDF, we shouldn't allow the traffic from
multi homed site CE to remote PE, for this BDF should not program the path
towards remote PE, so at BDF if there is any traffic from CE will be get
dropped at BDF.


I hope this will clarify your question.

Regards,
Gangadhar



On Sat, Aug 10, 2019 at 2:50 AM Thirumavalavan Periyannan (thiperiy) <
thiperiy@cisco.com> wrote:

> Hello Gangadhara,
>
> How remote PE detect the DF failure? It’s based on EVI/AD Withdraw message
> from DF PE if so then NDF PE also received this route and changed its DF
> status at the same time Remote PE changed its nexthop to NEW DF PE.
>
> The below info is not clear, could you please help me to understand.
>
> for faster convergence if we can install the route such that BDF can allow
> the traffic from remote PE towards to multi homed segment, we can forward
> the traffic received from the remote PE.
>
> at the same time we shouldn't allow the traffic from multi homed site this
> leads to duplicate traffic on the remote PE. to achieve this we should not
> program the path from multi home site towards remote PE until this PE
> elected as DF for that VPWS instance.
>
>
> Thanks,
> Thiru
>
> On 09-Aug-2019, at 19:02, gangadhara reddy chavva <
> meetgangadhara@gmail.com> wrote:
>
> HI All,
>
> i have one question on EVPN VPWS BDF forwarding behavior at MH site.
> when PE is selected as BDF, it will communicate the EAD EVI route with B
> bit set to remote PE. so remote PE will install the FRR route with primary
> path towards DF PE and secondary path towards BDF.
> when ever primary path get disconnected it will switch the path to
> secondary path quickly at remote PE. because of this data from the remote
> PE will reach to BDF very quickly, but if BDF is not programmed its path
> towards multi homed segment then traffic will be get dropped until control
> plane convergence and it will be elected as DF.
>
> for faster convergence if we can install the route such that BDF can allow
> the traffic from remote PE towards to multi homed segment, we can forward
> the traffic received from the remote PE.
>
> at the same time we shouldn't allow the traffic from multi homed site this
> leads to duplicate traffic on the remote PE. to achieve this we should not
> program the path from multi home site towards remote PE until this PE
> elected as DF for that VPWS instance.
>
> can you please let me know if there are any problems with this kind of
> approach..
>
> <image.png>
>
> Regards,
> Gangadhar
>
>
>
>
>
>
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
>