Subject: [manet] Updated version of AODVv2

From: Charlie Perkins <[email-masked]>
Date: Thu, 10 Jul 2014 21:44:58 -0700

Hello folks,

I have posted an updated version of AODVv2 at the following URL:

The biggest change by far is the inclusion of the appendix containing
the algorithms.  The other changes have to do with issue resolution
as we have discussed in preceding weeks.  I have not resolved any new
issues except by way of including the algorithms.

http://www.psg.com/~charliep/ietf90/draft-ietf-manet-aodvv2-pre04.txt

I had intended to upload this before the deadline, but then I found out
that the deadline was Friday instead of Monday.  That was a big 
disappointment,
sorry about that; I used the last few days for some additional proofreading.
The appendix containing the algorithms still needs more polishing, but it
is ready for review by interested WG members.

During the preparation of this revision, I have identified some more
issues that I will insert into the issue tracker shortly.  Also to come, a
new revision of the draft for Intermediate RREP, a feature that was
(perhaps mistakenly) isolated from the main AODVv2 specification.

Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 14 Jul 2014 09:21:12 +0000

I've read this draft, I'm not sure which was the last draft I read (a DYMO one). I actually still haven't read some of the detailed sections at this time.

While I have noted various other points on my copy, I'm just going to consider what I think are the major problems with this draft.

The protocol relies on links being didirectional. It must therefore provide a means to ensue that. It's not good enough to list several possibilities - that will not offer interoperability. It is fine of course to offer allowing additional reasons to exclude links, but there needs to be a basic non-optional mechanism for something that the protocol will not work without.

(Not a draft problem directly, but I think most if not all of those mechanisms make the protocol not fully reactive. That removes one of the motivations for interest in a reactive protocol in some use cases.)

The document is completely noncompliant with the RFC 5444 multiplexing mechanism, mandated by RFC 5498 (on the manet port/protocol). It does many things that are not within its competence.

There's a number of things I will roll together and express as there is a need to understand the architecture. The protocol needs many things from IP, such as failed routing notification, and interacts with it in ways such as queuing packets. It also interacts (sends and receives) with ICMP, and I'm not sure what else. This needs to be put together, so the reader can see what is needed to be able to implement this.

Despite saying that hop count is inadequate, it's the only metric supported. And unlike OLSRv2, which is designed so that the protocol can handle any future metric without change, that's not true here. That's a definite protocol weakness.

I think there will be compatibility issues with the optional features. As a point of IETF protocol, I don't think quoting two year expired Internet Drafts is acceptable. But I haven't dug into this.

The security approach is - and I've said this before, as others have made the above points before - completely unacceptable. The security directorate and ADs refused to accept this from OLSRv2. They will refuse to accept this from this protocol. Incidentally note that references to RFC 6621 should be to RFC 6622, except now to RFC 7182.

Appendix A. If pseudo-code is needed to explain the algorithms, it needs to be in the main body. If the main body is considered complete (and this is at the detail level I've not read) I'm not sure exactly what this is offering. I's also too C-lie (NULL for example) while not being C (use of := - although not fully consistently). I don't think the balance is right here.

The model is of routers with a single address per interface. In OLSRv2 this wasn't considered acceptable. The authors defined multiple addresses per interface, the WG required supporting unnumbered interfaces which shared addresses. Do we want a less capable protocol here? Also gateway support is weak - OLSRv2 can support multiple gateways with the same, or overlapping, address ranges. Again, is something less functional good enough?

My conclusion is that this document is still a long way from being in a state that could be published.

-- 
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 Charlie Perkins
Sent: 11 July 2014 05:45
To: Mobile Ad Hoc Networks mailing list
Subject: [manet] Updated version of AODVv2

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

Hello folks,

The biggest change by far is the inclusion of the appendix containing the algorithms.  The other changes have to do with issue resolution as we have discussed in preceding weeks.  I have not resolved any new issues except by way of including the algorithms.

I had intended to upload this before the deadline, but then I found out that the deadline was Friday instead of Monday.  That was a big disappointment, sorry about that; I used the last few days for some additional proofreading.
The appendix containing the algorithms still needs more polishing, but it is ready for review by interested WG members.

During the preparation of this revision, I have identified some more issues that I will insert into the issue tracker shortly.  Also to come, a new revision of the draft for Intermediate RREP, a feature that was (perhaps mistakenly) isolated from the main AODVv2 specification.

Regards,
Charlie P.

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

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