Re: [Roll] Adopting turnon 8138

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

Yes, I thought about 6CIO. I'm a big fan and used it quite a bit already for other purposes within ND operations.

But here it did not seem as appropriate. Let me elaborate on that.

- RFC 8138 is a RPL specific thing not a generic compression. It seems awkward to import RPL-only concepts in ND. Like any ND device would now have to see a but that's used exclusively by RPL.

- The compression has to be done for a packet down a RPL path that is contained inside a RPL DODAG. A subnet is not necessarily congruent to a DODAG. Thus 6CIOs do not follow a particular RPL DODAG and making ND aware of RPL DODAGs seems awkward again.

- The bit expresses a constraint on a RPL node. If the node does not support RFC 8138 then is should be a leaf. This is pure RPL semantics, and the text in the turnon draft has to be in a RPL spec not ND.

- The behavior is similar to another bit that is already in the configuration option, see https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-32#section-10 . Both affect packet operation, both lead to a certain position in the DODAG (router vs. leaf) depending on the support of the node. The turnon rfc8138 is homogeneous with that.

- This homogeneity is highly desirable. We are now working on a capabilities exchange protocol where the root can poll the devices to know whether they can do this and that, so it can decide to turn on a feature in the configuration option. We want to apply this method to both turning on RFC 8138 and the new RPI value, and more stuff in the future.

The reason for the above is this: For RPL we could not afford to go and manually configure every node for any configurable parameter because we wanted to scale to large number of devices which implies ~zero-touch. IOW we had to design for an autonomic network. So we made it so that RPL distributes its own configuration and the DODAG builds itself as it learns that configuration in a fashion that depends in the configuration. What we did not do with RFC 6550 is the maintenance of the configuration. That was OK for the first generation but now we're adding stuff and we need to manage it dynamically. The flag to turnon RFC 8138 is just an epiphenomenon in that larger story.

I cannot pronounce it, but Grüße 😊

Pascal

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Carsten Bormann
> Sent: mardi 5 novembre 2019 09:27
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] Adopting turnon 8138
> 
> We generally signal compression capabilities using 6CIO (see RFC 7400).
> 
> I think this discussion is a symptom of ROLL trying to usurp some of the
> neighbor discovery functions, so in the end we never know where to put what.
> Of course piggybacking routing setup into neighbor setup is a good
> optimization, but doing neighbor setup implicitly based on having seen routing
> setup is creating this problem.  Maybe we can clean this up at some point.
> 
> Grüße, Carsten
> 
> 
> > On Nov 5, 2019, at 08:31, Pascal Thubert (pthubert) <[e-mail]>
> wrote:
> >
> > DODAG configuration as it’s name indicates is configuration. The goal is to
> tell dynamically how the protocol is operated as opposed to configuring all
> nodes separately.
> >
> > RPL operates in control plane and data plane. It does proactive route setup
> and reactive invalidation. These are all trade offs that are chosen to optimize
> energy and bandwidth efficiency vs. some theoretical perfection.
> >
> > The current proposal does not generate any additional transmission.
> Defining a new protocol to set one bit might appear more perfect but would
> require bandwidth and code footprint that we do not have.
> >
> > You are very free to propose an alternate solution with enough details so we
> can understand it, even push a draft, and then the WG will make the best of
> all it sees.
> >
> > Pascal
> >
> > ---------- Forwarded message ---------
> >> From: Abdussalam Baryun <[e-mail]>
> >> Date: Fri, Nov 1, 2019 at 11:55 AM
> >> Subject: Re: [Roll] Adopting turnon 8138
> >> To: Routing Over Low power and Lossy networks <[e-mail]>
> >>
> >>
> >> I don't think it is the right approach, why using the DODAG configuration
> for compression? this compression turn on/off is not for the DODAG
> construction but for packets. I think we should separate configurations of the
> RPL routing standards and of the packet compression standards. We may add
> another configuration option per DODAG or another way.
> >>
> >> What do you think?
> >>
> >> AB
> >>
> >> On Tue, Oct 29, 2019 at 4:34 PM Pascal Thubert (pthubert)
> <[e-mail]> wrote:
> >> Dear all
> >>
> >>
> >>
> >> https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-03 is a simple
> draft that completes RFC 8138 with bits in the config option to enable turning
> it on in an brown field.
> >>
> >> There’s no black magic and it would be good to progress it in the
> background rather than forget it.. Could we consider adoption?
> >>
> >>
> >>
> >> All the best
> >>
> >>
> >>
> >> Pascal
> >>
> >> _______________________________________________
> >> Roll mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/roll
> >> _______________________________________________
> >> Roll mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/roll
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll