Subject: [sfc] Next steps to progress draft-ietf-sfc-nsh-tlv

From: Greg Mirsky <[email-masked]>
Date: Wed, 25 Mar 2020 16:27:14 -0700

Dear All,
I agree with Joel that the update of the important for SFC NSH
draft, draft-ietf-sfc-nsh-tlv, went all but unnoticed. I believe that the
draft provides very important for SFC NSH information. Constructs that are
defined in the draft are needed to move forward other work that the SFC WG
is chartered to work on. Hence, I thank Corona for her work on the draft
and offer my comments to start a discussion (or split discussion into
several threads):

   - Forwarding Context TLV defines three code points out of possible 16.
   Should these be under IANA control as a sub-registry?
   - Tenant Type TLV uses an explicit indication of the length of the
   Tenant ID. Two values, 32 bits, and 64 bits, defined in the draft. Could
   this TLV use the Length field on MD Type = 2 as the indicator of the length
   of Tenant ID (similar to the POLICY-ID TLV defined in Section 4.8)? In this
   case, the Length will be variable and TT and Reserved fields can be omitted.
   - Ingress Network Information TLV includes information about Node ID and
   Source Interface/Port. Each field is four octets long. At the same time,
   some scenarios, as noted in draft-ietf-ippm-ioam-data
   <https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-data/>, data may
   have "short format" and "wide format". Hence my questions:
      - is there a use case where the length of either Node ID or
      Source/Interface Port larger than four octets?
      - if "yes", would using sub-TLVs for Node ID and Source/Interface
      Port be useful?
   - the Flow TLV, in my opinion, is well-suited for users to select a
   Rendered Service Path among all available for the particular SFF. I think
   that the current text in the section can be expanded to point to this use
   case.

I hope we can discuss these topics on the list and/or virtual meeting and
move this draft to the WGLC.

Regards,
Greg

---

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

Dear Greg,

My comments inline.

> 2020/03/25 午後7:27、Greg Mirsky <[email-masked]>のメール:
> 
> Dear All,
> I agree with Joel that the update of the important for SFC NSH draft, draft-ietf-sfc-nsh-tlv, went all but unnoticed. I believe that the draft provides very important for SFC NSH information. Constructs that are defined in the draft are needed to move forward other work that the SFC WG is chartered to work on. Hence, I thank Corona for her work on the draft and offer my comments to start a discussion (or split discussion into several threads):
> 	• Forwarding Context TLV defines three code points out of possible 16. Should these be under IANA control as a sub-registry?

I agree.

> 	• Tenant Type TLV uses an explicit indication of the length of the Tenant ID. Two values, 32 bits, and 64 bits, defined in the draft. Could this TLV use the Length field on MD Type = 2 as the indicator of the length of Tenant ID (similar to the POLICY-ID TLV defined in Section 4.8)? In this case, the Length will be variable and TT and Reserved fields can be omitted.

There are many potential encodings, what’s the benefit of changing?

> 	• Ingress Network Information TLV includes information about Node ID and Source Interface/Port. Each field is four octets long. At the same time, some scenarios, as noted in draft-ietf-ippm-ioam-data, data may have "short format" and "wide format". Hence my questions:
> 		• is there a use case where the length of either Node ID or Source/Interface Port larger than four octets?

Not to me — and if it is, when it is, it can be defined later.

> 		• if "yes", would using sub-TLVs for Node ID and Source/Interface Port be useful?
> 	• the Flow TLV, in my opinion, is well-suited for users to select a Rendered Service Path among all available for the particular SFF. I think that the current text in the section can be expanded to point to this use case.

I think it should be the other way around. If there’s a documented use case it can point to this document.

Thanks,

Carlos.

> I hope we can discuss these topics on the list and/or virtual meeting and move this draft to the WGLC.
> 
> Regards,
> Greg
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 27 Mar 2020 14:32:59 -0700

Dear Carlos,
thank you for your response to my comments. Please find my follow-up notes
in-line below under GIM>> tag.

Regards,
Greg

On Thu, Mar 26, 2020 at 11:39 AM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> > I agree with Joel that the update of the important for SFC NSH draft,
> draft-ietf-sfc-nsh-tlv, went all but unnoticed. I believe that the draft
> provides very important for SFC NSH information. Constructs that are
> >       • Forwarding Context TLV defines three code points out of possible
> 16. Should these be under IANA control as a sub-registry?
>
> I agree.
>
> >       • Tenant Type TLV uses an explicit indication of the length of the
GIM>> My apologies for the confusion. My comment was on the Tenant
Identifier TLV, not the Tenant Type. The Tenant Identifier is defined as an
eight octets long field and two values for TT being defined. As a result,
if the length of the identifier is 32 bits, the overhead is 60 bits. At the
same time, the Length field in the Context Header is quite capable to
explicitly identify the length of the meta-data, even if the length is not
aligned at 4-bytes word boundary. The draft reminds that at the end of
Section 3. I propose to change the format of the Tenant ID TLV to the
following:

       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=var  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Tenant ID            ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> >       • Ingress Network Information TLV includes information about Node
