Subject: [manet] I-D Action: draft-ietf-manet-dlep-15.txt

From: [email-masked]
Date: Mon, 06 Jul 2015 08:17:26 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

        Title           : Dynamic Link Exchange Protocol (DLEP)
        Authors         : Stan Ratliff
                          Bo Berry
                          Cisco Systems
                          Darryl Satterwhite
                          Rick Taylor
	Filename        : draft-ietf-manet-dlep-15.txt
	Pages           : 66
	Date            : 2015-07-06

Abstract:
   When routing devices rely on modems to effect communications over
   wireless links, they need timely and accurate knowledge of the
   characteristics of the link (speed, state, etc.) in order to make
   routing decisions.  In mobile or other environments where these
   characteristics change frequently, manual configurations or the
   inference of state through routing or transport protocols does not
   allow the router to make the best decisions.  A bidirectional, event-
   driven communication channel between the router and the modem is
   necessary.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-manet-dlep-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Henning Rogge <[email-masked]>
Date: Tue, 7 Jul 2015 08:40:39 +0200

>         Filename        : draft-ietf-manet-dlep-15.txt

Hi,

I think the draft 15 solves quite a few issues, but there is one thing
I promised Rick to raise when he pushed draft 15.

I think it would be better to replace the "dlep" prefix for the UDP
packets with a single Zero Octet (0x00) for both UDP packets and the
start of all TCP sessions (once per TCP connection, not once for each
Signal/Message).

First, this would make communication more consistent because TCP and
UDP would be handled the same.

Second, we could call the Zero Octet the "DLEP version"... if we ever
need another one, we can just increment it to 0x01 and have a
guarantee that we don't clash with old versions.

Third, the Zero byte is enough to make sure that DLEP-14 instances
don't process new (DLEP-16?) DLEP data... and it is enough that new
(DLEP-16) instances don't process DLEP-14 data.

Henning Rogge

---

From: Rick Taylor <[email-masked]>
Date: Tue, 7 Jul 2015 09:36:50 +0000

Comments inline...

> start of all TCP sessions (once per TCP connection, not once for each

As I have mentioned before Henning, my issue with a 0-byte as an 
identifier rather than 'DLEP' is that with the Peer Discovery Signal 
there is only 1 optional data item, so if the router does not include 
it, using your proposal, a valid Peer discovery signal is just:

00 00 01 00 00

In my opinion, this just isn't a 'unique' enough fingerprint to be used 
by a parser to determine that this is a signal.  I know this is 
subjective, and when I originally had this discussion off-list with you 
the case was worse (00 00 00 00 00).

The same example with the draft-15 proposal is:

'D' 'L' 'E' 'P' 00 01 00 00

> UDP would be handled the same.

I am not worried about making the UDP and TCP layout consistent.  The 
main driver for renaming the TCP signals to messages was to 
differentiate them, as the handling of messages is very different to the 
handling of signals.

As has now been stated more explicitly in draft-15, after TCP 
connection, the first two octets received MUST be:

00 03

Adding a prefix of 0 seems to add nothing extra to me.

> guarantee that we don't clash with old versions.

We have attempted to move DLEP away from a versioned protocol, into a 
protocol with standardized extensions.  The proposed extension mechanism 
gives far more flexibility than a linear version numbering system.

The only thing that would require a 'version 2' of DLEP would be a 
totally breaking change at the message layout level, and at that point I 
would argue that it is no longer DLEP but something 'newer and better' 
and it should have different address/port allocations.  In the same way 
as OLSR and OLSRv2, I believe.  Am I right in thinking that it is almost 
impossible to write an OLSR-both agent? (I'm not saying that this is a 
problem for OLSRv2 btw).

Others please note: I do not want to reopen the versioning discussion.

> (DLEP-16) instances don't process DLEP-14 data.

I agree; but *any* leading octets that do not match the DLEP < v15 peer 
discovery header can be used for that purpose, 0 has no special benefit.

The same applies for the TCP connection first octets, and they already 
differ sufficiently.

Also, I'm not sure the WG would humour us taking time to make changes to 
support back compatibility with earlier drafts.

Cheers,

Rick