Subject: [Roll] Which functions in RPLv2?

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Sep 2020 11:29:17 +0000

Hello Rahul

I renamed the thread.

In your first list 1..5 I'd say they are all mandatory and the first 2 always on.

There's also:
6) P-DAO for SDN-RPL and
7) AODV-RPL.
I'd make those 2 optional

And yes I believe that the points in observations need to be addressed.
Each deserves a thread I believe. Let me start a few based on your email as well...

Take care,

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: lundi 14 septembre 2020 12:38
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] roll WG Virtual Meeting: 2020-09-30 - Call for Agenda Items-

Will now be the right time to check consensus with the WG on what behaviour may have to be mandated as part of RPLv2?

Following are some of the points which immediately comes to my mind:

1. Use of revised Option Type (0x23) in RPI ... (Obsolete use of 0x63 RPI Option Type value).
2. Mandating the use of 6LoRH (RFC 8138) ... (Allows compression of SRH (non-storing) and RPI (storing mode)). This is something that was discussed in context to turnon-8138 T-bit draft recently.
3. Use of MOPex (This is how we know the instance is RPLv2)
4. Support for Ext Control Options. (Allows Backward compatibility for new extns... part for same mopex draft)
5. Support for Capabilities. (Enables backward compatibility, allows incremental feature support)

There are some points from RPL Observations draft [2] which could be clarified as part of this work item. Not sure if those points could go in as part of this draft? For e.g., Path Control Bits handling issue in 6550 [1] ... 2) Mandating handling (not sending) of multiple targets in DAO [3]

WG could provide feedback on the following aspects:
1. Do you feel one of the points above need not be mandated?
2. Do you feel there is some other point which needs to be addressed?

[1] https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04#section-10
[2] RPL Observations: https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04
[3] https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04#section-7

________________________________
From: Roll <[email-masked]<mailto:[email-masked]>> on behalf of Michael Richardson <[email-masked]<mailto:[email-masked]>>
Sent: 14 September 2020 02:09 PM
To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Roll] roll WG Virtual Meeting: 2020-09-30 - Call for Agenda Items-

Georgios PAPADOPOULOS <[email-masked]<mailto:[email-masked]>> wrote:
    > Regarding the RPLv2, do you think it would be possible to have at the
    > end of the day everything in one single document?

Yes, eventually, we'd do rfc6550bis, and we'd merge in all the documents,
throw out the pieces that we didn't implement, and maybe advance to Internet Standard.

    > In stead of going over multiple documents, and multiple RFCs tomorrow,
    > imho, it would be more efficient to have one single RFC for the RPLv2
    > like the RFC 6550 for RPL.

    > What do you think?

It's just too soon.
We actually need to sort out the things we want to do.
Editing the huge rfc6550 won't be productive at this point.

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Ines Robles <[email-masked]>
Date: Mon, 14 Sep 2020 16:37:00 +0300

Hi,

Suggested topics are collected here:
https://github.com/roll-wg/RPL_v2_topics

Thank you,

Ines

On Mon, Sep 14, 2020 at 2:30 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Hello Rahul
>
>
>
> I renamed the thread.
>
>
>
> In your first list 1..5 I’d say they are all mandatory and the first 2
> always on.
>
>
>
> There’s also:
>
> 6) P-DAO for SDN-RPL and
>
> 7) AODV-RPL.
>
> I’d make those 2 optional
>
>
>
> Each deserves a thread I believe. Let me start a few based on your email
> as well…
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* Roll <[email-masked]> *On Behalf Of *Rahul Jadhav
> *Sent:* lundi 14 septembre 2020 12:38
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> *Subject:* Re: [Roll] roll WG Virtual Meeting: 2020-09-30 - Call for
> Agenda Items-
>
>
>
> Will now be the right time to check consensus with the WG on what
> behaviour may have to be mandated as part of RPLv2?
>
>
>
> 2. Mandating the use of 6LoRH (RFC 8138) ... (Allows compression of SRH
> (non-storing) and RPI (storing mode)). This is something that was discussed
> in context to turnon-8138 T-bit draft recently.
>
> There are some points from RPL Observations draft [2] which could be
> clarified as part of this work item. Not sure if those points could go in
> as part of this draft? For e.g., Path Control Bits handling issue in 6550
> [1] ... 2) Mandating handling (not sending) of multiple targets in DAO [3]
>
>
>
> [1]
> https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04#section-10
>
> [2] RPL Observations:
> https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04
>
> [3]
> https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04#section-7
>
>
>
>
> ------------------------------
>
> *From:* Roll <[email-masked]> on behalf of Michael Richardson <
> [email-masked]>
> *Sent:* 14 September 2020 02:09 PM
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> *Subject:* Re: [Roll] roll WG Virtual Meeting: 2020-09-30 - Call for
> Agenda Items-
>
>
>
>
> Georgios PAPADOPOULOS <[email-masked]> wrote:
> Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 14 Sep 2020 10:58:51 -0400

Rahul> Will now be the right time to check consensus with the WG on what
    Rahul> behaviour may have to be mandated as part of RPLv2?

I don't believe that it's yet time to do that.

I think that the path is to design and deploy capabilities.
To my mind, RPLv2 is not a set of knobs that are mandated to be on, but
rather the ability to determine what is available and turn them on.

Sure, we may well write a document that says all of your three points are
mandatory to implement, and turned on by default.