Subject: [Roll] DAO-Projection and new MOPs

From: Rahul Jadhav <[email-masked]>
Date: Sun, 2 Dec 2018 23:27:45 +0530

Hi Pascal, WG,

This mail is regarding concern on how to handle MOP exhaustion in DIO. With
AODV-RPL and DAO-projection we would essentially use up all the possible
MOP values. This point was raised in ROLL-sessions before but we haven't
really discussed this on ML.

To begin with, I was wondering, do we really need new MOPs for
dao-projection?
Can we handle dao-projection as something which can be incrementally added
to existing MOPs? For e.g. if the network is established in NS-MOP
(non-storing MOP=1) then we can use P-DAO to project routes down the
network and if the destination legacy node does not understand P-DAO then
it should send a negative ACK for the DAO. Problem is, right now i don't
see how legacy nodes (who dont understand new RPO options) can distinguish
between P-DAO and normal DAO.
As i understand, the new MOP is required because of this new mandatory
handling required for P-DAOs. Is it possible to have P-DAO such that legacy
nodes generate negative ACK if they cannot handle it?

Also currently we have two types of storing MOPs (in 6550), one with
multicast (MOP=3) and one without multicast (MOP=2). DAO-Projection defines
only one storing MOP. Thus as i understand in DAO-Projection draft the
storing MOP has multicast support by default. Is this ok to assume?

Regards,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 17 Dec 2018 07:36:13 +0000

Sorry for the delay, Rahul,  I’m dequeueing stuff now : )

I’m unclear on that. I think a legacy implementation will badly react to a weirdly formed message and the root will not know. How can we know?
I believe we need a new draft for MOP extender (use a MOP for saying that) and then use a field somewhere to define new MOPs.
This could be done quite quickly happy to help make that happen.

Take care,

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: dimanche 2 décembre 2018 18:58
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] DAO-Projection and new MOPs

Hi Pascal, WG,

This mail is regarding concern on how to handle MOP exhaustion in DIO. With AODV-RPL and DAO-projection we would essentially use up all the possible MOP values. This point was raised in ROLL-sessions before but we haven't really discussed this on ML.

To begin with, I was wondering, do we really need new MOPs for dao-projection?
Can we handle dao-projection as something which can be incrementally added to existing MOPs? For e.g. if the network is established in NS-MOP (non-storing MOP=1) then we can use P-DAO to project routes down the network and if the destination legacy node does not understand P-DAO then it should send a negative ACK for the DAO. Problem is, right now i don't see how legacy nodes (who dont understand new RPO options) can distinguish between P-DAO and normal DAO.
As i understand, the new MOP is required because of this new mandatory handling required for P-DAOs. Is it possible to have P-DAO such that legacy nodes generate negative ACK if they cannot handle it?

Also currently we have two types of storing MOPs (in 6550), one with multicast (MOP=3) and one without multicast (MOP=2). DAO-Projection defines only one storing MOP. Thus as i understand in DAO-Projection draft the storing MOP has multicast support by default. Is this ok to assume?

Regards,
Rahul

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Dec 2018 12:51:47 -0500

I strongly believe that we should have a specific new MOP:
  "Non-storing with DAO-project"

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 17 Dec 2018 19:57:22 +0000

I agree Michael 

Trouble is that there is no room left in MOP space (3 bits). We’ll soon need to define a value to mean extended.

Regards,

Pascal

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

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Tue, 18 Dec 2018 03:52:22 +0000

I'm wondering apart from MOP extension, it would be nice to have capability flags in DIO. 
1. Capabilities field can work with ext-MOP to handshake additional capabilities ..
2. Even leaf nodes can understand capabilities ... unlike MOP which is relevant only to routers.
Capabilities may be optional to support unlike MOP which is mandatory to be supported if the node is to be a 6LR in the instance.

