Subject: [Roll] MOP 7

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Nov 2019 01:43:46 +0000

Dear all

Yesterday we said that if MOP is 7 then the MOPext is expected else the packet is dropped. An alternate could be to say that if MOP is 7 in the DIO and the MOPext is not present then the MOP is non-storing, since this is the most widely used mode in constrained networks.

We also said that a MOP of 7 means RPLv2, which packages new support we are defining. Q is what's mandatory and what's optional.
I see mandatory the support of the MOPext, capabilities, useofrplinfo, DCO and RUL draft.
RFC 8138 (inc turn-on), PDAO and AODV RPL are also part of RPLv2 but then the support may be optional I guess, known through capability.

What do you think?

Pascal

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 19 Nov 2019 17:06:22 +0800

Please find my comments inline.

Regards,
Rahul

> Yesterday we said that if MOP is 7 then the MOPext is expected else the packet is dropped. An alternate could be to say that if MOP is 7 in the DIO and the MOPext is not present then the MOP is non…

[RJ] The advantage, I assume, is that not having MOPex will save bytes
in the DIO for the common case. This would result in three
representations for non-storing MOP:
a. base MOP = 1 ... RPLv1
b. base MOP = 7 ... without MOPex ... RPLv2
c. base MOP = 7 ... MOPex = 7 ... RPLv2
For the sake of simplicity, I would prefer to mandatorily use MOPex if
MOP=7. Simplicity I refer to is, Base MOP = 7 would mean, go check
MOPex value.
>From an implementation point of view, if base MOP=7, then the
implementation still cannot start using this value of MOP=7 since it
still needs to check the MOPex.

>
>
>
> We also said that a MOP of 7 means RPLv2, which packages new support we are defining. Q is what’s mandatory and what’s optional.
>

[RJ] Thank you, Will update this set in the mopex draft.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Nov 2019 14:14:53 +0800

Rahul Jadhav <[email-masked]> wrote:
    Pascal> Yesterday we said that if MOP is 7 then the MOPext is expected
    Pascal> else the packet is dropped. An alternate could be to say that if
    Pascal> MOP is 7 in the DIO and the MOPext is not present then the MOP is
    Pascal> non-storing, since this is the most widely used mode in constrained networks. 

    > MOP=7. Simplicity I refer to is, Base MOP = 7 would mean, go check

I agree.

    Pascal> We also said that a MOP of 7 means RPLv2, which packages new
    Pascal> support we are defining. Q is what’s mandatory and what’s
    Pascal> optional.

I think that we are working on MOPex because we are concerned about running
out, and we want to establish the rules for extending things early on.

But, I don't think that we need to rush to defining "RPLv2": which I think
would imply that CAP would provide the useful info.

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Nov 2019 09:34:07 +0200

I don't agree with this message proposals, because I think it needs to be
in separate draft if we are mentioning new version of RPL, as RPLv2 which
is not submitted yet to WG. We need to make discussion/work not complicated
and within WG milestones.

On Tue, Nov 19, 2019 at 3:44 AM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Dear all
>
> *   Yesterday we said that if MOP is 7 then the MOPext is expected else
> the packet is dropped. An alternate could be to say that if MOP is 7 in the
> DIO and the MOPext is not present then the MOP is non-storing, since this
> is the most widely used mode in constrained networks. *
>

even if non storing is widely used we cannot ignore storing or mix modes,

> *   We also said that a MOP of 7 means RPLv2, which packages new support
> we are defining. Q is what’s mandatory and what’s optional.*
>

You must mean by 'We'  the group that attended, and not All the WG.
However,
I support separating RPLv2 from RPLv1,

* I see mandatory the support of the MOPext, capabilities, useofrplinfo,
> DCO and RUL draft. *

don't agree for that for RPLv1,

* RFC 8138 (inc turn-on), PDAO and AODV RPL are also part of RPLv2 but then
> the support may be optional I guess, known through capability.*
>

Why? RPLv2 is not submitted as proposal to WG, please submit if there is
one so we can understand what is your v2 (many participants may think
different versions)!

> *   What do you think?*

I think We as WG need to focus to make it simple routing not complicated,
so this MOPext is for RPLv1 only and when the draft or proposal submitted
to WG with RPLv2 subject, then we can discuss with better focus/options.

AB

> *   Pascal *
>
>
>
>
> * _______________________________________________ Roll mailing list
> [email-masked] <[email-masked]> https://www.ietf.org/mailman/listinfo/roll
> <https://www.ietf.org/mailman/listinfo/roll> *