Subject: [ANCP] On TLVs

From: Mark Townsley <[email-masked]>
Date: Wed, 30 Jul 2008 14:18:26 +0100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 30 Jul 2008 19:32:10 +0200

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mark Townsley (townsley)
> Sent: 30 July 2008 15:18
> To: [email-masked]
> 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

---

From: "DE CNODDER Stefaan" <[email-masked]>
Date: Wed, 30 Jul 2008 20:10:50 +0200

It makes no sense to allow the target type to be at any position.  It
makes it more complex to process and for what reason?  What are the
benefits of allowing it to be placed at a random position in the
message?

regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wojciech Dec (wdec)
Sent: woensdag 30 juli 2008 19:32
To: Mark Townsley (townsley); [email-masked]
Subject: Re: [ANCP] On TLVs

Hi Mark,

Regards,
Woj.

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Mark Townsley (townsley)
> Sent: 30 July 2008 15:18
> To: [email-masked]
> 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.
> 

> 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?
> 

> coder might expect it to *be* a TLV when it is not by mandate from the

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

---

From: Peter Arberg <[email-masked]>
Date: Thu, 31 Jul 2008 06:02:42 -0700

Hi,

my comments in the meeting was exactly what you write Mark. Woj and others have after the meeting explained the reasoning for the TLV, as they have expanded the transactional multicast case from being a 1 target (single dsl line) to potentially in the future be multiple targets enabled simultaneously.

This can then with the TLV be done in 2 ways, either by including sub-tlvs for additional ACI identifiers, or add a new identifier which could be learned or configured by some today non identified mechanism.

As such the TLV is in my mind okay if people in general buy into the usability of having multiple simultaneous targets for transactional multicast.

In my mind I do not see a need for the capability of a NAS telling the AN to update the multicast forwarding state for many ports simultaneously, as individual clients in the multicast use-case discussed so far have to send individual joins, and as such it can not be a goal to be able to add many when they have to join individually.

So as I see it at the moment, there seems to be an argument that a generic target TLV can be useful in other/many ANCP messages, but it is defined in a transactional multicast draft, without any explanation why it is suggested, and what it will solve.

Also it is not clear to me what the authors have in mind for a use-case of multi targets in transactional multicast draft, which are trying to solve the framework requirements of the multicast use-case which is mainly focused around IPTV.

So it will be nice to either have a better explanation why multiple targets are useful, if this is aimed at having the transactional multicast solution handle a future use-case where many clients can be added to a multicast stream which the NAS learns out-of-band what clients should be added, or if the intention is to add a capability for the NAS to delay multicast joins so they can be batched in the ancp message.

In my mind the usage of this target TLV is just adding complexity to the transactional multicast communication, and it is in my mind not adding any significant value.

Peter

> Behalf Of Wojciech Dec (wdec)
> Sent: 30. juli 2008 18:32

---

From: "Maglione Roberta" <[email-masked]>
Date: Thu, 31 Jul 2008 19:46:08 +0200

Hi Peter,
               I agree with you that we may need to clarify a little bit more in which scenarios Target TLV could be useful and which are the benefits we can get from it. Let me try to give you my view on this and a couple of examples.

> Also it is not clear to me what the authors have in mind for a use-case of multi targets in transactional multicast draft, > which are trying to solve the framework requirements of the multicast use-case which is mainly focused around IPTV.

When we talk about re-using Target TVL across different messages, we have in mind different messages that will be defined to address other multicast use-cases. As Sanjay pointed out during the meeting Multicast Replication Control messages take in care only of one of the multicast use-cases currently defined in the framework, but there are still other multicast use-case to be addressed.
I give you a couple of examples:
1. all the multicast scenarios relay on white/grey/black lists concept. NAS can use ANCP to add or delete these lists on the AN. We think it could make sense to re-use a generic TLV like Target-TLV to achieve this goal.
2. we have a use case for multicast reporting that contains 3 different sub-cases:
Per port report query, per-flow report query and global report query
In all this three cases the Multicast report message can stay the same the only difference will be the object of the query: this case  can fit in the semantic of  the Target-type TLV and in case of global report query you may have a Target that actually contains all the ports or if you prefer you can just have  a "*" wildcard

In addition I see one more reason to support Target TLV:
Multicast use-cases are somehow different from other use cases defined in the draft, because at least in my mind, but you and others may have different opinions,  I see Multicast as a functionality technology independent.
 Considering also the fact that as far as I know we don't have any legacy for Multicast messages,  I think it makes sense to design new messages not strictly related to DSL but also thinking about future extensibility.
We may have other technologies that need the same multicast functionality except they use an identifier that is not ACI and it is longer then 64 bits. Why redesign everything from scratch?  ANCP framework draft already talks about PON and Wimax, I think it would be good if we can take in care of other possible technologies with a minimal impact on the complexity.

This is my view but I'd like to hear other comments/opinions on this topic.

Thanks and regards,
Roberta

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Peter Arberg [[email-masked]]
Sent: Thursday, July 31, 2008 3:02 PM
To: Wojciech Dec (wdec); Mark Townsley (townsley); [email-masked]
Subject: Re: [ANCP] On TLVs

Hi,

Peter

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

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Fri, 1 Aug 2008 09:42:05 +0200

Hi, 

> From: Peter Arberg [mailto:[email-masked]] 
> Sent: 31 July 2008 15:03
> Subject: RE: Re: [ANCP] On TLVs
> 
> Hi,
> 
> my comments in the meeting was exactly what you write Mark. 
> Woj and others have after the meeting explained the reasoning 
> for the TLV, as they have expanded the transactional 
> multicast case from being a 1 target (single dsl line) to 
> potentially in the future be multiple targets enabled simultaneously.
> 
> This can then with the TLV be done in 2 ways, either by 
> including sub-tlvs for additional ACI identifiers, or add a 
> new identifier which could be learned or configured by some 
> today non identified mechanism.
> 
> As such the TLV is in my mind okay if people in general buy 
> into the usability of having multiple simultaneous targets 
> for transactional multicast.

The re-use of such TLV is not just intended for transactional multicast,
but pretty much any (future) message type. Furthermore, it's not just a
case of multiple targets, but totally different target types, eg an ACL
is very much a target, and it's identifier (a string say) is not much
different from that of an ACI. It is very useful to have this traget
type concept in the protocol in order to have it extensible.

> 
> In my mind I do not see a need for the capability of a NAS 
> telling the AN to update the multicast forwarding state for 
> many ports simultaneously, as individual clients in the 
> multicast use-case discussed so far have to send individual 
> joins, and as such it can not be a goal to be able to add 
> many when they have to join individually.

The use-case for addressing multiple ports through a command (report) is
already in the framework/requirements doc.

> 
> So as I see it at the moment, there seems to be an argument 
> that a generic target TLV can be useful in other/many ANCP 
> messages, but it is defined in a transactional multicast 
> draft, without any explanation why it is suggested, and what 
> it will solve.
> 
> Also it is not clear to me what the authors have in mind for 
> a use-case of multi targets in transactional multicast draft, 
> which are trying to solve the framework requirements of the 
> multicast use-case which is mainly focused around IPTV.
> 
> So it will be nice to either have a better explanation why 
> multiple targets are useful, if this is aimed at having the 
> transactional multicast solution handle a future use-case 
> where many clients can be added to a multicast stream which 
> the NAS learns out-of-band what clients should be added, or 
> if the intention is to add a capability for the NAS to delay 
> multicast joins so they can be batched in the ancp message.
> 
> In my mind the usage of this target TLV is just adding 
> complexity to the transactional multicast communication, and 
> it is in my mind not adding any significant value.

Granted, a better explanation is due and will be put in place. As
mentioned earlier, the complexity is trivial; it's just a TLV # wrapper,
ie an extra few bytes, nothing more.

Thanks,
Woj.

> > Of Wojciech Dec (wdec)
> > Let me go over what the rationale for this TLV was. You and others 
> > feel free to comment/re-asses/advise.
> >
> > (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.
> >
> >
> > > 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
> > >
> location, and 
> > > 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.
> > >
> 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.
> > >
> encoded as a 
> > > It was a mistake, and we witnessed actual interop 
> problems from it 
> > > in the beginning. It either should have been a proper TLV placed