Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-07.txt

[Jiazi YI <[e-mail]>]

Hi,

The coauthors of olsrv2-multipath believe that the issues raised on the
draft have been addressed (some nits have been found after the submission
of -07, which will be improved in -08).

Although we know that having the second WGLC is a good way to trigger
comments :) , it's still appreciated that we can have some feedbacks on the
solution that we proposed before the next WGLC.

For your convenience, if you want to have an idea about how the major
issues are addressed and clarified, taking a look at the post below should
be enough.

regards

Jiazi


On Wed, Jan 20, 2016 at 11:45 PM, Jiazi YI <[e-mail]> wrote:

> Dear all,
>
> As you has seen, a new revision of the olsrv2-multipath draft was just
> submitted.
> Lots of modifications have been made based on Ulrich and Chris' comments
> -- thanks very much!
>
> For your convenience, here is a reply to the comments, explaining how they
> are updated in the new draft.
>
> Two major issues raised:
>
> *1. Issues related to Source Routing*
>
> Both Chris and Ulrich raised their concern on the source routing. The
> MP-OLSR extension uses standard IP source routing, which is clarified and
> improved in the new revision of the draft.
> For IPv4 networks, the datagram is forwarded using RFC 791 IPv4 loose
> source routing. This is due to the limitation of the IPv4 header length. If
> the number of intermediate routers exceed the capacity of the IP header,
> loose source routing is applied.
> For IPv6 networks, IPv6 strict source routing based on RFC6554 is used,
> because IPv6 header has no strict limit on the length and RFC6554 supports
> address compression. A difference it would make compared to loose source
> routing is when they are non-source-routing routers in the network: those
> routers won't be taken into account when calculating multiple paths. This
> will impact the performance of multipath routing, which I'll discuss in
> detail in the issues related to interoperability.
> In the new revision, the use of IP source routing is clarified.
>
> *2. Interoperability with OLSRv2 / MPR selection*
>
> Only a new message TLV is added to TC/HELLO messages. All the information
> bases of OLSRv2 are kept and used in MP-OLSRv2. In fact, MP-OLSRv2 is not
> designed to replace OLSRv2, but more as an extension to improve the
> performance of certain applications. If necessary, MP-OLSRv2 will fall back
> to OLSRv2. In the new revision, a new CUTOFF_RATIO is used: when the
> multiple paths to be obtained are worse than the cutoff value, the router
> will fall back to OLSRv2 automatically.
>
> Specifically, to answer Thomas' questions:
>
> "Will the presence of an OLSRv2 router in an OLSRv2-MP network break the
>> -MP network"?
>>
>
> No
>
>
>> "Will the presence of an OLSRv2-MP router in an OLSRv2 network break the
>> OLSRv2 network"?
>>
>
> No
>
>
>> "Will an OLSRv2-MP router be able to function in an OLSRv2 network"?
>>
>
> Yes
>
>
>> "Will an OLSRv2 router be able to function in an OLSRv2-MP network"?
>
>
> Yes.
>
>
>> And then, of course, what happens if it's not "a single" but "a bunch of"
>> ....
>
>
> Yes.
> One case that need to pay attention is that, if there are too many OLSRv2
> routers in the network, the multipath routing won't work effectively -- it
> will degrade (IPv4 loose source routing case) or fall back (IPv6 strict
> loose source routing case) to single path routing. But all those won't
> break the network.
>
> Chris mentioned an issue related to MPR selection. Generally speaking, as
> OLSRv2 uses a reduced topology graph (in terms of both vertex and edges) ,
> not every MP-OLSR router can be recognized as source-routing enabled,
> unless it generates a HELLO or TC message. The solution that we proposed is:
>    - MP-OLSR enabled routers MUST generate TC messages even it's not
> required to do so according to normal OLSR process, but with longer
> interval. This is because the change from MP-OLSR enabled to OLSR-only
> router is very rare compared to topology changes. The corresponding
> SR_OLSR_HOLD_TIME will be set to longer value also.
>     - During routing MPR selection, an MP-OLSR enabled router SHOULD be
> firstly considered. The number of MP-OLSR enabled MPRs MUST be equal or
> greater than NUMBER_OF_PATHS, providing there are enough MP-OLSR symmetric
> neighbors. Or else, all the MP-OLSR routers are selected as MPR.
> ----------
> Steps above can have MP-OLSR enabled routers and links be discovered as
> much as possible, while retaining the benefits of OLSRv2 topology
> reduction. In the worst case, we fall back to single path OLSRv2, and the
> network won't break.
>
> Chris also mentioned the interoperability between the multipath extension
> and the multi-topology extension. As far as I can see, there is no issue
> for them working together. In fact, it might even interesting to build
> mutiple paths using the multi-topology information, which is added as an
> item of the "experimental points".
>
> ===========================
>
> Other questions and clarifications:
>
>
>> o NUMBER_OF_PATHS: Is this a constant? Can it change during router
>> operations? If so what are the constraints, and how does the change
>> impact existing routes? Is this a constant per router, or could I
>> have, say, 3 paths for a certain destination that I need a lot, but
>> only 1 for others?
>
>
> Generally speaking, there is no strict constraints on this value.
> Different routers using different values, or a router changing it won't
> impact the interoperability.
>
> o MAX_SRC_HOPS: same as above. (constant? constraints?)
>> Do these two parameters have to be negotiated between all routers or are
>> there no interop problems if routers use different values in the network?
>
>
> The don't have to be negotiated. But for better support of IPv6 source
> routing, a the MAX_SRC_HOPS must be set to 0 (see the consideration of IP
> source routing).
>
> o fp/fe: This is a function (of what?). I am not sure I understand
>> why this is listed under a section Parameters. How can I implement this?
>
> As it's more algorithm specific, it's now moved to the section of the
> algorithm.
>
>> - section 7.2 Multi-path Routing Set:
>> How does this interact with the Routing Set in OLSRv2? Is this used
>> instead?
>
>
>  There is no direct interact with the routing set in OLSRv2, and doesn't
> replace OLSRv2's Routing Set.
>
> - "PT_cost -   the cost of the path to the destination"
>> Cost in what? Hops? Does this support metrics other than hop count?
>
> ...
>
>> 7.2 has costs of paths. If this is OLSRv2 path metric, use that term. If
>> not, why not?
>
>
> As an extension to OLSRv2, MP-OLSR uses the same metric type as OLSRv2.
> For consistency, we now use "metric", rather than "cost" in the draft.
> The example in the appendix is also updated using an arbitrary metric.
>
> - Section 8.2.: SR_OLSR_HOLD_TIME
>> What is the relationship with other OLSRv2 information sets? Could
>> there be a situation where I still have an SR-OLSR Router Tuple, but
>> the same destination is not present anymore in other OLSRv2 sets
>> (Routing Set, Topology Set etc). Since the hold_time can be chosen
>> independently, that seems possible.
>
> ...
>
> Does the MR_valid_time have to be the same as the timeout on
>> the Routing Set?
>
>
> The following updates are made:
>
> For the SR_OLSR_HOLD_TIME, it's set to 3*SR_TC_INTERVAL, in which
> SR_TC_INATERVAL is 10*TC_INTERVAL. The SR-OLSRv2 Router Set only servers
> for identifying if a router is source-routing enabled or not, which won't
> be changed frequently.
>
> For the tuples in Multi-path Routing set, they won't subject to
> timer-based expiration (like the OLSRv2 Routing Set). Instead, all the
> tuple will be removed whenever there is need to update the OLSRv2 Routing
> Set -- and the new tuples of Multi-path routing set will be recalculated
> on-demand. This can make it more reactive to the topology changes.
>
> - "   o  If the length of the path (n) is greater than MAX_SRC_HOPS, only
>>       the key routers in the path are kept.  By default, the key routers
>>       are uniformly chosen in the path."
>> What are key routers? How does this work?
>>    o  The routers with higher priority (such as higher routing
>>       willingness defined in [RFC7181]) are preferred.
>> How?
>
> Generally speaking, routers with greater capacity (such as higher
> transmission power, longer battery life, etc) and greater willingness in
> forwarding packets are preferred.
> Of course, those information is not always available. By default, the
> "key" routers are chosen uniformly in the path.
> We clarified it in the new revision.
>
> Section 1.1, first list, point 3. I don’t see this as a motivation for
>> multiple path routing. If routers are not to be used, that’s an issue for
>> single path routing too.
>
> The point 3 is: Certain scenarios require some routers must (or must not)
> be used.
>
> It's a motivation for source routing.
>
> Appendix, I haven’t studied, but I’d like to see an example not using hop
>> count. There’s a lot at the end that raises more questions than it answers.
>> Delay isn’t just about number of hops (and 50 is an exceptional case). If
>> delay matters, it should be part of your metric and handled that way.
>
>
> fixed by using an arbitrary metric.
>
> - Section 8.4: This doesn't use the information bases that have been
>> defined before. How can I implement this using the existing
>> information form the protocol? (without all that abstraction)
>
>
> Now it's separated into two subsection, one for requirements of the
> algorithm, and one for the default multipath dijkstra algorithm. The
> connection with the information bases is also built.
>
> security consideration section
>
>
> The security consideration section is updated a bit. Compared to OLSRv2,
> the vulnerability mainly comes from the source routing. Is it adequate?
> Let's leave it as an open question for the moment.
>
> Thanks again for your valuable comments. I'm looking forward to your
> further suggestions.
>
> regards
>
> Jiazi
>
> ---------- Forwarded message ----------
> From: <[e-mail]>
> Date: Wed, Jan 20, 2016 at 11:29 PM
> Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-07.txt
> To: [e-mail]
> Cc: [e-mail]
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Mobile Ad-hoc Networks Working Group of
> the IETF.
>
>         Title           : Multi-path Extension for the Optimized Link
> State Routing Protocol version 2 (OLSRv2)
>         Authors         : Jiazi Yi
>                           Benoit Parrein
>         Filename        : draft-ietf-manet-olsrv2-multipath-07.txt
>         Pages           : 21
>         Date            : 2016-01-20
>
> Abstract:
>    This document specifies a multi-path extension for the Optimized Link
>    State Routing Protocol version 2 (OLSRv2) to discover multiple
>    disjoint paths, so as to improve reliability of the OLSRv2 protocol.
>    The interoperability with OLSRv2 is retained.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>