Subject: Re: [Roll] [manet] Working group re-charter ideas (meeting summary)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Apr 2015 07:53:20 +0000

I disagree with the terms in your mail pretty much as much as I agree with your designs, Juliusz...

There are literally hundreds of papers that reference RPL, from Google scholar.

There are deployed networks of thousands of nodes, and they behave even better than expected.

But what hurts even more is your misunderstanding of the technology:

RPL inherits from the same roots as Babel, DSDV and DUAL/EIGRP, though RPL adds technology to cope with harsher constraints and multiple types of links that neither Babel nor any of the common ancestry has.

You do not seem to have fully realized how similar Babel is to RPL. Consider this: RPL's sequenced advertisement is called the iteration of an instance; so the process of microloop avoidance in Babel is effectively the same as what RPL calls a global recovery. Both protocols inherit DUAL's feasibility condition. But RPL adds the capability to make local repair which provides a service of freezing akin to the the diffusion algorithm but adapted to LLN and MANET. 

Even more, RPL adds a capability to stretch the rules, and a capability to delay the repairs so as to reduce the control overhead in Lower Power and mobile use cases. To enable these - arguably optional - features, RPL adds the capability to instrument packets beyond hop limit to detect loops and trigger repairs.

Saying the RPL does not work in MANET environment is a gross misrepresentation. RPL derives from early MANEMO work, which was MANET for NEMO, and it was fully demonstrated in that space. RPL works fine in MANET for the same reasons Babel will. And RPL probably works a lot better because it can:
- cope with all sorts of radios with objective functions 
- allow a trade off of routing stretch vs control plane overhead 
- address memory constraints 
- natively support interconnection with LLNs
- freeze a zone and perform local repairs
- support multiple exits. RPL's instances avoid the need for source/destination routing altogether

All in all I remain to be convinced that Babel is much, much, anything. In my view, it is a great approach but I will need more details to find novelty vs. an existing proposed std RFC that is RFC 6550. You will need to demonstrate that novelty to get a new work approved. We went through that in the first phase of ROLL. And I would be interested in bringing back that novelty in RPL.

On the side there are multiple implementations of RPL. Some on constrained devices. 2 on Linux, one of them at least running on OpenWRT (Unstrung). We even have one running on various network OS'es that Cisco ships in its big irons, and applicable from gigE to virtual links.

All in all, there's a lot of misconceptions that a discussion over a whiteboard could help clarify. I'm certainly willing to learn more from Babel and I trust that you'd need some catching up on RPL before you can discuss it decently, which sadly was not the case in this mail.

I would be glad to meet anytime. We are almost next door...

Cheers,

Pascal

Le 1 avr. 2015 à 23:41, Juliusz Chroboczek <[email-masked]> a écrit :

>> Any contribution you'd want to make to ROLL? This is probably the place
>> where the ideas you defend in Babel were most successful...
> 
> I hope you are not comparing RPL's proactive subset to Babel.  Babel is
> a much, much more refined and complete protocol.
> 
> Which is okay, since RPL's proactive subset is designed to work in
> a stable network with a single DODAG.  Babel is aimed at a completely
> different space -- which is why it has redundant routing tables, attempts
> stability in the presence of variable metrics, has strong loop avoidance
> properties, and includes blackhole resolution.
> 
> By the way -- I've tried to find experimental data on RPL, and couldn't
> find any (perhaps I haven't tried hard enough).  Could you send me some
> references, perhaps by private mail?
> 
> -- Juliusz

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Thu, 2 Apr 2015 08:30:19 +0000

Hi Juliusz,

Just chiming in here … since indeed you may want to have a deeper look into the several RFC specifying RPL.
Furthermore, beyond novelty, I would stress the fact that RPL has been deployed in a NUMBER of networks, 
at large scale (order of magnitude is millions) and showed outstanding results in the field, remember what the
IETF thinks about “running code” …

Thanks.

JP.

> On Apr 2, 2015, at 9:53 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Apr 2015 14:55:24 +0200

Thanks for your answer, Pascal.

> There are literally hundreds of papers that reference RPL,

Indeed.  But I've made a half-serious attempt at a bibliography search,
and couldn't find anything to satisfy my thirst for experimental data,
especially for the proactive subset.  Could you please give me a reference?

> so the process of microloop avoidance in Babel is effectively the same
> as what RPL calls a global recovery. Both protocols inherit DUAL's
> feasibility condition.

My perhaps mistaken understanding is that RPL uses a more primitive
version of DSDV's feasibility condition (without the even-odd mechanism
that avoids loops after a retraction).  If RPL uses DUAL feasibility, then
I completely fail to see the data structure that keeps the necessary
history (the equivalent of Babel's source table).

(Which makes sense for RPL -- you certainly don't want to multiply the
data structures being held in a sensor.  Babel and RPL play in different
spaces, right?)

> But RPL adds the capability to make local repair which provides
> a service of freezing akin to the the diffusion algorithm but adapted to
> LLN and MANET.

Again, I may be confused, but I think the local repair mechanism is not
specified in the RFC.  There's an example mechanism given in Section 3.7.2,
but that example is prone to loops in the presence of packet loss.

As what RPL calls a "global repair", all I could find in the RFC is

   A DODAG root institutes a global repair operation by incrementing the
   DODAGVersionNumber.  This initiates a new DODAG Version.

However, there's nothing I see to say when a root decides to trigger
a global repair (except for some vague mention of periodic updates, which
the DSDV experiment has shown are not a good idea).  This is very much
unlike Babel (different spaces, remember?)  which has a provably complete
reactive mechanism for triggering seqno updates.

> Even more, RPL adds a capability to stretch the rules, and a capability to
> delay the repairs so as to reduce the control overhead in Lower Power and
> mobile use cases.

Yes.  That's probably a very good feature in the space where RPL plays.
Which is different from the space that Babel aims for.

> All in all I remain to be convinced that Babel is much, much, anything.

That citation belongs on the conclusion slide of the next talk I give ;-)

-- Juliusz

---

From: Yvonne-Anne Pignolet <[email-masked]>
Date: Thu, 2 Apr 2015 13:11:59 +0000

Hi Juliusz

Some papers dealing with the RPL repair and loop avoidance mechanisms (and exlaining them) are for example

- A Study of the RPL Repair Process Using ContikiRPL, http://link.springer.com/chapter/10.1007%2F978-3-642-30633-4_8

- Efficiency of the RPL repair mechanisms for Low Power and Lossy Networks, http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6906339&url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel7%2F6895209%2F6906315%2F06906339.pdf%3Farnumber%3D6906339

- Doing it right - Recommendations for RPL in PLC-based networks for the Smart Grid, http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=7007688

- Recipes for faster failure recovery in Smart Grid communication networks, http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=7007654&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D7007654

Regards
Yvonne-Anne

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of Juliusz Chroboczek
Sent: Donnerstag, 2. April 2015 14:55
To: Pascal Thubert (pthubert)
Cc: ROLL WG; [email-masked]
Subject: [Roll] Understanding RPL [was: Working group re-charter ideas]

> There are literally hundreds of papers that reference RPL,

Indeed.  But I've made a half-serious attempt at a bibliography search, and couldn't find anything to satisfy my thirst for experimental data, especially for the proactive subset.  Could you please give me a reference?

> as what RPL calls a global recovery. Both protocols inherit DUAL's 

My perhaps mistaken understanding is that RPL uses a more primitive version of DSDV's feasibility condition (without the even-odd mechanism that avoids loops after a retraction).  If RPL uses DUAL feasibility, then I completely fail to see the data structure that keeps the necessary history (the equivalent of Babel's source table).

(Which makes sense for RPL -- you certainly don't want to multiply the data structures being held in a sensor.  Babel and RPL play in different spaces, right?)

> But RPL adds the capability to make local repair which provides a 
> service of freezing akin to the the diffusion algorithm but adapted to 
> LLN and MANET.

Again, I may be confused, but I think the local repair mechanism is not specified in the RFC.  There's an example mechanism given in Section 3.7.2, but that example is prone to loops in the presence of packet loss.

However, there's nothing I see to say when a root decides to trigger a global repair (except for some vague mention of periodic updates, which the DSDV experiment has shown are not a good idea).  This is very much unlike Babel (different spaces, remember?)  which has a provably complete reactive mechanism for triggering seqno updates.

> Even more, RPL adds a capability to stretch the rules, and a 
> capability to delay the repairs so as to reduce the control overhead 
> in Lower Power and mobile use cases.

-- Juliusz

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 Apr 2015 14:46:09 +0000

Hello Juliusz: 

> Indeed.  But I've made a half-serious attempt at a bibliography search, and
> couldn't find anything to satisfy my thirst for experimental data, especially for
> the proactive subset.  Could you please give me a reference?
> 

The references I'm aware of do belong to the private space of companies which make a living selling RPL devices. 
Maybe people in the list have academic links?

> My perhaps mistaken understanding is that RPL uses a more primitive version of
> DSDV's feasibility condition (without the even-odd mechanism that avoids loops
> after a retraction).  If RPL uses DUAL feasibility, then I completely fail to see the
> data structure that keeps the necessary history (the equivalent of Babel's source
> table).

That's all this discussion around that value L which is the smallest Rank a node has had in a given DODAG for a given version.
A DODAG gets to a number of routes as indicates by the RIO option with (pfx,plen) in the DIO via a root which is your router id.
The router needs to maintain it value L per DODAG it has participated to. All set. But there's more fun.

Let me explain what's behind the text below in RPL...
"  Let L be the lowest Rank within a DODAG Version that a given node
       has advertised...
   A node is allowed to join any DODAG Version that it has never been a
   prior member of without any restrictions, but if the node has been a
   prior member of the DODAG Version, then it must continue to observe
   the rule that it may not advertise a Rank higher than
   L+DAGMaxRankIncrease at any point in the life of the DODAG Version.
"
... I'm pretty sure you will like it:
 
- One interesting difference with Babel is that RPL can route to all nodes with a single DODAG to a single root, using MOP 2. This gives you the absolute minimum amount of state, but that has a potentially large stretch when not routing to or from the root. At the other extreme, RPL can route optimally to all nodes by building one DODAG per destination, using MOP 0, in which case you get roughly the same behavior as Babel. And the cool thing is that RPL can build as many DODAGs as wanted between these 2 extremes. With this, RPL fills one of the requirement discussed at Homenet, that is the capability to save resources by selectively drop state. RPL simply does that by NOT building MOP 0 DODAG for all destinations, and routing along other MOP 2 DODAGs with a stretch. IOW, one can use RPL to one or more MOP 2 instances, say, rooted at the edges of a stadium, and as many MOP 0 as you like to optimize to particular sources and sinks. All this can be done with the current spec.

- Another interesting difference is that if we have 2 roots, RPL partitions the network in 2 DODAGs. This translates into the fact that if we have 2 routers that expose a same destination, RPL, as opposed to Babel, does not suffer from a routing loop. The rule above forces a router to maintain its lowest rank per DODAG, and the feasibility condition applies on a per-DODAG basis with a different value of L per DODAG. Which has yet the other consequence that if a node has never been in  a particular DODAG, then that is enough feasibility condition; it can jump in with no loop.  That's divide and conquer for you, quite a key feature if you want to scale your network.

> (Which makes sense for RPL -- you certainly don't want to multiply the data
> structures being held in a sensor.  Babel and RPL play in different spaces, right?)
> 
> Again, I may be confused, but I think the local repair mechanism is not specified
> in the RFC.  There's an example mechanism given in Section 3.7.2, but that
> example is prone to loops in the presence of packet loss.

Oh, it is specified, most certainly.  Local repair is in fact a mobility-friendly freezing - which is intently not DUAL's diffusion because diffusion would not work on a MANET where some nodes may go away before the distributed algorithm is complete, which would cause DUAL to lock. Local repair is done by either poisoning or detaching, sections 8.2.2.5. Or 8.2.2.6. Because mobility and radio interferences may cause repeated packet loss, neither poisoning nor detaching is  a fool proof guarantee of freezing the whole impacted sub-dag. So there's all that discussion, which you'll find but scanning the RFC for the word poisoning. That's when a set of simple ideas turn into a lot of quasi-opaque text, to the great suffering of the editor, trust me on that. On the side, poisoning is really inheriting from IGRP, not EIGRP. 

