Subject: [Roll] comments on mopex-cap-00

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Aug 2019 16:47:18 -0400

1) If Capabilities and MOD-Extension are mutually independent, why is it in one document?

2) MOP clearly applies to the entire DODAG.
   I don't know if Capabilities do from the description:

   REQ3:  Optional capabilities handshake.  Capabilities are features,
          possibly optional, which could be handshaked between the nodes
          and the root within an RPL Instance.

   Are they things that the root tells nodes, or things that the node
   tells the root?  Are they individualized, or does every node in the
   LLN have to support a capability before it can be used?

3) I argued before against the Extended-MOP-value being added to the Base
   MOP. I prefer that the value 7 means *replace* the MOP with the MOPex.
   Yes, that results in two ways to encode MOP="3", but I think that it
   leads to far less confusing code.

4) 3.2, if the MOP is not 7, and the MOPex is present, what does this mean?
   (Nothing, I think it should be ignored)
   Would we really ever assign a new the value 7?

5) section 4.0:

>   Note that capabilities and MOPex are mutually exclusive and it is
>   possible for an implementation to support either or both of the
>   options.

I think that you mean, not mutually exclusive?

4.1: >There are no capability flags defined by this document.

that makes it really hard to know how they work :-)

4.2: use of "could" is very non-normative.

>   Capabilities
>   advertised by non-root nodes are strictly a subset of the
>   capabilities advertised by the root.

This should be in REQ3.

7.1/7.3. If you take my advance about not adding, but replacing, then this
document would Update the Mode of Operation registry, and we would not need
a new registry.

==== having done all of this.

How will DAO-projection signal itself?  It seems like a capability to me.
I haven't read that document in a few months.  If it uses capability, then
this document that creates capabilities SHOULD probably allocate a bit in
it's initial table.

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

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Sun, 25 Aug 2019 11:07:38 +0000

Thanks Michael for the review and feedback.

Please find my comments inline.

1) If Capabilities and MOD-Extension are mutually independent, why is it in one document?
[RJ] I raised the possibility of keeping it in separate document in IETF 104. But no one voiced any specific reason to separate it out. Even though semantically the Capabilities and MOP-Extns are mutually independent, some of the scenarios discussions might require to discuss them together. Do you believe we should separate it out and if there is any advantage doing so?

   tells the root?  

[RJ]: MOP is indicated by the root and the whole network has to follow it. The capabilities on the other hand are node specific. For e.g., the end node can indicate that it supports a primitive via cap flag and this info could be used by the root and vice-versa.
The answer to your questions above is, "Both".

Are they individualized, or does every node in the
   LLN have to support a capability before it can be used?
[RJ]: Nice point. I haven't thought about this in detail. In non-storing MOP, it may not be required that all the nodes support capabilities but in storing MOP, every 6LR needs to add the cap (if present) of the downstream child, thus requiring every node to support it. This definitely needs handling in the draft.
[Ref: https://github.com/roll-wg/MOPex-capabilities/issues/1]

3) I argued before against the Extended-MOP-value being added to the Base
   MOP. I prefer that the value 7 means *replace* the MOP with the MOPex.
   Yes, that results in two ways to encode MOP="3", but I think that it
   leads to far less confusing code.
[RJ]: I am ok with this approach. Will update the document.
[Ref: https://github.com/roll-wg/MOPex-capabilities/issues/2]

4) 3.2, if the MOP is not 7, and the MOPex is present, what does this mean?
   (Nothing, I think it should be ignored)
   Would we really ever assign a new the value 7?
[RJ] With point 3 accepted, this point is not relevant anymore. (?)

I think that you mean, not mutually exclusive?
[RJ] I meant that caps and MOPex do not depend on each other and are mutually independent. May be I should :s/exclusive/independent/ 

