Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-03.txt

["Carlos Pignataro (cpignata)" <[e-mail]>]

Dear Wei,

Thanks for addressing the vast majority of my comments from two full reviews, and incorporating all my textual suggestions.

Some still remain:

1.  s/byte/octet/g —> there are still 4 instances of “byte”.

2. Content Type

4.3.  Content Type
I’d recommend removing this one. It does not seem to be adequately defined.

3. Note ID

                     Figure 6: Ingress Network Node ID
Why is the length fixed to 8? I understand a 32-bit number can be a most common Node ID, but what if a 128-bit number wants to be used?

I’d allow either of two lengths.

4. Flow ID

4.6.  Flow ID

   Flow ID provides a representation of the flow.  Akin, but not
   identical to the usage described in [RFC6437].

This still needs to be more appropriately defined. I would replace:

   Flow ID provides a representation of the flow.  Akin, but not
   identical to the usage described in [RFC6437].

With at least

   The Flow ID provides a field in the NSH MD Type 2 to label
   packets belonging to the same flow.  Absence of this field, or
   a value of zero denotes that packets have not been labeled.



5. IANA

   This document defines the following new values (Table 1)in the
   Network Service Header (NSH) metadata context Type registry:

There’s a space missing in the first line.

More importantly though, I would add two Experimentation values in Table 1. I would also reserve the value of 0x00.


6. IANA Citation.

I think the URI for IANA should be without the file part:
https://www.iana.org/assignments/nsh/#optional-variable-length-metadata-types <https://www.iana.org/assignments/nsh/#optional-variable-length-metadata-types>


Lastly, here is some of the text proposed for some section descriptions:

Forwarding Context

   The forwarding context used for segregation and forwarding scope can
   Take several forms depending on the network environment. For example,
   VXLAN/VXLAN-GPE VNID, VRF identification, and VLAN. This context
   header carries this network-based forwarding context.

Tenant Identifier

   Tenant identification is often used for segregation within a multi-
   tenant environment.  Orchestration system-generated tenant IDs are an
   example of such data. This context header carries both the format and
   value of the Tenant identifier.

Content Type

// Remove
// I believe this needs further thinking on the namespace fo Content Types, could even be draft-penno-sfc-appid-05

Ingress Network Node Information

   This context header identifies the ingress network node.

Ingress Network Interface Information

   This context header identifies the ingress network interface.

Flow ID

   The Flow ID provides a field in the NSH MD Type 2 to label
   packets belonging to the same flow.  Absence of this field, or
   a value of zero denotes that packets have not been labeled.


Thanks!

Carlos.


> 2020/05/20 午後11:05、[e-mail]のメール:
> 
> Hi folks,
> 
> I just uploaded a new version of NSH metadata 2 variable-length context headers.
> 
> The updates resolved the comments received from the mailing list.
> 
> One important technical modification is splitting of the Ingress Network context header to two context headers (in 4.4 and 4.5) which is proposed by Carlos, Med and Greg.
> 
> Please keep reviewing and give your comments.
> 
>  <https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03.txt>https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03.txt <https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03.txt>
> 
> In addition,  I would as the  WG to consider changing the length of Tenant Identifier context header ( in 4.2) to "var", so that TT and IANA sub-registry are not needed.
> 
> 
> 
> Thank you for your kind support.
> 
> 
> 
> Best Regards,
> 魏月华 Corona Wei
> ZTE Corporation
> M: [phone] E: [e-mail] <mailto:[e-mail]>
> 
> 原始邮件
> 发件人：[e-mail] <[e-mail]>
> 收件人：[e-mail] <[e-mail]>;
> 抄送人：[e-mail] <[e-mail]>;
> 日 期 ：2020年05月21日 08:40
> 主 题 ：[sfc] I-D Action: draft-ietf-sfc-nsh-tlv-03.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Service Function Chaining WG of the IETF.
> 
>         Title           : Network Service Header Metadata Type 2 Variable-Length Context Headers
>         Authors         : Yuehua (Corona) Wei
>                           Uri Elzur
>                           Sumandra Majee
>     Filename        : draft-ietf-sfc-nsh-tlv-03.txt
>     Pages           : 12
>     Date            : 2020-05-20
> 
> Abstract:
>    This draft describes Network Service Header (NSH) Metadata (MD) Type
>    2 variable-length context headers that can be used within a service
>    function path.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sfc-nsh-tlv-03
> https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
> 
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc