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: gregory.mir...@ztetx.com
www.zte.com.cn
Original Mail
Sender: JamesGuichard
To: Greg Mirsky;Bruno Decraene;
CC: spring@ietf.org;draft-ietf-spring-nsh...@ietf.org;
Date: 2021/05/12 04:36
Subject: Re: [spring] WG Last Call draft-ietf-spring-nsh-sr
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Hi Greg,
Please see inline.
From: Greg Mirsky <gregimir...@gmail.com>
Sent: Wednesday, February 17, 2021 2:38 AM
To: Bruno Decraene <bruno.decra...@orange.com>
Cc: spring@ietf.org; draft-ietf-spring-nsh...@ietf.org
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 <bruno.decra...@orange.com> 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
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
