Subject: [manet] draft-ietf-manet-olsrv2-multipath-08

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 23 May 2016 12:55:16 +0000

Was away last week, but managed to read through and red-ink the multipath draft. I have some more detailed notes on it, but here - and all I'll get to right now - are my headline comments.

Editorially, if this came from the usual OLSRv2 authors, we'd be doing some work to make it a better fit to the style of the rest of the OLSRv2 suite. It's not bad, it just could be a bit better. For example what are listed as Information Bases aren't, they are Protocol Sets. Together they might form a new Information Base, or be added to one. And more.

There are also various other points that I'd make. For example, it says not just for hop count. Given that OLSRv2 is not just for hop count, I wouldn't emphasis this. And I don't know why MP-OLSRv2 is indicated as being suitable especially for low data rate links.

Technically, my first issue is that OLSRv2 distributes a partial topology, so this is working at a disadvantage. OK, but this isn't discussed, and - with the one exception of picking MPRs - tradeoffs of the incompleteness of the topology and overheads aren't even discussed. For a start, TC messages contain advertised neighbours. Advertised neighbours must include all MPR selectors, but may include more neighbours - up to all neighbours. I would expect a discussion of this. (I'm also not actually sure how good the alternative MPR heuristics are, that's me needing to read and think more.)

I've been critical of AODVv2 underspecifying interaction with IP. I'm going to make the same criticism here, given the suggestion of a reactive multi-path route determination. I'm actually not keen on that idea at all, I think it needs more discussion. It also, I think, is broken in that there is no indication of how and when these paths are expired. This alone I think requires a new draft. And before that discussion on whether a reactive mechanism that OLSRv2 otherwise doesn't have is acceptable. (I don't think it is.)

I'm not as familiar as I should be with loose source routing. Given that this protocol allows routes of non-minimum metric, is there any possibility of the interaction of the two allowing looping, especially with different routers having possibly different views of the topology? Some sort of proof (which might already exist) would be a good idea here. Incidentally why does the multiplicative factor on route metrics (CUTOFF_RATIO) have to be strictly greater than one? One should work.

The description of the multipath Dijkstra doesn't really explain fp and fe. With the appendix one begins to get an idea, but the main text should not depend on an appendix in that way. And those are defined parameters, not an example.

I don't understand (I may have missed) how SR_TC_INTERVAL is used. But the description in 5.1 isn't clear. Why would we have separate TC messages? And why would MP be prepared to do anything ten times slower?

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: [email-masked]<mailto:[email-masked]>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Jiazi YI <[email-masked]>
Date: Tue, 24 May 2016 00:10:07 +0200

Hi Chris,

thanks very much for your comments. Please check my reply inline:

On Mon, May 23, 2016 at 2:55 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Was away last week, but managed to read through and red-ink the multipath
> draft. I have some more detailed notes on it, but here - and all I’ll get
> to right now - are my headline comments.
>
>
>
> Editorially, if this came from the usual OLSRv2 authors, we’d be doing
> some work to make it a better fit to the style of the rest of the OLSRv2
> suite. It’s not bad, it just could be a bit better. For example what are
> listed as Information Bases aren’t, they are Protocol Sets. Together they
> might form a new Information Base, or be added to one. And more.
>

As you might have noticed, we try to make the style fit to the
OLSRv2-related RFCs. If you have more specific comments, we would glad to
make it better. Of course, we will check the style by ourselves also.

>
>
> There are also various other points that I’d make. For example, it says
> not just for hop count. Given that OLSRv2 is not just for hop count, I
> wouldn’t emphasis this. And I don’t know why MP-OLSRv2 is indicated as
> being suitable especially for low data rate links.
>

Because the specification uses parallel paths, which can provide higher
aggregated throughput.

>
>
> Technically, my first issue is that OLSRv2 distributes a partial topology,
> so this is working at a disadvantage. OK, but this isn’t discussed, and -
> with the one exception of picking MPRs - tradeoffs of the incompleteness of
> the topology and overheads aren’t even discussed. For a start, TC messages
> contain advertised neighbours. Advertised neighbours must include all MPR
> selectors, but may include more neighbours - up to all neighbours. I would
> expect a discussion of this. (I’m also not actually sure how good the
> alternative MPR heuristics are, that’s me needing to read and think more.)
>

In a pure MP-OLSRv2 network, no modification is required regarding the MPR
selection. Because the routers choose MPRs independently, and the
MPR-selection is non-optimal, we can obtain multiple paths in most cases
thanks to the topology redundancy. This has been proven in both simulation
study and field tests with various node densities.

I don’t understand (I may have missed) how SR_TC_INTERVAL is used. But the
> description in 5.1 isn’t clear. Why would we have separate TC messages? And
> why would MP be prepared to do anything ten times slower?

This is to deal with the OLSRv2/MP-OLSRv2 mixed network. As we mentioned in
our previous post, an MP-OLSR router can be recognized as source-enabled
unless it generates a HELLO or TC message. So what we do 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.

>
>
> I’ve been critical of AODVv2 underspecifying interaction with IP. I’m
> going to make the same criticism here, given the suggestion of a reactive
> multi-path route determination. I’m actually not keen on that idea at all,
> I think it needs more discussion.
>

The MP-OLSR is a bit different from AODVv2 -- the route calculation is
local. It doesn't require DSR/AODV-like route discovery/route reply (which
can have long delay). Therefore, no buffer (or very little buffer) is
required: the packet is either sent out or dropped. I think there is no
need to go to details on how to trigger the route calculation, which is
implementation specific.
Then for the source routing part, it's just standard IP routing.

