Re: [manet] draft-ietf-manet-olsrv2-multipath-06

[Christopher Dearlove <[e-mail]>]

That sounds like the right plan to me.

--  
Christopher Dearlove
[e-mail] (iPhone)
[e-mail] (home)

> On 20 Oct 2015, at 15:56, Stan Ratliff <[e-mail]> wrote:
> 
> All, 
> 
> Based on this discussion, and an email or two between myself and Justin and Ulrich, here's the plan going forward: 
> 
> I've just moved the document back to "WG Document" state. I think there is general agreement that there are issues to be addressed, and that the doc isn't yet ready for publication. We have a good discussion going here on the list; hopefully that discussion will lead to a resolution on all issues. At that point, we can reissue WGLC when the WG consensus indicates that the doc is ready. 
> 
> Other opinions? Questions?  Flames? 
> 
> Regards,
> Stan
> 
> 
>> On Tue, Oct 20, 2015 at 10:25 AM, Thomas Clausen <[e-mail]> wrote:
>> Just two quick points...
>> 
>>> On 20 Oct 2015, at 02:02, Jiazi YI <[e-mail]> wrote:
>>> 
>>> Hi, 
>>>  
>>>> 
>>>> Sorting out MPRs and interworking can't be fixed with just a SHOULD. There isn't even a proof on the table that making it a MUST works. This is not good enough to proceed.
>>>> 
>>>> No, creating a TC is anything but mandatory. It's mandatory under certain conditions, which may not apply.
>> 
>> Specifically, a TC is mandatory only if having a non-empty MPR-selector set, or a non-empty Attached Network set -- or, having recently had non-empty such sets (in which case empty TCs are mandated for a bit to "purge stale information").
>> 
>> A case where an OLSRv2-router will not send TCs would, for example, be with MPR_WILLING == WILL_NEVER. And a case where it likely would not would be a router with WILL_NEVER+1, in a dense network.
>> 
>>>> Again, this misunderstanding is fundamental to whether the protocol will interwork with basic OLSRv2.
>>> 
>>> The point I want to make is:
>>>    - The SOURCE_ROUTE TLV are sent over both HELLO and TC messages. 
>>>    - I'm skeptical to making it a MUST, because even we don't consider it at all, it won't bring any negative impact to the network. Although a router with this extension will find less SOURCE_ROUTE enabled routers in that case, it can still work perfectly with other OLSRv2-only routers like a normal OLSRv2 router. 
>> 
>> Gotta consider this, at least, these ways:
>> 
>> "Will the presence of an OLSRv2 router in an OLSRv2-MP network break the -MP network"? 
>> 
>> "Will the presence of an OLSRv2-MP router in an OLSRv2 network break the OLSRv2 network"?
>> 
>> "Will an OLSRv2-MP router be able to function in an OLSRv2 network"?
>> 
>> "Will an OLSRv2 router be able to function in an OLSRv2-MP network"?
>> 
>> And then, of course, what happens if it's not "a single" but "a bunch of" ....
>> 
>> Thomas
>> 
>>>> I haven't had time to consider the source routing. But if it's being done by IP, just say so and don't confuse matters here.
>>> 
>>> Agree. 
>>>  
>>>> This draft is, I'm afraid, not in a suitable state for a WGLC. It needs to go back, have some major changes made, and re-enter pre-WGLC discussion.
>>> 
>>> The authors are, of course, willing to discuss related issues with the WG and have them appropriately resolved. 
>>>  
>>>> 
>>>> (A point I've not previously made is that we have multitopology now out of the IESG and heading to be an RFC soon. I'd not be happy with this draft if incompatible with that, also a discussion worth having.)
>>> 
>>> I don't see the how the multipath draft would be incompatible with the multi-topology draft. 
>>> In fact, those two drafts are two different approaches to solve different problems. This olsrv2-multipath draft tries to make use of multiple parallel paths to send packets. It can even make use of the multiple topology to build multiple paths -- this is, of course, not tested yet. But we wrote it as a possible experiment to do in the "Motivation and Experiments to Be Conducted" section. 
>>> 
>>> best
>>> 
>>> Jiazi
>> [snip]
>