Subject: Tsvart last call review of draft-ietf-sfc-nsh-19

From: Wesley Eddy <[email-masked]>
Date: Tue, 22 Aug 2017 11:41:57 -0700

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.

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Aug 2017 20:27:28 -0700

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 1 Sep 2017 04:25:44 +0000

Hello, Wesley,

Thanks for the review! Please find some follow-ups inline.

—
Carlos Pignataro, [email-masked]

“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 <[email-masked]> wrote:
> 
> Reviewer: Wesley Eddy
> Review result: Not Ready
> 
> 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

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.

> assumptions about packet ordering/reordering, duplication, losses, corruption,

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?

> rather than UDP or TCP-based options.

The market chose those. Note that there are UDP-based options, such as Vxlan-gpe.

> others that are mainly open-loop.

Since there are no requirement of the underlying layer, no particular feedback needed.

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