[Roll] Re: WG input requested: draft-silva-hymrpl-01

[Ines Robles <[e-mail]>]

Dear all,

This is a kind reminder that we are looking for comments on
draft-silva-hymrpl-01.

Thanks,

Ines and Aris

On Mon, Aug 31, 2026 at 9:14 PM Ines Robles <[e-mail]>
wrote:

> Dear all,
>
> We have received draft-silva-hymrpl-01 [1], which proposes a Hybrid Mode
> of Operation for RPL (MOP=6), allowing storing-like and non-storing-like
> behavior within the same DODAG, together with an Inter-DODAG Bridge
> mechanism for connecting DODAGs operating with different MOPs.
>
> Before taking any further steps, we would like to invite WG review and
> discussion of the proposal. In particular, there are a couple of
> architectural and procedural questions on which input from the WG would be
> useful.
>
> First, the Inter-DODAG Bridge mechanism has a fairly direct dependency on
> MOPex. The draft uses MOP=7 (Extended) in the DIO header for the
> Inter-DODAG Bridge, with the bridge's actual mode (MOP=6 for HyMRPL)
> carried in the MOPex option. However, the previous MOPex work
> (draft-ietf-roll-mopex) did not progress to publication and was left
> dormant in the absence of identified consumers or concrete deployment
> drivers, with the possibility of revisiting it if such a need emerged [2].
> There are also a number of open issues from the previous MOPex work [3].
> The MOPex Value Registry referenced by this draft does not currently exist
> in the IANA RPL registries, and the draft currently lists
> draft-ietf-roll-mopex as a normative reference. As currently written, the
> draft therefore has a normative dependency on unpublished MOPex machinery.
> We would like to understand whether this proposal provides a reason to
> revisit that mechanism, or whether the necessary extension machinery should
> instead be specified within this document or otherwise progressed alongside
> it.
>
> Second, and related to the above, it is very good to see that the authors
> have already developed and made available an open-source implementation of
> the proposed mechanisms. The implementation has been experimentally
> evaluated. In light of the reasons the previous MOPex work was left
> dormant, we would be interested to understand whether HyMRPL represents a
> concrete use case for that mechanism, and whether there are concrete
> deployment scenarios or communities interested in this functionality.
>
> We would therefore like to invite comments from the WG over the next
> weeks, until 25 September.
>
> Authors, it would be particularly helpful to hear your views on the points
> above, especially the deployment/use cases motivating the work and how you
> think the dependency on MOPex should be handled.
>
> Thanks,
>
> Ines and Aris
>
> [1]  https://datatracker.ietf.org/doc/html/draft-silva-hymrpl-01
>
> [2]
> https://mailarchive.ietf.org/arch/msg/roll/6IpNvvPIRB45QJiSyrlviNFkHaU/
>
> [3] https://github.com/roll-wg/mopex/issues
>
> On Wed, Jul 29, 2026 at 4:54 AM Cassius Clay <[e-mail]>
> wrote:
>
>> Dear ROLL Working Group,
>>
>> We would like to bring to the group's attention our individual
>> Internet-Draft proposing extensions to RPL's Mode of Operation model:
>>
>> draft-silva-hymrpl-01 "HyMRPL: Per-Node Hybrid Mode of Operation and
>> Inter-DODAG Bridge Mechanism for RPL"
>> https://datatracker.ietf.org/doc/draft-silva-hymrpl/
>>
>> Problem addressed:
>>
>> RFC 6550 enforces a single MOP across all nodes in a DODAG, creating two
>> limitations: (1) intra-DODAG rigidity, where heterogeneous devices cannot
>> independently select their forwarding behavior; and (2) inter-DODAG
>> isolation, where DODAGs with different MOPs have no connectivity mechanism.
>>
>> What the draft defines:
>>
>> A Hybrid Mode of Operation (MOP=6) that enables per-node functional
>> profiles (Class-S storing-like, Class-N non-storing-like) within a single
>> DODAG, without modifying RPL control message formats.
>>
>> An Inter-DODAG Bridge mechanism leveraging MOPex signaling
>> (draft-ietf-roll-mopex) to interconnect DODAGs with different MOPs through
>> MOP masquerading (MOP=7 + extended option) and cross-DODAG route injection.
>>
>> The mechanisms introduce zero additional control messages and maintain
>> backward compatibility via the J-flag in extended options.
>>
>> Implementation status:
>>
>> We have a working open-source implementation (extension of rpld)
>> validated on Mininet-WiFi with 6LoWPAN over IEEE 802.15.4 in topologies
>> from 5 to 50 nodes. Results include 100% PDR across MOP boundaries,
>> convergence up to 35% faster than Storing mode at 20 nodes, and a dual
>> reconvergence mechanism providing 23 percentage points higher PDR than
>> Non-Storing under intermediate node failure. Over 100 independent
>> experiment runs have been conducted.
>>
>> Code: https://github.com/CassiusClayB/rpld_hymrpl
>>
>> Relationship to existing ROLL work:
>>
>> This draft complements draft-ietf-roll-mopex by defining concrete
>> semantics for MOPex value 6 and demonstrating an operational use of MOP=7
>> masquerading for inter-DODAG bridging. We believe it addresses a gap in
>> RPL's flexibility for heterogeneous IoT deployments that is not covered by
>> current WG documents.
>>
>> We welcome any feedback from the working group and would be happy to
>> present at a future ROLL session or interim meeting. We are also interested
>> in discussing whether this work might be appropriate for WG adoption.
>>
>> Best regards,
>> ___________________________________________________________
>> Cassius Clay Batista da Silva Filho - (Cassius Clay)
>> Engenheiro de DevOps Pós-graduado em Computação em Nuvem linkedin:
>> https://www.linkedin.com/in/cassius-clay-filho/
>> WhattsApp: (84) 992172382 | E-mail: [e-mail]
>> _______________________________________________
>> Roll mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>