Subject: [manet] DLEP Vendor Extensions negotiation

From: "Taylor, Rick" <[email-masked]>
Date: Fri, 19 Dec 2014 10:26:33 +0000

Henning, All,

I have been trying to catch up on this discussion having been out of the office for the last two days.  Can I summarise what I think you are proposing for Vendor Extensions, and ask for some feedback?

You propose that DLEP peers MAY implement metric sets outside of the core DLEP specification, and advertise the fact by placing a Vendor_Extension Data Item in the session initialization signals (Peer_Init/Peer_Init_Ack).  Ignoring the details of encoding, the Vendor Extension  Data Item uniquely identifies an 'extension', which is a set of metrics (defined elsewhere) using some TLV type codes from the experimental range.  Either Peer may reject the presence of a  Vendor Extension Data Item through the mechanisms already defined in DLEP-07 for Optional Signal/Data Items supported.

In principle I like this proposal, it ties in well with some of the ideas I have been pushing around, and I have the following comments:

1) The Vendor Extension TLV can follow the same format as the existing draft-07 Vendor Extension TLV, i.e. Use an IEEE OUI as you mentioned, but without the sub-type and payload.

2) There are very few experimental TLV values reserved.  I wonder whether a separate bank of TLV type codes for vendor extensions should be reserved and the Vendor Extension data item declare how many from that bank it uses, e.g. (in JSON)  "vendor_extension" : { "OUI" : "11:22:33", "Start-type" : 128, "Type-count" : 5 }.  Or, do we split TLV types into a tuple of {Type,Sub-type} and use Type 0 for core DLEP and allow vendor extensions to grab a whole Type for themselves?  (I know Stan hates Type/Sub-types as they can be seen as over-engineering.)

3) How does this work with the Optional Data Items supported TLV?  Are these two different approaches to solve the same problem? Or is the ODIS TLV used to specify which parts of the Vendor Extension is supported, or is this madness?

4) How does a DLEP peer advertise support for multiple extensions?  These might not be 'vendor' extensions, but perhaps a technology specific extension such as 'Satcom' or 'LTE'.

I like your proposal, which I summarise as: "Use a TLV at session initialization to negotiate the use of a profile of extra metrics".  I just have some questions over how to do it.

Regards,

Rick
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure.

If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system.

Emails to Airbus DS Limited may be processed, recorded and monitored anywhere in the European Community.

Airbus DS Limited

Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8FZ.
Registered in England and Wales under company number 04191036

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Dec 2014 11:51:07 +0100

> I have been trying to catch up on this discussion having been out of the office for the last two days.  Can I summarise what I think you are proposing for Vendor Extensions, and ask for some feedba…

I think this email is a proof that you can ask... ;)

> 1) The Vendor Extension TLV can follow the same format as the existing draft-07 Vendor Extension TLV, i.e. Use an IEEE OUI as you mentioned, but without the sub-type and payload.

I would go for a full MAC address instead of just the OUI... because
it allows to get a well-defined and unique identifier even for
organizations and persons who don't own a MAC block (e.g.
universities). You just put the MAC address of a device you own into
the Vendor-ID.

> 2) There are very few experimental TLV values reserved.  I wonder whether a separate bank of TLV type codes for vendor extensions should be reserved and the Vendor Extension data item declare how m…

Maybe we can add a few more IDs for experimental usage? If we allocate
the TLV and message-IDs 224-255 for experimental usage, a vendor has
32 messages and 32 TLVs for his extension. Would you say that is
enough?

> 3) How does this work with the Optional Data Items supported TLV?  Are these two different approaches to solve the same problem? Or is the ODIS TLV used to specify which parts of the Vendor Extensi…

I think we can just use the normal rules we already defined for
optional data items. Of course an implementation which plans to accept
and process the experimental ID range should also check if Vendor-ID
TLV content.

> 4) How does a DLEP peer advertise support for multiple extensions?  These might not be 'vendor' extensions, but perhaps a technology specific extension such as 'Satcom' or 'LTE'.

I would say that each DLEP implementation "sends" ONE vendor
extension... but its parser might understand multiple of them.

This way we don't need any negotiation, similar to the TLVs/messages
the session participants tell the other side what they transmit and
then decide if they keep the session open or not.

If a Vendor extension shows to be useful beyond a special radio and
might even be used by other vendors, it might be time to come to the
IETF and get normal (non-experimental) IANA IDs by writing a DLEP
extension draft.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Fri, 19 Dec 2014 11:00:06 +0000

Comments inline...

