Subject: [Roll] on omitting RPI artifact in downward routes in non-storing mode

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Sep 2018 12:55:45 -0400

Ines and I, in dealing with the review from Alvaro have clarified the text
in section 5 to say:

from:
   RPI should be present in every single RPL data packet.  There is one

to:
            RPI SHOULD be present in every single RPL data packet. There is one
            exception in non-storing mode: when a packet is going down from the
            root the RPI MAY be omitted.

            The rational is that in a downward non-storing mode, the entire
            route is written, so there can be no loops by construction, nor any
            confusion about which forwarding table to use (as the root has
            already made all routing decisions).  However, there are still
            cases, such as in 6tisch, where the instanceID portion of the RPI
            header may still be needed to pick an appropriate priority or
            channel at each hop.

So, we have a situation where there is one case where the RPI might not be
present, and we have an exception to THAT exception.  That seems like a lot
of code complexity.  Given compression of the RPI is defined now, maybe
having this exception is DUMB...

Since the receiver MUST deal with upward traffic that has the RPI, then it
has to be able to process the header (compressed or not) anyway.

I'd like to remove the exception (the "MAY be ommitted"), and just make
the SHOULD a MUST.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Sep 2018 19:13:00 +0000

Hello Michael 

The RPI is needed by 6LoRH to compress the routing header. It carries the instance ID from which the root it deducted so we can compress  addresses using it as reference. 

So please no, do not allow to omit the RPI, unless, maybe, you indicate that the implicit meaning is instance 0...

Cheers,

Pascal

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Sep 2018 01:02:12 -0400

Pascal Thubert \(pthubert\) <pthubert=[email-masked]> wrote:
    > The RPI is needed by 6LoRH to compress the routing header. It carries
    > the instance ID from which the root it deducted so we can compress
    > addresses using it as reference.

    > So please no, do not allow to omit the RPI, unless, maybe, you indicate
    > that the implicit meaning is instance 0...

Good, you are agree with me that allowing the RPI to be ommited in this
very very specific case is a code complexity we should avoid.

    >> Ines and I, in dealing with the review from Alvaro have clarified the
    >> text in section 5 to say:
    >>
    >> from: RPI should be present in every single RPL data packet.  There is
    >> one
    >>
    >> to: RPI SHOULD be present in every single RPL data packet. There is
    >> one exception in non-storing mode: when a packet is going down from
    >> the root the RPI MAY be omitted.
    >>
    >> The rational is that in a downward non-storing mode, the entire route
    >> is written, so there can be no loops by construction, nor any
    >> confusion about which forwarding table to use (as the root has already
    >> made all routing decisions).  However, there are still cases, such as
    >> in 6tisch, where the instanceID portion of the RPI header may still be
    >> needed to pick an appropriate priority or channel at each hop.
    >>
    >>
    >> So, we have a situation where there is one case where the RPI might
    >> not be present, and we have an exception to THAT exception.  That
    >> seems like a lot of code complexity.  Given compression of the RPI is
    >> defined now, maybe having this exception is DUMB...
    >>
    >> Since the receiver MUST deal with upward traffic that has the RPI,
    >> then it has to be able to process the header (compressed or not)
    >> anyway.
    >>
    >> I'd like to remove the exception (the "MAY be ommitted"), and just
    >> make the SHOULD a MUST.
    >>
    >> --
    >> _______________________________________________ Roll mailing list
    >> [email-masked] https://www.ietf.org/mailman/listinfo/roll
    > _______________________________________________ Roll mailing list
    > [email-masked] https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Sep 2018 05:30:54 +0000

Yes, Michael.

I was unclear what your suggestion was parsing your mail. RPI is needed. We can refer to RFC 8138 to support that assertion.

Regards,

Pascal

> Le 6 sept. 2018 à 07:02, Michael Richardson <[email-masked]> a écrit :
> 
> 
>>> Le 5 sept. 2018 à 18:56, Michael Richardson <mcr+ietf@sandelman..ca> a
>>> écrit :
>>> 
>>>