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

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Thu, 26 Mar 2020 18:35:29 +0000

Hi, SFC,

Apologies, a late response to https://mailarchive.ietf.org/arch/msg/sfc/pNT0kOnFHZeTBLXjuIH0hoKhJs4/

Looking at the document I’ve got a few comments, prefaced with “CMP”:

2.1.  Terminology

CMP: Instead of duplicating definition of terms, why not point to RFC 8300 and RFC 7665 as needed, and only define new terms.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Ver|O|C|R|R|R|R|R|R|   Length  |    MD Type    | Next Protocol |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 1: NSH Base Header

CMP: This is an old version, missing TTLL from RFC 88300

   where

      Metadata Class (MD Class): Defines the scope of the Type field to
      provide a hierarchical namespace.

      Type - Indicates the explicit type of metadata being carried.  The
      value is one from the Network Service Header (NSH) TLV Type
      registry (Section 7).

      Unassigned bit: One unassigned bit is available for future use.
      This bit MUST NOT be set, and it MUST be ignored on receipt.

      Length: Indicates the length of the variable-length metadata, in
      bytes.  In case the metadata length is not an integer number of
      4-byte words, the sender MUST add pad bytes immediately following
      the last metadata byte to extend the metadata to an integer number
      of 4-byte words.  The receiver MUST round the Length field up to
      the nearest 4-byte-word boundary, to locate and process the next
      field in the packet.  The receiver MUST access only those bytes in
      the metadata indicated by the Length field (i.e., actual number of
      bytes) and MUST ignore the remaining bytes up to the nearest 4-
      byte-word boundary.  The length may be 0 or greater.

      A value of 0 denotes a Context Header without a Variable-Length
      Metadata field.

CMP: Instead of copy/paste repeating this from RFC 8300, please add a pointer. Copy/past text gets desynchronized easily.

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

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Metadata Class = 0x0000    |  Type = 0x02  |U|  Length=12  |

CMP: Seems like this Type, as well as others, were changed from the previous version. Why?

7.  IANA Considerations

CMP: This needs registration: Metadata Class = 0x0000

CMP: Also, the Context Type (CT) needs registration.

CMP: And these as well:
* Tenant Type (TT)
* Group Type (GT)
* URI Type

Thanks!

Carlos.

---

From: <[email-masked]>
Date: Sat, 28 Mar 2020 11:13:55 +0800 (CST)

Dear Carlos,

I appreciated your comments.

Please see my response in line with Wei>> tag

Best Regards,

魏月华 Corona Wei

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

原始邮件

发件人：CarlosPignataro(cpignata) <cpignata=[email-masked]>
收件人：[email-masked] <[email-masked]>;
抄送人：[email-masked] <[email-masked]>;
日 期 ：2020年03月27日 02:36
主 题 ：Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-02.txt

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

Hi, SFC,

2.1. Terminology

Wei>> Will delete duplicated NSH, MD Type and SFC which have been defined in  RFC 8300 and RFC 7665

CMP: This is an old version, missing TTLL from RFC 88300
Wei>> Will modify this figure to align with RFC8300

 where

CMP: Instead of copy/paste repeating this from RFC 8300, please add a pointer. Copy/past text gets desynchronized easily.
Wei>> wil delete this part.

4.2. Tenant Identifier

 0 1 2 3

Wei>> Only editorial improvement. 

The Types in previous version were:

0x1,    0x4,    0x6,   0x7,  0x8,     0x9，  0xA，  0xB

The Types in current version are:

0x01,  0x02,  0x03, 0x04,0x05，0x06，0x07，0x08

7. IANA Considerations

CMP: And these as well:

* Tenant Type (TT)

* Group Type (GT)

* URI Type
Wei>> Will follow your advice.

Thanks!

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 28 Mar 2020 13:49:16 +0000

Dear Wei,

Thanks for the quick responses and accepting the suggestions.

Only one follow-up on this, which I bring to the top:

I do not believe that changing a protocol value is an editorial change (or editorial improvement) necessarily.

Are there implementations following the previous allocations? Unused values in between might look weird but it is to necessarily unoptimized, unimproved, or wrong.

If a goal is to have a gapless increasing list and there are no implementations, then TBAs can be used and assignment at the end (e.g., if we split the node/interface into two).

On the other hand, I’d always prioritize implementations (the entropy of reality will take care of disorganize the list :-)

I’d leave them as they were, since there are enough numbers in the space, or ask on the list for changing and wait.

Thanks,

Carlos.

2020/03/27 午後11:13、[email-masked]<mailto:[email-masked]>のメール:

Dear Carlos,

Best Regards,

魏月华 Corona Wei

M: +86 13851460269 E: [email-masked]<mailto:[email-masked]>

原始邮件
发件人：CarlosPignataro(cpignata) <cpignata=[email-masked]<mailto:cpignata=[email-masked]>>
收件人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年03月27日 02:36
主 题 ：Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-02.txt
_______________________________________________
sfc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sfc

Hi, SFC,

2.1.  Terminology

       0                   1                   2                   3

   where

4.2.  Tenant Identifier

       0                   1                   2                   3

