Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

Gyan Mishra <hayabusagsm@gmail.com> Sun, 11 July 2021 22: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 E03BD3A20F7; Sun, 11 Jul 2021 15:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.087
X-Spam-Level:
X-Spam-Status: No, score=-0.087 tagged_above=-999 required=5 tests=[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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 bOEt2_LPnNr3; Sun, 11 Jul 2021 15:24:26 -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 AACCA3A20FA; Sun, 11 Jul 2021 15:24:26 -0700 (PDT)
Received: by mail-pf1-x434.google.com with SMTP id j9so8861451pfc.5; Sun, 11 Jul 2021 15:24:26 -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=Vq8fZI3eqnNwdlZzoI1S2A8NrPspAvH6rBDSQT5GziM=; b=bHXqu3ILcH7RypHbDEev32Ijbky5E5IyQokOpmdmllWM1LOgvcdOVwPXH4cy32JRta zG/suSvP2VsSla87VlwsbmHdWa8RTok1AmQAg5EkaZ/8p+U1kvID7BuHxj1hAilttysl qEDEqEViSzsV7U9Yg2Pwy1g6kRJyCHER8LwDqjjYD3dRz6oqDxWg1i8Is+kmMBD06EaV XLZuV2jXY7VtXXM1EB3qsKhDlSqGv+TXpGV0vmwHglNow0kCt2nYc3O9IDQDBGl0J1eP vCARNUdCf9oeQMVDHGF2oDcyEBmnnJdT78VS1NqM9G0GcfdIOc5M5vwp4kcgbYdkRoUJ kVDA==
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=Vq8fZI3eqnNwdlZzoI1S2A8NrPspAvH6rBDSQT5GziM=; b=aowTjUAkb/gjR1QDzRGUgry1Lp/iqsz5eF82UKiiNCdCWdmP4DmUzdaWlX/3NOrhFh UUe20+qdjHky6Ow7gd2gJHg5e6kWBux7P7DFbnbtR5eeQ2prgql7PUIRkksx9SI08oOv lhDJTZPHeCe6deBISP7aTmOqiACw6iCLXkEBBHm0/jWz3YKs/HnFqB4DrKJgsp/C4rQ5 QNY2eQVwXiJZMyM0OOe/Ib3PpqHAZCw9gkpFIqEDwRfuW43KH7ganlljQZs37tGT4acr SkG453znZBf5ARDbso3Pz5NJ3q4dyW7OZmyDOEoWpwY+6thnx6OZEMiEpq1cLl504Rj0 f2zA==
X-Gm-Message-State: AOAM530FRROQ2HScwbqPuROCF/KmypmYCA3KFVaHd3t1TBfMBHTNaejf v870YFrwI6sy8MunYFpc9cb7axCy9w+2SDQ5PPc=
X-Google-Smtp-Source: ABdhPJyxsZO6z2nsPV4dij9ny5RLe8tKQYS5BbrB2ftPWWAHNYyM1pbR7qCWZ6r+qsgbfeJUdJ89yBB3XXcNjBdGbEU=
X-Received: by 2002:a05:6a00:214a:b029:323:3c6e:a24a with SMTP id o10-20020a056a00214ab02903233c6ea24amr32770903pfk.4.1626042264909; Sun, 11 Jul 2021 15:24:24 -0700 (PDT)
MIME-Version: 1.0
References: <25012_1612895472_6022D4F0_25012_72_1_53C29892C857584299CBF5D05346208A490C4A3A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <3058_1612896034_6022D722_3058_18_1_53C29892C857584299CBF5D05346208A490C4AE4@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MN2PR13MB420694920BB2C388FF833387D22C9@MN2PR13MB4206.namprd13.prod.outlook.com> <28823_1623169127_60BF9867_28823_29_1_53C29892C857584299CBF5D05346208A4CDC8DB3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MN2PR13MB42063DEA31BA4160BAA3034DC20D9@MN2PR13MB4206.namprd13.prod.outlook.com> <27549_1624365203_60D1D893_27549_177_1_53C29892C857584299CBF5D05346208A4CDF47BD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <MN2PR13MB4206DF56D1E5A9C54EA9BD69C2099@MN2PR13MB4206.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB4206DF56D1E5A9C54EA9BD69C2099@MN2PR13MB4206.namprd13.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 11 Jul 2021 18:24:14 -0400
Message-ID: <CABNhwV2uiu68=-X+89NFRoNR5jy1UVyWRC=PDSy6_JSr1d3ozA@mail.gmail.com>
To: James Guichard <jguichar@futurewei.com>
Cc: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, "draft-ietf-spring-nsh-sr@ietf.org" <draft-ietf-spring-nsh-sr@ietf.org>, "spring@ietf.org" <spring@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000096fc5705c6e07741"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/52nHw69uxNOGC8EZVrdrwfy7slo>
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr
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: Sun, 11 Jul 2021 22:24:32 -0000

Dear Authors

I have read the latest -08 draft and I support publication.

All comments seem to be addressed in this revision.

Thank you

Gyan

On Tue, Jun 22, 2021 at 9:01 AM James Guichard <jguichar@futurewei.com>
wrote:

> Hi Bruno,
>
>
>
> v-07 just posted please check section 6.1 to make sure that it satisfies
> your comments.
>
>
>
> Thanks!
>
>
>
> Jim
>
>
>
> *From:* bruno.decraene@orange.com <bruno.decraene@orange.com>
> *Sent:* Tuesday, June 22, 2021 8:33 AM
> *To:* James Guichard <jguichar@futurewei.com>om>; spring@ietf.org
> *Cc:* draft-ietf-spring-nsh-sr@ietf.org
> *Subject:* RE: WG Last Call draft-ietf-spring-nsh-sr
>
>
>
> Hi Jim,
>
>
>
> Thanks for the latest version and your replies.
>
> Please see inline [Bruno2]
>
>
>
> As an aside, I’m waiting for the reviews from the RTG and INT directorate.
> https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/history/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-nsh-sr%2Fhistory%2F&data=04%7C01%7Cjguichar%40futurewei.com%7C83f5845c9b634e4ee24c08d93579ee85%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637599620111594356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=boupVRw9WQaOYLDIWnW5gN8ZOht89rAwSEtfyO6g0oI%3D&reserved=0>
>
> In the meantime, I’m initiated the shepherd write up.
>
>
>
> *From:* James Guichard [mailto:jguichar@futurewei.com
> <jguichar@futurewei.com>]
> *Sent:* Friday, June 18, 2021 5:00 PM
> *To:* DECRAENE Bruno INNOV/NET <bruno.decraene@orange.com>om>;
> spring@ietf.org
> *Cc:* draft-ietf-spring-nsh-sr@ietf.org
> *Subject:* RE: WG Last Call draft-ietf-spring-nsh-sr
>
>
>
> Hi Bruno,
>
>
>
> Latest version covers most of your comments I think. Please see inline.
>
>
>
> *From:* bruno.decraene@orange.com <bruno.decraene@orange.com>
> *Sent:* Tuesday, June 8, 2021 12:19 PM
> *To:* James Guichard <jguichar@futurewei.com>om>; spring@ietf.org
> *Cc:* draft-ietf-spring-nsh-sr@ietf.org
> *Subject:* RE: WG Last Call draft-ietf-spring-nsh-sr
>
>
>
> Hi Jim,
>
>
>
> Thanks for your reply.
>
> Please see inline [Bruno]
>
>
>
> *From:* spring [mailto:spring-bounces@ietf.org <spring-bounces@ietf.org>] *On
> Behalf Of *James Guichard
> *Sent:* Tuesday, May 18, 2021 5:13 PM
> *To:* DECRAENE Bruno TGI/OLN <bruno.decraene@orange.com>om>; spring@ietf.org
> *Cc:* draft-ietf-spring-nsh-sr@ietf.org
> *Subject:* Re: [spring] WG Last Call draft-ietf-spring-nsh-sr
>
>
>
> Hi Bruno,
>
>
>
> Following up on this. Please see inline.
>
>
>
> *From:* bruno.decraene@orange.com <bruno.decraene@orange.com>
> *Sent:* Tuesday, February 9, 2021 1:41 PM
> *To:* spring@ietf.org
> *Cc:* draft-ietf-spring-nsh-sr@ietf.org
> *Subject:* RE: WG Last Call draft-ietf-spring-nsh-sr
>
>
>
> Hi authors, WG,
>
>
>
> Speaking as the shepherd.
>
>
>
> Thanks for the -04 which answer my previous set of comments.
>
>
>
> I’ve reviewed the document again, focusing on the new text. Please find
> below some additional comments.
>
>
>
> ===
>
> SR-MPLS  §6.1
>
>
>
> " At the end of the SR-MPLS path it is necessary to provide an
>
>    indication to the tail-end that NSH follows the SR-MPLS label stack
>
>    as described by [RFC8596]."
>
>
>
> My understanding is that RFC8596 performs the above goal by adding an SFF
> label at the bottom of the stack. In which case it would not be mandatory
> to disable Penultimate Hop Popping on the prefix SID as
> draft-ietf-spring-nsh-sr-04 is mandating.
>
>
>
> I"m seeing two options that you could either choose from or describe both:
>
> - a prefix SID dedicated to NSH. In which case PHP needs to be disabled
> and there is no need for the SFF label specified in RFC8596 (alternatively,
> this prefix SID is _the_ SFF label defined in RFC8596, although 8596 refers
> to a local label(segment) while usually a prefix SID is a global segment)
>
> - use a multi-purpose prefix SID. In which case, indeed " At the end of
> the SR-MPLS path it is necessary to provide an  indication to the tail-end
> that NSH follows the SR-MPLS label stack  as described by [RFC8596].
>
>
>
> Jim> I believe this is clarified in -v05. The new text says:
>
>
>
>    As described in [RFC8402], the IGP signaling extension for IGP-Prefix
>
>    segment includes a flag to indicate whether directly connected
>
>    neighbors of the node on which the prefix is attached should perform
>
>    the NEXT operation or the CONTINUE operation when processing the SID.
>
>    When NSH is carried beneath SR-MPLS it is necessary to terminate the
>
>    NSH-based SFC at the tail-end node of the SR-MPLS label stack.  This
>
>    is the equivalent of MPLS Ultimate Hop Popping (UHP) and therefore
>
>    the prefix-SID associated with the tail-end of the SFC MUST be
>
>    advertised with the CONTINUE operation so that the penultimate hop
>
>    node does not pop the top label of the SR-MPLS label stack and
>
>    thereby expose NSH to the wrong SFF.  This is realized by setting No-
>
>    PHP flag in Prefix-SID Sub-TLV [RFC8667], [RFC8665].  It is
>
>    RECOMMENDED that a specific prefix-SID be allocated at each node for
>
>    use by the SFC application for this purpose.
>
>
>
>    Alternatively, if NEXT operation is performed, then at the end of the
>
>    SR-MPLS path it is necessary to provide an indication to the tail-end
>
>    that NSH follows the SR-MPLS label stack as described by [RFC8596].
>
>
>
> So there are two options as you indicate above. 1) use the prefix segment
> as the indicator as described by the 1st paragraph in the new text, or 2)
> use an SFF label as described by the second paragraph.
>
>
>
> [Bruno] There are two options but the text currently says that the first
> option MUST be used (“the prefix-SID associated with the tail-end of the
> SFC MUST be advertised with the CONTINUE operation”) which seems to
> nullifies the second paragraph (“Alternatively, “).
>
> So may be some rephrasing may be needed to indeed allow both options.
>
>
>
> Jim> Covered in latest version.
>
> [Bruno2] In -06, I’m not seeing any change related to this section 6.1
>
>
>
> Also
>
> "   At the end of the SR-MPLS path it is necessary to provide an
>
>    indication to the tail-end that NSH follows the SR-MPLS label stack
>
>    as described by [RFC8596]."
>
>
>
> In the scheme "SR-based SFC", "the end of the SR-MPLS" is only the last SF
> (not all other SF on the SF chain).
>
> So how does others SFC have an indication that the NSH follows the SR-MPLS
> label stack?
>
> Alternatively something along :s/ end of the SR-MPLS path/for all the SF
> along the SR-MPLS path
>
>
>
> Jim> as far as I can tell “other SFC” do not need an indication as the
> prefix SID has End.NSH action so they will remove and cache the SR stack
> and forward the NSH packet to the SF associated with the prefix SID.
>
> [Bruno] OK for SRv6.
>
> For SR-MPLS, how does this work? Draft says “In the case of SR-MPLS this will be a prefix SID [RFC8402 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8402&data=04%7C01%7Cjguichar%40futurewei.com%7C83f5845c9b634e4ee24c08d93579ee85%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637599620111594356%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=wiA17CTD5o5b3TdxuKJqC6JwJJdRrOZSZ2V4kmTmcKU%3D&reserved=0>]”
>
>  - Can it use the “regular” prefix SID? (draft only says that It is RECOMMENDED that a specific prefix-SID be allocated at each node for use by the SFC application for this purpose.)
>
>  - If not, does it needs a specific & dedicated IP address? (RFC8402 seem to mandate that a Prefix Segment be an IGP prefix segment and that a single prefix-SID be advertised per tuple <prefix, topology, algorithm>
>
>  - How does the ingress know that this Prefix SID is to be used for SR-based SFC? And only to be used for SR-based SFC?
>
>
>
> Jim> In MPLS (including SR-MPLS) nodes uses labels as they please.  So
> yes, an SFF that may also be an MPLS switch needs to advertise separate
> labels to indicate that they are used for SFF processing (looking at the
> NSH).  As far as I know, MPLS / SR-MPLS has never standardized how this is
> indicated / coordinated.  By assumption, the PCE / Ingress classifier knows
> what labels to use.
>
> [Bruno2] OK.
>
> --Bruno
>
>
>
> Jim
>
> _________________________________________________________________________________________________________________________
>
>
>
> 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 *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*