Re: [spring] Rtgdir early review of draft-ietf-spring-nsh-sr-07

[[e-mail]]

Mike, Thank you for your review.

Authors, Please reply to the review.

--Bruno
> -----Original Message-----
> From: Mike McBride via Datatracker [mailto:[e-mail]]
> Sent: Monday, June 28, 2021 10:56 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Rtgdir early review of draft-ietf-spring-nsh-sr-07
> 
> Reviewer: Mike McBride
> Review result: Has Nits
> 
> Reviewer: Mike McBride
> Review result: Ready with nits
> 
> I have been selected to do a routing directorate early review of this draft
> which has passed SPRING WG Last Call (copied to SFC WG) , but would benefit
> from a larger review.
> 
> Document: draft-ietf-spring-nsh-sr
> Review Date: 28 June 2021
> Intended Status: Standards Track
> 
> Summary:
> 
> A couple of nits found but otherwise this document is ready to proceed to the
> IESG.
> 
> Comments:
> 
> The document is well written. Aside from the following recommended changes its
> good to go.
> 
> There are a couple of long semi-awkward sentences. They still make sense but,
> for readability, it would help to reword them. And there are a couple of
> recommended grammar related changes.
> 
> 1. The 3rd paragraph, in the Abstract, says:
> 
> "The integration described in this document demonstrates that NSH and
> SR can work jointly and complement each other leaving the network
> operator with the flexibility to use whichever transport technology
> makes sense in specific areas of their network infrastructure, and
> still maintain an end-to-end service plane using NSH."
> 
> I would recommend rewording this to:
> 
> "This integration demonstrates that NSH and SR can work
> cooperatively with each other and provide the network
> operator with the flexibility to use whichever transport technology
> makes sense in specific areas of their network infrastructure while
> still maintaining an end-to-end service plane using NSH."
> 
> 2. In the section 1.1. SFC Overview and Rationale I would recommend changing
> this:
> 
> "Particularly, cascading SFs at the so-called Third Generation
> Partnership Project (3GPP) Gi interface (N6 interface in 5G
> architecture) in the context of mobile network infrastructure, have
> shown their limitations, such as the same redundant classification
> features must be supported by many SFs to execute their function,
> some SFs receive traffic that they are not supposed to process (e.g.,
> TCP proxies receiving UDP traffic), which inevitably affects their
> dimensioning and performance, an increased design complexity related
> to the properly ordered invocation of several SFs, etc."
> 
> to this:
> 
> "For instance, cascading SFs at the 3GPP (Third Generation
> Partnership Project) Gi interface (N6 interface in 5G
> architecture) has shown limitations such as 1) redundant classification
> features must be supported by many SFs to execute their function,
> 2) some SFs receive traffic that they are not supposed to process (e.g.,
> TCP proxies receiving UDP traffic) which inevitably affects their
> dimensioning and performance, 3) an increased design complexity related
> to the properly ordered invocation of several SFs."
> 
> 3. Need a comma after "problems":
> 
> "In order to solve those problems and to decouple the services
> topology from the underlying physical network while allowing for
> simplified service delivery, Service Function Chaining (SFC)
> techniques have been introduced [RFC7665]."
> 
> 4. Probably can scratch the "Indeed" and just start with "SFC...":
> 
> "Indeed, SFC allows to dynamically create service
> planes that can be used by specific traffic flows"
> 
> 


_________________________________________________________________________________________________________________________

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.