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

[Michael Richardson]

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 <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

[Pascal Thubert (pthubert)]

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 <mcr+***@sandelman.ca> a écrit :
>
>
> 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 <mcr+***@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Roll mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/roll

[Michael Richardson]

Pascal Thubert \(pthubert\) <pthubert=***@dmarc.ietf.org> 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.


>> Le 5 sept. 2018 à 18:56, Michael Richardson <mcr+***@sandelman..ca> a
>> écrit :
>>
>>
>> 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 <mcr+***@sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>>
>>
>>
>> _______________________________________________ Roll mailing list
>> ***@ietf.org https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________ Roll mailing list
> ***@ietf.org https://www.ietf.org/mailman/listinfo/roll

--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-

[Pascal Thubert (pthubert)]

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 <mcr+***@sandelman.ca> a écrit :
>
>
> Pascal Thubert \(pthubert\) <pthubert=***@dmarc.ietf.org> 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.
>
>
>>> Le 5 sept. 2018 à 18:56, Michael Richardson <mcr+***@sandelman..ca> a
>>> écrit :
>>>
>>>
>>> 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 <mcr+***@sandelman.ca>, Sandelman Software Works
>>> -= IPv6 IoT consulting =-
>>>
>>>
>>>
>>> _______________________________________________ Roll mailing list
>>> ***@ietf.org https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________ Roll mailing list
>> ***@ietf.org https://www.ietf.org/mailman/listinfo/roll
>
> --
> Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Roll mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/roll