Subject: [manet] IETF 100 minutes

From: Victoria Pritchard <[email-masked]>
Date: Thu, 16 Nov 2017 19:11:32 +0800

Hi everyone,

Meeting notes are on the etherpad link
https://etherpad.tools.ietf.org/p/notes-ietf-100-manet?useMonospaceFont=true

I believe other people were taking notes too so there may be more to come.

Regards,
Vicky.

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 22 Nov 2017 10:38:51 +0000

I'm still watching things here, though unfunded to attend meetings.

Obviously my main interest is in the OLSRv2 suite, and there I might note that we now have all RFCs, no Internet Drafts, with the publication of RFC 8245. I've got a slide somewhere showing the main inter-relationships of the 25 RFCs that make up this work (everything the group has done except 2501, the original four experimental protocols, and DLEP), 15 of which I'm an author of, beaten by Thomas Clausen at 19. 

To my mind, the most important thing is use, and getting reports on use. Obviously that applies to the experimental RFCs such as 7722, 7779 and 7859, but even more so the basic specification 7181 (and its updates). There's some reporting in the literature of community networks - though I'm not sure to what extent they are using pure OLSRv2, rather than older modified OLSRv1. But beyond that, I'd like to know more for a variety of reasons. That some of that use might be military may not help, but shouldn't be an impossible barrier. And of course there might be material I've overlooked. It's real use, rather than simulations, that I'd be after.

Reports of use - what works, what doesn't (if anything) I think are key to any further progress. We can create speculative extensions (to some extent multitopology is that, although the ability to extend to that I seem to recall being important in earlier acceptance by at least one person) but we need to know first about base protocol use.

Having said that, some obvious areas that could be taken further are multicast, some more security issues, some use of DTN concepts, hybrid/policy-based protocols, and scalability/hierarchy (several of which there is work on - I've looked at most of those, and I know others have too). But to build any of those on firm foundations, I go back to needing to know how (if) the main protocol is being used.

(I'd also note that there is some undocumented - we keep trying, but other work intervenes - material largely in the authors' heads about why some things are as they are, and some less obvious things you can already do but may not have spotted.)

With regard to the OLSRv2 maintenance side of the group I think that - documented experience to build on - is the priority. Anyone got any?

--  
Christopher Dearlove
[email-masked]

> On 16 Nov 2017, at 11:11, Victoria Pritchard <[email-masked]> wrote:
> 
> Hi everyone,
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Justin Dean <[email-masked]>
Date: Wed, 22 Nov 2017 09:13:31 -0500

It's been our plate to release our OLSRv2 implementation for some time
now.  In addition to the multicast work (mostly independent of the OLSRv2
work) we have played around with the idea of implementing support for
unicast links.  One thing that we've found helps deployed networks is
having extended timeouts for TC link information.  I'd be interested in
helping with a writeup about why things are the way they are and some best
practices or hints on how to set parameters to attempt better performance.

Justin Dean

On Wed, Nov 22, 2017 at 5:38 AM, Christopher Dearlove <
[email-masked]> wrote:

> Obviously my main interest is in the OLSRv2 suite, and there I might note
> that we now have all RFCs, no Internet Drafts, with the publication of RFC
> 8245. I've got a slide somewhere showing the main inter-relationships of
> the 25 RFCs that make up this work (everything the group has done except
> 2501, the original four experimental protocols, and DLEP), 15 of which I'm
> an author of, beaten by Thomas Clausen at 19.
>
> To my mind, the most important thing is use, and getting reports on use.
> Obviously that applies to the experimental RFCs such as 7722, 7779 and
> 7859, but even more so the basic specification 7181 (and its updates).
> There's some reporting in the literature of community networks - though I'm
> not sure to what extent they are using pure OLSRv2, rather than older
> modified OLSRv1. But beyond that, I'd like to know more for a variety of
> reasons. That some of that use might be military may not help, but
> shouldn't be an impossible barrier. And of course there might be material
> I've overlooked. It's real use, rather than simulations, that I'd be after.
>
> Reports of use - what works, what doesn't (if anything) I think are key to
> any further progress. We can create speculative extensions (to some extent
> multitopology is that, although the ability to extend to that I seem to
> recall being important in earlier acceptance by at least one person) but we
> need to know first about base protocol use.
>
> Having said that, some obvious areas that could be taken further are
> multicast, some more security issues, some use of DTN concepts,
> hybrid/policy-based protocols, and scalability/hierarchy (several of which
> there is work on - I've looked at most of those, and I know others have
> too). But to build any of those on firm foundations, I go back to needing
> to know how (if) the main protocol is being used.
>
> (I'd also note that there is some undocumented - we keep trying, but other
> work intervenes - material largely in the authors' heads about why some
> things are as they are, and some less obvious things you can already do but
> may not have spotted.)
>
> With regard to the OLSRv2 maintenance side of the group I think that -
> documented experience to build on - is the priority. Anyone got any?
>
> --
> Christopher Dearlove

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 22 Nov 2017 17:08:05 +0000

We've also done work on unicast links, but I didn't put it on my list as there are some real downsides to it (and that's ignoring the issues that L2 might not work). Essentially you either need feedback via another route (in which case why not use that other route?) or you are operating blind. We did something that was a bit of each. You've got to have a real motivation, not just the thought that using a unicast link might help, because it probably won't.

As for rationale/how-to material, yes, when time (not just mine) permits, which it all too often doesn't.

> On 22 Nov 2017, at 14:13, Justin Dean <[email-masked]> wrote:
> 
> It's been our plate to release our OLSRv2 implementation for some time now.  In addition to the multicast work (mostly independent of the OLSRv2 work) we have played around with the idea of implementing support for unicast links.  One thing that we've found helps deployed networks is having extended timeouts for TC link information.  I'd be interested in helping with a writeup about why things are the way they are and some best practices or hints on how to set parameters to attempt better performance.
> 
> Justin Dean
> 
>> On Wed, Nov 22, 2017 at 5:38 AM, Christopher Dearlove <[email-masked]> wrote:

---

From: Henning Rogge <[email-masked]>
Date: Thu, 23 Nov 2017 07:21:43 +0100

We already have implemented (for a project) support for unicast
links... it is quite easy to do in my opinion, but you either need

1) at least one side being able to deliver multicast
2) know the unicast address of all possible neighbors
3) get the unicast address of your neighbors via DLEP