> ID and Source Interface/Port. Each field is four octets long. At the same
> time, some scenarios, as noted in draft-ietf-ippm-ioam-data, data may have
> "short format" and "wide format". Hence my questions:
> >               • is there a use case where the length of either Node ID
> or Source/Interface Port larger than four octets?
>
GIM>> Another way to approach it could be to split the Ingress Information
TLV into two TLVs, Node and Ingress Interface/Port. Each TLV has the format
as proposed above. Thus we should not worry about defining a new TLV for ID
of a different size.

> >       • the Flow TLV, in my opinion, is well-suited for users to select
> a Rendered Service Path among all available for the particular SFF. I think
GIM>> I agree, that is another way. I find that the current text is too
terse and is not sufficient to justify the introduction of this TLV.

 Akin, but not identical to the usage described in [RFC6437].

We might encounter a comment that would suggest removing this TLV from the
document until its use is better defined.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 28 Mar 2020 02:55:36 +0000

Dear Greg,

Please see inline.

2020/03/27 午後5:32、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:

Dear Carlos,
thank you for your response to my comments. Please find my follow-up notes in-line below under GIM>> tag.

Regards,
Greg

On Thu, Mar 26, 2020 at 11:39 AM Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,

My comments inline.

> 2020/03/25 午後7:27、Greg Mirsky <[email-masked]<mailto:[email-masked]>>のメール:
>
> Dear All,

I agree.

There are many potential encodings, what’s the benefit of changing?
GIM>> My apologies for the confusion. My comment was on the Tenant Identifier TLV, not the Tenant Type. The Tenant Identifier is defined as an eight octets long field and two values for TT being defined. As a result, if the length of the identifier is 32 bits, the overhead is 60 bits. At the same time, the Length field in the Context Header is quite capable to explicitly identify the length of the meta-data, even if the length is not aligned at 4-bytes word boundary. The draft reminds that at the end of Section 3. I propose to change the format of the Tenant ID TLV to the following:

       0                   1                   2                   3

I am not concerned with a little extra overhead. However, the benefit of directly including a 24-bit tenant-id is very useful. At the same time, it limits to not define non-numerical tenant ids.

Given the Tenant-ids defined is 32-bit and 64-bit only, this alternate encoding is OK.

Not to me — and if it is, when it is, it can be defined later.
GIM>> Another way to approach it could be to split the Ingress Information TLV into two TLVs, Node and Ingress Interface/Port. Each TLV has the format as proposed above. Thus we should not worry about defining a new TLV for ID of a different size.

In practice, I still expect the current format to be what is generally used — 4-octet for each.

That said, separating node and interface seems like a good approach.

In fact, I wonder if we should say something about potentially receiving multiple incoming interface ids ((bundles, tunnels, ad physical interfaces)

I think it should be the other way around. If there’s a documented use case it can point to this document.
GIM>> I agree, that is another way. I find that the current text is too terse and is not sufficient to justify the introduction of this TLV.
 Akin, but not identical to the usage described in [RFC6437].
We might encounter a comment that would suggest removing this TLV from the document until its use is better defined.

We might encounter a comment that would suggest keeping this as-is because this sub-TLV can be used for some other use and narrowing on a single use-case does not explicitly limit others.

This document is not about specifying use cases but information elements.

As such, I still disagree with adding such text.

Best,

Carlos.

Thanks,

Carlos.

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

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 27 Mar 2020 20:00:44 -0700

Dear Carlos,
thank you for your kind consideration of my notes. I'm glad we agree on
more items now and I hope others will join in the discussion helping to
progress this work.

Regards,
Greg

On Fri, Mar 27, 2020 at 7:55 PM Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Dear Greg,
>
> Please see inline.
>
> 2020/03/27 午後5:32、Greg Mirsky <[email-masked]>のメール:
>
> Dear Carlos,
>> >       • Forwarding Context TLV defines three code points out of
>> possible 16. Should these be under IANA control as a sub-registry?
>>
>> I agree.
>>
>> >       • Tenant Type TLV uses an explicit indication of the length of
>> the Tenant ID. Two values, 32 bits, and 64 bits, defined in the draft.
>> Could this TLV use the Length field on MD Type = 2 as the indicator of the
>> length of Tenant ID (similar to the POLICY-ID TLV defined in Section 4.8)?
>> In this case, the Length will be variable and TT and Reserved fields can be
>> omitted.
>>
> I am not concerned with a little extra overhead. However, the benefit of
> directly including a 24-bit tenant-id is very useful. At the same time, it
> limits to not define non-numerical tenant ids.
>
> In fact, I wonder if we should say something about potentially receiving
> multiple incoming interface ids ((bundles, tunnels, ad physical interfaces)
>
>
> We might encounter a comment that would suggest keeping this as-is because
> this sub-TLV can be used for some other use and narrowing on a single
> use-case does not explicitly limit others.
>