Skip to main content

Last Call Review of draft-ietf-sfc-nsh-19

Request Review of draft-ietf-sfc-nsh
Requested revision No specific revision (document currently at 28)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2017-08-25
Requested 2017-08-11
Authors Paul Quinn , Uri Elzur , Carlos Pignataro
I-D last updated 2017-08-22
Completed reviews Rtgdir Early review of -10 by Acee Lindem (diff)
Secdir Last Call review of -18 by Christian Huitema (diff)
Opsdir Last Call review of -18 by Jürgen Schönwälder (diff)
Rtgdir Last Call review of -18 by Acee Lindem (diff)
Opsdir Last Call review of -19 by Jürgen Schönwälder (diff)
Tsvart Last Call review of -19 by Wesley Eddy (diff)
Genart Last Call review of -19 by Dan Romascanu (diff)
Secdir Telechat review of -25 by Christian Huitema (diff)
Assignment Reviewer Wesley Eddy
State Completed
Review review-ietf-sfc-nsh-19-tsvart-lc-eddy-2017-08-22
Reviewed revision 19 (document currently at 28)
Result Not Ready
Completed 2017-08-22
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,

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.