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

[Teco Boot <[e-mail]>]

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

Op 10 mrt. 2014, om 20:23 heeft Henning Rogge <[e-mail]> het volgende geschreven:

> 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)
> <[e-mail]> wrote:
>> 
>> On Mar 10, 2014, at 1:25 PM, "Taylor, Rick" <[e-mail]> wrote:
>> 
>>> 
>>>> 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.
>> 
>> Hmmm... could be. Let me noodle on this a bit.
>> 
>> Regards,
>> Stan
>> 
>> 
>>> 
>>> 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
>> 
>> _______________________________________________
>> manet-dlep-rg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> 
> _______________________________________________
> manet-dlep-rg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg