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

["JP Vasseur (jvasseur)" <[e-mail]>]

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) <[e-mail]> wrote:
> 
> 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 <[e-mail]> 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
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet