[sfc] Review of draft-ietf-sfc-nsh-tlv-05

[Donald Eastlake <[e-mail]>]

Hi,

I have reviewed draft-ietf-sfc-nsh-tlv-05. Attached is a detailed
suggestion as to wording. Below are the main points.

Title: The title sounds like the draft is a general discussion of
these headers rather than the specification of several of them. I
think it should be a little more specific.

Abstract: Seems very brief. I suggest a slight expansion to provide a
little bit of background.

Introduction: There are a few missing definite articles here and
there. Also should probably mention and include a refeence to RFC
8979.

Section 4: There is one occurrence of "draft" that should be changed
to "document" or the like. For Forwarding Contexts where there are
unused bits, the document should specify that they must be sent as
zero and ignored on receipt.

Section 4.1: It seems like most Forwarding Contexts are 24 bits or
less. Given that there is a Length in header already, I think in most
cases the Forwarding Context should be in the same word with the CT
field saving 4 bytes. The only 32-bit Forwarding Context that occurs
to me is the Session ID in L2TPv3 (which is called Key in GRE) so for
that you would need a Length of 8 and the additional word. Should
probably also list the VSID in NVGRE and VNI in GENEVE. Should specify
the alignment of shorter Forwarding Context values.

Section 4.2: If Tenant IDs are either 32 bits or 64 bits or, more
generally, as long as they are an even multiple of 8 bits, I see no
reason for the TT field and the wasted 28 bits after it. That
information is provided by the Length field.

Section 4.3: If the Ingress Node IDs are either 32 or 128 bits or,
more generally, if they are a multiple of 8 bits, I see no reason for
the NIT field and the wasted 28 bits after it. To the extent that
Ingress Node IDs are addresses, note that 48 and 64 bits MAC addresses
would also have a unique length. (If it is actually necessary to
include the type of address, then instead of the NIT field, there
should be a 16-bit field with an AFI, followed by 16 reserved bits,
and then the Node ID/Address.)

Section 4.5: Note that NVGRE specifies an 8-bit flow ID.

Section 4.6: If there is only one type of Source & Dest Group, which
seem to be represented by opaque 32-bit quantities, why do we need the
GT field and wasted 28 bits?

Section 4.7: This should reference RFC 3986. It's "Uniform" Resource
Identifier, not "Universal". Need to specify something about the 4
bits after the UT field. What sort of "compacted hash" is type 0x2?
Actually, I don't think you can compact a hash -- hashes are more or
less pseudorandom and incompressible. They can be truncated but not
compacted.

Section 5: I think more is needed in the Security Considerations.
Shouldn't it reference draft-ietf-sfc-nsh-integrity?

Section 7: Generally, the best thing to do when requesting that IANA
set up a registry or sub-registry is to list the Name, the
Registration Procedures, and the Reference at the top in the same
order they appear in the actual IANA Web pages.
     If my suggestions above are accepted, there is no need for
Sections 7.2, 7.3, or 7.4.
    There is no reason to say "and maintain". IANA automatically
maintains all IANA registries.

Section 8: I think RFC 7665 should be an Informational reference, not
Normative. The [GROUPBASEDPOLICY] and [GROUPPOLICY] references need a
URL or some additional information so someone could find them. As
marked in the attachment, I think several Informational references
should be added.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]