Re: [Roll] Which functions in RPLv2?

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=
40cisco.com@dmarc.ietf.org> 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
>
>
>
> 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 <roll-bounces@ietf.org> *On Behalf Of *Rahul Jadhav
> *Sent:* lundi 14 septembre 2020 12:38
> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>
> *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 <roll-bounces@ietf.org> on behalf of Michael Richardson <
> mcr+ietf@sandelman.ca>
> *Sent:* 14 September 2020 02:09 PM
> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>
> *Subject:* Re: [Roll] roll WG Virtual Meeting: 2020-09-30 - Call for
> Agenda Items-
>
>
>
>
> Georgios PAPADOPOULOS <gpapadopoulos.ietf@gmail.com> 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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>