> It also, I think, is broken in that there is no indication of how and when
> these paths are expired. This alone I think requires a new draft.
>

In fact, in the previous revision (-06), there is a valid time field in the
multi-path routing set. But it's removed to match RFC7181-style based on
the comments received (because Routing Set in RFC7181 is not based on
timer-based expiration either). All the tuples in the Multi-path Routing
Set will be removed whenever there is need to update the OLSRv2 Routing
Set. This can make it more reactive to topology changes.
We will clarify it in the next revision.

> And before that discussion on whether a reactive mechanism that OLSRv2
> otherwise doesn’t have is acceptable. (I don’t think it is.)
>
>
Personally, I don't see why it's not acceptable. Here I just want to note
that this is an experimental draft. As far as I can see, if we have:

   - a clear specification
   - a mechanism that can bring potential performance benefit and won't
break existed networks
   - some simulation study and implementation that prove the idea actually
works and can be implemented (the implementation is even not mandatory to
standard track protocol -- although I think it's not a good policy)
   - people interested in the idea

we already have good reason to move ahead?

>
>
> I’m not as familiar as I should be with loose source routing. Given that
> this protocol allows routes of non-minimum metric, is there any possibility
> of the interaction of the two allowing looping, especially with different
> routers having possibly different views of the topology?
>

When loose source routing is used, the forwarding decision is based on the
forwarding table generated by OLSRv2. So if there is a loop, it's a loop in
OLSRv2 (which is possible, due to attacks or high dynamic topology).

> Some sort of proof (which might already exist) would be a good idea here.
> Incidentally why does the multiplicative factor on route metrics
> (CUTOFF_RATIO) have to be strictly greater than one? One should work.
>
>
>
> The description of the multipath Dijkstra doesn’t really explain fp and
> fe. With the appendix one begins to get an idea, but the main text should
> not depend on an appendix in that way. And those are defined parameters,
> not an example.
>

will clarify the description.

and thanks again for the comments.

regards

Jiazi

>
>
>
>
> *-- *
>
>
>
>
> *Christopher Dearlove Senior Principal Engineer BAE Systems Applied
> Intelligence Laboratories *
> *__________________________________________________________________________
> *
> *T*:  +44 (0)1245 242194  |  *E: [email-masked]
>
> www.baesystems.com/ai
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 24 May 2016 15:39:10 +0000

Comments CMD> below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jiazi YI
Sent: 23 May 2016 23:10
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] draft-ietf-manet-olsrv2-multipath-08

