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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Michael

> -----Original Message-----
> From: Michael Richardson <[e-mail]>
> Sent: dimanche 13 décembre 2020 22:25
> To: [e-mail]; Alvaro Retana <[e-mail]>; Pascal Thubert
> (pthubert) <[e-mail]>
> Subject: Re: MOP 7 Reserved/Specification (draft-ietf-roll-useofrplinfo / draft-
> ietf-roll-unaware-leaves / draft-ietf-roll-turnon-rfc8138)
> 
> 
> 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.

You just did! We need to mark your words. I flagged your email and plan to use it (be reference) in the next review cycle if questions are asked again (If that's OK?).

Take care!

Pascal


> ----
> 
> 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