IETF Logo Mail Archive

Re: [mpls] Control plane solutions for the use cases of NFFRR

Ketan Talaulikar <ketant.ietf@gmail.com> Tue, 26 July 2022 15:46 UTC

Return-Path: <ketant.ietf@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4065C147921; Tue, 26 Jul 2022 08:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTZCfYaMOy5S; Tue, 26 Jul 2022 08:46:33 -0700 (PDT)
Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15C1C15A727; Tue, 26 Jul 2022 08:46:17 -0700 (PDT)
Received: by mail-ua1-x92f.google.com with SMTP id r22so5740583uap.13; Tue, 26 Jul 2022 08:46:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YwOy3CYsSHc97hecAl1aObcTosoJJ3WFMS42V2MpmB8=; b=jUcLTFEbBcJRA8C67aubcY6C+0L8+04cMAYvwh6Z5RrfYrHDSGyCSpFdlmW6aNCU8r aDz0Ll6zLzSFRF9wMuhsQJsgEe6O0MtZ5WRu2YijYNjVgztQPulXWP5KHZKxN68yEg9I P0up03Ro17xvgIgsllNastqJumPhqoXcuU9xV0Ulobz77NrNusEPg8AX9Yg9V2F0I7lM mHS9e7M54fVqBIUzV0zhKkFfCXwlhRW+gYsaknrA8qz/MD70m+dxz0hzmTBZkBO/lTt2 9jA9DSQw34qkbon0ZDQfe5sxGX1DZlSQhUDiO3h6VWXocttF/N9O843V6MgfIZnWkSE5 qrWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YwOy3CYsSHc97hecAl1aObcTosoJJ3WFMS42V2MpmB8=; b=I+L51zlwAWiguGHe+6Qhx3ucV5agdp/xuMOT5IYN/eiQXt4skFyYQe7Zhgnj5BZB2X /0XNQr1twgefLCXnqyQegn7Ck4zQTjmlgoBY1pVIQ9V8BvoAfjyVozY8LPM+J0fFq5dw /TAvyskMWRMRLM9iEUgT+lpn07MQKdvxrKsL0AYVoScf1yGzYZvLsFdiHlb9P/mQqFpq SjWU461zmdOZSduDaIlug9bgnw/DLEl01bHepEbjwIO01hFdPP6xTXK8ntSl/3fHfamZ y0YLOEk2FLUB0AlqeWfutFYfEaBKX0QIixOOLljsMEdX/hAluuJRZFRNXtBiOPqH0hYd iBVQ==
X-Gm-Message-State: AJIora+uVYI/7c50x5AxDAj6ynEHMiwficTCly9zOxvGBXVEIEYhBJce 357KJsWROSEBwUS5vGk8H6X7F0d+EfCceyuSLxM=
X-Google-Smtp-Source: AGRyM1tEQw3k7qApHdO0pDF1FcPgQGEBRzjKZszTaNReWY726E7aiLvdHC/imF7twOrZ0lYSm9sdtF7oFDKqq8v95Ec=
X-Received: by 2002:ab0:3d93:0:b0:383:fb30:91a1 with SMTP id l19-20020ab03d93000000b00383fb3091a1mr5126358uac.110.1658850376407; Tue, 26 Jul 2022 08:46:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAH6gdPzgyHUFJP2F4MUg9-XXteg8TM3TSVoDez4VGP9OUsgkXQ@mail.gmail.com> <4E51CE22-6A30-4273-BD4A-BC1CEAFFD512@gmail.com>
In-Reply-To: <4E51CE22-6A30-4273-BD4A-BC1CEAFFD512@gmail.com>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Tue, 26 Jul 2022 21:16:04 +0530
Message-ID: <CAH6gdPxPV5mn_GB4KBtMQ5PGAZvFn4Z5w-9yLy5g2PshY3WraA@mail.gmail.com>
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: draft-kompella-mpls-nffrr@ietf.org, mpls@ietf.org
Content-Type: multipart/alternative; boundary="0000000000006bdfac05e4b7338f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/u-9-k4JIOpr_fnvSXH8eEQIlIIA>
Subject: Re: [mpls] Control plane solutions for the use cases of NFFRR
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2022 15:46:34 -0000

Hi Stewart,

Could you be more specific about the FRR technologies that you are
referring to?

Also, you mention "... at the cost of one bit in the data plane ...". Is it
one bit or one/more labels (i.e., if I understand the latest proposal from
the authors to align with the MNA work)?

Thanks,
Ketan

On Tue, Jul 26, 2022 at 8:09 PM Stewart Bryant <stewart.bryant@gmail.com>
wrote:

> In general FRR takes the view that it is only possible to repair a single
> failure. If a second failure occurs the risk of micro looping usually means
> giving up and falling back on regular convergence. NFRR allows two PLRs to
> act as ships in the night safe in the knowledge that if the repairs
> intersect the potentially looping packets will be dropped.
>
> At the cost of one bit in the data plane it allows the very simple first
> generation methods to deliver a bit more repair capacity, such as coping
> with unexpected SRLGs.
>
> Stewart
>
> Sent from my iPad
>
> On 26 Jul 2022, at 10:09, Ketan Talaulikar <ketant.ietf@gmail.com> wrote:
>
> 
> Hello Kireeti/Wen,
>
> I wanted to check if you had considered a control plane-based solution for
> some of the use cases that motivated the NFFRR work.
>
> I would like to draw your attention to a draft that tries to address a
> similar problem space for EVPN:
> https://datatracker.ietf.org/doc/draft-burdet-bess-evpn-fast-reroute/
>
> For Segment Routing, we have the unprotected adjacency SIDs and there have
> been discussions in the SPRING WG for unprotected prefix SIDs. The use of
> these SIDs for the TI-LFA backup path can also address the issue.
>
> There may perhaps be similar control plane mechanisms that may work for
> other similar problem spaces?
>
> IMHO, tackling this problem space in the control plane alone seems more
> beneficial than in the data plane (I note that the NFFRR proposal also
> needs control plane extensions). Could you please share your views on this?
>
> Thanks,
> Ketan
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>

v2.23.0 | Report a Bug | By Email