> -----Original Message-----
> From: Henning Rogge [mailto:[email-masked]]
> Sent: 19 December 2014 10:51
> To: Taylor, Rick
> Cc: manet IETF
> Subject: Re: [manet] DLEP Vendor Extensions negotiation
>
> On Fri, Dec 19, 2014 at 11:26 AM, Taylor, Rick <[email-masked]>
> wrote:
> > Henning, All,
> >
> > I have been trying to catch up on this discussion having been out of the
> office for the last two days.  Can I summarise what I think you are proposing
> for Vendor Extensions, and ask for some feedback?
>
> > You propose that DLEP peers MAY implement metric sets outside of the
> core DLEP specification, and advertise the fact by placing a Vendor_Extension
> Data Item in the session initialization signals (Peer_Init/Peer_Init_Ack).
> Ignoring the details of encoding, the Vendor Extension  Data Item uniquely
> identifies an 'extension', which is a set of metrics (defined elsewhere) using
> some TLV type codes from the experimental range.  Either Peer may reject
> the presence of a  Vendor Extension Data Item through the mechanisms
> already defined in DLEP-07 for Optional Signal/Data Items supported.
> >
> > In principle I like this proposal, it ties in well with some of the ideas I have
> been pushing around, and I have the following comments:
> >
> > 1) The Vendor Extension TLV can follow the same format as the existing
> draft-07 Vendor Extension TLV, i.e. Use an IEEE OUI as you mentioned, but
> without the sub-type and payload.
>
> I would go for a full MAC address instead of just the OUI... because it allows
> to get a well-defined and unique identifier even for organizations and
> persons who don't own a MAC block (e.g.
> universities). You just put the MAC address of a device you own into the
> Vendor-ID.

+1, seems reasonable, vendors can always pad with 0s.

>
> > 2) There are very few experimental TLV values reserved.  I wonder
> > whether a separate bank of TLV type codes for vendor extensions should
> > be reserved and the Vendor Extension data item declare how many from
> > that bank it uses, e.g. (in JSON)  "vendor_extension" : { "OUI" :
> > "11:22:33", "Start-type" : 128, "Type-count" : 5 }.  Or, do we split
> > TLV types into a tuple of {Type,Sub-type} and use Type 0 for core DLEP
> > and allow vendor extensions to grab a whole Type for themselves?  (I
> > know Stan hates Type/Sub-types as they can be seen as
> > over-engineering.)
>
> Maybe we can add a few more IDs for experimental usage? If we allocate the
> TLV and message-IDs 224-255 for experimental usage, a vendor has
> 32 messages and 32 TLVs for his extension. Would you say that is enough?

I have been led to believe that IESG don't like big blocks of experimental TLVs as it is open to abuse.  I was thinking that a more formal block with rules for its use might have a better chance of passing their review.  Comments from those with more experience please?

>
> > 3) How does this work with the Optional Data Items supported TLV?  Are
> these two different approaches to solve the same problem? Or is the ODIS
> TLV used to specify which parts of the Vendor Extension is supported, or is
> this madness?
>
> I think we can just use the normal rules we already defined for optional data
> items. Of course an implementation which plans to accept and process the
> experimental ID range should also check if Vendor-ID TLV content.

Okay, that seems to keep everything consistent.

>
> > 4) How does a DLEP peer advertise support for multiple extensions?  These
> might not be 'vendor' extensions, but perhaps a technology specific
> extension such as 'Satcom' or 'LTE'.
>
> I would say that each DLEP implementation "sends" ONE vendor extension...
> but its parser might understand multiple of them.
>
> This way we don't need any negotiation, similar to the TLVs/messages the
> session participants tell the other side what they transmit and then decide if
> they keep the session open or not.
>
> If a Vendor extension shows to be useful beyond a special radio and might
> even be used by other vendors, it might be time to come to the IETF and get
> normal (non-experimental) IANA IDs by writing a DLEP extension draft.

Isn't that just pushing the negotiation back to the Optional Data Items Supported TLV (which might get really big).  I imagine that one day there might be several IETF standards for DLEP metrics for different classes of modem, and there still needs to be negotiation.  Are people happy to just rely on ODIS TLVs or do we want to explore using the Vendor Extension mechanism as a kind of general purpose Extension mechanism?

Cheers,

Rick

Airbus DS Limited

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Dec 2014 12:06:35 +0100

> I have been led to believe that IESG don't like big blocks of experimental TLVs as it is open to abuse.  I was thinking that a more formal block with rules for its use might have a better chance of…

Whats about this?

220 - 251 Vendor-Specific TLVs
252 - 255 Experimental TLVs

If we need the range for "vendor-specific" stuff, just call it this way.

We could add a line that if you use the Vendor-Specific block, you
MUST add the Vendor-ID. And maybe say a bit more about the idea behind
the block and the reason why you should go for "IETF RFC" with your
extensions if they seem to be useful.

> Isn't that just pushing the negotiation back to the Optional Data Items Supported TLV (which might get really big).  I imagine that one day there might be several IETF standards for DLEP metrics fo…

Not sure you can really call it "negotiation" if both sides announce
what they will transmit and then the other side can parse the data (or
a subset of it) or just drop the connection.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 19 Dec 2014 11:21:33 +0000

An unimportant nit, I'd start the vendor specific block at 224, it's a rounder number (D0) if doing it that way. (Our earlier drafts use 224 to 255 for that reason, later on we got limited to 252 to 255.)