> -----Original Message-----
> From: Roll [mailto:[email-masked]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: 18 December 2018 01:27
> Subject: Re: [Roll] DAO-Projection and new MOPs
> 
> I agree Michael
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Dec 2018 07:42:11 +0000

All for it. What do others think?

> From: Roll <[email-masked]> On Behalf Of Rahul Arvind Jadhav
> Sent: mardi 18 décembre 2018 04:52
> Capabilities may be optional to support unlike MOP which is mandatory to be
> supported if the node is to be a 6LR in the instance.
> 
> 
> > Trouble is that there is no room left in MOP space (3 bits). We’ll
> > soon need to define a value to mean extended.
> >
> >
> > Regards,
> >
> > Pascal
> >
> > > Le 17 déc. 2018 à 18:52, Michael Richardson <[email-masked]>
> > > a
> > écrit :
> > >
> > >

---

From: Peter van der Stok <[email-masked]>
Date: Tue, 18 Dec 2018 09:21:51 +0100

sounds reasonable,

Peter
Pascal Thubert (pthubert) schreef op 2018-12-18 08:42:

> Trouble is that there is no room left in MOP space (3 bits). We'll
> a écrit : 
> Michael Richardson <[email-masked]>, Sandelman Software Works -= IPv6 IoT consulting =-
> 
> https://www.ietf.org/mailman/listinfo/roll _______________________________________________
> Roll mailing list
> [email-masked]

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Tue, 18 Dec 2018 10:21:40 +0100

Hello Pascal,

I will support such document. 
I would be happy to help.

Georgios

> On Dec 18, 2018, at 08:42, Pascal Thubert (pthubert) <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Dec 2018 11:34:41 -0500

> need to define a value to mean extended.

3bits = 8 choices.  We have four choices now.
Did MOP=0 ever have useful meaning?  (Tell me the use case...)

I'd redefine that to mean extended, or 7 if we have to...
But for the moment, I don't see why we can't allocate MOP=4 for this.
I don't think new MOP's come along that often.

    >> _______________________________________________ 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: Michael Richardson <[email-masked]>
Date: Tue, 18 Dec 2018 11:35:53 -0500

Rahul Arvind Jadhav <[email-masked]> wrote:
    > 2. Even leaf nodes can 
    > understand capabilities ...

I think we should continue this conversation.
Are they negotiated, or simply declared? ("I can do X")

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

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 18 Dec 2018 22:14:41 +0530

Currently we have,
4 MOPs defined in 6550,
1 MOP defined in p2p-rpl/6997,
1 in aodv-rpl,
2 are needed for dao projection.

Thus all 8 mops will be used and none left. Thus mop extension may have to
be handled before dao projection since extension will take one mop itself.

I am curious to know also if mop=0 is put to use by any one.

Regards,
Rahul

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Dec 2018 12:00:46 -0500

Rahul Jadhav <[email-masked]> wrote:
    > dao-projection?  Can we handle dao-projection as something which can be
    > incrementally added to existing MOPs? For e.g. if the network is
    > established in NS-MOP (non-storing MOP=1) then we can use P-DAO to
    > project routes down the network and if the destination legacy node does
    > not understand P-DAO then it should send a negative ACK for the DAO.
    > Problem is, right now i don't see how legacy nodes (who dont understand
    > new RPO options) can distinguish between P-DAO and normal DAO.  As i
    > understand, the new MOP is required because of this new mandatory
    > handling required for P-DAOs. Is it possible to have P-DAO such that
    > legacy nodes generate negative ACK if they cannot handle it?

We have lots of ICMP code fields available, we could do:

   o  0x04: Projected Destination Advertisement Object 

If we want to be able to incrementally deploy P-DAO, then we need to be sure
that devices will send some kind of negative statement back for ICMP codes
that are unknown.  It's supposed to be an ICMP parameter error, but maybe not
everything does that.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 19 Dec 2018 06:44:32 +0200

> All for it. What do others think?

I think I posted a message before months about this MOP problem but no
reply from the list, but now seems there started a discussion, but yes the
MOP should be more than 3 bit. I suggest modifying that RFC that specifies
3 bits, I don't support extending but changing.

> > I'm wondering apart from MOP extension, it would be nice to have
> capability
> > flags in DIO.
> > 2. Even leaf nodes can understand capabilities ... unlike MOP which is
> relevant
> > only to routers.

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 19 Dec 2018 06:52:29 +0200

>   "Non-storing with DAO-project"

I disagree, because there is shortage of MOP. IMHO it needs to be planned
well for those all 8 options for all use-cases of ROLL, otherwise, we plan
to change the MOP number of bits so we cover most of ROLL use-cases. I
mentioned this before on the list when AODV first used one MOP, but not
much participants discussed it.

AB

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Wed, 19 Dec 2018 06:33:07 +0000

Actually this (new ICMP code) would have worked very nicely but as you mentioned the legacy nodes won't send back any response for unknown codes.

I checked whether 6550 has an explicit statement and it does.

Section 6:
 "If a node receives a RPL control message with an unknown Code field,
   the node MUST discard the message without any further processing, MAY
   raise a management alert, and MUST NOT send any messages in response."

> From: Roll [mailto:[email-masked]] On Behalf Of Michael Richardson
> Sent: 18 December 2018 22:31
> If we want to be able to incrementally deploy P-DAO, then we need to be
> sure that devices will send some kind of negative statement back for ICMP
> codes that are unknown.  It's supposed to be an ICMP parameter error, but
> maybe not everything does that.
> 
> --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 19 Dec 2018 07:12:39 +0000

Hello Abdussalam

We do care about backwards compatibility. And we do not change RFCs. What we do is publish new RFCs the supersede the old for new devices in a spirit of maintaining maximum compatibility with old devices.

Regards,

Pascal

Le 19 déc. 2018 à 05:45, Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> a écrit :

On Tue, Dec 18, 2018 at 9:42 AM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
All for it. What do others think?

I think I posted a message before months about this MOP problem but no reply from the list, but now seems there started a discussion, but yes the MOP should be more than 3 bit. I suggest modifying that RFC that specifies 3 bits, I don't support extending but changing.

> From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Rahul Arvind Jadhav
> To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
> > From: Roll [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Pascal Thubert
> > (pthubert)
> > To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
> > > Le 17 déc. 2018 à 18:52, Michael Richardson <[email-masked]<mailto:[email-masked]>>
> > > a
> > écrit :
> > >
> > >
> > > Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software
> > Works
> > > Roll@ietf..org<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Arvind Jadhav <[email-masked]>
Date: Wed, 19 Dec 2018 09:18:59 +0000

>     > capability flags in DIO.

I had simple declaration in mind but negotiation would be more powerful and also does not add much overhead. We already have the signaling primitives (DIO-DAO-ACK)to handle it. Capabilities can be a new rpl control message option and optionally added if required in RPL ctrl msg.
Do we require to tag optional data along with capabilities flag?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Dec 2018 18:24:09 -0500

Rahul Arvind Jadhav <[email-masked]> wrote:
    > Actually this (new ICMP code) would have worked very nicely but as you
    > mentioned the legacy nodes won't send back any response for unknown
    > codes.

    > Section 6: "If a node receives a RPL control message with an unknown
    > Code field, the node MUST discard the message without any further
    > processing, MAY raise a management alert, and MUST NOT send any
    > messages in response."

maybe this deserves an update as well then :-)

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 20 Dec 2018 04:42:00 +0200

Hi Pascal,

I know what we can do and can not do. If something is wrong we can fix it
as technology is changing.

On Wed, Dec 19, 2018 at 9:12 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Abdussalam
>
> We do care about backwards compatibility.
>

I don't mind backwards but with good planning, it seems there was no good
plan in the first design.

And we do not change RFCs.

We do comment on all old RFCs to change in future. We do obsolete and new
RFC take over, it happens all the time in IETF.

> What we do is publish new RFCs the supersede the old for new devices in a
> spirit of maintaining maximum compatibility with old devices.
>

That is one solution approach, but there are other solutions, don't forget
that IPv6 is changing full protocol of IPv4 and not compatible, it was IETF
creation, so it is ok in our group if we agree on such approach. Changing
MOP is not changing the protocol.

AB

>
> Regards,
>
> Pascal
>
> Le 19 déc. 2018 à 05:45, Abdussalam Baryun <[email-masked]> a
> écrit :
>
>
>
>> > > > Roll@ietf..org <[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 20 Dec 2018 06:11:04 +0000

Hello all:

Note that we will need capabilities of the RPL node passed to the root. This is needed to express neighborhood, amount of free resources to install routes, etc... this way a node can signal support for this spec to the root.

Whether the root expects that can be added to the configuration options, we have a reserved space there.

Regards,

Pascal

> Le 20 déc. 2018 à 00:24, Michael Richardson <[email-masked]> a écrit :
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 22 Dec 2018 20:36:37 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > Note that we will need capabilities of the RPL node passed to the
    > root. This is needed to express neighborhood, amount of free resources
    > to install routes, etc... this way a node can signal support for this
    > spec to the root.

This is probably the key part of what we need to do any useful extensions:
node capabilities.  The non-storing DAO message clearly is a place to do
this. The question is how to encode the capabilities?

(I think that they likely need to be encoded by reference)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 23 Dec 2018 08:01:43 +0000

Hello Michael 

I think we voted to make that to separate draft though it is needed for P DAO to get a complete solution. I agree the capabilities could be compressed, e.g., reference to well-known sets as opposed to list.

Regards,

Pascal

> Le 23 déc. 2018 à 02:36, Michael Richardson <[email-masked]> a écrit :
> 
>