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

[Thomas Heide Clausen <[e-mail]>]

> On 22 Mar 2016, at 21:51, Justin Dean <[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

> Justin
> 
> 
>> On Tue, Mar 22, 2016, 4:36 PM Thomas Heide Clausen <[e-mail]> wrote:
>> I will get to the rest of your mail some other time, but one point...
>> 
>>>  
>>>> Multiple interfaces configured with the same address(es) - & RFC6621
>>>> I think that it has been established that the ability to use the same address on multiple interfaces is a requirement. It’s not clear to me that a single way of doing so has been proposed, nor that the “operating conditions” are called out (for example, will it work  if router A and router B both have two interfaces, and that all 4 interfaces use the same IP address?)
>>>> 
>>>> This is not entirely unrelated to flooding reduction and RFC6621. One of the complexities is to get that just right: OLSRv2 - for example - calculates Flooding-MPRs per interface, and RFC6130 is careful in how it detects bidirectionality of links. 
>>>> 
>>>> I have not worked out all the details of how this impacts this protocol — but, it requires attention. Especially when wanting to be able to say “…use RFC6621”, then the interface configuration constraints when faced with multiple interfaces must be worked out.
>>>> 
>>> JWD: The super simple dumb way of doing this is to mandate that any interface which shares an address with another much be bridged.  Then you really only have a single interface again. Or just say it's not allowed.  Other more complex methods may be possible but we are honestly past time for that and as Thomas points out there are corner cases that we will likely miss and its past time for that.
>> 
>> You do simply not get to say that it is "past time" for this, given that I have been pointing the need for this to be resolved out, on the list, repeatedly and for ages -- only to have the authors ignore it.
>> 
>> To declare that "it is past time for that" when the issue in question has been raised in public and for a long time is, I believe, grounds for a process appeal.
>> 
>> Thomas
>> 
>>>  
>>>> Prefixes & Gateways
>>>> A question to my mind, and I am not sure I know how to answer that from reading the draft since it is not discussed in section 9 (at least), is: “What happens if I send a RREQ to a prefix” (i.e., a /<128 in IPv6)?
>>>> 
>>> JWD: I believe Lotte answered this in that it's not allowed.  Simple fix. 
>>>> 	o	If the whole prefix is part of the attached network set of a single router, 
>>>> 		then I expect to get a single RREP back, is that the case?
>>>> 
>>>> 	o	If "half the prefix"  is part of the attached network set of a single router, 
>>>> 		and the other half is part of the attached network set of another  single router, 
>>>> 		then I expect two RREPs, is that the case?
>>>> 
>>>> 	o	More generally, will I get a tree build through the network here?
>>>> 
>>>> Section 9 (or, the whole spec) is also not explicit enough about multiple  "default gateways" — i.e., the external network being “the rest of the Internet”, and there being multiple gateways to the Internet. I understand how the RREQ gets to the gateway, and how the gateway determines if it should respond (the destination is not part of “the MANET prefix, with which it is configured”).
>>>> 
>>>> But, if A is close to GW1, and B is close to GW2, but A and B being far far apart (according to the metric used) within the MANET, then it would be preferential for the route from A to B to go via GW1-“the-Internet”-GW2? 
>>>> 
>>>> Is this a supported configuration? 
>>>> 	o	If yes, how is it (seq# wise, I would expect some complications) handled? 
>>>> 	o	If not, where is it stated that this configuration is not possible with this protocol?
>>>> 
>>>> 
>>>> The applicability statement says:
>>>> 
>>>>    AODVv2 is designed for stub or disconnected mobile ad hoc networks,
>>>>    i.e., non-transit networks or those not connected to the internet.
>>>>    AODVv2 can, however, be configured to perform gateway functions when
>>>>    attached to external networks, as discussed in Section 9.
>>>> 
>>>> I believe that the scenario I describe is indeed a stub network (and not a transit network)?
>>>> 
>>> JWD: I'd change it to be configured to perform limited gateway functions when attached to external networks. 
>>>> — — — 
>>>> 
>>>> As I indicated, these are the big-picture issues that I have gotten around to thinking about enough to write up. I’m not through working through the document, but those were the ones that came to mind, and which seem imperative to resolve.
>>>> 
>>>> Best,
>>>> 
>>>> Thomas
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> manet mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>> 
>>>