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 <jguic...@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.decra...@orange.com <bruno.decra...@orange.com> > *Sent:* Tuesday, June 22, 2021 8:33 AM > *To:* James Guichard <jguic...@futurewei.com>; spring@ietf.org > *Cc:* draft-ietf-spring-nsh...@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:jguic...@futurewei.com > <jguic...@futurewei.com>] > *Sent:* Friday, June 18, 2021 5:00 PM > *To:* DECRAENE Bruno INNOV/NET <bruno.decra...@orange.com>; > spring@ietf.org > *Cc:* draft-ietf-spring-nsh...@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.decra...@orange.com <bruno.decra...@orange.com> > *Sent:* Tuesday, June 8, 2021 12:19 PM > *To:* James Guichard <jguic...@futurewei.com>; spring@ietf.org > *Cc:* draft-ietf-spring-nsh...@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-boun...@ietf.org <spring-boun...@ietf.org>] *On > Behalf Of *James Guichard > *Sent:* Tuesday, May 18, 2021 5:13 PM > *To:* DECRAENE Bruno TGI/OLN <bruno.decra...@orange.com>; spring@ietf.org > *Cc:* draft-ietf-spring-nsh...@ietf.org > *Subject:* Re: [spring] WG Last Call draft-ietf-spring-nsh-sr > > > > Hi Bruno, > > > > Following up on this. Please see inline. > > > > *From:* bruno.decra...@orange.com <bruno.decra...@orange.com> > *Sent:* Tuesday, February 9, 2021 1:41 PM > *To:* spring@ietf.org > *Cc:* draft-ietf-spring-nsh...@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.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
