Subject: [manet-dlep-rg] Slight issue with Data items

From: Rick Taylor <[email-masked]>
Date: Mon, 10 Mar 2014 16:40:34 +0000

Hi All,

I've been ruminating over Data Items and their default handling as we discussed in London, i.e. an implementation MUST silently drop any unrecognised Data Items it receives.

But, there is some inconsistency over what a Data Item is (in my mind), and so I ask:  Is a Data Item *any* signal payload, or is it one of the payload items in a Destination Up/Down/Update message?

The reason I ask is that there is a class of TLVs in DLEP that appear in session initiation (and possibly discovery) that are semantically different from 'regular' TLVs in session signals: Version information, TCP server addresses, etc...  Now, are these TLVs treated as Data Items as far as the handling rules apply?  What happens if you receive a Version Data Item in a Destination_Update:  The implementation should recognise it, but not expect it where it finds it.

So, have I revealed a new class of Data Item that needs it's own rules and status code, or do the existing rules still work?

In summary, do we need to define "Status Code <N>: Data Item not allowed in last signal"

Hmm... something for you all to ponder at the start of the week...

Rick

P.S> Is everyone happy for me to post the summary report to the WG mailing list?  If I hear no objections by close of play Tuesday, I'll just forward it.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 10 Mar 2014 16:57:27 +0000

> So, have I revealed a new class of Data Item that needs it's own rules and status code, or do the existing rules still work?

I don't know if you've revealed a new class of data item, but you've opened an area for discussion that we haven't talked about yet - Data Items that are understood, but not meaningful for the DLEP signal. Version information in a destination update is a perfect example of that.

I'll offer up a slight modification of the "London Rule" :  Experimental Data Items (and Vendor-specific TLVs) that are not supported by an implementation should be parsed (e.g. "stepped over') and silently dropped. Data Item TLVs that are not *understood* (e.g. TLV number not registered, or "reserved"), OR are out-of-context (like a Version TLV in a destination update message) should cause PEER_TERMINATION and closure of TCP session.

Regards,
Stan

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

---

From: "Taylor, Rick" <[email-masked]>
Date: Mon, 10 Mar 2014 17:25:16 +0000

> I'll offer up a slight modification of the "London Rule" :  Experimental Data
> Items (and Vendor-specific TLVs) that are not supported by an
> implementation should be parsed (e.g. "stepped over') and silently dropped.
> Data Item TLVs that are not *understood* (e.g. TLV number not registered,
> or "reserved"), OR are out-of-context (like a Version TLV in a destination
> update message) should cause PEER_TERMINATION and closure of TCP
> session.

That will rely on a clear list of every suitable data item TLV used with each signal, which might turn into an O(N^2) documentation nightmare.

I was wondering about adding an 8bit context field to the TLV header: 8bit Type, 8bit Context, 16bit Length (seems to align nicely).

Context: 1 = Discovery Data Item, 2 = Session Initiation/Termination Data Item, 3 = Peer Data Item, 4 = Link Data Item, plus the classic experimental and reserved spaces.

This might be easier to specify, and reduces the London Rule to "Any data item received with a context field that does not match the context of the enclosing signal MUST result in PEER_TERMINATION", then all that is needed is to define the context of each signal, back to O(N) for those of you familiar with big-O notation.

I know this seems like adding error checking to the protocol, but with Vendor Extensions and experimental TLVs a bit of error checking is no bad thing, just think of it as an FEC code...

Alternatively you could consider Type and Context as one little endian 16bit value... or swap them around to make CTLV...

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. Cassidian Limited, part of the Airbus Defence and Space division. Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8FZ. Registered in England and Wales under company number 04191036

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 10 Mar 2014 17:52:11 +0000

> This might be easier to specify, and reduces the London Rule to "Any data item received with a context field that does not match the context of the enclosing signal MUST result in PEER_TERMINATION"…

Hmmm… could be. Let me noodle on this a bit.

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Mon, 10 Mar 2014 20:23:14 +0100

Don't we already have a list of "mandatory/optional" data items for each signal?

Maybe we should reword "unknown" into "neither defined as mandatory or
optional for a signal" ?

Henning Rogge

On Mon, Mar 10, 2014 at 6:52 PM, Stan Ratliff (sratliff)
<[email-masked]> wrote:
> Hmmm... could be. Let me noodle on this a bit.
>
> Regards,
> Stan
>
>
>>

---

From: Teco Boot <[email-masked]>
Date: Mon, 10 Mar 2014 20:56:36 +0100

I would keep the protocol as simple as possible.
Version points to the RFC and defines which Data Items are mandatory and which are optional. All non-mandatory Data Items may silently be dropped. A DLEP peer may terminate a session at any moment at own willing.

Clarification question. My understanding is that it is NOT required to provide the mandatory Data Items in each and every message for a certain neighbor. It is required that the mandatory Data Item value is made available. Only the updates are transferred. An implementation may re-transfer unchanged Data Items, but a receiver MUST keep previous received Data Item values until explicitly changed or set to unknown.

Maybe add some rate control on session initiation, wire speed flooding DLEP session initiation messages isn’t helpful.

Teco