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]. 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 === 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. If so, - it would be good if the title/section hierarchy could reflect this. - 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) ==== §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). 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? 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") - 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 From: spring [mailto:spring-boun...@ietf.org] On Behalf Of bruno.decra...@orange.com Sent: Tuesday, February 9, 2021 7:31 PM To: spring@ietf.org Cc: draft-ietf-spring-nsh...@ietf.org 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.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
