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

From: <[email-masked]>
Date: Tue, 11 May 2021 17:43:55 +0800 (CST)

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
收件人：[email-masked];
抄送人：[email-masked];
日 期 ：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 refeence 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>>

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 ?

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

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   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 11 May 2021 09:56:06 -0400

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 <[email-masked]> wrote:
> there. Also should probably mention and include a reference to RFC
> 8979.
>
> <<WeiYuehua:
>
> Accepted. >>
>
>

OK.

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

> will delete this section per comments from JoelM.Halpern and  mohamed.boucadair >>

OK.

Thanks,
Donald

---

From: <[email-masked]>
Date: Wed, 12 May 2021 09:46:43 +0800 (CST)

Donald,

Thank you.

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.

Best Regards,

Yuehua Wei

M: +86 13851460269 E: [email-masked]

原始邮件

发件人：DonaldEastlake
收件人：魏月华00019655;
抄送人：[email-masked];Joel M. Halpern;[email-masked];[email-masked];
日 期 ：2021年05月11日 21:57
主 题 ：Re: [sfc] Review of draft-ietf-sfc-nsh-tlv-05

Hi,

 
OK.

 
 
OK.
 
Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 12 May 2021 14:01:15 -0400

Hi,

> 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

---

From: <[email-masked]>
Date: Thu, 13 May 2021 10:05:26 +0800 (CST)

OK，uploaded already.

looking forward to further review and more comments from SFCers

Thank you.

Best Regards,

Yuehua Wei

原始邮件

发件人：DonaldEastlake
收件人：魏月华00019655;
日 期 ：2021年05月13日 02:02

Hi,

You're welcome.

 
Thanks,
Donald