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

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 1 Mar 2010 16:04:20 +0100

Tom and all,

Tom's proposal to collapse what is currently called "TLVs" and "sub-TLVs" into a single notion of TLVs (that are allowed to be embedded one into another) seems to make sense to me.
This would mean that ancp-proto:
	* collapses the two IANA registries into one
	* adjusts the text that defines the notion of TLVs and sub-TLVs
	* adjust text whenever a sub-TLV is discussed.
Right?

I have not looked at the "padding/boundary" issue, though.

Tom, 
one question. You say below:
"In the -01 version of the multicast extensions document, that condition is not met.  " meaning that some sub-TLVs have the same type code as TLVs. Which conflict do you have in mind?
(the only allocated sub-TLVs I see are    < Request-Source-IP  | 0x92> and < Request-Source-MAC | 0x93>) 

On 22 Feb 2010, at 12:35, Tom Taylor wrote:

> 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
> 
> 
> Maglione Roberta wrote:
>> 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.
> ...
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Tom Taylor <[email-masked]>
Date: Mon, 01 Mar 2010 15:29:46 -0500

Besides Request-Source-xx, there were two sub-TLVs in the 
Multicast-Service-Profile, with Type Codes 0x01 and 0x02.

Francois Le Faucheur wrote:
> Tom and all,
> 
> Tom's proposal to collapse what is currently called "TLVs" and "sub-TLVs" into a 
> single notion of TLVs (that are allowed to be embedded one into another) seems 
> to make sense to me.
> "In the -01 version of the multicast extensions document, that condition is not 
> met.  " meaning that some sub-TLVs have the same type code as TLVs. Which 
> conflict do you have in mind?
>> 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
>>
>>
>> Maglione Roberta wrote:
>>> 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.
>> ...
>> [email-masked] <mailto:[email-masked]>
> *
> Francois Le Faucheur*
> *Distinguished Engineer*
> *Corporate Development*
> [email-masked] <mailto:[email-masked]>
> Phone: *+33 49 723 2619*
> Mobile: *+33 6 19 98 50 90*
> 
> 
> 	
> 
> *Cisco Systems France*
> Greenside
> 400 Ave de Roumanille
> 06410 Sophia Antipolis
> France
> Cisco.com <http://www.cisco.com>
> 
> 	 
> 
>  Think before you print.
> 
> This email may contain confidential and privileged material for the sole use of 
> the intended recipient. Any review, use, distribution or disclosure by others is 
> strictly prohibited. If you are not the intended recipient (or authorized to 
> receive for the recipient), please contact the sender by reply email and delete 
> all copies of this message.
> 
> Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – 
> Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 
> 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel 
> Givone.
>