Subject: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-00.txt

From: Axel Colin de Verdière <[email-masked]>
Date: Mon, 17 Feb 2014 12:37:53 +0100

Dear all,

We submitted a new version for ODMRP, which we wish to revive if there's interest in the WG. In particular, it has been rewritten to use the RFC5444 packet format.

We also submitted a new experimental draft specifying an extension of ODMRP that allows it to make use of unidirectional links. Here's the link: http://tools.ietf.org/html/draft-gerla-manet-odmrp-asym-00. Given the characteristics of certain MANET deployments, we believe it can be a useful alternative to blacklisting such links.

Any feedback or comment on those documents would be very appreciated.

Thank you,

Axel

Début du message réexpédié :

> De: [email-masked]
> Objet: New Version Notification for draft-gerla-manet-odmrp-00.txt
> Date: 14 février 2014 22:21:54 UTC+1
> À: "Yunjung Yi" <[email-masked]>, "William Su" <[email-masked]>, "Axel Coli Verdiere" <[email-masked]>, "Sung-Ju Lee" <[email-masked]>, Mario Gerla <[email-masked]>, "Professor Mario Gerla" <[email-masked]>, Axel Colin de Verdiere <[email-masked]>
> 
> 
> A new version of I-D, draft-gerla-manet-odmrp-00.txt
> has been successfully submitted by Axel Colin de Verdiere and posted to the
> IETF repository.
> 
> Name:		draft-gerla-manet-odmrp
> Revision:	00
> Title:		On-Demand Multicast Routing Protocol (ODMRP) for Ad Hoc Networks
> Document date:	2014-02-14
> Group:		Individual Submission
> Pages:		29
> URL:            http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/
> Htmlized:       http://tools.ietf.org/html/draft-gerla-manet-odmrp-00
> 
> 
> Abstract:
>   The On-Demand Multicast Routing Protocol (ODMRP) is a multicast
>   routing protocol designed for ad hoc networks with mobile hosts.
>   ODMRP is a mesh-based, rather than a conventional tree-based,
>   multicast scheme and uses a forwarding group concept (only a subset
>   of nodes forwards the multicast packets via scoped flooding).  It
>   applies on-demand procedures to dynamically build routes and maintain
>   multicast group membership.  ODMRP is well suited for ad hoc wireless
>   networks with mobile hosts where bandwidth is limited, topology
>   changes frequently and rapidly, and power is constrained.
> 
> 
> 
> 
> 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
>

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 17 Feb 2014 13:23:33 +0100

Axel, Mario, All,

There seems to be a slight datatracker issue here. When clicking:

	http://www.ietf.org/id/draft-gerla-manet-odmrp-00.txt

One gets to the 2014-draft, whereas when clicking:

	http://tools.ietf.org/html/draft-gerla-manet-odmrp-00

One gets to the 1998-draft, of the same name. I believe that the "problem" may be that there are two I-Ds submitted (the 2014 and 1998 versions) with the same name and version number (-00). Perhaps an email to the lovely folks at the secretariat would help fix that problem?

Best,

Thomas

On 17 Feb 2014, at 12:37, Axel Colin de Verdière <[email-masked]> wrote:

> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Axel Colin de Verdière <[email-masked]>
Date: Mon, 17 Feb 2014 13:26:25 +0100

Hi Thomas,

Thank you, I hadn't seen that! I'll drop them an email to see what they can do. In the meantime, I think the datatracker (https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/) and txt/pdf links work correctly.

Best,

Axel

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 17 Feb 2014 13:32:10 +0100

Dear Axel,

