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? - 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. - 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? - Section 5, path-id is not used anywhere else; should it be mentioned that this is Service Path Identifier (SPI)? - 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. Nits - Remove references in the Abstract - Should there be some reference to 3GPP in the first paragraph Section 1.1? - Section 5, s/RFC 8754/[RFC8754] 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 <bruno.decra...@orange.com> 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: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 >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
