Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths

Gyan Mishra <hayabusagsm@gmail.com> Sat, 15 August 2020 06:24 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259733A0814; Fri, 14 Aug 2020 23:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 LUu0pykQ_cqy; Fri, 14 Aug 2020 23:24:30 -0700 (PDT)
Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 40FD93A080E; Fri, 14 Aug 2020 23:24:30 -0700 (PDT)
Received: by mail-vk1-xa2a.google.com with SMTP id k1so2472173vkb.7; Fri, 14 Aug 2020 23:24:30 -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=HuHj6rwoLzSnctFWj0TvD201cAvpCB4AYha7xM1/6RU=; b=N65izRa+LgD4x2O/WPmBvmW0Qog6CzmGPPDFBFgzOZeZ1ElfKVbjqdp/25qosMw8Tl MwAKIibdzawU7WbPwscplfLIj5517HFVguVpxSwq/uMN+zz5BgfZ1s034pBuAWK/DeWs GfzVnsXM6+Cv8SGwFU7K2G9BEW58gYMhA6VC+EZb7/Q+IxhxS5w2UhOdhl5+7KjX+WtI Wr4nulusE45LUYYBDd10TygBCRN0iijlFVjOaDezqfRvpi70spb5nGOhpYi2VdQ8z1dX 0SjN4rZgBofF9ig2d/jR1QI8m5rJXmn7ZJAnPgKJftoiWMZYx18tUZLfmEI9CNNF18BN mbNA==
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=HuHj6rwoLzSnctFWj0TvD201cAvpCB4AYha7xM1/6RU=; b=NT9m2IdNHbDQxcSJPi6qJDgoarYr4OZpsaH3fDff3FepI7Au8zDRI9fxAx5O0cJclH MT34j3dcTDmxyTgKF4ocXoFhCDuxnejqOlm5iGn8d41CY+1aZNFqL38vlU+7HA5X28NE ARSilfJv2adA5+ME+VTxjZIN/Kc1vj9D5Va2v34yRiyWdavcBM0Vq79N/OTlDW0ODlG+ OBkwZ+wbGIu6CDKowErQXiRpokfMnp/xVcxzN9G/C8EW2H12b/sMe3VGpR8AFWArUeGi SkM8BMWvBgaOKqThHE9C13NcdInGLjTGKOIGOqebqWcAt2ppeijvorVGE1MrJrmmMaGJ MbHQ==
X-Gm-Message-State: AOAM530zDkoiWIomRfH6aUiwr9BvK5+h3yXBghlmRqwV6E5hK8504MuU Kqgl2OLR+inkRWCrdpM/dgSITii5ARocFMdamaw=
X-Google-Smtp-Source: ABdhPJxIgthK3gQJJ+Q2MHEytgjtGsG6urH5qmUYrfrtpK3zn9IDwTlrBU0SyKrIDOR/Attk0Oe7AuMfwX2Daq0jC6w=
X-Received: by 2002:a1f:5fcf:: with SMTP id t198mr3420258vkb.32.1597472669216; Fri, 14 Aug 2020 23:24:29 -0700 (PDT)
MIME-Version: 1.0
References: <3815_1596111875_5F22BC03_3815_57_2_53C29892C857584299CBF5D05346208A48F028F5@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MW3PR11MB457084F193199C18C0987047C1400@MW3PR11MB4570.namprd11.prod.outlook.com>
In-Reply-To: <MW3PR11MB457084F193199C18C0987047C1400@MW3PR11MB4570.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 15 Aug 2020 02:24:18 -0400
Message-ID: <CABNhwV2WaH8WYDnp_C5z7JGpsi3egRHRs4H=BT6D2Db6Zd5z9w@mail.gmail.com>
To: "Ketan Talaulikar (ketant)" <ketant=40cisco.com@dmarc.ietf.org>
Cc: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org" <draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fcbd4d05ace496f7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/rdt1XTqXaOANp_KB_n8qaMk71Pg>
Subject: Re: [spring] WG adoption call for draft-hegde-spring-node-protection-for-sr-te-paths
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Aug 2020 06:24:32 -0000

