Subject: [manet] DLEP-14 comments

From: Rick Taylor <[email-masked]>
Date: Wed, 24 Jun 2015 08:13:42 +0000

Can I say a big thank you to everyone who has given us feedback on DLEP-14.

We are currently updating the draft, to integrate the comments we have. 
  With that in mind, can I ask for some patience and a moratorium on the 
topics of Versioning and Ids please?

Thanks

Rick

---

From: Lou Berger <[email-masked]>
Date: Wed, 24 Jun 2015 10:51:43 -0400

Rick,

> topics of Versioning and Ids please?
I think I see the rough consensus that can be document on IDs, but I'm
not sure I've seen it on Versioning.  Could you summarize the Versioning
consensus that you'll be documenting?

Thanks,
Lou

> Thanks
>
> Rick
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Rick Taylor <[email-masked]>
Date: Thu, 25 Jun 2015 10:53:03 +0000

> consensus that you'll be documenting?

After much consideration, Stan and I have decided to go for the KISS 
solution (not white face-paint and platforms) and drop version numbers 
from the TCP session, and alter the Discovery signal.  The reasons:

1) The current version data item has been criticised as non-trivial to 
parse.

2) We have a more flexible solution to managing changes and updates to 
the protocol than a monotonically increasing number, via the Extensions 
mechanism.

3) If a radical change to the protocol was required that broke the 
Extensions mechanism then it stops being DLEP, and becomes something 
else, and a new IANA multicast address/port registration is the cleanest 
solution.

4) The discovery mechanism must allow peers to determine if the probes 
are DLEP discovery queries rather than anything else.

5) I do not see consensus on versioning from the recent discussions, so 
we are returning to the rough consensus of the last 4 years of DLEP 
design, where a granular extensions mechanism has been preferred over 
monolithic version changes.

I know this will be contentious, but we need to make progress.  Can I 
request that any comments on versioning use the following template:  "I 
don't like this approach because it prevents my future enhancement from 
doing: X"?  Otherwise we can continue to discuss each others personal 
preferences.

To mis-quote The Matrix: "There is no version number..." - Just Extensions.

Rick.

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Jun 2015 07:27:26 -0400

Rick,
    Thanks for the summary.  This approach resolves the issue I raised
for TCP sessions. 

Is the same approach followed for UDP signals?

Lou

---

From: Rick Taylor <[email-masked]>
Date: Thu, 25 Jun 2015 12:39:24 +0000

>      Thanks for the summary.  This approach resolves the issue I raised

Thank you for your support!

> Is the same approach followed for UDP signals?

Is a very good question...

We don't really need a signal header, as one type of packet is multicast 
and the other unicast, so no type requirement, and given we are using 
UDP, we don't need another length field, and less octets is better for 
datagrams.

So using my new skills in RFC-5511:

<Discovery_Signal> ::=  "DLEP"
                          [<Peer_Type>]

<Offer_Signal> ::= "DLEP"
                    [<Peer_Type>]
                    (<IPv4_Conn_Pt> | <IPv6_Conn_Pt>) ...

I have put in the "DLEP" literal as a discriminator for receivers, and 
so that there has to be at least something in the Discovery packet!

The data item order doesn't matter, just the "DLEP" literal needs to be 
first.

To differentiate between the UDP format and the TCP format, I am going 
to rename the TCP 'signals' to 'messages' to underline their difference 
(and transactional nature).

Rick

---

From: Lou Berger <[email-masked]>
Date: Thu, 25 Jun 2015 10:23:39 -0400

Hi Rick,

> Thank you for your support!

Sure - although to be clear I wasn't endorsing this as the "right"
answer -- I don' have enough of a vested interest in DLEP to make such
an endorsement -- but rather as "an answer" that resolves the issue.

> so that there has to be at least something in the Discovery packet!
Based on the current rev I think you have:

<Discovery_Signal> ::=  <DLEP Signal Header>
                          [<Peer_Type>]

<Offer_Signal> ::= <DLEP Signal Header>
                    [<Peer_Type>]
                    [<IPv4 Connection Point> ... ] 
                    [<IPv6 Connection Point> ... ] 

Yes, this allows both v4 and v6 in the same message, but that's how I
read what -14 says.
> (and transactional nature).
okay.
Thanks,
Lou