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
d3e3e3@xxxxxxxxx
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
On Thu, Jun 16, 2022 at 9:19 AM The IESG <iesg-secretary@xxxxxxxx> 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-call@xxxxxxxx mailing lists by 2022-06-30. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
