Subject: Re: [ANCP] Small ANCP issues -- definition of sub-TLV

From: Tom Taylor <[email-masked]>
Date: Tue, 09 Feb 2010 14:29:13 -0500

I forgot to say as part of my proposal for sub-TLVs that the type number for a 
sub-TLV is scoped to the specific TLV rather than the set of TLVs. That is, the 
set of sub-TLV type numbers for any given TLV always runs from 0x01 up.

Another name for "sub-TLV" might be "variable-length field".

Tom Taylor wrote:
> I'm doing a revision of the multicast extensions draft and have a couple 
> of trivial issues, the sort of thing that is important to an editor.
> 
> Can we provide a consistent definition of a sub-TLV? My problem is that 
> currently the text in the base document says that the Status-Info TLV, 
> for instance, can contain sub-TLVs. However, these sub-TLVs are actually 
> TLVs which happen to be encapsulated in the Status-Info. On the other 
> hand, both the base protocol draft and the multicast extensions draft 
> have IANA registries for sub-TLV numbers.
> 
> I make the following proposal:
> 
> a) A sub-TLV is defined as a tag-length-value field that is always a 
> subordinate part of a specific TLV type. That is, sub-TLVs are not 
> reusable between TLVs. I doubt this introduces much if any specification 
> redundancy. This definition should be given as part of the terminology 
> section of the base protocol document.
> 
> b) If we want the set of sub-TLVs for a given TLV type to be extensible, 
> we define an IANA registry for "Sub-TLVs of TLV Type xxxxx".
> 
> c) It is also possible for TLVs to be encapsulated in other TLVs. We 
> would use the term "encapsulated TLV" instead of "sub-TLV" for this case.
> 
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 10 Feb 2010 16:45:59 -0500

I've decided this is a bad idea. The basic problem is how the receiver 
distinguishes between encapsulated TLVs and sub-TLVs within the same TLV. My 
conclusion is that "sub-TLVs" should all share the same type code space, which 
means changes in presentation in the base document (I think the actual type 
codes can stay the same) and changes in both type code values and presentation 
in the multicast extensions document.

The definition of a sub-TLV is a TLV that happens to be encapsulated in another 
TLV. It may or may not occur on its own in a different context.

Tom Taylor
Multicast extensions co-editor

Tom Taylor wrote:
> I forgot to say as part of my proposal for sub-TLVs that the type number 
> for a sub-TLV is scoped to the specific TLV rather than the set of TLVs. 
> That is, the set of sub-TLV type numbers for any given TLV always runs 
> from 0x01 up.
> 
...

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 11 Feb 2010 11:00:58 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tom Taylor
> Sent: 10 February 2010 22:46
> To: [email-masked]
> Subject: Re: [ANCP] Small ANCP issues -- definition of sub-TLV
> 
> I've decided this is a bad idea. The basic problem is how the 
> receiver distinguishes between encapsulated TLVs and sub-TLVs 
> within the same TLV. My conclusion is that "sub-TLVs" should 
> all share the same type code space, which means changes in 
> presentation in the base document (I think the actual type 
> codes can stay the same) and changes in both type code values 
> and presentation in the multicast extensions document.
> 
> The definition of a sub-TLV is a TLV that happens to be 
> encapsulated in another TLV. It may or may not occur on its 
> own in a different context.

I believe that this is inline with the intent to try to get "re-usable"
information elements (to avoid calling them TLVs or sub-TLVs). What
changes in the base document you think will be required?

Regards,
Woj.

> > I forgot to say as part of my proposal for sub-TLVs that the type 
> > number for a sub-TLV is scoped to the specific TLV rather 
> than the set of TLVs.
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp
>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 11 Feb 2010 09:10:05 -0500

The last entry in the current IANA section is a sub-TLV type registry. That 
should be absorbed into the TLV registry.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 11 Feb 2010 15:50:41 +0100

> From: Tom Taylor [mailto:[email-masked]] 
> Sent: 11 February 2010 15:10
> To: Wojciech Dec (wdec)
> Cc: [email-masked]
> The last entry in the current IANA section is a sub-TLV type 
> registry. That should be absorbed into the TLV registry.

I see no problem with that. Others?

-Woj.

> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Tom Taylor
> >> receiver distinguishes between encapsulated TLVs and 
> sub-TLVs within 
> >> the same TLV. My conclusion is that "sub-TLVs" should all 
> share the 
> >> same type code space, which means changes in presentation 
> in the base 
> >> document (I think the actual type codes can stay the same) and 
> >> changes in both type code values and presentation in the multicast 
> >> extensions document.
> >>
> encapsulated 
> >> in another TLV. It may or may not occur on its own in a different 
> >> context.
> >

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 15 Feb 2010 10:28:15 +0100

Hi Tom,
        I think I'm missing something here:
Last IANA section contains sub-TLVs like " Actual-Net-Data-Upstream", " Actual-Net-Data-Rate-Downstream" and these sub-TLVs were present since the initial version of the document. Are you proposing to change these sub-TLVs to TLVs?
I'm not familiar with this type of details but wouldn't such a change impact current implementations?
Thanks,
Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Thursday, February 11, 2010 3:10 PM
To: Wojciech Dec (wdec)
Cc: [email-masked]
Subject: Re: [ANCP] Small ANCP issues -- definition of sub-TLV

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Tom Taylor <[email-masked]>
Date: Mon, 15 Feb 2010 10:15:50 -0500

The change will have zero impact because the type codes don't overlap. The 
problem in distinguishing between TLVs and sub-TLVs came from something I did in 
the multicast extensions document. I declared some structures to be sub-TLVs, 
hence local to a particular TLV. I started assigning type codes beginning with 
0x01, figuring it was a local numbering space. But a receiver parsing the 
message can't tell whether that is TLV 0x01 (defined in the base document) or 
sub-TLV 0x01 (specific to the given TLV). The conclusion was that the TLVs and 
sub-TLVs had to share the same type code space. Hence there is no need to 
distinguish them. In fact, in my latest edit of the multicast extensions 
document, I redefined the sub-TLVs to have potentially broader usage.

---

From: <[email-masked]>
Date: Tue, 16 Feb 2010 13:32:43 +0100

All,

may be didn't get the whole issue. But as Roberta indicated a change in fundamental TLV structure of a port status message such as TLVs which are already used for basic port information like net data rates is not acceptable. 

If changes only belong to multicast extensions may be considered because only one use case is affected.

Regards
Thomas

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 22 Feb 2010 12:04:54 +0100

Hi All,
        I am not sure I understood this discussion, because last entry of the IANA section in the ancp-protocol does not contain any multicast specific sub-TLVs all the sub-TLVs are related to the other use cases.

Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, February 16, 2010 1:33 PM
To: [email-masked]; Maglione Roberta
Cc: [email-masked]; [email-masked]
Subject: AW: [ANCP] Small ANCP issues -- definition of sub-TLV

 All,

Regards
Thomas

---

From: Tom Taylor <[email-masked]>
Date: Mon, 22 Feb 2010 06:35:41 -0500

Let me state this again.

You need some way for the parser at the receiving end to determine what is next 
in the message body, and that something is the TLV/sub-TLV type code. Unless 
there is some other semantic means of distinguishing a TLV from a sub-TLV, that 
means the TLVs and sub-TLVs have to share the same type code space. In other 
words, a sub-TLV cannot have the same type code as a TLV.

In the base protocol document, that condition is met. In the -01 version of the 
multicast extensions document, that condition is not met.  Hence the multicast 
extensions document has to change. The base document does not have to change on 
that ground alone. (I should say that there are errors in the base document 
where sometimes an assignment is 10 (e.g), somewhere else it is 0x10.)

Now I don't know why the original authors of the base document took the trouble 
to distinguish sub-TLVs from TLVs, or was it my compilation of IANA requirements 
that was responsible? But if the type codes share the same numbering space, why 
bother to put them into a separate IANA registry? I would point out that the 
same data structure can be a TLV or a sub-TLV, for example, if it is appended to 
the Status-Info TLV as diagnostic information. There are lots of other examples.

There is one technical issue in all this. TLVs are padded to a word boundary. I 
seem to recall that somewhere some text said that sub-TLVs are run together 
without intervening padding. We'll have to decide which rule applies.

Tom

...

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 24 Feb 2010 10:29:55 +0100

Hi Tom,
    thanks  for the clarification, the issue is clear to me now.
As you pointed out that this change may imply one technical issue, I think we should get the WG consensus before modifying the ancp protocol draft.

Regards,
Roberta

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]]
Sent: Monday, February 22, 2010 12:36 PM
To: Maglione Roberta
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [ANCP] Small ANCP issues -- definition of sub-TLV

Let me state this again.

Tom

...