Subject: [manet] AODVv2 and interacrion with IP

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 21 Aug 2015 10:42:34 +0000

I'm not happy with the interaction of AODVv2 with IP. My unhappiness is reinforced by Charlie's comment:

>  IP never had to do this before, because IP never had to work with reactive route establishment

Taken at face value (but consistent with how the draft is written) this is saying that this draft wants the IP handling of this router to be unlike IP as we know it.

Now if we have a way to make this work on, say, Linux, by various intercepts, or even rewriting the kernel, then that's OK for an experimental protocol (I think).

But the stated intent is for AODVv2 to be a Standard Track protocol. I do not see that flying. Are we saying this updates RFC 791? (And its IPv6 equivalent.) That's a mountain to climb.

This ties in with that a router expects a packet to come in, look at routing table, and get handled accordingly. The routing protocol is irrelevant by then. But this is suggesting it now isn't.

If all packets were just dropped if no route were known (not what's suggested) there would still be an issue of a non-standard interaction with IP, having to know that happened.

OK, I'll stop there, any further comments would be details. But I'd want some advice from appropriate people (our AD would be the obvious starting point) on how they think this will be received.

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

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

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Fri, 21 Aug 2015 13:07:51 +0200

I think there are two (three) additional things AODV2 needs from the
network stack:

1) detect usage of a route (e.g. a packet counter for the route)
2) intercept incoming IP packets which have no valid route to forward them
3) (optional) store these "no route available packets" to inject them into
the network stack later.

Henning Rogge

On Fri, Aug 21, 2015 at 12:42 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Taken at face value (but consistent with how the draft is written) this is
> saying that this draft wants the IP handling of this router to be unlike IP
> as we know it.
>
> Now if we have a way to make this work on, say, Linux, by various
> intercepts, or even rewriting the kernel, then that's OK for an
> experimental protocol (I think).
>
> But the stated intent is for AODVv2 to be a Standard Track protocol. I do
> not see that flying. Are we saying this updates RFC 791? (And its IPv6
> equivalent.) That's a mountain to climb.
>
> This ties in with that a router expects a packet to come in, look at
> routing table, and get handled accordingly. The routing protocol is
> irrelevant by then. But this is suggesting it now isn't.
>
> If all packets were just dropped if no route were known (not what's
> suggested) there would still be an issue of a non-standard interaction with
> IP, having to know that happened.
>
> OK, I'll stop there, any further comments would be details. But I'd want
> some advice from appropriate people (our AD would be the obvious starting
> point) on how they think this will be received.
>
> --
> Christopher Dearlove
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Teco Boot <[email-masked]>
Date: Fri, 21 Aug 2015 14:36:36 +0200

> Op 21 aug. 2015, om 12:42 heeft Dearlove, Christopher (UK) <[email-masked]> het volgende geschreven:
> 

The OpenFlow flag is present at the top of the mountain, isn't it? There is the "table-miss" flow entry, with possible action to send the packet to a controller. 
Didn't test it, I just discussed this option with few others how it could be used for a reactive protocol. Outcome was: yes this could work. 

This is not the only way to implement.

In some way the IP - ARP interaction is similar too.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 21 Aug 2015 14:43:27 +0200

On Fri, Aug 21, 2015 at 2:36 PM, Teco Boot <[email-masked]> wrote:

>
> > Op 21 aug. 2015, om 12:42 heeft Dearlove, Christopher (UK) <
> [email-masked]> het volgende geschreven:
> >
> > Taken at face value (but consistent with how the draft is written) this
> is saying that this draft wants the IP handling of this router to be unlike
> IP as we know it.
> >
> > But the stated intent is for AODVv2 to be a Standard Track protocol. I
> do not see that flying. Are we saying this updates RFC 791? (And its IPv6
> The OpenFlow flag is present at the top of the mountain, isn't it? There
> is the "table-miss" flow entry, with possible action to send the packet to
> a controller.
> Didn't test it, I just discussed this option with few others how it could
> be used for a reactive protocol. Outcome was: yes this could work.
>
iptables (for the route usage statistics) and a blackhole route into a
tap-device would also work (on Linux).

Henning Rogge

---

From: Thomas Clausen <[email-masked]>
Date: Tue, 25 Aug 2015 10:08:45 +0200

All,

It do *not* believe this to be a matter of “we can hack Linux this way and we can hack OpenFlow that way, to make it possible … ” -- but rather, a matter of “if you want to use this protocol, your platform MUST be ‘hackable’ to do X, Y and X”.

A-minima, the “hooks” required into the IP stack/forwarding plane needs to be clearly identified and enumerated — including where the protocol expects changed behavior from IP (for example, where “best effort” is set aside when there’s a routing table miss).  

This is sufficiently fundamental, that a shout-out belongs in the applicability statement, and a detailed treatment must be offered elsewhere in the main (not appendix) part of the document.

Best,

Thomas

> On Aug 21, 2015, at 14:43, Henning Rogge <[email-masked]> wrote:
> 
> On Fri, Aug 21, 2015 at 2:36 PM, Teco Boot <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > Op 21 aug. 2015, om 12:42 heeft Dearlove, Christopher (UK) <[email-masked] <mailto:[email-masked]>> het volgende geschreven:
> >
> iptables (for the route usage statistics) and a blackhole route into a tap-device would also work (on Linux).
> 
> Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Tue, 25 Aug 2015 18:10:56 +0200

> Op 25 aug. 2015, om 10:08 heeft Thomas Clausen <[email-masked]> het volgende geschreven:
> 
> All,
> 

+1 for adding a few words in the applicability statement section.
Detailed treatment is present already (6.4., 7.1.1.).

I'm not with you in that the required behavior is not IP. The "table miss - report to control plane" function is used quite often.

Openflow doesn't need a hack.

Teco