Subject: Requesting 6man review of draft-ietf-roll-useofrplinfo-25

From: Suresh Krishnan <[email-masked]>
Date: Sat, 4 May 2019 02:37:51 +0000

Hi all,
  This draft (https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25) was on yesterday's telechat. Ever since I read the document, I have not been very comfortable with the way the document redefines the RFC6553 HbH option. I personally (with my AD hat off) think the right way to do this is to obsolete RFC6553 with a new document. Also at the very minimum, I think this document requires review from 6man and that has not taken place(I do remember reading an earlier version of this (-13) in April 2017 specifically in relation to the 2460bis work but the option redefinition was not there in the document then). So I have deferred this document by two weeks so that the 6man review can take place. I will summarize the results to the authors, the roll chairs and the responsible AD and determine next steps. So please do chime in with your opinions in response to this mail by Wednesday May 15 2019.

Thanks
Suresh

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 5 May 2019 13:22:14 +0100

Suresh Krishnan wrote on 04/05/2019 03:37:
> So please do chime in with your opinions in response to this mail by 
> Wednesday May 15 2019..

this looks like a difficult consequence of force majeure.  Section 3.3 
defines a mechanism to avoid a flag day.  From an operational point of 
view, what matters is that if there is a change in a code point, that 
there is a non-disruptive mechanism which allows migration from old to 
new.  The authors have defined this, and have made it clear that there 
is a significant change in this draft. So they've done the due diligence 
for what's operationally important.

After that, it's a matter of branding / versioning to make it clear to 
us stupid humans that there is a compatibility change.  Whether this is 
done by reclassifying RFC6553 to historic, and/or by renaming the 
contents of the current draft RPL1.1 or RPLv2 or RPLbis or whatever is a 
matter of taste.  But there is the potential for confusion if the same 
label is used for something which is not backwards compatible.

Regarding interoperability with other ipv6 routers, so long as the draft 
acknowledges rfc8200 compatibility for hbh headers and doesn't make any 
extra demands for general hbh processing, that's fine.

Nick

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 May 2019 13:42:26 -0400

Suresh Krishnan <[email-masked]> wrote:
    > Hi all,
    > This draft (https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25) was
    > on yesterday's telechat. Ever since I read the document, I have not been very
    > comfortable with the way the document redefines the RFC6553 HbH
    > option. I

Thank you for initiating this.

The document has been in an out of 6man, and Brian Carpenter has done a lot
of work with the ROLL WG on what would fit and what would not.  At one point,
we wanted to use the flow-label for compression, and some of the useofrplinfo
work came out of the desire to specify exactly what we wanted to compress:
Some very old thread, just to establish some history:
  https://mailarchive.ietf.org/arch/msg/roll/pk6SPBXCPQM3XXCex3TWX9pBsM8

Some much more recent analysis:
  https://mailarchive.ietf.org/arch/msg/roll/N293f2gxhl7GcqswsKiL7L6j1eU

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 May 2019 13:47:49 -0400

> defines a mechanism to avoid a flag day.  From an operational point of view,
    > what matters is that if there is a change in a code point, that there is a
    > non-disruptive mechanism which allows migration from old to new.  The authors
    > have defined this, and have made it clear that there is a significant change
    > in this draft. So they've done the due diligence for what's operationally
    > important.

Thank you.
It was the view of the authors that very few deployed RPL/LLN networks will
experience a flag day of non-interoperation, because most of those networks
are homogeneous from vendors.

We are rather far, unfortunately, from having multi-vendor RFC6550/6553
interop shown in the field.  As such, a vendor that wants to do things
as this document shows likely will arrange to do this by simply deploying new
networks, with old networks remaining untouched. (Fork-lift upgrades)

Our definition of a flag-day avoidance signal was therefore done for academic
reasons.

    > acknowledges rfc8200 compatibility for hbh headers and doesn't make any extra
    > demands for general hbh processing, that's fine.

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 May 2019 13:36:33 +1200

The text partly covers this anyway:

>> This change creates a flag day for existing networks which are
>> currently using 0x63 as the RPI value.  A move to 0x23 will not be
>> understood by those networks.  It is suggested that implementations
>> accept both 0x63 and 0x23 when processing.

which allows for some period of overlap if the rollout is carefully managed. Maybe some of this needs to be repeated in Section 9 "Operational considerations of introducing 0x23".

> Our definition of a flag-day avoidance signal was therefore done for academic

Yes. If this was a widely deployed protocol already, we'd have a problem. But it isn't, so we won't. 

But Suresh said:

> I personally (with my AD hat off) think the right way to do this is to obsolete RFC6553 with a new document. 

That's always a toss-up in such cases. I have no strong opinion, but wouldn't it be OK to consolidate the documents once there is real deployment experience with RPL?

    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 May 2019 14:37:50 -0400

> That's always a toss-up in such cases. I have no strong opinion, but
    > wouldn't it be OK to consolidate the documents once there is real
    > deployment experience with RPL?

getting useofrplinfo out the door was considered by a few people to be the
first step towards eventually doing RFC6550bis, but there is no point in
doing that until we have some real multi-vendor interop experience.

So I am not crazy with doing RFC6553bis at this point.
Had it been suggested in 2015, I would have been okay to go in that
direction, but it would have been very surprising to me.