Subject: [Roll] FW: New Version Notification for draft-thubert-roll-turnon-rfc8138-00.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 23 May 2019 13:04:44 +0000

Dear all:

It was reported to me as a deployment issue that RFC 8138 creates a backward compatibility issue when mixed with legacy RPL nodes that do not support the compression.
RFC 8138 fails to provide a toggle that turns the compression down in mixed environment. This blocks the deployment of newer versions that actually support the draft.
I created a quick draft to fix that oversight. It's very short and I'd appreciate if you can comment rapidly so we can answer the field situation with a complete standard.

What do you think?

Pascal

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: jeudi 23 mai 2019 14:55
To: Pascal Thubert (pthubert) <[email-masked]>
Subject: New Version Notification for draft-thubert-roll-turnon-rfc8138-00.txt

A new version of I-D, draft-thubert-roll-turnon-rfc8138-00.txt
has been successfully submitted by Pascal Thubert and posted to the IETF repository.

Name:		draft-thubert-roll-turnon-rfc8138
Revision:	00
Title:		Configuration option for RFC 8138
Document date:	2019-05-23
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts/draft-thubert-roll-turnon-rfc8138-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thubert-roll-turnon-rfc8138/
Htmlized:       https://tools.ietf.org/html/draft-thubert-roll-turnon-rfc8138-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-thubert-roll-turnon-rfc8138

Abstract:
   This document complements RFC 8138 and dedicates a bit in the RPL
   configuration option to indicate whether RFC 8138 compression should
   be used within the RPL instance.  When the bit is not set, source
   nodes that support RFC 8138 should refrain from using the compression
   unless the information is superseded by configuration.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Sun, 26 May 2019 21:31:20 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > It was reported to me as a deployment issue that RFC 8138 creates a
    > backward compatibility issue when mixed with legacy RPL nodes that do
    > not support the compression.

Yes... I said exactly this would happen when we started this work.
I was told that a forklife upgrade of networks to RFC8138 was going to be
acceptable, but I guess this isn't the case :-)

    > RFC 8138 fails to provide a toggle that turns the compression down in
    > mixed environment. This blocks the deployment of newer versions that
    > actually support the draft.

    > I created a quick draft to fix that oversight. It's very short and I'd
    > appreciate if you can comment rapidly so we can answer the field
    > situation with a complete standard.

    > What do you think?

I think that the document needs to say that DIO messages can never be RFC8138
compressed, and I think that DAO's can't either, but I might have to think
about that some more.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 May 2019 06:57:33 +0000

Yes, you were right Michael.

The problem is really the transition time during a network upgrade.

About compressing control messages, well doing that was not the idea, the idea was for data packets. 

Non-storing DAO to the root, though, can be considered as data  packets.
Maybe we can leverage this draft to indicate more rules on when / how to use RFC 8138, in particular the root encaps IP in IP with RFC 8138 to the parent if the child does not support the compression.
Are you willing to contribute text on this? This shouldn't weight and slow the draft too much, and certainly increases the value.

All the best,

Pascal

> From: Roll <[email-masked]> On Behalf Of Michael Richardson
> Sent: lundi 27 mai 2019 03:31
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-turnon-
> rfc8138-00.txt
> 
> 
> I think that the document needs to say that DIO messages can never be
> RFC8138 compressed, and I think that DAO's can't either, but I might have to
> think about that some more.
> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 27 May 2019 14:14:15 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Maybe we can leverage this draft to indicate more rules on when / how
    > to use RFC 8138, in particular the root encaps IP in IP with RFC 8138
    > to the parent if the child does not support the compression.

Ick!
That would imply different parts of the network have or don't have 8138?
I don't think this was your goal, and requires too much information at each
node about child capabilities.

    > Are you willing to contribute text on this? This shouldn't weight and
    > slow the draft too much, and certainly increases the value.

sure, but I think we shouldn't do this.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 May 2019 18:32:13 +0000

Well there’s always the case of unaware leaves for which we need to terminate IP in IP at the parent.

Leaves that are not capable of 8138 are not a problem we encapsulate in both directions at the parent.

With the capabilities draft the root has all the information to know what the leaf can do. 

What’s more trouble is if the non 8138 is a parent. That is the thing I really want to avoid...

Regards,

Pascal

> Le 27 mai 2019 à 20:14, Michael Richardson <[email-masked]> a écrit :
> 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll