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

From: <[email-masked]>
Date: Tue, 11 May 2021 12:51:25 +0000

Hi authors, Jim,

> https://datatracker.ietf.org/doc/html/draft-ietf-spring-nsh-sr-05

> A diff from the previous version is available at:

> https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-nsh-sr-05

Thanks for the updated -05.

-05 addresses my latest comment and I believe the comment from Med.

But it's not crystal clear to me that -05 addresses the below comments from Greg, Dhruv and myself.

https://mailarchive.ietf.org/arch/msg/spring/TtkYuNfK_M1PVezxzWEnpuU5eig/
https://mailarchive.ietf.org/arch/msg/spring/0OZP8nLe1iGNCqmENzMc1tYUZz4/
https://mailarchive.ietf.org/arch/msg/spring/WUa0pmGG_DmlGh461UWKqPVBU6g/

Could you please reply to the above three emails and to the comments and questions raised in those emails?

Thanks,
Regards,
--Bruno

From: DECRAENE Bruno TGI/OLN
Sent: Friday, April 30, 2021 2:49 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: WG Last Call draft-ietf-spring-nsh-sr

Hi authors,

As a friendly remainder, during WG LC some questions and comments have been raised.
Please resolve the point raised and update the draft as needed.

Thanks,
Bruno

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, February 9, 2021 7:31 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Last Call draft-ietf-spring-nsh-sr

Dear WG,

This message starts a 2 weeks WG last call for draft-ietf-spring-nsh-sr [1].

After review of the document please indicate whether you believe this document should be progressed to the IESG.

In addition to yes/no, please consider providing a technical review of this document; in particular if you care for this document.
Indeed, since WG adoption, this document had benefited from little reviews from the WG, so we need more review from the SPRING WG.

If you are aware of an implementation of this document, please report the implementation either on the list or to the chairs so that the shepherd can report implementations in the writeup.

Note that I'll forward that call to the SFC WG.

Thanks!