*** WARNING ***
This message originates from outside our organisation, either from an external partner or the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
For information regarding Red Flags that you can look out for in emails you receive, click here<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Red%20Flags.pdf>.
If you feel the email is suspicious, please follow this process<http://intranet.ent.baesystems.com/howwework/security/spotlights/Documents/Dealing%20With%20Suspicious%20Emails.pdf>.
Hi Chris,

On Mon, May 23, 2016 at 2:55 PM, Dearlove, Christopher (UK) <[email-masked]<mailto:[email-masked]>> wrote:
Was away last week, but managed to read through and red-ink the multipath draft. I have some more detailed notes on it, but here - and all I’ll get to right now - are my headline comments.

Editorially, if this came from the usual OLSRv2 authors, we’d be doing some work to make it a better fit to the style of the rest of the OLSRv2 suite. It’s not bad, it just could be a bit better. For example what are listed as Information Bases aren’t, they are Protocol Sets. Together they might form a new Information Base, or be added to one. And more.

As you might have noticed, we try to make the style fit to the OLSRv2-related RFCs. If you have more specific comments, we would glad to make it better. Of course, we will check the style by ourselves also.

CMD> Later for this one.

There are also various other points that I’d make. For example, it says not just for hop count. Given that OLSRv2 is not just for hop count, I wouldn’t emphasis this. And I don’t know why MP-OLSRv2 is indicated as being suitable especially for low data rate links.

Because the specification uses parallel paths, which can provide higher aggregated throughput.

CMD> Not convinced by that argument. You’re going to gain a factor of maybe two or three at most (and only if the network is differentially loaded - at worst you lose, not gain) whereas when I see low data rate paths, that can vary by orders of magnitude.

Technically, my first issue is that OLSRv2 distributes a partial topology, so this is working at a disadvantage. OK, but this isn’t discussed, and - with the one exception of picking MPRs - tradeoffs of the incompleteness of the topology and overheads aren’t even discussed. For a start, TC messages contain advertised neighbours. Advertised neighbours must include all MPR selectors, but may include more neighbours - up to all neighbours. I would expect a discussion of this. (I’m also not actually sure how good the alternative MPR heuristics are, that’s me needing to read and think more.)

In a pure MP-OLSRv2 network, no modification is required regarding the MPR selection. Because the routers choose MPRs independently, and the MPR-selection is non-optimal, we can obtain multiple paths in most cases thanks to the topology redundancy. This has been proven in both simulation study and field tests with various node densities.

CMD> References? And even if so, I would expect a discussion of the subject. And that still doesn’t address the advertised neighbours issue.

I don’t understand (I may have missed) how SR_TC_INTERVAL is used. But the description in 5.1 isn’t clear. Why would we have separate TC messages? And why would MP be prepared to do anything ten times slower?

This is to deal with the OLSRv2/MP-OLSRv2 mixed network. As we mentioned in our previous post, an MP-OLSR router can be recognized as source-enabled unless it generates a HELLO or TC message. So what we do 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.

 CMD> Not happy with that. That assumes in effect that multipath routes are more stable - because that’d what sending ten times less often means. And if you are sending ten times less often, that will require ten times the validity time. Which will cause those links to hang around longer, and will be used by non-MP routers in the same way. (It’s even possible that a compliant implementation might choose to preferentially use links with longer validity times, all else being equal. I’ve never tried that, but it’s an obvious possibility in some heterogeneous networks.) If ten times longer is OK for some links, why not all? I think there’s a problem here - how much work with highly mobile mixed networks has been done?

I’ve been critical of AODVv2 underspecifying interaction with IP. I’m going to make the same criticism here, given the suggestion of a reactive multi-path route determination. I’m actually not keen on that idea at all, I think it needs more discussion.

The MP-OLSR is a bit different from AODVv2 -- the route calculation is local. It doesn't require DSR/AODV-like route discovery/route reply (which can have long delay). Therefore, no buffer (or very little buffer) is required: the packet is either sent out or dropped. I think there is no need to go to details on how to trigger the route calculation, which is implementation specific.
Then for the source routing part, it's just standard IP routing.

CMD> No, it’s introduced something new to OLSRv2, the need to be triggered by IP. Somebody (Henning?) criticising AODVv2 made the observation this isn’t actually easy to do. And it’s new to OLSRv2, and unnecessary. I’m strongly against this as a specification.

Note that as this is local, you could choose to do this locally if you wanted to and still interoperate. I wouldn’t be as set against this as an option in a highly resource limited router. But as the only specification, that must be done this way? No. I’m against this draft proceeding with this as the only option.

It also, I think, is broken in that there is no indication of how and when these paths are expired. This alone I think requires a new draft.

In fact, in the previous revision (-06), there is a valid time field in the multi-path routing set. But it's removed to match RFC7181-style based on the comments received (because Routing Set in RFC7181 is not based on timer-based expiration either). All the tuples in the Multi-path Routing Set will be removed whenever there is need to update the OLSRv2 Routing Set. This can make it more reactive to topology changes.
We will clarify it in the next revision.

Yes, it needs clarification however the set is created, proactively or reactively.

But there’s more. If proactive, when it expires, it actually is replaced. (The Routing Set in OLSRv2 is described as recalculated, but of course intelligent differential update is not just allowed but a good idea.) But reactive? Are you going to remove it and re-trigger its calculation from IP? Or how otherwise to decide when to stop recalculating it?
And before that discussion on whether a reactive mechanism that OLSRv2 otherwise doesn’t have is acceptable. (I don’t think it is.)