that makes it really hard to know how they work :-)
[RJ] Yeah, should have added an example. Will be done in the next update.
[Ref: https://github.com/roll-wg/MOPex-capabilities/issues/3]

>   capabilities advertised by the root.

This should be in REQ3.
[RJ] Actually I am not sure that this will be true going forward. Why can't a intermediate 6LR add its own capability in DIO (without depending on root) for its downstream childs? If this is the case then the draft's above statement is not true. I am glad you pointed this out and wish to discuss more on this.

7.1/7.3. If you take my advance about not adding, but replacing, then this document would Update the Mode of Operation registry, and we would not need a new registry.

How will DAO-projection signal itself?  It seems like a capability to me.
I haven't read that document in a few months.  If it uses capability, then this document that creates capabilities SHOULD probably allocate a bit in it's initial table.
[RJ] I am considering this for the example use-case of caps

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 26 Aug 2019 09:31:45 +0000

Hello Michael

There were headwinds against flooding the IESG with too many small documents. Now, we ma be wrong in this case and I'm perfectly OK to split if the ADs recommend to do so.
In this case, we have 2 functions which, though logically separate, are both needed infrastructure. This gives us an infrastructure uplift spec and a single reference for all the work that will build on it. 
As Rahul says some new components will need a bit of both at the same time. So keeping together is defensible.

All the best,

Pascal

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Rahul Arvind Jadhav
> Sent: dimanche 25 août 2019 13:08
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: Re: [Roll] comments on mopex-cap-00
> 
> [RJ] I raised the possibility of keeping it in separate document in IETF 104. But
> no one voiced any specific reason to separate it out. Even though semantically
> the Capabilities and MOP-Extns are mutually independent, some of the
> scenarios discussions might require to discuss them together. Do you believe
> we should separate it out and if there is any advantage doing so?
> 
> [RJ]: MOP is indicated by the root and the whole network has to follow it. The
> capabilities on the other hand are node specific. For e.g., the end node can
> indicate that it supports a primitive via cap flag and this info could be used by
> the root and vice-versa.
> [RJ]: Nice point. I haven't thought about this in detail. In non-storing MOP, it
> may not be required that all the nodes support capabilities but in storing
> MOP, every 6LR needs to add the cap (if present) of the downstream child,
> thus requiring every node to support it. This definitely needs handling in the
> draft.
> [RJ] I meant that caps and MOPex do not depend on each other and are
> mutually independent. May be I should :s/exclusive/independent/
> 
> that makes it really hard to know how they work :-) [RJ] Yeah, should have
> added an example. Will be done in the next update.
> [RJ] Actually I am not sure that this will be true going forward. Why can't a
> intermediate 6LR add its own capability in DIO (without depending on root)
> for its downstream childs? If this is the case then the draft's above statement
> is not true. I am glad you pointed this out and wish to discuss more on this.
> 
> document would Update the Mode of Operation registry, and we would not
> need a new registry.
> 
> I haven't read that document in a few months.  If it uses capability, then this
> document that creates capabilities SHOULD probably allocate a bit in it's initial
> table.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Aug 2019 19:57:27 -0400

Rahul Arvind Jadhav <[email-masked]> wrote:
    RJ> I raised the possibility of keeping it in separate document in IETF
    RJ> 104. But no one voiced any specific reason to separate it out. Even
    RJ> though semantically the Capabilities and MOP-Extns are mutually
    RJ> independent, some of the scenarios discussions might require to
    RJ> discuss them together. Do you believe we should separate it out and
    RJ> if there is any advantage doing so?

I think that it will be easier for reviewers if the two parts are clearly
separated.  On the other hand, both parts deal with how to do extensions to
the RPL control plane, and there is a non-trivial fixed cost to processing an
RFC.

    mcr> 2) MOP clearly applies to the entire DODAG.  I don't know if
    mcr> Capabilities do from the description:

    doc>    REQ3: Optional capabilities handshake.  Capabilities are features,
    doc> possibly optional, which could be handshaked between the nodes and the
    doc> root within an RPL Instance.

    mcr>    Are they things that the root tells nodes, or things that the node
    mcr> tells the root?

    RJ> MOP is indicated by the root and the whole network has to follow
    RJ> it. The capabilities on the other hand are node specific. For e.g.,
    RJ> the end node can indicate that it supports a primitive via cap flag
    RJ> and this info could be used by the root and vice-versa.  The answer
    RJ> to your questions above is, "Both".

okay, so probably need to have two requirements, and we need to clearly
delineate the two behaviours.

    mcr> Are they individualized, or does every node in the LLN have to support
    mcr> a capability before it can be used?

    rj> Nice point. I haven't thought about this in detail. In non-storing
    rj> MOP, it may not be required that all the nodes support capabilities
    rj> but in storing MOP, every 6LR needs to add the cap (if present) of
    rj> the downstream child, thus requiring every node to support it. This
    rj> definitely needs handling in the draft.  [Ref:
    rj> https://github.com/roll-wg/MOPex-capabilities/issues/1]

I'll start a new thread.

    > 5) section 4.0:

    doc> Note that capabilities and MOPex are mutually exclusive and it is
    doc> possible for an implementation to support either or both of the
    doc> options.

    mcr> I think that you mean, not mutually exclusive?

    rj> I meant that caps and MOPex do not depend on each other and are
    rj> mutually independent. May be I should :s/exclusive/independent/

yes.

    mcr> How will DAO-projection signal itself?  It seems like a capability to
    mcr> me.  I haven't read that document in a few months.  If it uses
    mcr> capability, then this document that creates capabilities SHOULD
    mcr> probably allocate a bit in it's initial table.

    RJ> I am considering this for the example use-case of caps

If DAO-projection references this document, then they will likely become a
set when published, and we coud probably get them reviewed together.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Aug 2019 20:46:45 -0400

I asked:

    rj> https://github.com/roll-wg/MOPex-capabilities/issues/1

I see:

1) the root announces a capability.  6LRs that understand it may use the
   new capability unilaterally if they understand it, and see a need for it.
   Nodes that do not understand the new capability are not affected.
   This could be a control plane thing, or a data plane thing.

2) the root announces support for capability that it wishes to enable, in
   order for it be used, every node must support it.  If every DAO from
   every node supports the capability, then the root announces that it
   is turned on.
   This in effect is a two-pass system, requiring either two capability
   bits.
   It might be that it is better to encode these two bits are three
   values (plus 00-not supported).

3) any 6LR may announce a capability to it's children that it received from
   it's parent, if it understands that capability.  If it does not, then
   it MUST clear the capability.

   This can be a unilateral capability (like 1), or one that has to be
   confirmed (like 2).  So this is really 3A and 3B.

4) any 6LR may announce a capability to it's children, even if it did not
   receive it from a parent.  The capability is not to be repeated by
   the children (regardless of whether they understand it), unless they also
   wish to enable it.

I therefore see several issues to resolve.
For capabilities that a node understands, it can know which type of
capability it is.  For a capability that is unknown, if the behaviour
is other than "set to zero", then we need to tell the node what kind of
capability it is, and how it is encoded.

Counting above, I see (1)-available, (2)-query, (2)-enable, (3)-available,
(3)-query, (3)-enable, (4)-available.  Conveniently, 7 things, plus all
zeros.  We could encode capabilities in three bits, so the behaviour would
be part of the encoded.

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Tue, 27 Aug 2019 13:18:23 +0000

I see:

[RJ] The problem may be in the other direction, .. In storing MOP, how 
should a 6LR which does not understand capability treat a DAO containing 
capability? Also how should a 6LR treat an unknown option in general? 
6550 mentions how to treat unknown RPL code but there is no handling 
for unknown option in DIO/DAO. Is there? I searched and could not find.
Most of the existing implementations just ignore what they don't 
understand.

[RJ] Another scenario could be that Root announces support for an 
optional capability. The 6LN just needs to know whether it could 
make use of this capability of the root to do something. It may not 
need to reply back to the root saying I see it and I support it.
Also should we be using two capability bits or we could use the info 
on whether the bit is set in DIO/DAO to infer the direction.

   This can be a unilateral capability (like 1), or one that has to be
   confirmed (like 2).  So this is really 3A and 3B.