I support WG adoption adoption of this draft.

For operators moving towards SR technology, RSVP FRR is widely deployed by
operators, so SR node protection is a critical feature for operators.

>From the thread started by Joel Halpern I think path protection is as well
critical to operators.

With regards to SR FRR node protection,  how does TI-LFA FRR work in
conjunction with SR FRR node protection for the  same PLR junction to the
merge point bypass loop.

Is the concept of context table a requirement for node FRR as it will
consume more resources.  In the bypass loop if their is only one next next
hop path Neighbor or a few would a context table be necessary.  For the
node protection this does seem similar conceptually to RSVP node protection
with the additional label to signal lsp  to the merge point.

Kind Regards

Gyan

On Fri, Aug 14, 2020 at 8:25 AM Ketan Talaulikar (ketant) <ketant=
40cisco.com@dmarc.ietf.org> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi All,
>
>
>
>
>
> I believe this topic is relevant and something for the WG to adopt and
> work on.
>
>
>
>
>
> I have some concerns though on it’s applicability and more specifically
> it’s implications on existing deployments/use-cases. I’ve share the same on
> the thread started by Joel on this specific aspect [1]. Some discussion and
> clarity on this
>
> would help before adoption.
>
>
>
>
>
> One other bit, for the example in Sec 2.3, perhaps some text is required
> to clarify that this applies only for segments signalled via IGPs and if
> the 9054 was a BSID or BGP-EPE SID then this approach would not work. May I
> suggest to add
>
> a section 2.4 to capture these aspects (it would be some what on the lines
> of Sec 3.4 but not related to the context table solution).
>
>
>
>
>
> The document is well-written and detailed. It does a very good job of
> describing the node protection scenarios and options.
>
>
>
>
>
> Thanks,
>
>
> Ketan
>
>
>
>
>
> [1]
>
> https://mailarchive.ietf.org/arch/msg/spring/8UIcjT9HMPc4XUp_WAiClFwpOmM/
>
>
>
>
>
>
>
>
>
> *From:* spring <spring-bounces@ietf.org>
>
> *On Behalf Of *bruno.decraene@orange.com
>
>
>
>
> *Sent:* 30 July 2020 17:55
>
>
> *To:* spring@ietf.org
>
>
> *Cc:* draft-hegde-spring-node-protection-for-sr-te-paths@ietf.org
>
>
> *Subject:* [spring] WG adoption call for
> draft-hegde-spring-node-protection-for-sr-te-paths
>
>
>
>
>
>
>
>
>
> Hi SPRING WG,
>
>
>
>
>
> Authors of draft-hegde-spring-node-protection-for-sr-te-paths  [1] have
> asked for WG adoption.
>
>
>
>
>
> Please indicate your support, comments, or objection, for adopting this
> draft as a working group item by August 20th 2020. (*)
>
>
>
>
>
> Could those who are willing to work on this document, please notify the
> list. That gives us an indication of the energy level in the working group
> to work on this.
>
>
>
>
>
> Thanks,
>
>
> Regards,
>
>
> Bruno, Jim, Joel
>
>
>
>
>
> [1]
>
>
> https://tools.ietf.org/html/draft-hegde-spring-node-protection-for-sr-te-paths-07
>
>
> (*) 3 weeks to account for the IETF meeting week and the august/summer
> period.
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
>
>
>
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>
>
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>
>
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>
>
>
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
>
>
>
>
>
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
>
>
>
> they should not be distributed, used or copied without authorisation.
>
>
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.
>
>
>
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>
>
>
> Thank you.
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> spring mailing list
>
> spring@ietf.org
>
> https://www.ietf.org/mailman/listinfo/spring
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD