Hello Michael

I understand that  you suggest to reverse the bit from my draft, so that it is 
set by a leaf that does not support its own routing.
I agree that this minimizes the changes to the existing. But also this means 
that I should change RFC6775-update to specify that.

I'm happy with that approach and will do it if the WG does not disagree. What 
do others think?


-----Original Message-----
From: Roll [mailto:roll-boun...@ietf.org] On Behalf Of Michael Richardson
Sent: jeudi 22 février 2018 17:57
To: Routing Over Low power and Lossy networks <r...@ietf.org>
Cc: 6lo@ietf.org
Subject: Re: [Roll] A bit for ROLL

Pascal Thubert (pthubert) <pthub...@cisco.com> wrote:
    > With RPL, and probably any other route-over protocol, there is a need
    > to signal either way, i.e. the node handles its routing (like a
    > classical RPL node) or the node expects that the 6LR will manage the
    > routing on its behalf (like a RPL leaf). The bit is IGP-agnostic, and
    > it applies to any protocol.

    > draft-thubert-roll-unaware-leaves suggests a bit that indicates that
    > the 6LR that is capable to handle its routing should signal it, so the
    > unaware leaf does not need to set it.

This *is* a new change to existing devices.

    > Q: Should the bit be defined in rfc6775-update as opposed to a ROLL
    > since it is IGP agnostic?

    > Side question: Is it the right approach or should the leaf set the bit
    > instead?

I think it depends upon whether the leaf is a legacy device.

We can't just plug a Windows7 PC into an arbitrary 802.15.4 network, because 
there generally aren't drivers.  So there really isn't a legacy question.

We almost always are creating new code, in which case we can create code which 
sets a bit which says, "Please manage my routing for me".
This is not a burden, because such leaf devices do not really exist yet.

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

6lo mailing list

Reply via email to