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. > >