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

[Jiazi YI <[e-mail]>]

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