Last Call Review of draft-ietf-sfc-nsh-19
review-ietf-sfc-nsh-19-tsvart-lc-eddy-2017-08-22-00
| Request | Review of | draft-ietf-sfc-nsh |
|---|---|---|
| Requested rev. | 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 | |
| Draft 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 rev. | 19 (document currently at 28) | |
| Review result | Not Ready | |
| Review completed: | 2017-08-22 |
Review
review-ietf-sfc-nsh-19-tsvart-lc-eddy-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, 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.