RE: Routing area draft minutes available

"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Tue, 26 July 2016 15:24 UTC

Return-Path: <chris.dearlove@baesystems.com>
X-Original-To: routing-discussion@ietfa.amsl.com
Delivered-To: routing-discussion@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA912DBC3; Tue, 26 Jul 2016 08:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.187
X-Spam-Level:
X-Spam-Status: No, score=-8.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsGqx5-FQ4PB; Tue, 26 Jul 2016 08:24:52 -0700 (PDT)
Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A08A12DBD7; Tue, 26 Jul 2016 07:51:02 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.28,425,1464649200"; d="scan'208";a="92660559"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta1.baesystems.com with ESMTP; 26 Jul 2016 15:51:00 +0100
X-IronPort-AV: E=Sophos;i="5.28,425,1464649200"; d="scan'208";a="127649993"
Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds016.greenlnk.net with ESMTP; 26 Jul 2016 15:51:00 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.169]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0248.002; Tue, 26 Jul 2016 15:51:00 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>, "routing-discussion@ietf.org" <routing-discussion@ietf.org>, "rtg-chairs@ietf.org" <rtg-chairs@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "rtg-ads@tools.ietf.org" <rtg-ads@tools.ietf.org>
Subject: RE: Routing area draft minutes available
Thread-Topic: Routing area draft minutes available
Thread-Index: AdHnLXWJAkRNXUXbTkuFzXoYajOiEQAHKn9Q
Date: Tue, 26 Jul 2016 14:50:59 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D923F00D9@GLKXM0002V.GREENLNK.net>
References: <BY2PR0201MB19101F66A87DF2E90C055679840E0@BY2PR0201MB1910.namprd02.prod.outlook.com>
In-Reply-To: <BY2PR0201MB19101F66A87DF2E90C055679840E0@BY2PR0201MB1910.namprd02.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: text/plain; charset="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/routing-discussion/9D2g_ylpIJx84I1N3nTwD5BAkd4>
X-BeenThere: routing-discussion@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area General mailing list <routing-discussion.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/routing-discussion/>
List-Post: <mailto:routing-discussion@ietf.org>
List-Help: <mailto:routing-discussion-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/routing-discussion>, <mailto:routing-discussion-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 15:24:57 -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: chris.dearlove@baesystems.com

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:routing-discussion-bounces@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 26 July 2016 12:05
To: routing-discussion@ietf.org; rtg-chairs@ietf.org; rtg-dir@ietf.org; rtg-ads@tools.ietf.org
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.
********************************************************************