Re: [manet] draft-ietf-manet-aodvv2-13 review - a couple of big ticket Items

[[e-mail]]

Justin, all,

Apologies for the delayed response to this. Day-job, and all that, I know you know what I’m talking about…

> On Mar 23, 2016, at 13:59, Justin Dean <[e-mail]> wrote:
> 
> On Tue, Mar 22, 2016 at 5:04 PM, Thomas Heide Clausen <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On 22 Mar 2016, at 21:51, Justin Dean <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> I think you're misunderstanding my point. It's my opinion that it's past time to come up with some elegant and complex solution to fix this issue. Simple and safe solutions should be preferred as we'd likely miss something. This is regardless of when the outstanding problem was first raised.
>> 
> 
> My point is that it is an issue that must be addressed: the requirements that multiple interfaces can be sharing the same address is old, I have raised it multiple times over the years. OLSRv2 was built to support it. Henning reported an additional use case.
> 
> The WG chair suggesting to disallow it, or to "bridge it", is *not* solving the issue raised. It is the WG chair ignoring legitimate requirements from the WG, which does not strike me as aligned with proper process.
> 
> The WG chair saying "it is past time to solve" a long raised (and ignored) issue does not strike me as being aligned with proper process either.
> 
> Thomas
> 
> Since you seem quite passionate about this issue let's work on fixing it then. 

Thanks, appreciate it.

> I looked back over NHDP to see how we "solved" this issue (vaguely remembering something about limiting the address assignment when two interfaces on a node could reach the same medium but was unable to find that).

I have not looked it up, but the trick is indeed in that area, plus what you write below also.

Part of the motivation is, that if you do not do that, you may (potentially) break MPR flooding (remember, the race condition diagrams …?), so restrictions like that are in order.

> It works because we tag neighboring addresses with either link or neighbor status based on the incoming interface on which we received hello messages.
> It seems to me that if AODVv2 limited RREP messages to the interface on which the RREQ came in on (multicast or otherwise) that this would fix the issue.

Did anyone work through that/if this approach would work? I haven’t actually constructed a proof, but for a network without reduced relay set flooding optimizations, I’ve not been able to find a counter-example which would easily break it [as described above], which is at least a good thing ;)

Now, as to how to implement it….

> To do this the Neighbor Table (section 6.3) would have to be updated to include the local interface on which this neighbor is associated with. 
> When attempting to check bidirectionality messages would only be sent out on the listed interface.  This would be similar to the link table in NHDP and link tlv types.

Would that not entail an additional restriction required, such that the neighbor (as identified by an address) is reachable only over one, but not the other, interface? I.e., if the same address is used for two interfaces on a router, then those two must unequivocally be on different channels?

It seems that this avenue would be well worth developing, actually.

Best,

Thomas 


> 
> Justin