Henning

On Wed, Nov 22, 2017 at 3:13 PM, Justin Dean <[email-masked]> wrote:
> It's been our plate to release our OLSRv2 implementation for some time now.
> In addition to the multicast work (mostly independent of the OLSRv2 work) we
> have played around with the idea of implementing support for unicast links.
> One thing that we've found helps deployed networks is having extended
> timeouts for TC link information.  I'd be interested in helping with a
> writeup about why things are the way they are and some best practices or
> hints on how to set parameters to attempt better performance.
>
> Justin Dean
>
>> 8245. I've got a slide somewhere showing the main inter-relationships of the
>> 25 RFCs that make up this work (everything the group has done except 2501,
>> the original four experimental protocols, and DLEP), 15 of which I'm an
>> author of, beaten by Thomas Clausen at 19.
>>
>> Obviously that applies to the experimental RFCs such as 7722, 7779 and 7859,
>> but even more so the basic specification 7181 (and its updates). There's
>> some reporting in the literature of community networks - though I'm not sure
>> to what extent they are using pure OLSRv2, rather than older modified
>> OLSRv1. But beyond that, I'd like to know more for a variety of reasons.
>> That some of that use might be military may not help, but shouldn't be an
>> impossible barrier. And of course there might be material I've overlooked.
>> It's real use, rather than simulations, that I'd be after.
>>
>> too). But to build any of those on firm foundations, I go back to needing to
>> know how (if) the main protocol is being used.
>>

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 29 Nov 2017 07:50:57 -0800

Hi!

Just to feed the discussion on potential future work, please take a look at
his draft:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking

Background:  the ipwave (IP Wireless Access in Vehicular Environments) is
chartered to do initial work on vehicular networks: IPv6 over 802.11-OCB.
They are close to completing that initial charter and put together this
draft to "capture the problems that the WG finds interesting” with a view
towards rechartering.  I find that there is close relationship between the
type of routing environments considered there and the MANET work…

Just food for thought.

Alvaro.

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 29 Nov 2017 17:38:15 +0000

There's a failure somewhere (or more than one somewhere) that not a single protocol from this WG gets even a mention in that draft, not even to raise and dismiss. And looking at the author list, there's at least two people who are quite familiar with this group.

What does that mean we should do? Not sure.

> On 29 Nov 2017, at 15:50, Alvaro Retana <[email-masked]> wrote:
> 
> Hi!
> 
> Just to feed the discussion on potential future work, please take a look at his draft: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking 
> 
> Background:  the ipwave (IP Wireless Access in Vehicular Environments) is chartered to do initial work on vehicular networks: IPv6 over 802.11-OCB.  They are close to completing that initial charter and put together this draft to "capture the problems that the WG finds interesting” with a view towards rechartering.  I find that there is close relationship between the type of routing environments considered there and the MANET work…
> 
> Just food for thought.
> 
> Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 29 Nov 2017 10:16:56 -0800

On November 29, 2017 at 12:38:21 PM, Christopher Dearlove (
[email-masked]) wrote:

Hi!

There's a failure somewhere (or more than one somewhere) that not a single
protocol from this WG gets even a mention in that draft, not even to raise
and dismiss. And looking at the author list, there's at least two people
who are quite familiar with this group.

Participate in ipwave…

Yes, I agree that it is somewhat worrisome that no mention exists,
specially because the problem space is so similar.  An obvious way to
remedy is to participate in the discussion.

Some more background: when ipwave was originally chartered I objected at it
(explicitly) taking on routing because of the work in Manet…. I think that
we’re getting close to a new discussion and having you guys (the WG) become
familiar with the problem statement and shed light on existing
protocols/efforts/similarities/etc. would go along way towards reuse.

Thanks!

Alvaro.