But that's not a big range (32 or 28) for a vendor specific block if the idea is successful. You could instead define a single vendor specific TLV, and then require that the first N octets (you suggested 8) of the value indicate which vendor. (If it weren't, as Rick indicates, trampling on an already made decision, I'd suggest or than one, maybe two, with the distinction being vendor specific, you can just ignore TLV, and vendor specific, you need to ignore message, for not recognised cases.)

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 19 December 2014 11:07
To: Taylor, Rick
Cc: manet IETF
Subject: Re: [manet] DLEP Vendor Extensions negotiation

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

>> Maybe we can add a few more IDs for experimental usage? If we 
>> allocate the TLV and message-IDs 224-255 for experimental usage, a 
>> vendor has

Whats about this?

We could add a line that if you use the Vendor-Specific block, you MUST add the Vendor-ID. And maybe say a bit more about the idea behind the block and the reason why you should go for "IETF RFC" with your extensions if they seem to be useful.

> Isn't that just pushing the negotiation back to the Optional Data Items Supported TLV (which might get really big).  I imagine that one day there might be several IETF standards for DLEP metrics fo…

Not sure you can really call it "negotiation" if both sides announce what they will transmit and then the other side can parse the data (or a subset of it) or just drop the connection.

Henning Rogge

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

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 19 Dec 2014 12:05:01 -0500

OK, it might look like I'm jumping into the middle of the thread here, but
I promise, I've read the whole thing... ;-)

On Fri, Dec 19, 2014 at 6:06 AM, Henning Rogge <[email-masked]> wrote:
> the
> > I have been led to believe that IESG don't like big blocks of
> experimental TLVs as it is open to abuse.  I was thinking that a more
> formal block with rules for its use might have a better chance of passing
> their review.  Comments from those with more experience please?
>
My experience, FWIW, is that the IESG doesn't like large blocks of
experimental TLVs. IIRC, that's one of the reasons that 5444 got limited
down to just a few.

I'll also say that in this case (and I note the case has gone quickly to
*METRICS*, which is a hot button for me), I'm opposed to handing a
vendor more than just a few Experimental TLVs.  If they can't express some
device-specific metric in just one or two TLVs, then we need to
*drastically* re-think the core spec we currently have. IIRC, some of the
proposals floated contain almost as many Experimental TLVs as what is
documented in the entirety of DLEP. So, I'm ok with with "3-to-5" range,
but not any more than that.

Now, as to the option that Chris brought up - that of flagging the TLVs
(saying in effect, 'If the receiver does not understand this TLV, here are
the processing options'.). I'm not completely opposed, but as I understand
the implementation proposed, I think we've already covered the problem. As
I understand it, this would start out with a "Vendor ID" or "Vendor
Extension" tlv in the Peer exchange. This TLV really boils down to "I'm
going to use experimental TLV space, and I hope you're capable of
understanding what I'm getting ready to tell you." The receiving peer has
(or should have) the capability right then and there to respond with "I
don't understand (support) your extension, therefore, I will ignore
them."). Or, to support the maximum flexibility, verbiage can be added that
says implementations MAY (not SHOULD or MUST) choose to close the socket,
dropping session with the peer.

Regards,
Stan

> > Isn't that just pushing the negotiation back to the Optional Data Items
> Supported TLV (which might get really big).  I imagine that one day there
> might be several IETF standards for DLEP metrics for different classes of
> modem, and there still needs to be negotiation.  Are people happy to just
> rely on ODIS TLVs or do we want to explore using the Vendor Extension
> mechanism as a kind of general purpose Extension mechanism?
>

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Dec 2014 18:10:03 +0100

On Fri, Dec 19, 2014 at 6:05 PM, Stan Ratliff <[email-masked]> wrote:
> the implementation proposed, I think we've already covered the problem. As I
> understand it, this would start out with a "Vendor ID" or "Vendor Extension"
> tlv in the Peer exchange. This TLV really boils down to "I'm going to use
> experimental TLV space, and I hope you're capable of understanding what I'm
> getting ready to tell you." The receiving peer has (or should have) the
> capability right then and there to respond with "I don't understand
> (support) your extension, therefore, I will ignore them."). Or, to support
> the maximum flexibility, verbiage can be added that says implementations MAY
> (not SHOULD or MUST) choose to close the socket, dropping session with the
> peer.

We could solve this by splitting the "Optional TLVs" TLV in half...

by adding an "Additional Mandatory TLVs" TLV. This way we could say
"if you don't understand one of these, please drop the session".

No need to do this in the TLVs itself, we can do it in session setup.

Henning

---

From: Stan Ratliff <[email-masked]>
Date: Fri, 19 Dec 2014 12:15:03 -0500

Henning,

Yeah, that was my point - it's already done via the "Optional TLVs
Supported" mechanism.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Fri, 19 Dec 2014 18:27:56 +0100

> Yeah, that was my point - it's already done via the "Optional TLVs

Damned, you are right...

I somehow had the "direction" of the announcement the other way around
in my head.

Each side announces which TLVs it understands... if something
mandatory is missing the other side can drop the session.

So it is a non-issue.

Henning Rogge