> However, there's nothing I see to say when a root decides to trigger a global
> repair (except for some vague mention of periodic updates, which the DSDV
> experiment has shown are not a good idea).  This is very much unlike Babel
> (different spaces, remember?)  which has a provably complete reactive
> mechanism for triggering seqno updates.
 
We voluntarily left out the trigger for a new iteration, because that can be largely outside the scope of the routing protocol, and for the part that belongs to the routing protocol, it is highly dependent of the use case, how frequently and for which reason you want to fire a new iteration. As you point out, if the network has large to infinite resources, a new iteration can be fired on any event that causes a freeze somewhere. But you rapidly find that you want to delay that to save control plane, in particular if the frozen area is not transmitting any data to that destination anyway. Then you start thinking in terms of OSPF throttling and may get quite far, depending on how constrained your network is. We went as far as allowing a configurable stretch in the feasibility condition, allowing to increase the Rank by a limited extra, which may, if you are lucky, save the day, or, if you are unlucky, count to a very tightly controlled infinity.

Because RPL has local repair, it needs a lot less global repair, which in turn is a great news if a new iteration is indeed a relatively costly operations vs. effective traffic in the network.

Note well:

The base RFC only incorporates what's common to all RPL cases, that's the core DV operation. Anything too specific is left to an external plug-in that is adapted to the use case, called an objective function (OF). The bare minimum OF is RFC 6552. If a particular use case has a valid reason to trigger a new iteration, then the OF is the place to make that decision. Arguably, we could have documented a vector to trigger this new iteration in RFC 6550, and we have not. There are a number of other things that we left out, in a search for the bare minimum, and yet we ended with 100+ pages. But that does not reflect the footprint of the code, which can be quite small..

And then, there are the external sources of trigger, say, an event such as an explosion that will disrupt the network and is detected outside of the routing protocol. The local repairs will fail and or at best consume lots of resources. The reactive triggers will either no get there or too many will, in which case there will be too many iterations, too close from one another. This is when an external source -an open loop between the events and the routing action - can be welcome. We certainly did not start discussing such a thing in the RFC.

All in all I do not buy the different spaces. RPL was explicitly designed for multiple spaces because, by design, we left out of RPL and into the OF everything  that's specific. You have a different space, you figure a different way to use RPL (how many DODAGs, MOP x, etc...) and you design your own objective function if need be, tying metrics and logic to feed your particular needs. This has been tried from some the smallest to some of the largest routers on this planet, quite successfully, if you ask me. I'd say that a MANET or a HOMENET router stand peacefully in the middle ground between these extremes.

> That citation belongs on the conclusion slide of the next talk I give ;-)

Do I get an invite? I'll be a good citizen ; ) 

After this discussion, I'm tempted to start a "RPL for not so low power lossy networks" spec that would probably no have to specify anything much but mostly provide guidance on how to use RPL for wired, home and MANET deployments.

All the best,

Pascal

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 02 Apr 2015 18:41:10 +0200

> (and exlaining them) are for example

Thanks for the references, Yvonne-Anne.  I'll have a look as soon as
I find out whether we still have access to IEEE-paywalled articles (budget
cuts, so I'm no longer sure we do).

However -- some of the abstracts are not entirely clear, but it looks like
it's all simulation work.  Do you have any experimental data?

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 03 Apr 2015 01:41:53 +0200

Thanks a lot for the lengthy explanation, Pascal, I feel that I understand
RPL somewhat better now.

>> version of DSDV's feasibility condition

> That's all this discussion around that value L

Ah, I see.  Section 8.2.2.4.3.  (I'm not apologising for missing it -- it
is well hidden.)

Yes, that looks like DUAL-feasibility, but weakened so that loops of
diameter DAGMaxRankIncrease or less are allowed, right?  Why the
weakening?  Is that to compensate for the fact that you don't have
a mechanism to resolve blackholes in a timely manner?

> L+DAGMaxRankIncrease at any point in the life of the DODAG Version.

Yeah, that's pretty clear.  The same is true of Babel.

> One interesting difference with Babel is that RPL can route to all nodes
> with a single DODAG to a single root, using MOP 2.

Yes, I've noticed this mechanism before.  I think that's a smart mechanism
(I much prefer it to MOP 1), and I trust you've evaluated its performance
carefully, at least for some OF.  However, that's definitely not something
I'd ever consider adding to Babel -- I have a very strong desire to keep
the base protocol small, and to make sure that all extended variants can
interoperate as long as they implement the base protocol correctly.

You see -- once again, we're aiming at two different application spaces.
You're thinking of sensor networks, where it is reasonable to require that
all nodes in a given network implement MOP 2.  Babel is aimed at home and
hybrid networks (cash-starved networks with some meshy bits), which tend
to grow organically, with routers that never get reflashed, and therefore
contain different variants of the protocol.

> Another interesting difference is that if we have 2 roots, RPL
> partitions the network in 2 DODAGs.

Sorry if I'm being slow, but I don't see how that can be true.  If you have

   R1    R2
   /\
  /  \
 A    B

and there is instability in the network, so that simultaneously A switches
to B as parent, and B switches to R2 while its retraction ("poison") gets
lost, what prevents A from having B as parent while believing it's still in
R1's DODAG?

> Local repair is done by either poisoning or detaching, sections
> 8.2.2.5.

I don't see how that can be implemented.

Suppose A is B's parent.  A advertises INFINITE_RANK.  A's retraction
("poison") is lost.  B has no reason to change parents, so B has a parent
with infinite rank.  Oops, B is just violating the MUST NOT in 8.2.2.5.2.

Are you assuming the network is reliable?  Or am I missing some mechanism
that prevents that from happening?

> Or 8.2.2.6.

That's just a variant of the above but advertising DIO instead of
a retraction, right?

> On the side, poisoning is really inheriting from IGRP,

It's been a long time since I looked at IGRP, but I seem to recall that it
avoids the issue I describe above by imposing a silent time after a metric
increase.  This causes temporary blackholes, of course, of up to 3 minutes
if memory serves.

> We voluntarily left out the trigger for a new iteration, because that
> can be largely outside the scope of the routing protocol,

I disagree with that, at least in the space for which Babel is aiming.

> All in all I do not buy the different spaces. RPL was explicitly
> designed for multiple spaces because, by design, we left out of RPL and
> into the OF everything that's specific.

Well, the space Babel aims for requires that implementations from different
vendors interoperate.  That requires putting a provably complete set of
"must implement" mechanisms in the base spec.  I don't believe that RPL
has that property.

> Do I get an invite?

Sure, I'll try to remember to send you a note when I next give a seminar.

-- Juliusz

---

From: Cenk Gündogan <[email-masked]>
Date: Fri, 03 Apr 2015 08:14:57 +0200

Hello Juliusz,

> that prevents that from happening?

I also did struggle with this scenario for quite some time.
However, there are several places in the RFC that specifically deal 
(directly or indirectly) with this issue.

          8.2.2.5 <https://tools.ietf.org/html/rfc6550#section-8.2.2.5>.
          Poisoning

    1.  A node poisons routes by advertising a Rank of INFINITE_RANK.

    2.  A node MUST NOT have any nodes with a Rank of INFINITE_RANK in
        its parent set.

My interpretation of these bullet points is that DIOs advertising 
INFINITE_RANK are sent out periodically
(probably in a decaying fashion via Trickle), in order to reduce the 
chance that these DIOs stay unnoticed.
However, this might not be a complete solution, as all DIOs from A to B 
can become lost thus leading to the same problem,
but then the RFC states that links should be guaranteed to be symmetric 
anyways, e.g. by using NUD [1] or other alternatives.

Something else I want to mention is that RPL utilizes a few lifetime 
counters (e.g. for the dodag or route),
which would also help in this scenario (We wouldn't refresh the lifetime 
of a node with INFINITE_RANK, would we?),
but admittedly, depending on the specified lifetime values, in a very 
sluggish way.

At last, it is important to remember that RPL uses data-path validation 
to reduce the chattiness of control packets,
described in [2] and most likely realized by using [3].
In that case A can reset its Trickle timer when encountering 
inconsistencies and start e.g. another poisoning routine
by sending out another set of INFINITE_RANK DIOs.

Best,
Cenk

[1] Neighbor Unreachability Detection 
(https://tools.ietf.org/html/rfc2461#page-66)
[2] https://tools.ietf.org/html/rfc6550#section-3.2.7
[3] https://tools.ietf.org/html/rfc6553

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 3 Apr 2015 08:51:04 +0000

You pretty much have it all, Cenk, I thank you for this great explanation.

Let me observe a few things:

One is that poisoning gives you only half of the value of detaching since detaching maintains connectivity within the detached DODAG, which is a useful consideration in A MANET situation. This mode is an inheritance from MANEMO where we were looking for the minimal topological awareness so as to ensure maximum resilience to swarming in a highly mobile situation.

Second is that both RPL methods derive from the desire of getting a similar service as the diffusion algorithm  in DUAL/EIGRP, but in a MANET situation where connectivity is uncertain and the real diffusion algorithm is doomed to fail.

We had to adapt to the real world and its statistical behavior, and had to cover for the exception, which RPL does as you describe. So DUAL was replaced with a trickle-based diffusion, and the packets were instrumented beyond hop count to detect and fix the anomalies.

There was ample simulation work that showed the value for traffic continuity vs. plain black holing (till the next sequence is advertised). Same goes for the stretch to the feasibility condition.

Now if you disable those functionalities - arguably in a rather fast and stable network - , and you make one mop0 DODAG per router in one instance, you get something that is highly similar to BABEL - and that is no magic. And in that, BABEL is less than EIGRP, but arguably, for that same reason, EIGRP is not applicable to MANET.

If you make that 2 instances, you can select the Homenet multi homed GW without the need for source/destination routing.

If you add the option of P2P RPL you probably get a reactive DV in the close family of AODV.

RPL aggregated the quintessence of classical DV with the best knowledge of people applying DV to mobility (MANEMO/ NINA), and of those applying it to sensors (such as CTP and multiple proprietary solutions from WSN vendors).

At the same time, RPL kept out anything specific to a particular type of use case - metrics, logic, policies. One really creates a solution by choosing his own objective function. It can be said that RFC 6550 is generic and that the application of an OF creates an instance which is the real routing protocol.

The text is arguably hard to read.

Part of that came from the aggregation process over 19 rounds of the draft. I'm afraid that if we pass the BABEL RFC through the WG process, one will hardly recognize it in the end, even if we manage to preserve the basic operations.

Another reason is that we had to strip all the why's and focus on specifying observable behaviors. That is certainly not how one would write a book or a paper. I'm afraid that what makes BABEL such a great read today will be lost if the same process is applied.

Cheers,

Pascal

Le 3 avr. 2015 à 08:15, Cenk Gündogan <[email-masked]<mailto:[email-masked]>> a écrit :

Hello Juliusz,

I also did struggle with this scenario for quite some time.
However, there are several places in the RFC that specifically deal (directly or indirectly) with this issue.

8.2.2.5<https://tools.ietf.org/html/rfc6550#section-8.2.2.5>.  Poisoning

My interpretation of these bullet points is that DIOs advertising INFINITE_RANK are sent out periodically
(probably in a decaying fashion via Trickle), in order to reduce the chance that these DIOs stay unnoticed.
However, this might not be a complete solution, as all DIOs from A to B can become lost thus leading to the same problem,
but then the RFC states that links should be guaranteed to be symmetric anyways, e.g. by using NUD [1] or other alternatives.

Something else I want to mention is that RPL utilizes a few lifetime counters (e.g. for the dodag or route),
which would also help in this scenario (We wouldn't refresh the lifetime of a node with INFINITE_RANK, would we?),
but admittedly, depending on the specified lifetime values, in a very sluggish way.

At last, it is important to remember that RPL uses data-path validation to reduce the chattiness of control packets,
described in [2] and most likely realized by using [3].
In that case A can reset its Trickle timer when encountering inconsistencies and start e.g. another poisoning routine
by sending out another set of INFINITE_RANK DIOs.

Best,
Cenk

[1] Neighbor Unreachability Detection (https://tools.ietf.org/html/rfc2461#page-66)
[2] https://tools.ietf.org/html/rfc6550#section-3.2.7
[3] https://tools.ietf.org/html/rfc6553
_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 03 Apr 2015 11:59:34 +0200

>>> Local repair is done by either poisoning or detaching, section 8.2.2.5.

> (directly or indirectly) with this issue.

I'm afraid I don't understand your answer.  Could you please tell me
exactly what happens in the scenario I've described above?

-- Juliusz