[1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr

--Bruno

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

---

From: James Guichard <[email-masked]>
Date: Wed, 12 May 2021 11:35:35 +0000

Hi Greg,

Please see inline.

From: Greg Mirsky <[email-masked]>
Sent: Wednesday, February 17, 2021 2:38 AM
To: Bruno Decraene <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

Dear All,
I have several questions about the draft:

  *   When using the approach described in Section 4, i.e., SR-based SFC with the integrated NSH, how does a re-Classifier scenario be handled? If I understand it correctly, a re-Classifier can change the SPI of the NSH coming back from the SF. If that is the case, the SFF will not match it to the saved SR information because the SPI had changed. How would SFF forward the NSH and the payload?
Jim> A reclassification both in service chaining and segment routing means that the original path is replaced by a new path. In this case a new SPI would forward the packet based upon the SFF lookup just like any other service chain; the original path would be replaced and the network programmed to support that new path based upon the policy action. Of course the network operator would need to program this in such a way that if necessary the original SR path (or parts thereof) are integrated into the new path.

  *   Related to the scenario from the above. The stored SR information that is not being used appears to become stale. It seems that it creates a leak of resources in a system that should be controlled somehow.
Jim> yes you are right Greg and we probably need to add some text to support the caching operation which was also suggested by Dhruv in another email. If you have any suggested text that would be great but I will also look into it.
Regards,
Greg

On Tue, Feb 9, 2021 at 10:31 AM <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG,

Thanks!

[1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-nsh-sr&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ccb89827bcbdd4742350d08d8d3170a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637491443219237530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qLw6TUw0pZgid1ez%2BKh3BSmBoAHEf6I3yX7tu5Q3ULk%3D&reserved=0>

--Bruno

Thank you.
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ccb89827bcbdd4742350d08d8d3170a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637491443219237530%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lgC3kKUaNsnSEOZwKvXcrrbuc3pxLJyjO93STGddcJU%3D&reserved=0>

---

From: James Guichard <[email-masked]>
Date: Wed, 12 May 2021 11:47:39 +0000

Hi Dhruv,

Please see inline.

From: Dhruv Dhody <[email-masked]>
Sent: Wednesday, March 17, 2021 10:20 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

Hi WG,

I support the publication of this I-D. A few comments -

- Section 2
   A classifier SHOULD assign an NSH Service Path Identifier (SPI) per
   SR policy so that different traffic flows that use the same NSH
   Service Function Path (SFP) but different SR policy can coexist on
   the same SFP without conflict during SFF processing.

Why not MUST?

Jim> yes and good catch thank you. I will update the text.

- Section 4, I suggest adding some recommendations related to the cache? How long to keep (aging)? What happens in case of a cache miss? Should these be set by the operator? Would be good from an operational point of view to provide some more details related to caching.

Jim> yes agreed. We will add a section and would appreciate your input.

- Section 4,

   The behavior of remembering the SR stack occurs at the end of the
   regularly defined logic.  The behavior of reattaching the stack
   occurs before the SR process of forwarding the packet to the next
   entry in the segment-list.  Both behaviors are further detailed in
   section 5.

The SR stack reads as SR-MPLS specific. Can this be generalized or perhaps text added for SRv6 as well?

Jim> I am not sure where (or what text) to add to make this clearer. Do you have any suggestions?

- Section 5, path-id is not used anywhere else; should it be mentioned that this is Service Path Identifier (SPI)?

Jim> yes and I will update the text thank you.

- Suggest adding a backward compatibility section to describe what is likely to happen if an SFF does not support "Integrated NSH Service Plane" but receives an NSHoSR packet.

Jim> I will try to add some text.

Nits
- Remove references in the Abstract

Jim> done

- Should there be some reference to 3GPP in the first paragraph Section 1.1?

Jim> do you have a suggested reference/s ?

- Section 5, s/RFC 8754/[RFC8754]

Jim> done.

Note
- There are 2 cases of Normative reference to Informational RFCs: RFC 8596 and 7665. Need to handle Downref registry during IETF LC.

Thanks!
Dhruv

On Thu, Mar 4, 2021 at 11:15 PM <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG,

We received very few support and review so far: two reviews excluding the authors and including the shepherd.
Thanks Greg for the review.

To allow for more feedback, the WG last call is extended for two weeks until March 18.

In the meantime, authors are invited to reply to the comments sent on the list.

Thanks,
--Bruno

From: spring [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>

Dear WG,

Thanks!

[1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-nsh-sr&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ce51f5164e92342de2b3f08d8e94fcc52%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637515876229708689%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8VUbWJmlw5F5LI%2BiB1cI3LAet5KUPXUjT7f%2FQjkcfow%3D&reserved=0>

--Bruno

Thank you.

Thank you.
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Ce51f5164e92342de2b3f08d8e94fcc52%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637515876229718682%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=CHl6HR2YXp32DL0Cx30RkkRVdTBDjbjlOSgpqWWEEeg%3D&reserved=0>

---

From: <[email-masked]>
Date: Thu, 13 May 2021 05:56:33 +0800 (CST)

Hi Jim,

thank you for your kind consideration of my comments. Please find my notes in-line below under the GIM>> tag.

Regards,

Greg Mirsky

Sr. Standardization Expert
预研标准部/有线研究院/有线产品经营部 Standard Preresearch Dept./Wireline Product R&D Institute/Wireline Product Operation Division

E: [email-masked] 
www.zte.com.cn

Original Mail

Sender: JamesGuichard
To: Greg Mirsky;Bruno Decraene;
CC: [email-masked];[email-masked];
Date: 2021/05/12 04:36
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

Hi Greg,

Please see inline.

 

Dear All,

When using the approach described in Section 4, i.e., SR-based SFC with the integrated NSH, how does a re-Classifier scenario be handled? If I understand it correctly, a re-Classifier can change the SPI of the NSH coming back from the SF. If that is the case, the SFF will not match it to the saved SR information because the SPI had changed. How would SFF forward the NSH and the payload?

GIM>> I agree with you, the re-classification is a generic function in SFC and the reader is expected to be familiar with it from Section 4.8 RFC 7665. It might be useful to have some text that reflects what you've explained above.

Related to the scenario from the above. The stored SR information that is not being used appears to become stale. It seems that it creates a leak of resources in a system that should be controlled somehow.

GIM>> I'll think and try to come with some proposal. I thought of how the mechanism can work when I reviewed the draft. At the time, I couldn't figure how to associate the state in the SFF with the new path resulted from the re-classification. I agree, keeping it until it expires is not the best idea.

Regards,

Greg

On Tue, Feb 9, 2021 at 10:31 AM <[email-masked]> wrote:

Dear WG, 

 

 

 

Note that I’ll forward that call to the SFC WG.

Thanks!

 

--Bruno

_________________________________________________________________________________________________________________________   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
 [email-masked]
 https://www.ietf.org/mailman/listinfo/spring

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 13 May 2021 11:40:40 +0530

Hi Jim,

> you have any suggestions?
Dhruv> Perhaps we can add "(SR header (SRH) in case of SRv6)" alongside the
term SR stack. Another option would be using a generic term like "segment
list" instead of a stack (or something similar)?

> Jim> do you have a suggested reference/s ?
Dhruv> My guess would be [TS.29.061]. Better check with a 3GPP expert :)

Thanks!
Dhruv

---

From: James Guichard <[email-masked]>
Date: Thu, 13 May 2021 11:19:20 +0000

Hi Dhruv,

Inline.

From: Dhruv Dhody <[email-masked]>
Sent: Thursday, May 13, 2021 2:11 AM
To: James Guichard <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr

Hi Jim,

- Section 4,

Dhruv> Perhaps we can add "(SR header (SRH) in case of SRv6)" alongside the term SR stack. Another option would be using a generic term like "segment list" instead of a stack (or something similar)?

Jim> ack and updated the document with “segment list” instead of “stack”.

Jim> thanks I will check this out.

Thanks!
Dhruv

---

From: James Guichard <[email-masked]>
Date: Tue, 18 May 2021 15:12:58 +0000

Hi Bruno,

Following up on this. Please see inline.

From: [email-masked] <[email-masked]>
Sent: Tuesday, February 9, 2021 1:41 PM
To: [email-masked]
Cc: [email-masked]
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.

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.

===
This document defines two schemes: NSH-based SFC and SR-based SFC.

§5 is called "Packet Processing Details" but seems to only cover SRv6 and  the "SR-based SFC" scheme.

Jim> I will change the title to reflect these details are only applicable to SR-based SFC (see below).

If so,
- it would be good if the title/section hierarchy could reflect this.

Jim> done (see below).

- what about the behavior for SR-MPLS with the "SR-based SFC" scheme (a priori with SR-MPLS you equally need a cache in order to re-push the SR-MPLS header)

Jim> for SR-MPLS the label semantics indicates the same processing logic. I added some text and broke up the SR-based SFC packet processing section to make this clearer.
====
§4
For "SR-based SFC", my understanding is that the Service Chain (ordered list of SF) is specified in the list of segments.
Please forgive my lack of NSH knowledge, but it seems to me that the NSH SPI look up may return multiple next-hop within a service path for a given SF (e.g. for load balancing). (cf table 4 of RFC 8600).

Jim> yes that is true.

Here, if the NSH SPI change the SFC next-hop, the SR header on the packet will be completely wrong (well most probably the list of segment will override the choice from the NSH SPI look up). Is this a correct understanding?

Jim> no. The SR header is removed before the packet is forwarded to the SF so the SF next-hop is not relevant at the SFF when packets return as a lookup on the SPI will be performed (note: SPI does not change regardless of SF next-hop).

If so is this a bug or a feature? Either way, may be some text would need to be added. e.g. to warn that such SFC feature is not available anymore.

=====
Nits:
- I'm not a fan of the use of the term "details" which to me are "specifications". (e.g. "5. Packet Processing Details", "6. Encapsulation Details", "encapsulation details")

Jim> I can change "Encapsulation Details" to simply "Encapsulation", and "Packet Processing Details" to "Packet Processing for SR-based SFC". Would that satisfy your comment?

- ID Nits still reports one error (**) on the new text (in the abstract).
https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-spring-nsh-sr-04.txt

Thanks,
Regards,
--Bruno

Dear WG,

Thanks!

[1] https://tools.ietf.org/html/draft-ietf-spring-nsh-sr<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-spring-nsh-sr&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C8c3e33b9b6bf412042ac08d8cd2a370e%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637484928488404203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2FlIPoy63MyqXq2zbGEdJFAsPVXRTIVU1aCXTesNho3I%3D&reserved=0>

--Bruno

Thank you.

Thank you.