Re: [Tsv-art] Tsvart last call review of draft-ietf-sfc-nsh-19

[Joe Touch <[e-mail]>]

FWIW, this doc would benefit from consideration of the terminology
developed for draft-ietf-intarea-tunnels

In particular, the issue of the differences between the MTU of a hop,
path, and edge-to-edge (e.g., the last including receiver reassembly).

Joe


On 8/22/2017 11:41 AM, Wesley Eddy wrote:
> Reviewer: Wesley Eddy
> Review result: Not Ready
>
> In general, the document describes the NSH structure and some loose examples of
> how it might be used, but this isn't a very clear protocol specification.  It's
> mostly just about NSH format and less on the expected behaviors of NSH
> speakers, how to maintain state of the NSH peers or other data structures, etc.
>  It seems like there could easily be problems in interoperations between
> vendors coding solely based on the document.
>
> Section 5 on fragmentation considerations is nebulous and has technical issues.
>  Specifically, it says that PMTUD should be used when NSH is encapsulated in
> IP.  PMTUD requires ICMP to work, and has known issues when ICMP is blocked in
> the path.  Is there a requirement is SFC networks running NSH that ICMP needs
> to be carried by the network?  Further, there is no discussion here on PLPMTUD
> versus PMTUD, nor reference to the specific RFCs, algorithms, and options or
> configuration parameters suggested to do this properly in SFC systems.
>
> In Section 6, the assumptions, expectations, or hard requirements for mapping
> NSH onto an underlying "transport" are not very clear.  Only examples are
> given, and some of these (e.g. Ethernet) are not capable of doing things like
> detecting fragmentation issues.  Other examples (e.g. GRE) are tunnels where
> there may be more state.  There is no discussion about whether there are
> assumptions about packet ordering/reordering, duplication, losses, corruption,
> etc.
>
> It isn't clear why the particular encapsulations discussed have been chosen
> rather than UDP or TCP-based options.
>
> There should probably be more discussion about what types of network paths NSH
> is suitable for and that the choice of an encapsulation for NSH needs to be
> appropriate to the underlying path between service entities.  Some
> encapsulations will need to be tuned for the combination of path and offered
> load of traffic.  Some can provide much more feedback to the NSH "layer" than
> others that are mainly open-loop.
>
> Propagation of errors through a service function chain or signaling of errors
> backwards on a chain seems like it bears further discussion.
>
>