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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]>
wrote:

> Hi Bruno,
>
>
>
> v-07 just posted please check section 6.1 to make sure that it satisfies
> your comments.
>
>
>
> Thanks!
>
>
>
> Jim
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Tuesday, June 22, 2021 8:33 AM
> *To:* James Guichard <[e-mail]>; [e-mail]
> *Cc:* [e-mail]
> *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:[e-mail]
> <[e-mail]>]
> *Sent:* Friday, June 18, 2021 5:00 PM
> *To:* DECRAENE Bruno INNOV/NET <[e-mail]>;
> [e-mail]
> *Cc:* [e-mail]
> *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:* [e-mail] <[e-mail]>
> *Sent:* Tuesday, June 8, 2021 12:19 PM
> *To:* James Guichard <[e-mail]>; [e-mail]
> *Cc:* [e-mail]
> *Subject:* RE: WG Last Call draft-ietf-spring-nsh-sr
>
>
>
> Hi Jim,
>
>
>
> Thanks for your reply.
>
> Please see inline [Bruno]
>
>
>
> *From:* spring [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *James Guichard
> *Sent:* Tuesday, May 18, 2021 5:13 PM
> *To:* DECRAENE Bruno TGI/OLN <[e-mail]>; [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [spring] WG Last Call draft-ietf-spring-nsh-sr
>
>
>
> Hi Bruno,
>
>
>
> Following up on this. Please see inline.
>
>
>
> *From:* [e-mail] <[e-mail]>
> *Sent:* Tuesday, February 9, 2021 1:41 PM
> *To:* [e-mail]
> *Cc:* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*