Re: [manet] DLEP-17: duplicate functions - Options & extensions negotiations

Stan Ratliff <ratliffstan@gmail.com> Thu, 10 December 2015 13:57 UTC

Return-Path: <ratliffstan@gmail.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0493A1B2EA7; Thu, 10 Dec 2015 05:57:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 QQLGCEzhdnXE; Thu, 10 Dec 2015 05:57:25 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8481B308B; Thu, 10 Dec 2015 05:57:09 -0800 (PST)
Received: by lbbcs9 with SMTP id cs9so51174293lbb.1; Thu, 10 Dec 2015 05:57:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XEL3PiPQEvT6J+wqpM+jzvXngXyqPnpB8W2Prou8tjw=; b=LKfOBM/Kfy7y4IlJG6Fkkja4SGdifm0uFgerXU9wa12cOSSw7qxiqlWffKuNPOKsVj WRHFYlqOfR6VrHXa012k+jshpuJfaLLy/ycAf9EK1AoDPLqmwLhYzNuKtDnNpvoClyvQ MFhjn2+wVoh9ffhpAFSUqYO+KHtIj5tExqQPn+nKx8Mn8oI4Xg3JCzJ99cSiDNd4uK6y p5+UnAhFF2M1Bo18eG4SV1ZgMPNfKXH/roMttrfZ7ozLEb/MxEt6RM7figzBTlJRNk+n 86R8QeoWVw116j+YjBMgDcJI39+66ygtDmJTeoI74qO2ypCIL8afE8Tb5Tho5avzJmT6 yhyg==
MIME-Version: 1.0
X-Received: by 10.112.200.40 with SMTP id jp8mr5363410lbc.104.1449755827214; Thu, 10 Dec 2015 05:57:07 -0800 (PST)
Received: by 10.25.209.71 with HTTP; Thu, 10 Dec 2015 05:57:07 -0800 (PST)
In-Reply-To: <B31EEDDDB8ED7E4A93FDF12A4EECD30D848E753E@GLKXM0002V.GREENLNK.net>
References: <56687ABA.803@labn.net> <B31EEDDDB8ED7E4A93FDF12A4EECD30D848E753E@GLKXM0002V.GREENLNK.net>
Date: Thu, 10 Dec 2015 08:57:07 -0500
Message-ID: <CALtoyo=kyOkv5nv8rsud-Q25=aSf-XW1EC7KT295-n4gXBi=5A@mail.gmail.com>
From: Stan Ratliff <ratliffstan@gmail.com>
To: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
Content-Type: multipart/alternative; boundary="001a11c36b2a17a78205268b95ea"
Archived-At: <http://mailarchive.ietf.org/arch/msg/manet/y9-uTIBhvYXy-kr61R3PdicsLoA>
Cc: MANET IETF <manet@ietf.org>, "draft-ietf-manet-dlep@ietf.org" <draft-ietf-manet-dlep@ietf.org>
Subject: Re: [manet] DLEP-17: duplicate functions - Options & extensions negotiations
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2015 13:57:32 -0000

Chris,

First up, I'm in the process of looking at your review comments - I've just
been buried by the other threads, along with the day job.


On Thu, Dec 10, 2015 at 5:20 AM, Dearlove, Christopher (UK) <
chris.dearlove@baesystems.com> wrote:

> I commented (and so far I've had one comment on one detail I noted,
> nothing else) on that the draft makes reference to an extensions register,
> and then really doesn't specify it.
>
> I think part of this issue is that what an extension is needs more
> specification.
>
> Is an extension defined completely by a list of new messages and/or data
> items that it consists of?
>

The short answer is Yes. An extension could be a group of data items,
and/or new messages to the protocol.


>
> If no, what else? (Yes of course a new message requires new processing,
> but is that fully defined by the message type?)
>
> If yes, why not drop the extensions register, and just list the messages
> and data items directly? OK, then there's an issue of what needs listing?
> And then you end up at Lou's comment, just list everything you are using.
> (Which needs to interact correctly with indicating default values.)
>

The idea with the currently documented mechanism is that new functionality,
whether that's a collection of Data Items (potentially strewn about
multiple existing messages), and/or new messages, is grouped according to
functionality and assigned an extension number. As I envision it, an
extension number would map one-to-one with a DLEP follow-on draft. The
extension, regardless of its component make-up, is either supported (it
appears in Extensions Supported) or it's not.