Personally, I don't see why it's not acceptable. Here I just want to note that this is an experimental draft. As far as I can see, if we have:

   - a clear specification
   - a mechanism that can bring potential performance benefit and won't break existed networks
   - some simulation study and implementation that prove the idea actually works and can be implemented (the implementation is even not mandatory to standard track protocol -- although I think it's not a good policy)
   - people interested in the idea

CMD> I don’t agree. A specification fills a space. A poor specification is hard to push aside if a better one comes along. And I think a mandatory reactive mechanism in a multipath OLSrv2 is poor. And it’s easily addressed, define how you calculate it, make the norm that you maintain (as the normal Routing Set) but (if you want to) allow a reactive alternative (where you can send rather than drop - I see no reason to drop - using the standard Routing Set in the interim.

I’m not as familiar as I should be with loose source routing. Given that this protocol allows routes of non-minimum metric, is there any possibility of the interaction of the two allowing looping, especially with different routers having possibly different views of the topology?

When loose source routing is used, the forwarding decision is based on the forwarding table generated by OLSRv2. So if there is a loop, it's a loop in OLSRv2 (which is possible, due to attacks or high dynamic topology).

CMD> That’s one of those non-proof arguments that I’m not sure of. I can’t see an infinite loop, but the slack in the process means suppose you have A - B - C - D - E loosely routed, and now you need to go from B to C. Is it possible for D to be on the shortest path from B to C?

Some sort of proof (which might already exist) would be a good idea here. Incidentally why does the multiplicative factor on route metrics (CUTOFF_RATIO) have to be strictly greater than one? One should work.

The description of the multipath Dijkstra doesn’t really explain fp and fe. With the appendix one begins to get an idea, but the main text should not depend on an appendix in that way. And those are defined parameters, not an example.

regards

Jiazi

T:  +44 (0)1245 242194<tel:%2B44%20%280%291245%20242194>  |  E: [email-masked]<mailto:[email-masked]>

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Jiazi YI <[email-masked]>
Date: Wed, 25 May 2016 00:55:14 +0200

Hi Chris,

Please check the reply JY> below:

> CMD> Not convinced by that argument. You’re going to gain a factor of
> maybe two or three at most (and only if the network is differentially
> loaded - at worst you lose, not gain) whereas when I see low data rate
> paths, that can vary by orders of magnitude.
>

JY> The metric of the paths are considered in the path calculation. We can
expect that the multiple path obtained will not vary that much, and
certainly not by orders of magnitude.
About differential loading -- sure. It's written as part of the
"experiments to be conducted":

DRAFT>      In
      some scenarios, weighted scheduling (over different paths) can be
considered: for
      example, the paths with lower metrics (i.e., higher quality) can
      transfer more datagrams compared to paths with higher metrics.

> CMD> References? And even if so, I would expect a discussion of the
> subject. And that still doesn’t address the advertised neighbours issue.
>

*Some papers from co-authors of the draft:*

[1] Multipath optimized link state routing for mobile ad hoc networks
J Yi, A Adnane, S David, B Parrein
Ad Hoc Networks 9 (1), 28-47
https://hal.archives-ouvertes.fr/hal-00521719/file/MPOLSR_2.pdf

[2] Simulation and performance analysis of MP-OLSR for mobile ad hoc
networks
J Yi, E Cizeron, S Hamma, B Parrein
Wireless Communications and Networking Conference, 2008. IEEE WCNC 2008.
http://arxiv.org/pdf/0902.4779.pdf

[3] Multipath OLSR: simulation and testbed
J Yi, S David, HA Adnane, B Parrein, X Lecourtier
5th OLSR Interop/Workshop
http://hal.univ-nantes.fr/file/index/docid/424891/filename/Multipath_OLSR_Simulation_and_Testbed.pdf

[4] QOS ENHANCED HYBRID MULTIPATH ROUTING PROTOCOL FOR MOBILE ADHOC NETWORKS
J Yi, B Parrein, D Radu
Wireless Personal Multimedia Communications (WPMC), 2011 14th International
Symposium on
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6081479&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6081479

*And from other 3rd party researchers, who used tested MP-OLSR and
developed extensions based on MP-OLSR:*

Experimental performance comparison of single-path and multipath routing in
VANETs
2014 IEEE Global Information Infrastructure and Networking Symposium (GIIS)
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6934283

QOS ENHANCED HYBRID MULTIPATH ROUTING PROTOCOL FOR MOBILE ADHOC NETWORKS
International Journal of Distributed and Parallel Systems3.6 (Nov 2012):
89-105.
http://airccse.org/journal/ijdps/papers/3612ijdps08.pdf

A multipath routing strategy to prevent flooding disruption attacks in link
state routing protocols for MANETs
Journal of Network and Computer Applications
Volume 36, Issue 2, March 2013, Pages 744–755
http://www.sciencedirect.com/science/article/pii/S1084804512002603

Performance Evaluation of MBA-OLSR Routing Protocol for MANETs
Waheb A. Jabbar, Mahamod Ismail, and Rosdiadee Nordin
Journal of Computer Networks and Communications
Volume 2014 (2014), Article ID 951638
http://www.hindawi.com/journals/jcnc/2014/951638/abs/

An enhanced MP-OLSR protocol for MANETs
A Boushaba, A Benabbou, R Benabbou
2014 International Conference on Next Generation Networks and Services
(NGNS)
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6990231&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6990231

There are about 200~ citations of [1][2][3][4], so above is far away from a
complete list of research related to MP-OLSR. Generally speaking,
tests/simulations have been performed from very sparse networks (such
4-node network) to dense and mobile networks. And no issue is reported
regarding exploring multiple paths because of OLSR's partial topology.

> This is to deal with the OLSRv2/MP-OLSRv2 mixed network. As we mentioned
> in our previous post, an MP-OLSR router can be recognized as source-enabled
>  CMD> Not happy with that. That assumes in effect that multipath routes
> are more stable - because that’d what sending ten times less often means.
> And if you are sending ten times less often, that will require ten times
> the validity time. Which will cause those links to hang around longer, and
> will be used by non-MP routers in the same way. (It’s even possible that a
> compliant implementation might choose to preferentially use links with
> longer validity times, all else being equal. I’ve never tried that, but
> it’s an obvious possibility in some heterogeneous networks.) If ten times
> longer is OK for some links, why not all? I think there’s a problem here -
> how much work with highly mobile mixed networks has been done?
>

JY> Let me clarify:
The assumption is not multi-path routes are more stable, but simply
multi-path routers won't change from a multipath enabled router to
multipath disabled router (or very rare).
The multipath enabled routers generate TC messages as ordinary OLSRv2
routers. *Additionally*, if those routers didn't generate TC message in
certain interval (the longer SR_TC_INTERVAL), those MP-OLSR routers are
required to generate TC messages.
The latter is more for declaring: hey, I'm multipath enabled!
The validity time SR_OLSR_HOLD_TIME is related to identifying the router is
multipath enabled or not -- it has nothing to do with link stability.

> CMD> No, it’s introduced something new to OLSRv2, the need to be triggered
> by IP. Somebody (Henning?) criticising AODVv2 made the observation this
> isn’t actually easy to do. And it’s new to OLSRv2, and unnecessary. I’m
> strongly against this as a specification.
>
>
>
> Note that as this is local, you could choose to do this locally if you
> wanted to and still interoperate. I wouldn’t be as set against this as an
> option in a highly resource limited router. But as the only specification,
> that must be done this way? No. I’m against this draft proceeding with this
> as the only option.
>

JY> Although we haven't found proactive algorithms to solve the multipath
issue yet, we can make the reactive part optional for further
extensibility.

> In fact, in the previous revision (-06), there is a valid time field in
> the multi-path routing set. But it's removed to match RFC7181-style based
> on the comments received (because Routing Set in RFC7181 is not based on
> But there’s more. If proactive, when it expires, it actually is replaced.
> (The Routing Set in OLSRv2 is described as recalculated, but of course
> intelligent differential update is not just allowed but a good idea.) But
> reactive? Are you going to remove it and re-trigger its calculation from
> IP? Or how otherwise to decide when to stop recalculating it?
>

JY> If reactive, it's simply re-trigger the calculation from IP "on
demand".

> CMD> I don’t agree. A specification fills a space. A poor specification is
> hard to push aside if a better one comes along. And I think a mandatory
> reactive mechanism in a multipath OLSrv2 is poor. And it’s easily
> addressed, define how you calculate it, make the norm that you maintain (as
> the normal Routing Set) but (if you want to) allow a reactive alternative
> (where you can send rather than drop - I see no reason to drop - using the
> standard Routing Set in the interim.
>

JY> we agree to keep the specification as extendable as possible. And as
mentioned above, we can make the reactive mechanism optional.

> CMD> That’s one of those non-proof arguments that I’m not sure of. I can’t
> see an infinite loop, but the slack in the process means suppose you have A
> - B - C - D - E loosely routed, and now you need to go from B to C. Is it
> possible for D to be on the shortest path from B to C?
>

JY>
It should be very rare. I can *imagine* that might happen for IPv4
networks, if:

   - The network is big so that loose source routing must be used (more
than 10 hops); AND
   - The the network is highly dynamic that A's local topology map is
staled; AND
   - D accidentally moves to the shortest path from B to C.

But I think it won't break anything, but brings temporary performance
penalty:
   - The packet being forwarded will travel more hops, but it can get to
the destination eventually.
   - after the correct topology information is propagated to router A, the
problem will disappear automatically.

This can also be mitigated by choosing the "key" routers in the loose
source routing header carefully: if the routers are more stable and have
higher willingness in forwarding the packets, they should be chosen as
"key" routers, as specified in the document.

cheers

Jiazi