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

[Stan Ratliff <[e-mail]>]

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]