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

Hi Wes,

thanks for the review! I've just put in my ballot position and note your 
second and third points there as well. However, from my point of few the 
fragmentation part seems actually okay. If you have further comments there 
please reply directly to Carlos or/and maybe you can put in a new review for 
this current version today (because this doc in on the telechat tomorrow).

Thanks!
Mirja

On 22.08.2017 20:41, 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.
> 
> 
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
> 