[RJ] I get 3A .. but do we really need 3B. I mean if the node also needs 
to indicate that it also supports the same capability to the root then it 
can set the same bit in the DAO and send it back ... Thus working in 
both directions. It may not be required that capabilities be handshaked 
in both directions mandatorily. For e.g., root may indicate the capability 
that it has access to 6BBR and that unaware leaves could register 
through 6LRs. Thus 6LRs could proxy the NS (EARO) and other relevant 
messages. In this case, is it needed that 6LR reply back to the root 
saying it supports unaware leaves?
There might be another example which requires 6LRs/6LNs to indicate
in the reply that it supports the feature asked by root using the same 
cap bit in DAO. The DIO/DAO decides the direction but the bit can be 
the same.

[RJ] agree

I therefore see several issues to resolve.
For capabilities that a node understands, it can know which type of capability it is.  For a capability that is unknown, if the behaviour is other than "set to zero", then we need to tell the node what kind of capability it is, and how it is encoded.

Counting above, I see (1)-available, (2)-query, (2)-enable, (3)-available, (3)-query, (3)-enable, (4)-available.  Conveniently, 7 things, plus all zeros.  We could encode capabilities in three bits, so the behaviour would be part of the encoded.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Aug 2019 13:49:14 -0400

Rahul Arvind Jadhav <[email-masked]> wrote:
    mcr> Are they individualized, or does every node in the LLN have to
    mcr> support a capability before it can be used?

    > 1) the root announces a capability.  6LRs that understand it may use
    > the new capability unilaterally if they understand it, and see a need
    > for it.  Nodes that do not understand the new capability are not
    > affected.  This could be a control plane thing, or a data plane thing.

    RJ> The problem may be in the other direction, .. In storing MOP, how
    RJ> should a 6LR which does not understand capability treat a DAO
    RJ> containing capability? Also how should a 6LR treat an unknown option
    RJ> in  general?  6550 mentions how to treat unknown RPL code but there
    RJ> is no handling for unknown option in DIO/DAO. Is there? I searched
    RJ> and could not find.  Most of the existing implementations just ignore
    RJ> what they  don't understand.

There is the case where an implementation does not understand the capability
extension, in which case, it likely does not copy it down, and no node below
that node can use that capability, even if would be safe.  The children could
hear other DIOs via other paths, so all is not lost.

I'm trying to address the case where the capability extension is passed on,
but the node may not know the specific capablity that was listed.

    > 2) the root announces support for capability that it wishes to enable,
    > in order for it be used, every node must support it.  If every DAO from
    > every node supports the capability, then the root announces that it is
    > turned on.  This in effect is a two-pass system, requiring either two
    > capability bits.  It might be that it is better to encode these two
    > bits are three values (plus 00-not supported).

    RJ> Another scenario could be that Root announces support for an optional
    RJ> capability. The 6LN just needs to know whether it could make use of
    RJ> this capability of the root to do something. It may not need to reply
    RJ> back to the root saying I see it and I support it.  Also should we be
    RJ> using two capability bits or we could use the info on whether the bit
    RJ> is set in DIO/DAO to infer the direction.

That's case (1).
Case (2) is where the root wants to enable use of some capability, but to do
so, it needs to know if all nodes support it.  This where we need a discover
operation followed by an enable operation.  

    > 3) any 6LR may announce a capability to it's children that it received
    > from it's parent, if it understands that capability.  If it does not,
    > then it MUST clear the capability.

    > confirmed (like 2).  So this is really 3A and 3B.

    RJ> I get 3A .. but do we really need 3B. I mean if the node also needs
    RJ> to indicate that it also supports the same capability to the root
    RJ> then it can set the same bit in the DAO and send it back ... Thus
    RJ> working in both directions. It may not be required that capabilities
    RJ> be handshaked in both directions mandatorily. For e.g., root may
    RJ> indicate the capability that it has access to 6BBR and that unaware
    RJ> leaves could register through 6LRs. Thus 6LRs could proxy the NS
    RJ> (EARO) and other relevant messages. In this case, is it needed that
    RJ> 6LR reply back to the root saying it supports unaware leaves?  There
    RJ> might be another example which requires 6LRs/6LNs to indicate in the
    RJ> reply that it supports the feature asked by root using the same cap
    RJ> bit in DAO. The DIO/DAO decides the direction but the bit can be the
    RJ> same.

But, (3) is about an intermediate node announcing it can do something for its
children (and grandchildren).  

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