Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-41.txt

From: [email-masked]
Date: Mon, 21 Sep 2020 11:45:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF.

        Title           : Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane
        Authors         : Maria Ines Robles
                          Michael C. Richardson
                          Pascal Thubert
	Filename        : draft-ietf-roll-useofrplinfo-41.txt
	Pages           : 63
	Date            : 2020-09-21

Abstract:
   This document looks at different data flows through LLN (Low-Power
   and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
   and Lossy Networks) is used to establish routing.  The document
   enumerates the cases where RFC6553 (RPI Option Type), RFC6554
   (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
   required in data plane.  This analysis provides the basis on which to
   design efficient compression of these headers.  This document updates
   RFC6553 adding a change to the RPI Option Type.  Additionally, this
   document updates RFC6550 defining a flag in the DIO Configuration
   option to indicate about this change and updates [RFC8138] as well to
   consider the new Option Type when the RPL Option is decompressed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-41
https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-41

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-41

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Sep 2020 14:59:46 -0400

> https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-41

Hi, based upon a conversation this morning among the authors and useofrplinfo
and turnon-rfc8138, we arrived at the diffs above.

The point is that the changes to MOP and the rename of the
DODAG Configuration Options Flags registry would get done in the first
document that uses them, which is useofrplinfo.

I agreed to make the diffs required, and I hope that I got it right.

Some bits of the diff:

 4.3.  Updates to RFC6550: Configuration Options and Mode of Operation 
   
     RFC6550 section 6.7.6 describes the DODAG Configuration Option.  In 
     this option are a series of Flags in the first octet of the payload. 
     These flags are described by the DODAG Configuration Option Flags 
     registry [dodagcfg], in section 20.14 of RFC6550. 
   
     Anticipating future work to revise RPL relating to how the LLN and 
     DODAG is configured, this document changes the interpretation of the 
     [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) 
     specific.  The MOP is described in [RFC6550] section 6.3.1.  The 
     Options Flags Registry is renamed, and applies to MOP values zero (0) 
     to six (6) only, leaving the flags reserved for MOP value seven (7). 
   
     In addition, this document reserves MOP value 7 for future expansion.

...

11.2.  Changes to DODAG Configuration Options Flags 
   
     This document changes the name of the "DODAG Configuration Option 
     Flags" [dodagcfg] to "DODAG Configuration Option Flags for MOP 0..6". 
   
11.3.  Change MOP value 7 to Reserved 
   
     This document changes the allocation status of the Mode of Operation 
     (MOP) [ianamop] from Unassigned to Reserved.  This change is in 
     support of future work related to capabilities.

The MOPEX document would then allocate the value, but nobody else can use it
before then.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 21 Sep 2020 19:58:21 +0000

Hello Michael 

Many thanks for this; I agree with those diffs and will change the other 2 drafts to refer to this.

Take care,

Pascal

> Le 21 sept. 2020 à 21:01, Michael Richardson <[email-masked]> a écrit :
> 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 21 Sep 2020 13:46:28 -0700

> > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-41

Michael:

At first glance the diffs look good to me too.

But I have a question: §4.3 now reads: "For a MOP value of 7, a	node
SHOULD assume that the RPI 0x23 option is enabled."  When is it ok for
a node to assume that the RPI 0x23 option is not enabled?  IOW, why is
the behavior recommended but not required?  It seems to me that the
behavior may not be consistent.

Also, please reword so that the normative action is not to "assume";
maybe something like "use 0x23"...

Thanks!

Alvaro.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Sep 2020 21:12:55 -0400

> behavior may not be consistent.

I always like to hedge my bet with SHOULD rather than MUST :-)

I can imagine:
  1) local configuration says use 0x63.
  2) some heuristic that says, if you receive 0x63, you send 0x63.

But, I am okay with changing that to MUST.

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