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

Teco Boot <teco@inf-net.nl> Mon, 10 March 2014 19:56 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: manet-dlep-rg@ietfa.amsl.com
Delivered-To: manet-dlep-rg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021341A0527 for <manet-dlep-rg@ietfa.amsl.com>; Mon, 10 Mar 2014 12:56:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G-d4uBN2Cc9 for <manet-dlep-rg@ietfa.amsl.com>; Mon, 10 Mar 2014 12:56:46 -0700 (PDT)
Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 301C91A0488 for <manet-dlep-rg@ietf.org>; Mon, 10 Mar 2014 12:56:45 -0700 (PDT)
Received: by mail-ee0-f47.google.com with SMTP id b15so3278159eek.6 for <manet-dlep-rg@ietf.org>; Mon, 10 Mar 2014 12:56:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=iGUikQ6wFnPWUyzLG3Xn7toHDkHnYEZ27ZpM2e5H+P0=; b=I807Dh6pstPvjdvv+tfu+uY5/loCiGujQA8Nt7Jp4LR3xq6UkLSkO4Labs/FloaJdD cDs3qM8wcNCqs0nV7Y2G9b1fQCCNG+rnxyjUxDFFcLR2UWt6vME45uc1rZUlAiOMICMn Bhyrpt45jiH0rZgoCQhLVaJs4JzhzloAXo34SYHS7kqdhTNU6fLtWB9c4x2W2G4P8Ifr IJQQQAdGcnzMNb3Z0ZISdkMUIeDg7N4S1ZW6LBkfUpQzTeaXNb9I8c7JeeInCLIobKcm pRiq5VU/UQZEwndh0I0g/6/1LgdFaaMkg9unH8foOaa+GCpL1mzdlLNXxGe1DJwVoBym xO9g==
X-Gm-Message-State: ALoCoQl29U9EQvFOyjd0eMsrkMHi/Dr2jkCrWNB8ROKpNeepXnj03o+9jg3wblXw+uxVyMjLZFOk
X-Received: by 10.14.207.68 with SMTP id m44mr6145321eeo.79.1394481398713; Mon, 10 Mar 2014 12:56:38 -0700 (PDT)
Received: from [10.175.173.26] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPSA id q44sm48678198eez.1.2014.03.10.12.56.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Mar 2014 12:56:37 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <CAGnRvuroF05-k0Kw9qyP5rAyqFu2y+RROa6MOMZWZG2ErNSwmw@mail.gmail.com>
Date: Mon, 10 Mar 2014 20:56:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E6F594A-7F9C-4D7B-81C4-53C22610039C@inf-net.nl>
References: <38A5475DE83986499AEACD2CFAFC3F98FA6C8222@tss-server1.home.tropicalstormsoftware.com> <d5a2b437-1a21-4569-9b97-5048512604bc@SUCNPTEXC01.COM.AD.UK.DS.CORP> <B177F831FB91F242972D0C35F6A0733106FD04FB@SUCNPTEXM01.com.ad.uk.ds.corp> <3007663E-E9AA-4D24-93B4-F8810C5471D4@cisco.com> <CAGnRvuroF05-k0Kw9qyP5rAyqFu2y+RROa6MOMZWZG2ErNSwmw@mail.gmail.com>
To: Henning Rogge <hrogge@gmail.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/manet-dlep-rg/i9UWwUiDxoOy_fKpVcaJuA6muoA
Cc: "manet-dlep-rg@ietf.org Group, \(manet-dlep-rg@ietf.org\)" <manet-dlep-rg@ietf.org>, "Taylor, Rick" <Rick.Taylor@cassidian.com>, Rick Taylor <rick@tropicalstormsoftware.com>, Stan Ratliff <sratliff@cisco.com>
Subject: Re: [manet-dlep-rg] Slight issue with Data items
X-BeenThere: manet-dlep-rg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DLEP Radio Group <manet-dlep-rg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet-dlep-rg/>
List-Post: <mailto:manet-dlep-rg@ietf.org>
List-Help: <mailto:manet-dlep-rg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet-dlep-rg>, <mailto:manet-dlep-rg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2014 19:56:50 -0000

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 <hrogge@gmail.com>; 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)
> <sratliff@cisco.com>; wrote:
>> 
>> On Mar 10, 2014, at 1:25 PM, "Taylor, Rick" <Rick.Taylor@cassidian.com>; 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
>> manet-dlep-rg@ietf.org
>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> 
> _______________________________________________
> manet-dlep-rg mailing list
> manet-dlep-rg@ietf.org
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg