Subject: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.txt

From: Henning Rogge <[email-masked]>
Date: Mon, 28 Jul 2014 09:17:44 +0200

Hi,

I have uploaded the first revision of my "NHDP dualstack optimization"
draft to the IETF.

Looking forward to your comments.

Henning Rogge

-------- Forwarded Message --------
Subject: New Version Notification for
draft-rogge-manet-nhdp-dualstack-optimization-00.txt
Date: Mon, 28 Jul 2014 00:15:22 -0700
From: [email-masked]
To: Henning Rogge <[email-masked]>, Henning Rogge
<[email-masked]>

A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-00.txt
has been successfully submitted by Henning Rogge and posted to the
IETF repository.

Name:		draft-rogge-manet-nhdp-dualstack-optimization
Revision:	00
Title:		Optimized flooding for NHDP Dual Stack routers
Document date:	2014-07-28
Group:		Individual Submission
Pages:		8
URL:
http://www.ietf.org/internet-drafts/draft-rogge-manet-nhdp-dualstack-optimization-00.txt
Status:
https://datatracker.ietf.org/doc/draft-rogge-manet-nhdp-dualstack-optimization/
Htmlized:
http://tools.ietf.org/html/draft-rogge-manet-nhdp-dualstack-optimization-00

Abstract:
   This document specifies an optimization for the flooding of RFC5444
   control traffic with NHDP.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 28 Jul 2014 09:10:17 +0000

I admit to not having read every detail, but I find this quite underspecified in terms of how the dual stack is organised when it is described as a combined implementation, not two separate implementations. What is different to running an IPv4 and an IPv6 implementation, with a small change to the latter (just the latter?). There are lots of questions, such as if we should attempt to use the same message schedules (that's just an example).

I also would like to know about interoperability with non-dual-stack implementations. And later about what happens with OLSRv2. (I wouldn't be happy with a dual stack NHDP unless I knew what happened with OLSRV2 also.)

At the detail level, this seems to assume compulsory originator addresses. But they are not compulsory in standard NHDP - only when used with OLSRv2.

(I also want to rename the L_ element, but let's address the big picture items.)

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 28 July 2014 08:18
To: [email-masked]
Subject: [manet] Fwd: New Version Notification for draft-rogge-manet-nhdp-dualstack-optimization-00.txt

Hi,

Henning Rogge

-------- Forwarded Message --------
To: Henning Rogge <[email-masked]>, Henning Rogge <[email-masked]>

A new version of I-D, draft-rogge-manet-nhdp-dualstack-optimization-00.txt
has been successfully submitted by Henning Rogge and posted to the IETF repository.

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jul 2014 12:16:11 +0200

If I did not misunderstood I think the draft does not follow RFC5498 which
I think makes it flexible and benefits from UDP packets advantages. Also
specifies that RFC5444 messages are allowed to not need to have an RFC5444
packet (I remember discussing this before and some refused the idea) just
UDP packets which is another advantage. Please reply if I misunderstood.

AB

On Monday, July 28, 2014, Henning Rogge wrote:

> From: [email-masked] <javascript:;>
> To: Henning Rogge <[email-masked] <javascript:;>>,
> Henning Rogge
> <[email-masked] <javascript:;>>
>
>
> mailto:[email-masked] <javascript:;>
> http://www.fkie.fraunhofer.de
>
>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 28 Jul 2014 12:16:18 +0200

AB

---

From: Henning Rogge <[email-masked]>
Date: Mon, 28 Jul 2014 12:59:58 +0200

On Mon, Jul 28, 2014 at 11:10 AM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> I admit to not having read every detail, but I find this quite underspecified in terms of how the dual stack is organised when it is described as a combined implementation, not two separate implementations.

You need a way to put IPv4 RFC5444 messages into IPv6 UDP/RFC5444
packets... and to parse this messages. You could do this with separate
implementation and a pipe between them, but combining both instances
makes it easier.

> What is different to running an IPv4 and an IPv6 implementation, with a small change to the latter (just the latter?).

Would not work, because the IPv4 implementation could not parse IPv6
RFC5444 messages incoming through IPv4 UDP packets (and a RFC5444
packet).

> There are lots of questions, such as if we should attempt to use the same message schedules (that's just an example).

Yes, this would (of course) help...

> I also would like to know about interoperability with non-dual-stack implementations. And later about what happens with OLSRv2. (I wouldn't be happy with a dual stack NHDP unless I knew what happen…

I tested my "dual stack" implementation with IPv4-only nodes,
IPv6-only nodes and nodes that run both IPv4-only and IPv6-only
routing instance. It should work with all of them because it
downgrades to "IPv4 messages over IPv4 packet, IPv6 messages over IPv6
packets" in the presence of IPv4- or IPv6-only nodes.

> At the detail level, this seems to assume compulsory originator addresses. But they are not compulsory in standard NHDP - only when used with OLSRv2.

Yes. The requirements are NHDP plus an originator address. Doesn't
need to be one defined by OLSRv2, but it needs this address.

> (I also want to rename the L_ element, but let's address the big picture items.)

no problem with this (both the renaming and doing it later).

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Mon, 28 Jul 2014 13:03:06 +0200

On Mon, Jul 28, 2014 at 12:16 PM, Abdussalam Baryun
<[email-masked]> wrote:
> If I did not misunderstood

You did (misunderstood)

> I think the draft does not follow RFC5498 which I
> think makes it flexible and benefits from UDP packets advantages.

No, it does follow RFC5498.

RFC5498 does not mandate to put only address length 4 RFC5444 messages
into RFC5444 packets that are in IPv4 UDP packets.

> Also

The problem is that the phrase "IPv4 RFC5444 packet" doesn't make much
sense, because the RFC5444 packet header is not address family aware.

Maybe I should add two definitions "IPv4/6 RFC5444 packet" to the
draft that mean IPv4/6 UDP packet with RFC5444 packet inside.

Henning Rogge