Subject: Re: [manet] Routing area draft minutes available

From: "Ratliff, Stanley" <[email-masked]>
Date: Tue, 26 Jul 2016 15:37:48 +0000

Chris, 

> -----Original Message-----
> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2016 10:51 AM
> To: Jonathan Hardwick <[email-masked]>; routing-
> [email-masked]; [email-masked]; [email-masked]; rtg-
> [email-masked]
> Subject: RE: Routing area draft minutes available
> 
> 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.)

In the DLEP/OSPF implementation I worked on - when the router-side DLEP received a Destination Up message from the modem, it (the router-side DLEP) would simply indicate to OSPF that the event occurred. OSPF used this indication to send a normal HELLO, irrespective of the state of its HELLO timer. There is a similar indication on receipt of Destination Down from the modem; that indicator causes OSPF to act as if the "Dead Timer" has expired on the neighbor. I can see this type of interaction between DLEP and NHDP. 

Regards,
Stan

> 
> --
> 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]; rtg-
> [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.
> **********************************************************
> **********
> 

_____________________________________________________
This electronic message and any files transmitted with it contains
information from iDirect, which may be privileged, proprietary
and/or confidential. It is intended solely for the use of the individual
or entity to whom they are addressed. If you are not the original
recipient or the person responsible for delivering the email to the
intended recipient, be advised that you have received this email
in error, and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited. If you received this email
in error, please delete it and immediately notify the sender.
_____________________________________________________

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 26 Jul 2016 16:13:21 +0000

Yes, that is an additional form of possible interaction. But it meets the same basic shape - DLEP can inform the user of HELLO messages (OLSR or OSPF) - here to help manage its schedule, which I hadn't considered - but doesn't substitute for them.

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

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

-----Original Message-----
From: Ratliff, Stanley [mailto:[email-masked]] 
Sent: 26 July 2016 16:38
To: Dearlove, Christopher (UK); [email-masked]
Subject: RE: Routing area draft minutes available

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

Chris, 

> Obviously (as I wasn't present) I'm not commenting on the minutes 
> reflecting what was said. But to the questions asked about MANET:
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.)

Regards,
Stan

> 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]; rtg- [email-masked]
> For information regarding Red Flags that you can look out for in 
> emails you receive, click here.
> 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.

_____________________________________________________
This electronic message and any files transmitted with it contains information from iDirect, which may be privileged, proprietary and/or confidential. It is intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please delete it and immediately notify the sender.
_____________________________________________________