If you simple list *everything* (both Data Items and messages), then it's
up to the receiver to make sure that the "everything" listed actually works
- for example, if I create an extension that has 4 new messages, but your
implementation lists only 3 of them, now what? It seems easier to me to
write up a spec and introduce it into the MANET WG, talk about the 4 new
messages (because the 4 messages make up a logical function that I want to
accomplish), then add the whole logical function as an Extension.
Implementations then either support it, or they don't.


>
> This does depend on the yes/no question above - and I think that
> regardless, the draft needs to be clearer on what an extension is to allow
> it to be answered.
>
> There might be an issue with listing lots of items. Except you need to do
> this anyway for default values if I understand correctly.
>

The default notion only applies to metrics. Right now, there are 9:
MDRR/MDRT
CDRR/CDRT
Latency
RESR/REST
RLQR/RLQT

That's why I'm proposing to add the "Session Metric Initialization" message
- to clear up some of the confusion, let's not use the session init to both
(a) establish the protocol level with Extensions Supported, and (b)
establish default values for metrics that are to be flowed over the
session. Let's let the Session Init establish the effective protocol level
and "bells & whistles" in play (the Extensions), and then explicitly set
the default metric values.

Regards,
Stan



>
>
>
> -----Original Message-----
> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: 09 December 2015 19:02
> To: draft-ietf-manet-dlep@ietf.org; MANET IETF
> Subject: [manet] DLEP-17: duplicate functions - Options & extensions
> negotiations
>
> ----------------------! 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.
> --------------------------------------------------------
>
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our organization.
>
>
> Authors/WG,
>
> The current version of DLEP contains two negotiations as part of a Session
> Initialization transaction:
> 1) <Extensions Supported> is included in both the <Session
> Initialization> and <Session Initialization Response> messages
> 2) the optional data items, <Resources> and <Relative Link Quality>
>
> Both have parallel allocation policies:
>
>    +-------------+-----------------------------------------------------+
>    | Type Code   | Description                                         |
>    +-------------+-----------------------------------------------------+
>    | 0           | Reserved                                            |
>    | 1           | Status (Section 10.1)                               |
>      ...
>    | 20          | Relative Link Quality (Transmit) (RLQT) (Section    |
>    | 21-65407    | Reserved for future extensions                      |
>    | 65408-65534 | Private Use. Available for experiments              |
>    | 65535       | Reserved                                            |
>    +-------------+-----------------------------------------------------+
>
>                        Table 2: DLEP Data Item types
>
>    +-------------+-----------------------------------------------------+
>    | Code        | Description                                         |
>    +-------------+-----------------------------------------------------+
>    | 0           | Reserved                                            |
>    | 1           | Credit Windowing                                    |
>    | 2-65519     | Reserved for future extensions                      |
>    | 65520-65534 | Private Use. Available for experiments              |
>    | 65535       | Reserved                                            |
>    +-------------+-----------------------------------------------------+
>
>                        Table 4: DLEP Extension types
>
> It seems to me that given the current definition, one of these two should
> suffice.  I don't have a strong opinion on which, but do strongly believe
> that a single approach should be selected to facilitate interoperability.
>
> To be clear, the following spells out the options:
>
> Option A: Extensions (aka capabilities) based
>   Any optional or new data item or message would need to be indicated
>   in <Extensions Supported> to be used.  To cover the current optional
>   data items the following would need to be defined:
>     | 1 | Resources |
>     | 2 | Relative Link Quality |
>     | 3 | Credit Windowing |
>   <Session Initialization Response> could still contain the optional
>   data items, if the corresponding type is present in <Extensions
>   Supported>
>
>   Note that other messages will still use optional data items.
>
> Option B: Data item based.
>   An optional or new data item must be both Session Initialization
>   messages to be used. To allow/enable <Resources> and <Relative Link
>   Quality>, they would need to be included in both the <Session
>   Initialization> and <Session Initialization Response> messages.
>
>   To enable the Credit Windowing extension, the three credit-related
>   state items, <Grant>, <Window Status>, and <Request> would need to be
>   included in both session init messages for the full extension to be
>   used.
>
> Option C: keep both
>   Keep current text
>
> While I like Option A and have seen similar approaches in other protocols,
> e.g., BGP Capabilities, I actually have a slight preference for B.  The
> reason for this is DLEP uses optional data items in other places and
> implementations will already need to handle this, so it seems like option B
> will probably require smaller incremental code.
>
> Either way, I think Option C is much less desirable then either of the
> other options.
>
> Thoughts? Opinions?
>
> Lou
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> 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.
> ********************************************************************
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>