Subject: [sfc] early AD review of draft-ietf-sfc-nsh-10

From: Alia Atlas <[email-masked]>
Date: Wed, 5 Oct 2016 13:51:59 -0400

As requested by the WG Chairs, I have done an early AD review of
draft-ietf-sfc-nsh-10.    First, I would like to thank the editors, Paul
and Uri, and those who provided text in the discussions.  This document has
improved significantly.

Below are my review comments.  There are still a number of minor things to
clean up or discuss.

Minor:
a) In Sec 3.2, it says "MD Type: indicates the format of NSH beyond the
mandatory Base Header

   and the Service Path Header.  MD Type defines the format of the
   metadata being carried.  Please see IANA Considerations section
   below.

   NSH defines two MD types:

   0x1 - which indicates that the format of the header includes fixed
   length context headers (see Figure 4 below).

   0x2 - which does not mandate any headers beyond the Base Header and
   Service Path Header, but may contain optional variable length context
   information."

   This is an 8-bit field and from the IANA considerations appears to be
intended to be an integer.   This implies that it isn't possible for an NSH
packet to have both the fixed length context headers and the TLV context
information.    Why is that the case?  Since the MD Type 1 is MTI, it seems
to provide an excellent way of ensuring that information can be understood
by every entity, and then TLV information could be used for additional
information to be passed along.

Is there a reason or a conversation when this approach was ruled out?

b) Sec 3.2:  The Next Protocol field defines different values for IPv4 and
IPv6.  Why isn't there simply a value for IP that the enclosed IP packet
can then self-identify as to its version?    Separately, can you please
name the Next Protocol field to either something that indicates what types
of next protocol might be carried or at least a less generic name so that
intelligent reuse is possible?

c) Sec 12.2.5:  I am concerned about all values in the NSH Base Header Next
Protocol field being "Standards Action".   Any new encapsulation now will
have to get allocations from potentially EtherType, NSH Next Protocol, IP
Next Protocol, and possibly more if the NSH Next Protocol field isn't
reused.  I would strongly recommend at least having part of the range
available for Specification Required which will also require guidance to be
provided for an expert reviewer.

d) Sec 3.3:  "Service Index MUST be decremented by Service Functions or by
SFC Proxy nodes after performing required services and the new
   decremented SI value MUST be used in the egress NSH packet."
Is this "decremented by 1"' or "strictly decreasing" or something else?  Is
it possible for the SI along a given SPI to ever increase (for instance for
an intentional loop)?  Please clarify.
   This same issue appears in Sec 4 bullet 3.

e) Sec 8.2:  Is there a reason that removal of metadata isn't mentioned?
Presumably, an SF can remove a piece of metadata if it is no longer needed
by the SFP for the remainder of the processing?

f) Sec 9:   "Further, as  described in [section 8.1], operators can and
should use indirect
   identification for personally identifying information, thus
   significantly mitigating the risk of privacy violation."
The reference of Section 8.1 doesn't describe this.  Can you please update
the reference?

g) Sec 12.1:  I continue to be concerned about the reuse of an EtherType
that was allocated initially for another purpose.  Has the IEEE ok'd this
and assigned ownership to the IETF?

h) Sec 12.2.3:  The description for MD Type 1 and MD Type 2 should be more
accurate and not the same!  "Indicates fixed metadata attached" and
"Indicates TLV metadata may be attached"' or something similar.

i)Sec 12.2.4 MD Class Registry:  This defines Expert Review for a range but
provides no guidance to the expert on how to evaluate or make decisions.
That is needed.  Given the need to potentially understand the different
meanings of the meta-data, I think that Specification Required would be
preferable to Expert Review.

Regards,
Alia