> Thank you, I hadn't seen that! I'll drop them an email to see what they can do. In the meantime, I think the datatracker (https://datatracker.ietf.org/doc/draft-gerla-manet-odmrp/) and txt/pdf link…

They absolutely do work - yet, some of us (at least, I) live and breathe by the datatracker, and use tools that link up against it (rfcdiff is one such tool, but not the only one), so it'd be great if the good folks at the secretariat could work their magic on this ;)

Cheers,

Thomas

---

From: Axel Colin de Verdière <[email-masked]>
Date: Mon, 17 Feb 2014 13:38:23 +0100

Dear Thomas,

> They absolutely do work - yet, some of us (at least, I) live and breathe by the datatracker, and use tools that link up against it (rfcdiff is one such tool, but not the only one), so it'd be great…

Of course, and thank you again for pointing that out; I just sent them an email regarding the issue, hopefully they should be able to resolve this.

Best,

Axel

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Feb 2014 13:28:54 +0000

The obvious question is comparing ODMRP with SMF. Is there anyone with experience of both? Published results?

--
Christopher Dearlove
Senior Principal Engineer, Communications 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]<mailto:[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

From: manet [mailto:[email-masked]] On Behalf Of Axel Colin de Verdière
Sent: 17 February 2014 11:38
To: <[email-masked]> List
Cc: soon Oh; gerla
Subject: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-00.txt

*** 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<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Dear all,

Thank you,

Axel

De: [email-masked]<mailto:[email-masked]>
Objet: New Version Notification for draft-gerla-manet-odmrp-00.txt
Date: 14 février 2014 22:21:54 UTC+1
À: "Yunjung Yi" <[email-masked]<mailto:[email-masked]>>, "William Su" <[email-masked]<mailto:[email-masked]>>, "Axel Coli Verdiere" <[email-masked]<mailto:[email-masked]>>, "Sung-Ju Lee" <[email-masked]<mailto:[email-masked]>>, Mario Gerla <[email-masked]<mailto:[email-masked]>>, "Professor Mario Gerla" <[email-masked]<mailto:[email-masked]>>, Axel Colin de Verdiere <[email-masked]<mailto:[email-masked]>>

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<http://tools.ietf.org>.

The IETF Secretariat

********************************************************************
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: Thomas Clausen <[email-masked]>
Date: Mon, 17 Feb 2014 14:38:32 +0100

Chris,

> The obvious question is comparing ODMRP with SMF. Is there anyone with experience of both? Published results?

That was also one of my questions, alas, I think that they're not entirely comparable in that the former does group management whereas the latter does "optimized flooding". Thus, I'd suspect (at least, hope) that there would be scenarios where ODMRP incurs a vastly lower total network load than SMF (say, a big network and a small group with group members being topologically far apart) and possibly vice-versa also.

I agree that published results on this would be interesting - caveating with the usual "show me a protocol, and I'll come up with a scenario where it won't work as well as XXXX", of course.

There are a few informative references in ODMRP - to the Authors, those references are actually incomplete, I couldn't easily figure out where I could dig out [ODMRP-Journal] for reading more (I also note that the year for that reference is missing, is that recent work, or 1998-work?)

Cheers,

Thomas

> [email-masked] | http://www.baesystems.com
> 
> 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.
> 
> Dear all,
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Feb 2014 15:56:17 +0000

What's needed is some sort of quantification of if and when it becomes "not worth being clever, let's just [optimised] flood". And of whether [optimised] flooding is more (or less) reliable.

Obvious limiting cases are everyone is in the multicast group, and very small number in multicast group.

From: Thomas Clausen [mailto:[email-masked]]
Sent: 17 February 2014 13:39
To: Dearlove, Christopher (UK)
Cc: Axel Colin de Verdière; <[email-masked]> List; soon Oh; Mario Gerla
Subject: Re: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-00.txt

*** WARNING ***

On 17 Feb 2014, at 14:28, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:

Cheers,

Thomas

[email-masked]<mailto:[email-masked]> | http://www.baesystems.com<http://www.baesystems.com/>

From: manet [mailto:[email-masked]] On Behalf Of Axel Colin de Verdière
Sent: 17 February 2014 11:38
To: <[email-masked]<mailto:[email-masked]>> List
Cc: soon Oh; gerla
Subject: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-00.txt

*** WARNING ***

Thank you,

Axel

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<http://tools.ietf.org/>.

The IETF Secretariat

[email-masked]<mailto:[email-masked]>

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 17 Feb 2014 17:00:25 +0100

On 17 Feb 2014, at 16:56, Dearlove, Christopher (UK) <[email-masked]> wrote:

> What’s needed is some sort of quantification of if and when it becomes “not worth being clever, let’s just [optimised] flood”. And of whether [optimised] flooding is more (or less) reliable.

Absolutely. To quantify it a bit more, when does "group management" and "maintaining the broadcast tree/graph" become more "expensive" than just flooding. this would be good to see discussed in the applicability statement.

[While we're at the applicability statement, but of course not going all the way of a full review, how would ODMRP interact with an instance of OLSRv2 running on the same router? As in SMF, I imagine that some benefits could be drawn from the topology view acquired by OLSRv2. On the same token, if SMF and ODMRP are, both, running on the same device, are we expecting synergy or conflict?]

> Obvious limiting cases are everyone is in the multicast group, and very small number in multicast group.

Yes, everything "less than everybody" and "more than two" are the interesting cases :D

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Feb 2014 16:06:05 +0000

The limiting cases have their uses. If you get a bad result (for SMF or ODMRP) at the relevant extreme (consistently), you might as well just use the other all the time.

From: Thomas Clausen [mailto:[email-masked]]
Sent: 17 February 2014 16:00
To: Dearlove, Christopher (UK)
Cc: soon Oh; <[email-masked]> List; Mario Gerla
Subject: Re: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-00.txt

*** WARNING ***

On 17 Feb 2014, at 16:56, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:

Thomas

Cc: Axel Colin de Verdière; <[email-masked]<mailto:[email-masked]>> List; soon Oh; Mario Gerla

*** WARNING ***

Cheers,

Thomas

*** WARNING ***

Thank you,

Axel

Abstract:

The IETF Secretariat

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 17 Feb 2014 17:06:49 +0100

Violent agreement ;)

---

From: Brian Adamson <[email-masked]>
Date: Mon, 17 Feb 2014 12:16:24 -0500

The Elastic Multicast (draft-adamson-manet-elasticmcast-00) concept we presented at the last IETF is very similar to ODMRP (the non-ASYM version) with respect to them both being a form of flood and prune (well more of a graft with "downstream" routers ACKing to keep that portion of the SMF flooding mesh alive on a group-specific basis).  With Elastic Multicast, there is a natural devo-lution (morphing) to more meshy, SMF flooding behavior where there are high dynamics.  I would also note that Elastic Multicast uses the proactively-created flooding topology (per NHDP and SMF relay set selection and possibly metric-based approaches to getting there) as opposed to an "on demand" approach per ODMRP.  As with other proactive vs. reactive (on demand) MANET tradeoffs, there is probably utility in both approaches for different circumstances.  It would be interesting to have implementations of both available for comparison and exploration of these tradeoffs.

Some of the more recent work on ODMRP and the ODMRP-ASYM protocol was initiated under the same ONR-sponsored effort as the Elastic Multicast and there was some discussion consideration towards instantiating  ODMRP on top of the SMF flooding mesh.  Since the new odmrp-00 draft isn't accessible yet, I haven't seen if that idea was adopted, but it could be worth consideration.  With ODMRP-ASYM, there would be a difference here since the current SMF relay set selection algorithms require reciprocal (bi-directional) links.

Given some potential interest in addressing group-specific multicast within MANET, it may be worthwhile to outline some of the various multicast routing requirements for MANET including group management, gateway interaction with other routing domains (e.g., PIM), expected application/transport protocol needs and behaviors.  There may be some common aspects (e.g. group membership mechanisms, management, etc) regardless of the specific routing mechanism (e.g. whether reactive, proactive, etc)

cheers,

Brian

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 17 Feb 2014 18:36:10 +0100

IMHO, there is no comparison in current publications of ODMRP vs SMF, but I
think there are for MAODV vs ODMRP. The question needs to compare two
similar protocols but SMF is not reactive. So why we do not ask what is the
comparison between multicast AODVv2 (the current reactive WG protocol) and
ODMRP?

AB

On Monday, February 17, 2014, Dearlove, Christopher (UK) wrote:

> [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>|
> http://www.baesystems.com
>
> *From:* manet [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *On Behalf Of *Axel Colin de Verdière
> *Sent:* 17 February 2014 11:38
> *To:* <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> List
> *Cc:* soon Oh; gerla
> *Subject:* [manet] Fwd: New Version Notification for
> draft-gerla-manet-odmrp-00.txt
>
>
>
>
>
> **** 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
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.*
> * If you feel the email is suspicious, please follow this process
> <http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.*
>
> Dear all,
>
>
>
> We submitted a new version for ODMRP, which we wish to revive if there's
> interest in the WG. In particular, it has been rewritten to use the RFC5444
> packet format.
>
>
>
> We also submitted a new experimental draft specifying an extension of
> ODMRP that allows it to make use of unidirectional links. Here's the link:
> http://tools.ietf.org/html/draft-gerla-manet-odmrp-asym-00. Given the
> characteristics of certain MANET deployments, we believe it can be a useful
> alternative to blacklisting such links.
>
>
>
>  *De: [email-masked]
>
> *Objet: New Version Notification for draft-gerla-manet-odmrp-00.txt*
>
> *Date: *14 février 2014 22:21:54 UTC+1
>
> *À: *"Yunjung Yi" <[email-masked]>, "William Su"
> <[email-masked]>, "Axel Coli Verdiere" <
> [email-masked]>, "Sung-Ju Lee" <[email-masked]>,
> Mario Gerla <[email-masked]>, "Professor Mario Gerla" <
> [email-masked]>, Axel Colin de Verdiere <[email-masked]>
>
>
>
>
> URL:
> http://www.ietf.org/internet-drafts/draft-gerla-manet-odmrp-00.txt
>   multicast scheme and us

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 17 Feb 2014 18:39:40 +0100

On 17 Feb 2014, at 18:36, Abdussalam Baryun <[email-masked]> wrote:

> IMHO, there is no comparison in current publications of ODMRP vs SMF, but I think there are for MAODV vs ODMRP. The question needs to compare two similar protocols but SMF is not reactive. So why we do not ask what is the comparison between multicast AODVv2 (the current reactive WG protocol) and ODMRP?

Because it's an uninteresting question to ask: I have never heard of "multicast AODVv2".

---

From: Axel Colin de Verdière <[email-masked]>
Date: Mon, 17 Feb 2014 19:00:05 +0100

Hi all,

Thanks a lot for your comments. A few replies:

- The ODMRP paper referenced is from Mobile Networks and Application Journal, Vol.7 issue 6 from Dec. 2002., pp 441-453. The FGMP paper is from Cluster Computing June 1998, vol.1, issue 2, pp 187-196.

- As for SMF vs ODMRP, I do not have definitive results pointing to the limit where one becomes more efficient than the other. However the idea of taking advantage of the relay set built by SMF should work to disseminate Join Queries, the same way it can be used for unicast routing protocols such as AODV. I believe it should lead to something relatively close to Elastic Multicast actually, except for the periodic flooding of Join Queries.

- The idea behind ODMRP-ASYM could also very probably apply to a protocol such as Elastic Multicast: I think that routing the EM-ACK packet around the unidirectional link could work. The only issue would be that the relay set selection only uses bidirectional links as well, which is something that ODMRP (with or without SMF) would not have to deal with.

Best,

Axel

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Feb 2014 18:09:56 +0000

It's been so long since I looked at ODMRP that I'd forgotten it was on demand. That makes it less attractive as a WG item in that developing an on demand multicast protocol before an on demand unicast protocol is complete is a bit odd.

From: Brian Adamson [mailto:[email-masked]]
Sent: 17 February 2014 17:16
To: Dearlove, Christopher (UK)
Cc: Thomas Clausen; soon Oh; <[email-masked]> List; Mario Gerla
Subject: Re: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-00.txt

*** WARNING ***

cheers,

Brian

On Feb 17, 2014, at 11:06 AM, "Dearlove, Christopher (UK)" <[email-masked]<mailto:[email-masked]>> wrote:

From: Thomas Clausen [mailto:[email-masked]<http://thomasclausen.org>]
Sent: 17 February 2014 16:00
To: Dearlove, Christopher (UK)
Cc: soon Oh; <[email-masked]<mailto:[email-masked]>> List; Mario Gerla
Subject: Re: [manet] Fwd: New Version Notification for draft-gerla-manet-odmrp-00.txt

*** WARNING ***

Thomas

*** WARNING ***

Cheers,

Thomas

*** WARNING ***

Thank you,

Axel

Abstract:

The IETF Secretariat

---

From: Axel Colin de Verdière <[email-masked]>
Date: Mon, 17 Feb 2014 19:21:00 +0100

Isn't it possible to develop both in parallel? After all, the unicast protocol is not nearly finished, it might be interesting to start tackling multicast-related issue in the meantime? As Brian said, regardless of the actual solution(s) chosen for unicast/multicast, there are some common aspects to determine.

Le 17 févr. 2014 à 19:09, Dearlove, Christopher (UK) <[email-masked]> a écrit :

> It’s been so long since I looked at ODMRP that I’d forgotten it was on demand. That makes it less attractive as a WG item in that developing an on demand multicast protocol before an on demand unicast protocol is complete is a bit odd.
>  
> --
> Christopher Dearlove

---

From: Henning Rogge <[email-masked]>
Date: Mon, 17 Feb 2014 19:25:14 +0100

Hi,

I have two questions about the new draft.

1) is there an Open Source implementation of ODMRP?
2) does it need a kernel module?

Henning Rogge

On Mon, Feb 17, 2014 at 12:37 PM, Axel Colin de Verdière
<[email-masked]> wrote:
> We also submitted a new experimental draft specifying an extension of ODMRP
> that allows it to make use of unidirectional links. Here's the link:
> À: "Yunjung Yi" <[email-masked]>, "William Su"
> <[email-masked]>, "Axel Coli Verdiere"
> <[email-masked]>, "Sung-Ju Lee"
> <[email-masked]>, Mario Gerla <[email-masked]>,
> "Professor Mario Gerla" <[email-masked]>, Axel Colin de Verdiere
> <[email-masked]>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 17 Feb 2014 21:17:24 +0100

> Because it's an uninteresting question to ask: I have never heard of

The MAODV (i.e. multicast AODV) and ODMRP are well known reactive
multicasts in our old drafts, so if a renew of the ODMRP by using RFC5444,
it is reasonable of the WG to look at our standard WG reactive protocol
that uses RFC5444 and it's multicast protocol as comparing multicast
protocols and seeing what to do.

AB

---

From: Henning Rogge <[email-masked]>
Date: Mon, 17 Feb 2014 21:23:26 +0100

We have yet so see someone coming forward to finish MAODV and
transform it into RFC5444 format. The MAODV draft never left release
-00, so there might be a lot of work to be done.

Henning Rogge

On Mon, Feb 17, 2014 at 9:17 PM, Abdussalam Baryun
<[email-masked]> wrote:
> The MAODV (i.e. multicast AODV) and ODMRP are well known reactive multicasts
> in our old drafts, so if a renew of the ODMRP by using RFC5444, it is
> reasonable of the WG to look at our standard WG reactive protocol that uses
> RFC5444 and it's multicast protocol as comparing multicast protocols and
> seeing what to do.
>
> AB
>
>
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 17 Feb 2014 22:15:43 +0100

On Monday, February 17, 2014, Axel Colin de Verdière wrote:

> Isn't it possible to develop both in parallel?
>

After all, the unicast protocol is not nearly finished, it might be
> interesting to start tackling multicast-related issue in the meantime?
>

I agree to start discussing multicast. Also is it possible we ask : Why not
we don't finish the old draft of the WG of ODMRP -04 without 5444, then we
go for this new one using RFC5444.  I am not sure why the WG drafts of
multicast: MAODV and ODMRP were adopted by the WG in the past then they
left them without finishing? I expected because they found out that they
needed to finish unicast first.

AB

---

From: Joe Macker <[email-masked]>
Date: Tue, 18 Feb 2014 10:19:24 -0500

> - As for SMF vs ODMRP, I do not have definitive results pointing to the limit where one becomes more efficient than the other. However the idea of taking advantage of the relay set built by SMF sho…

SMF is also somewhat of a building block with different modes (CDS, elastic multicast) and the potential to build group-specific behavior on top of it basic profile.   

One might ask more taxonomy based questions rather than SMF vs. ODMRP. Like ODMRP vs. classical flooding  or vs. CDS-flooding without group information (modes of SMF behavior) and then one has to also consider the traffic pattern dynamics and group distribution as in past studies of flood n’ prune  vs. core based multicast.  Likely no one size fits all.

I personally like the ideas behind ODMRP as it covers a particular good taxonomy area.  Unfortunately the group scope back its work on multicast in the past to make progress.  I personally feel the time is right to rework some of these issues.  

If modernized with newer capabilities such as multiple interfaces,IPv6 support (one the reasons to reinvigorate older design) It will be a good area of engineering work in my opinion.

It would be nice to know more about any progress related to any potential open reference implementations.

-Joe

---

From: Axel Colin de Verdière <[email-masked]>
Date: Tue, 18 Feb 2014 20:28:32 +0100

I am not aware of any open-source implementation of ODMRP. I agree that it would be a good thing, I'll see if I can have something started soon.
The latest draft currently supports multiple interfaces (although I think that there is still work to be done here), and the shift to RFC5444 packet format allows it to support IPv6 addresses as well.

Axel