Hello, Wesley, Thanks for the review! Please find some follow-ups inline. — Carlos Pignataro, carlos@xxxxxxxxx “Sometimes I use big words that I do not fully understand, to make myself sound more photosynthesis." > On Aug 22, 2017, at 2:41 PM, Wesley Eddy <wes@xxxxxxxxxxxxxxx> 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. Please note that this specification is scoped to within a management domain, and not the open Internet. As such, the expectation is that the 2nd paragraph of Section 5 suffices. And within said administrative domain, it is also expected that ICMPs will not be blocked (even when they are unreliable by nature). > 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. There is no requirement than ICMP is carried by the network, since NSH can run directly over Ethernet for example. Further, note that the relevant sentence begins: “ For example, when the NSH is encapsulated in IP, IP-level" Making it an example and not a normative broad requirement. PLPMTUD is not mentioned since there is no TCP and no other packetization layer for which, to my knowledge, PLPMTUD is specified. > > 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. I think you have a good point here in enclosing “transport” within quotes. What is meant here is an encapsulation, and not a transport in the TSV sense of the term. We can use more precision on this. Would that help a bit? > > It isn't clear why the particular encapsulations discussed have been chosen > rather than UDP or TCP-based options. > The market chose those. Note that there are UDP-based options, such as Vxlan-gpe. > 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. Since there are no requirement of the underlying layer, no particular feedback needed. > > Propagation of errors through a service function chain or signaling of errors > backwards on a chain seems like it bears further discussion. > > OAM, which includes propagation of errors, is explicitly outside the scope of this spec (see O bit definition). I would like to hear your feedback (and, ideally, specific recommendations and suggestions) regarding the use of “transport” in Section 6. Thanks! — Carlos.