Re: [Roll] MOP 7 Reserved/Specification (draft-ietf-roll-useofrplinfo / draft-ietf-roll-unaware-leaves / draft-ietf-roll-turnon-rfc8138)

[Michael Richardson <[e-mail]>]

I'm removing the tripe-document CC:
    <[e-mail]>,
    "[e-mail]" <[e-mail]>,
    <[e-mail]>,
    <[e-mail]>

and just putting the WG back in the discussion.

Alvaro Retana <[e-mail]> wrote:
    > Yes, I know, the IESG is a pain.  As Pascal said, the reasoning can be
    > counterintuitive -- it took me a while to get it, and now I agree that
    > it is not complex.  Martin also got it.

    > Individual explanations don't scale and don't prevent others from
    > asking the same question.  Pre-emptive notes matter only if considered
    > in context and if they are top of mind.  A permanent record is what I
    > think is better.

What I'm hearing here is that we need to move MOP=7 Reserved into a document
of it's own.

   _Considerations for evolution of RPL_
   updating RFC6550.

   {like RFC7346, which took a mere 12 months to publish after all the
   details were discussed over dinner at a Vancouver IETF meeting.
   Forgive my cynicism.}

    > I'm ok if you want to leave the text as is — no need to talk about this
    > anymore.  With any luck, there will be no issues and we can approve the
    > documents before the holidays.

Uhm, okay.

    > If you decide to change something, I have a suggestion for
    > §4.1.2/UseofRPLInfo:

    >    Nodes that support this specification may need to operate in
    > networks where MOP 7 is used.  As explained in rfc6550, if the MOP is
    > not supported, it must only join the network as a leaf.  To facilitate
    > the integration into LLNs using MOP 7, a document that defines
    > functionality using DODAG Configuration Option Flags MAY specify
    > required behaviors (see §4.1.3).

That doesn't really say anything to me.

I would write somewhere. Where I don't know.

----

RFC6550 does not provide a way for a DODAG root node to know what
capabilities are ubiqutiously available on an RPL LLN.
This lack includes both control plane (RPL) and data plane (RFC8505, RFC8138,
RFC8931, etc.) capabilities.
[capex] is an upcoming effort to deal with in a systematic way.

Until such time as [capex] can be finished, major control plane options are
expected to be defined in an backwards compatible way, or to be make
judicious use of the remaining available MOP values (4, 5 and 6 being still
free).   A major change in control plane behaviour for which a node
does not understand causes the node to join in leaf mode only
(RFC6550, section 9.2)

The above logic takes care of the control plane, but leaves the data plane
options in the dark.  For a node to join in leaf mode it still needs to be
able to communicate in the data plane.
For this reason, [useofrplinfo], [turnon-rfc8138], [unaware-leaves] define
*ad-hoc* mechanisms to enable data-plane options.  This permits Flag Day-free
incremental deployment of new firmware as explained in [useofrplinfo] section 4.1.3.

Because the mechanism are adhoc, and use a very limited resource of flags in
the DIO header,  there is a desire not to maintain them longer than
necessary.   Negotiating data-plane options in the DIO header as at best, a
hack.  Attaching them to the MOP value is also a bit of a hack, but RFC6550
did not give us any other way to do revise the protocol in an incremental manner.

The WG also wishes to establish that many of these innovations will become
mandatory going forward, and so has established that by the time the
WG allocates MOP==7, that these data plane options will no longer be optional.
It is likely that MOP==7 will be allocated by [mopex] to extend the MOP
values, and will include a capability negotiation mechanism at both the data
plane and control plane.

However, while we can not entirely predict the future, for the data plane
options, we know which ones we want permanently on in the future, and so we
are declaring them so in each document, based upon the MOP value.
Based upon advice from IANA, the WG has marked MOP==7 as Reserved, because
the WG has specific plans for it.

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide