Subject: Re: [ANCP] On TLVs

From: "Maglione Roberta" <[email-masked]>
Date: Fri, 22 Aug 2008 16:52:38 +0200

Hello,
     as Design Team is going to start working on other Multicast messages that may re-use Target Type TLV  we'd like to know if anybody has additional opinions/comments or would like have more clarifications on the proposed new TLV.

Thanks and best regards.
Roberta on behalf of the Design Team.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
Sent: Friday, August 01, 2008 9:42 AM
To: Peter Arberg; Mark Townsley (townsley); [email-masked]
Subject: Re: [ANCP] On TLVs

Hi,

> -----Original Message-----
> From: Peter Arberg [mailto:[email-masked]]
> Sent: 31 July 2008 15:03
> To: Wojciech Dec (wdec); Mark Townsley (townsley); [email-masked]
> 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.

>
> Peter
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf
> > Of Wojciech Dec (wdec)
> > Sent: 30. juli 2008 18:32
> > To: Mark Townsley (townsley); [email-masked]
> > Subject: Re: [ANCP] On TLVs
> >
> > 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
> > > _______________________________________________
> > > ANCP mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/ancp
> > >
> > _______________________________________________
> > ANCP mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ancp
> >
>
_______________________________________________
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

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

---

From: Peter Arberg <[email-masked]>
Date: Fri, 22 Aug 2008 09:25:17 -0700

Hi Maglione,

I have nothing against a Target Type TLV, my comments is much more
towards where and when you use it.

I will still like to see a description on the TLV, what the idea is
by introducing it, generic usage of it and the rules you envision
it to play by.

One of my comments on the TLV was that if you really think this is a
generic TLV which can be used in many places, then maybe it is not
the multicast draft which is the right place to define it, maybe it
needs to be defined in the protocol draft, and then simply used in the
new messages where it makes sense.

So I will say, please update the existing drafts with the Target Type
TLV explanation, then it is much easier to make comments if people
are satisfied with the TLV and its usage or not.

cheers,
Peter

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Maglione Roberta
> Sent: 22. august 2008 07:53
> To: [email-masked]
>      as Design Team is going to start working on other
> Multicast messages that may re-use Target Type TLV  we'd like
> to know if anybody has additional opinions/comments or would
> like have more clarifications on the proposed new TLV.
>
> Thanks and best regards.
> 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: "Maglione Roberta" <[email-masked]>
Date: Mon, 25 Aug 2008 11:14:24 +0200

Hi Peter,
    thanks for your feedback.

> towards where and when you use it.

Great.

> by introducing it, generic usage of it and the rules you envision

Indeed, I agree with you we need to update the draft with a better description for this TLV and clearer explanation of its uses.

> the multicast draft which is the right place to define

I understand your point, our initial intention was to incorporate the whole Multicast extensions in the ANCP Protocol I-D, thus we didn't clearly differentiated between Multicast specific items and more generic elements, like for example Target Type TLV.
Now, in case this draft may live as standalone, we may consider following your suggestion and moving some stuff like, Target Type TLV, in ANCP Protocol I-D.
We will discuss this point in the design team meeting and we will update the draft(s) accordingly.

In the meanwhile if nobody is against Target Type TLV, Design Team will consider re-using it across other messages.

Thanks and best regards,
Roberta

-----Original Message-----
From: Peter Arberg [mailto:[email-masked]]
Sent: Friday, August 22, 2008 6:25 PM
To: Maglione Roberta; [email-masked]
Subject: RE: Re: [ANCP] On TLVs

Hi Maglione,

cheers,
Peter

> Behalf Of Wojciech Dec (wdec)

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it