7.  IANA Considerations

CMP: And these as well:
* Tenant Type (TT)
* Group Type (GT)
* URI Type

Thanks!

Carlos.

---

From: <[email-masked]>
Date: Mon, 30 Mar 2020 15:29:22 +0800 (CST)

Dear Carlos,

Thank you for reminding this kind of modifications to the mailing list so that more people could notice and give comments.

https://tools.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-tlv-02.txt

Your suggestion is reasonable.

Does anyone aware of implementations? 

or How do you think of TBAs?

I appreciate your comments.

Best Regards,

魏月华 Corona Wei

原始邮件

发件人：CarlosPignataro(cpignata) <[email-masked]>
收件人：魏月华00019655;
抄送人：[email-masked] <[email-masked]>;[email-masked] <[email-masked]>;
日 期 ：2020年03月28日 21:49
主 题 ：Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-02.txt

Dear Wei,

2020/03/27 午後11:13、[email-masked]:

Dear Carlos,

Best Regards,

魏月华 Corona Wei

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

日 期 ：2020年03月27日 02:36

_______________________________________________sfc mailing [email-masked]://www.ietf.org/mailman/listinfo/sfc
Hi, SFC,

2.1. Terminology

 where

4.2. Tenant Identifier

 0 1 2 3

7. IANA Considerations

CMP: And these as well:

* Tenant Type (TT)

* Group Type (GT)

* URI Type

Thanks!

Carlos.

---

From: <[email-masked]>
Date: Tue, 31 Mar 2020 08:16:46 +0000

Hi all,

Some easy to fix comments:

·         You may consider adding more description to the actual usage of each TLVs.

·         The TLVs content should also be clarified. For example, “Akin, but not identical to the usage described in [RFC6437]” does not say what is the diff vs. 6437 nor why not reusing FL would be sufficient if an IPv6 transport is used.

·         Clarify whether conveying multiple instances of each TLV is allowed.

·         What is a “a network-centric forwarding context”?

·         Section 7: Please delete “IANA is requested to create a new "Network Service Header (NSH) TLV” as we do already have a registry at: https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types. You may use this NEW wording:

   This document requests IANA to assign the following types from the
   "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000
   IETF Base NSH MD Class) registry available at:
   https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-<https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types>
   length-metadata-types<https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types>.

Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]
Envoyé : lundi 30 mars 2020 09:29
À : [email-masked]; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-02.txt

Dear Carlos,

Best Regards,

魏月华 Corona Wei

原始邮件

Thanks,

Carlos.

Dear Carlos,

2.1.  Terminology

       0                   1                   2                   3

   where

      registry (Section 7).

      Metadata field.

4.2.  Tenant Identifier

   example of such data.

       0                   1                   2                   3

7.  IANA Considerations

CMP: And these as well:
* Tenant Type (TT)
* Group Type (GT)
* URI Type

Thanks!

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 31 Mar 2020 13:22:47 +0000

Hi, Med,

Really good comments!

In general, I tend to agree with your second comment, which is a meta-comment, about adding more descriptive text. That said, I’d cautious that this document defines foundational data fields and not the usage and use cases of them.

Based on that, see below.

2020/03/31 午前4:16、[email-masked]<mailto:[email-masked]>のメール:

Hi all,

•         You may consider adding more description to the actual usage of each TLVs.

This document defines information elements rather than use cases for them. As such, I hesitate in adding too much usage which can be containing. That said, do you have specific thoughts on usage?

•         The TLVs content should also be clarified. For example, “Akin, but not identical to the usage described in [RFC6437]” does not say what is the diff vs. 6437 nor why not reusing FL would be sufficient if an IPv6 transport is used.

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

•         Clarify whether conveying multiple instances of each TLV is allowed.

That is not for this document to say. Some use cases can restrict to one interface for example, others to multiple.

•         What is a “a network-centric forwarding context”?

Here’s my take on text proposal on various fields (this is full text, not diff):

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

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

4.3.  Content Type

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

4.4.  Ingress Network Information

   This data identifies the ingress network node, and, if required,
   ingress interface.

// this should be split into Node and Ingress Interface.

4.4. Ingress Network Node Information

   This context header identifies the ingress network node.

4.5. Ingress Network Interface Information

   This context header identifies the ingress network interface.

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

...

•         Section 7: Please delete “IANA is requested to create a new "Network Service Header (NSH) TLV” as we do already have a registry at: https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable-length-metadata-types. You may use this NEW wording:

Indeed!!!

And additionally should move the Types to TBAs.

Thanks,

Carlos.

Thank you.

Cheers,
Med

De : sfc [mailto:[email-masked]] De la part de [email-masked]<mailto:[email-masked]>
Envoyé : lundi 30 mars 2020 09:29
À : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-02.txt

Dear Carlos,

Best Regards,
魏月华 Corona Wei

原始邮件
发件人：CarlosPignataro(cpignata) <[email-masked]<mailto:[email-masked]>>
收件人：魏月华00019655;
抄送人：[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>;
日 期 ：2020年03月28日 21:49
主 题 ：Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-02.txt
Dear Wei,
Thanks for the quick responses and accepting the suggestions.

Thanks,

Carlos.

Dear Carlos,

2.1.  Terminology

       0                   1                   2                   3

   where

      registry (Section 7).

      Metadata field.

4.2.  Tenant Identifier

   example of such data.

       0                   1                   2                   3

7.  IANA Considerations

CMP: And these as well:
* Tenant Type (TT)
* Group Type (GT)
* URI Type

Thanks!

Carlos.

---

From: <[email-masked]>
Date: Tue, 31 Mar 2020 14:07:33 +0000

Hi Carlos,

Please see inline.

Cheers,
Med

De : Carlos Pignataro (cpignata) [mailto:[email-masked]]
Envoyé : mardi 31 mars 2020 15:23
À : BOUCADAIR Mohamed TGI/OLN
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [sfc] I-D Action: draft-ietf-sfc-nsh-tlv-02.txt

Hi, Med,

Really good comments!

In general, I tend to agree with your second comment, which is a meta-comment, about adding more descriptive text. That said, I’d cautious that this document defines foundational data fields and not the usage and use cases of them.
[Med] Without being verbose, we need to explain why a TLV is useful/how it can be used. For example, a reader may ask: how the flow TLV is populated? Why it is needed if we can access to the inner packet? should the flow TLV by updated on-path? What if there are address rewriting SFs?

I may have answers to some of those questions but my point is that we need to have some of the details in the document (especially, when this is important for interoperability).

Hi all,

This document defines information elements rather than use cases for them. As such, I hesitate in adding too much usage which can be containing. That said, do you have specific thoughts on usage?
[Med] I do have for some (content type, for example), but not sure about the others. For example, who sets the tenant-ID? Is it by control or extracted from the packets? Idem for the policy-ID.

Agreed. I would replace:

With at least

[Med] That’s a good start. Thanks. The natural questions then are: what is a label? What to do with a labeled a packet? do we allow to change the label when progressing in an SFP? We need to think about this further.

That is not for this document to say.
[Med] RFC8300 says the following:

   If multiple instances of the same metadata are included in an NSH
   packet, but the definition of that Context Header does not allow for
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   it, the SFC-aware SF MUST process the first instance and ignore
   ^^
   subsequent instances.  The SFC-aware SF MAY log or increase a counter
   for this event.

Some use cases can restrict to one interface for example, others to multiple.

Here’s my take on text proposal on various fields (this is full text, not diff):
[Med] Thank you for drafting this. I hope I can provide text as well.

4.1.  Forwarding Context

4.2.  Tenant Identifier

4.3.  Content Type

4.6.  Flow ID

...

Indeed!!!

Thanks,

Carlos.

Thank you.

Cheers,
Med

Dear Carlos,

Best Regards,
魏月华 Corona Wei

原始邮件

Thanks,

Carlos.

Dear Carlos,

2.1.  Terminology

       0                   1                   2                   3

   where

      registry (Section 7).

      Metadata field.

4.2.  Tenant Identifier

   example of such data.

       0                   1                   2                   3

7.  IANA Considerations

CMP: And these as well:
* Tenant Type (TT)
* Group Type (GT)
* URI Type

Thanks!

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 31 Mar 2020 14:21:51 +0000

Hi, Med,

It is somewhat hard for me to follow the inlined comments. If there’s something I miss, please let me know. I’ll preface with “[CMP]"

2020/03/31 午前10:07、[email-masked]<mailto:[email-masked]>のメール:

Hi Carlos,

Please see inline.

Cheers,
Med

Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi, Med,

Really good comments!

[CMP] I believe this document should answer the questions on syntax and definition/meaning, but not the use-case. Saying “Flow id is for marking packets of the same flow, and it is a 32-bit number” is as far as I think this should go.

[CMP] What do others think?

Interoperability has many layers. Syntax and semantics need to be ensured in this doc.

Hi all,

[CMP] To me specific usages are outside scope. Many specifications in the IETF describe the fields while future companion documents define usage. This, to me, is one of those.

Agreed. I would replace:

With at least

[CMP] I did not mean to add a “label” as a noun, but rather label as in mark or tag.

[CMP] Immutability is a great question! I tent to think that it could change, but what do you think?

[CMP] Fair enough. We could add requirements on multiplicity.

[CMP] Of course! That’s a back-of-napkin start only.

4.1.  Forwarding Context

4.2.  Tenant Identifier

4.3.  Content Type

4.6.  Flow ID

...

Indeed!!!

Thanks,

Carlos.

Thank you.

[CMP] You are welcome!

Carlos.

Cheers,
Med

Dear Carlos,

Best Regards,
魏月华 Corona Wei

原始邮件

Thanks,

Carlos.

Dear Carlos,

2.1.  Terminology

       0                   1                   2                   3

   where

      registry (Section 7).

      Metadata field.

4.2.  Tenant Identifier

   example of such data.

       0                   1                   2                   3

7.  IANA Considerations

CMP: And these as well:
* Tenant Type (TT)
* Group Type (GT)
* URI Type

Thanks!

Carlos.