Hi Mike, Thanks for the review. Comments inline (Jim>).
-----Original Message----- From: Mike McBride via Datatracker <[email protected]> Sent: Monday, June 28, 2021 4:56 PM To: [email protected] Cc: [email protected]; [email protected] Subject: Rtgdir early review of draft-ietf-spring-nsh-sr-07 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." Jim> ack and I have updated the document with the above text minus "with each other" as this seems redundant. 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." Jim> ack and text updated. 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]." Jim> ack. 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" Jim> agreed and removed. _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
