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

[Donald Eastlake <[e-mail]>]

Hi,

On Tue, May 11, 2021 at 9:46 PM <[e-mail]> wrote:
>
> Donald,
>
> Thank you.

You're welcome.

> Still looking forward to further review and more comments from SFCers before I  publish a new version to IETF website by the end of this week.

I recommend you go ahead and post your current version so reviews will
be based on that.

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

> Best Regards,
>
> Yuehua Wei
>
> M: [phone] E: [e-mail]
>
>
>
> 原始邮件
> 发件人：DonaldEastlake
> 收件人：魏月华00019655;
> 抄送人：[e-mail];Joel M. Halpern;[e-mail];[e-mail];
> 日 期 ：2021年05月11日 21:57
> 主 题 ：Re: [sfc] Review of draft-ietf-sfc-nsh-tlv-05
> 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]