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

[[e-mail]]

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: [e-mail] 
www.zte.com.cn








Original Mail



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




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

 

Hi Greg,


 


Please see inline.


 



From: Greg Mirsky <[e-mail]> 
 Sent: Wednesday, February 17, 2021 2:38 AM
 To: Bruno Decraene <[e-mail]>
 Cc: [e-mail]; [e-mail]
 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.


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.


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.


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



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. 

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