Re: [ANCP] On TLVs

["Wojciech Dec (wdec)" <wdec at cisco.com>]

Hi Mark,

Let me go over what the rationale for this TLV was. You and others feel
free to comment/re-asses/advise.

1. The target type wrapper TLV
There is a very reasonable need to have a protocol wide (ie re-usable
across messages) container TLV that carries in its payload information
allowing the recipient to identify the target of a command. There may be
different target type identifiers, besides different types of target
(these would need to be definied in the future).
The information that allows an access node to identify the traget
(access port) is currently the ACI, but others may get defined, inluding
things like group of ports say, or an access-list. If the access port,
and/or the ACI were the only type of object and identifier respectively
that we envisage commands to act upon, then we can do away with the
target type wrapper, gaining a few bytes of efficency, at the cost of
extensibility. Given though other types of targets and identifiers are a
definite possility, the wrapper TLV would appear to be a small
cost/complication to have.

2. Fixed position of target wrapper TLV
It was thought that having the target be the 1st information TLV in a
multicast request message (the same TLV could however be anywhere else
in other messages) would allow the recipient to be more efficent in
determining whether the target is valid. Processing any commands before
identifying the target makes little sense, and since a single message
may contain N commands, it appearead resonable to have the target be
before the commands. That said, nothing is set in stone, so if the WG is
more comfortable with allowing this TLV to be anywhere in the message,
that's a change that can be easily done.

Regards,
Woj.


> -----Original Message-----
> From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On 
> Behalf Of Mark Townsley (townsley)
> Sent: 30 July 2008 15:18
> To: ancp at ietf.org
> Subject: [ANCP] On TLVs
> 
> 
> Taking this to the list...  There was a discussion on whether 
> a TLV was the right construct to use for something.
> 
> First, TLVs are great, they allow extensibility, are proven 
> protocol mechanics, etc. etc.
> 
> But. If you restrict the TLV to be in a fixed location, 
> always be present, and never be repeated, it effectively 
> neuters all of the good reasons to have a TLV.
> 
> For example:
> 
> Type = X
> Length = Y
> Value = Information
> 
> If this is always present, always present at the same 
> location, and never repeated in a list of TLVs, you are 
> effectively putting an "X" and "Y" in your protocol message 
> which will always be present and adds no value at all. It's 
> always there. If it is *always* there, and *always* the same, 
> what's the point of it even existing? Just to see if one 
> implementation can put it in the right place and the other 
> can check to see if it is there?
> 
> In actuality, you could just put "Information" the meesage as 
> part of the fixed header that precedes it.
> 
> It's really not a big deal at the end of the day, one can 
> skip over "X and Y" when processing. But, it's one more thing 
> to get wrong in terms of interoperability. i.e., make 
> something *look* like a TLV, and some coder might expect it 
> to *be* a TLV when it is not by mandate from the RFC.
> 
> I speak from experience here. L2TP has its Message Type 
> encoded as a TLV, with the same kinds of rules I heard 
> proposed in the meeting today. 
> It was a mistake, and we witnessed actual interop problems 
> from it in the beginning. It either should have been a proper 
> TLV placed anywhere, or a part of the fixed header at the 
> start of the message.
> 
> - Mark
> _______________________________________________
> ANCP mailing list
> ANCP at ietf.org
> https://www.ietf.org/mailman/listinfo/ancp
> 
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp