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

[Donald Eastlake <[e-mail]>]

Hi,

Thanks for accepting so many of my suggestions. With these changes, I
support this draft. See a few responses below.

On Tue, May 11, 2021 at 5:44 AM <[e-mail]> wrote:
>
> To Donald: Thank you Donald. Please see inline and the attachment.
>
> To Joel & Med, Please see the attachment for resolution of previous comments.
>
>
> Thank you so much!
>
>
> Best Regards,
>
> Yuehua Wei
>
> 原始邮件
> 发件人：DonaldEastlake
> 收件人：[e-mail];
> 抄送人：[e-mail];
> 日 期 ：2021年05月03日 04:34
> 主 题 ：[sfc] Review of draft-ietf-sfc-nsh-tlv-05
> 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.
>
> <<WeiYuehua:
>
> Right, since it's a set of VLCH, It's not easy to do the summary in the title. Let's do the explanation in "Introduction".
>
> Comments are welcome>>
>
> 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 reference to RFC
> 8979.
>
> <<WeiYuehua:
>
> Accepted. >>
>
>
> 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.
>
> <<WeiYuehua:
>
> Accepted.  Will change all the "draft" to "document"  >>
>
> 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.
>
> <<WeiYuehua:
>
> Accepted.  >>
>
> 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.
>
> <<WeiYuehua:
>
> Accepted.  will delete TT field, Length is variable>>
>
> 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.)
>
> <<WeiYuehua:
>
> Accepted.  will delete NIT field, Length is variable. I'd prefer not involving AFI， because Node ID could be various format other than address>>

OK.

> Section 4.5: Note that NVGRE specifies an 8-bit flow ID.
>
> <<WeiYuehua:
>
> https://datatracker.ietf.org/doc/html/rfc7637
>
> RFC7637 is an informational document. I am not sure if it's necessary/proper to mention the 8-bit flow ID here ?
>
> >>

Mentioning the 8-bit flow ID here would create a down reference to the
NVGRE RFC but I don't see that as much of a problem. VXLAN is also
Informational and also causes a down reference.

> 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?
>
> <<WeiYuehua:
>
> Accepted.  >>
>
> 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.
>
> <<WeiYuehua:
>
> will delete this section per comments from JoelM.Halpern and  mohamed.boucadair >>

OK.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]
> Section 5: I think more is needed in the Security Considerations.
> Shouldn't it reference draft-ietf-sfc-nsh-integrity?
>
> <<WeiYuehua:
>
> Accepted.  >>
>
> 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.
>
> <<WeiYuehua:
>
> Accepted.  >>
>
> 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.
>
> <<WeiYuehua:
>
> Accepted.  >>
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   [phone] (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  [e-mail]