Subject: Re: [Roll] Adopting turnon 8138

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 1 Nov 2019 11:54:49 +0200

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) <
[email-masked]> wrote:

> Dear all
>
> *   https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-03
> <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
> [email-masked] <[email-masked]> https://www.ietf.org/mailman/listinfo/roll
> <https://www.ietf.org/mailman/listinfo/roll> *

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 3 Nov 2019 09:05:49 +0200

I hope this needs discussion, please note that the authors need to reply to
messages if they really communicating with the WG for adoption.

To WG Chair> please advise now and future authors that want adoption to
respond otherwise the WG is directed by private/big companies and not by
IETF.

AB

---

From: Rahul Jadhav <[email-masked]>
Date: Sun, 3 Nov 2019 14:06:22 +0000

I support adoption of turnon 8138.
8138 allows compression of control overhead in data plane.
We need to have a mechanism to signal use of 8138. This draft enables that.

Regards,
Rahul

________________________________
From: Roll <[email-masked]> on behalf of Ines Robles <mariainesrobles=[email-masked]>
Sent: Wednesday, October 30, 2019 10:20 AM
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] WG Call for Adopting turnon 8138

Hi,

The Call for adoption finalizes on 13th November,

Please let us know your opinion.

Thank you,

Ines, Dominique and Peter

On Tue, Oct 29, 2019 at 4:34 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 4 Nov 2019 20:21:15 +0200

> We need to have a mechanism to signal use of 8138. This draft enables that.

That mechanism is not done right, I hope the author discusses with us,

AB

>
> Regards,
> Rahul
>
> ------------------------------
> *From:* Roll <[email-masked]> on behalf of Ines Robles
> <mariainesrobles=[email-masked]>
> *Sent:* Wednesday, October 30, 2019 10:20 AM
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> *Subject:* [Roll] WG Call for Adopting turnon 8138
>
> Hi,
>
> <https://tools.ietf..org/html/draft-thubert-roll-turnon-rfc8138-03> is a
> be good to progress it in the background rather than forget it.. Could we

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 5 Nov 2019 07:31:01 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Fri, Nov 1, 2019 at 11:55 AM
Subject: Re: [Roll] Adopting turnon 8138
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>

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

All the best

Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Nov 2019 09:26:58 +0100

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) <[email-masked]> wrote:
> 
>> From: Abdussalam Baryun <[email-masked]>
>> On Tue, Oct 29, 2019 at 4:34 PM Pascal Thubert (pthubert) <[email-masked]> wrote:
>> Dear all
>> 
>>  
>> 
>> [email-masked]
>> [email-masked]
> [email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 5 Nov 2019 09:43:40 +0000

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 <[email-masked]> On Behalf Of Carsten Bormann
> Sent: mardi 5 novembre 2019 09:27
> 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
> 
> 
> > 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
> >
> 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
> >>
> >> 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
> >>

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 11 Nov 2019 08:54:48 +0200

On Tue, Nov 5, 2019 at 9:31 AM Pascal Thubert (pthubert) <[email-masked]>
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.
>

The draft is not about configuring the DAG, it is for compression, why your
proposal mixes them?

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

yes, so we need to give RPL more options and alternatives and not use its
few reserved,

> The current proposal does not generate any additional transmission.

how can we be sure of this if we do not separate functions specially while
RPL is in both data and control planes.

> require bandwidth and code footprint that we do not have.

I agree but this draft proposed is already a new protocol defined as
standard and updating standards. Updates for protocols can make things very
more complicated.

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

We are now trying to understand your proposal and your request to adopt and
to find good solutions, why we are asking for another draft or solutions?

AB

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 11 Nov 2019 07:42:41 +0000

Hi

Le 11 nov. 2019 à 07:55, Abdussalam Baryun <[email-masked]> a écrit :

On Tue, Nov 5, 2019 at 9:31 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> 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.

The draft is not about configuring the DAG, it is for compression, why your proposal mixes them?

It is a configuration knob of a RPL device so it belongs to configuration. It configures the compression of RPL artifacts and belongs to RPL. There is no inconsistency.

yes, so we need to give RPL more options and alternatives and not use its few reserved,

how can we be sure of this if we do not separate functions specially while RPL is in both data and control planes.

The draft uses an existing bit that was wasted so far.

Defining a new protocol to set one bit might appear more perfect but would require bandwidth and code footprint that we do not have.

I agree but this draft proposed is already a new protocol defined as standard and updating standards. Updates for protocols can make things very more complicated.

We are now trying to understand your proposal and your request to adopt and to find good solutions, why we are asking for another draft or solutions?

You say it’s wrong. Show us what’s right...

AB

Pascal

---------- Forwarded message ---------
From: Abdussalam Baryun <[email-masked]<mailto:[email-masked]>>
Date: Fri, Nov 1, 2019 at 11:55 AM
Subject: Re: [Roll] Adopting turnon 8138
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>

What do you think?

AB

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