Subject: [RTG-DIR] Routing area draft minutes available

From: Jonathan Hardwick <[email-masked]>
Date: Tue, 26 Jul 2016 11:04:52 +0000

The draft minutes for the RTGAREA meeting at IETF 96 are now available.  Please let me know if you have any comments.
https://www.ietf.org/proceedings/96/minutes/minutes-96-rtgarea

Best regards
Jon

---

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Jul 2016 09:37:16 -0400

Jon,

Thank you very much for the minutes - and for all the work you do with the
Routing Directorate.
It makes a really big difference to be able to have more good reviews on
documents with such ease.

Alia

On Tue, Jul 26, 2016 at 7:04 AM, Jonathan Hardwick <
[email-masked]> wrote:

> The draft minutes for the RTGAREA meeting at IETF 96 are now available.
> Please let me know if you have any comments.
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 26 Jul 2016 14:50:59 +0000

Obviously (as I wasn't present) I'm not commenting on the minutes reflecting what was said. But to the questions asked about MANET:

> George Swallow: Building large packets by putting small packets together; large
>                packets more likely to get corrputed; how about sending smaller
>              packets?
> Justin: Smaller packets will get through more, which is not always good as you
>       don't want to find neighbours that you have a poor link to.

I think a more important point is that packets have overheads (headers for RFC 5444, UDP, IP, MAC and also media access overheads). So fewer packets can be a significant win.

> Chris Bowers: Why is the 2-hop neighbour important?
> Justin: Many of the algorithms require you to know your 2-hop neighbours.
> Chris: So unlike IS-IS, you need to be careful to constraing flooding? (Yes)
> Stan: RFC 5820 uses a 2-hop neighbourhood for flooding in OSPFv3.

RFC 3626 (OLSR) predates this in using two hop information to define MPRs (used for improved flooding and topology reduction), it's where some ideas in the experimental OSPF wireless extensions came from. And of course now we have OLSRv2 (RFC 7181) at Proposed Standard.

> Jehan Tremback: Does DLEP replace Hello in OLSR protocols?
> Justin: Not completely as the Hello messages require TLVs.

NHDP (RFC 6130), the owner of the HELLO messages in the OLSRv2 family, permits using any other sources of information (DLEP could be one) to augment HELLO messages (subject to certain constraints). But there are several things in HELLO messages that DLEP doesn't supply to the router - in particular, but not only, things added by OLSRv2 (MPRs, knowledge of OLSRv2 support using its metrics). I'm also not sure DLEP would provide the multiple interface information properly.

But even if DLEP did report such things radio to router, DLEP is entirely about that interface. DLEP defines no over the air signalling, which is what HELLO messages provide - to establish connectivity and exchange information. To use DLEP to provide the information that routers need to run NHDP/OLSRv2, you'd need to define an over the air signalling between radios. Or in other words, re-invent NHDP.

Rather, what might make sense is that if you want some over the air signalling for DLEP gather some of its information, you could add it to HELLO messages if running NHDP. (Not quite ideal, as HELLO messages are designed to run router to router, not radio to radio. And off course you may well not be running NHDP, in which case you would need another solution.)

-- 
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: routing-discussion [mailto:[email-masked]] On Behalf Of Jonathan Hardwick
Sent: 26 July 2016 12:05
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Routing area draft minutes available

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here.
If you feel the email is suspicious, please follow this process.
The draft minutes for the RTGAREA meeting at IETF 96 are now available.  Please let me know if you have any comments.
https://www.ietf.org/proceedings/96/minutes/minutes-96-rtgarea

Best regards
Jon

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