I think this is a useful draft and support its publication.
Minor comments:
- At the beginning of Section 4 you assume, for that scenario, that SFs
are NSH aware. It is my impression that you make that assumption just to
simplify things. If my impression is correct, I suggest inserting "... for
simplicity of exposition ..." or something like that in the first sentence
of Section 4. On the other hand, if I am mistaken and there is some
requirement that SFs be NSH aware, that should be explained.
- I found Section 9 to be a little sparse and jarring. Perhaps a few
more words could be added. Also, "time" sounds like a specific time while I
think you are referring to a time interval. I suggest something like the
following:
- The SFF cache mechanism referred to in Sections 4 and 5 must remove
cached entries after an appropriate time interval determined by the
implementation. Further, an implementation MAY allow network
operators to
set the said time value interval. In the case where a packet
arriving from
an SF does not have a matching cached entry, the SFF SHOULD log
this event.
- Suggest Section 10 would read better if worded as follows:
- To align with Section 5 of [RFC8300] and Section 5.3 of [RFC8754],
increasing the underlying MTU to avoid fragmentation of SR/NSH traffic
within an SR domain is RECOMMENDED.
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e...@gmail.com
On Thu, Jun 16, 2022 at 9:19 AM The IESG <iesg-secret...@ietf.org> wrote:
>
> The IESG has received a request from the Source Packet Routing in
> Networking
> WG (spring) to consider the following document: - 'Integration of Network
> Service Header (NSH) and Segment Routing for
> Service Function Chaining (SFC)'
> <draft-ietf-spring-nsh-sr-11.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> last-c...@ietf.org mailing lists by 2022-06-30. Exceptionally, comments
> may
> be sent to i...@ietf.org instead. In either case, please retain the
> beginning
> of the Subject line to allow automated sorting.
>
> Abstract
>
>
> This document describes the integration of the Network Service Header
> (NSH) and Segment Routing (SR), as well as encapsulation details, to
> support Service Function Chaining (SFC) in an efficient manner while
> maintaining separation of the service and transport planes as
> originally intended by the SFC architecture.
>
> Combining these technologies allows SR to be used for steering
> packets between Service Function Forwarders (SFF) along a given
> Service Function Path (SFP) while NSH has the responsibility for
> maintaining the integrity of the service plane, the SFC instance
> context, and any associated metadata.
>
> This integration demonstrates that NSH and SR can work cooperatively
> and provide a 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.
>
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-spring-nsh-sr/
>
>
> The following IPR Declarations may be related to this I-D:
>
> https://datatracker.ietf.org/ipr/4626/
> https://datatracker.ietf.org/ipr/3695/
>
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
