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

["Dearlove, Christopher (UK)" <[e-mail]>]

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?

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.)

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.



-----Original Message-----
From: manet [mailto:[e-mail]] On Behalf Of Lou Berger
Sent: 09 December 2015 19:02
To: [e-mail]; 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
[e-mail]
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.
********************************************************************