Re: [Roll] RUL and RootACK

Hi Pascal

Section 6.2 *of RPL Unaware Leaves draft* states that

“Section 4.1 of [USEofRPLinfo] provides a set of rules that MUST be
followed for the routing operations to a RUL.

A 6LR that is upgraded to act as a border router for external routes
advertises them using Non-Storing Mode DAO messages that are unicast
directly to the Root, even if the DODAG is operated in Storing Mode.”

*Section 4.1 of the RPL Data Plane* (USEofRPLinfo) also states the same
thing

“This specification updates [RFC6550] to RECOMMEND that external targets
are advertised using Non-Storing Mode DAO messaging even in a Storing-Mode
network”

Here Non-Storing Mode DAO is basically a DAO message with transit
information option having a valid parent address.

*Do these statement overrides the rule mentioned in section 9.8 of RFC
6550?*

“In Storing mode, RPL routes messages Downward by the IPv6 destination address.
The following rules apply to nodes that are in Storing

mode:

1. The DODAG Parent Address subfield of a Transmit Information option MUST
be empty.”

Implementations  complying  with RFC 6550, operating in storing mode can
reject DAO messages, with transit information having a valid parent address
subfield.

I feel both the draft need to update this MUST clause of RFC 6550 and it’s
missing in both the drafts.

Thanks

Rabi

On Mon, Jun 8, 2020 at 7:42 PM Pascal Thubert (pthubert) <pthubert=
40cisco.com@dmarc.ietf.org> wrote:

> Dear Rahul (as Shepherd), and all
>
>
>
> I just submitted a correction of the RUL draft that removes the storing
> mode section.
>
> Since the publication was already requested, can you please make a pass to
> validate the diffs?
>
>
>
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
>
>
>
> There are also htmlized versions available at:
>
> https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-16
>
> https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves-16
>
>
>
> A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-16
>
>
>
> Many thanks indeed!
>
>
>
> Pascal
>
>
>
> *From:* Roll <roll-bounces@ietf.org> *On Behalf Of *Rahul Jadhav
> *Sent:* vendredi 5 juin 2020 09:45
> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>
> *Subject:* Re: [Roll] RUL and RootACK
>
>
>
> This clarifies all for me. Thanks Pascal, Rabi.
> ------------------------------
>
> *From:* Roll <roll-bounces@ietf.org> on behalf of Pascal Thubert
> (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>
> *Sent:* 05 June 2020 02:46 PM
> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>
> *Subject:* Re: [Roll] RUL and RootACK
>
>
>
> ...And for this I’m the one confused. I’m confused that I never removed
> that section when we decided to use NS signaling for RULs. It’s like that
> typo that the author can read 10 times and never see.  I need to make a
> pass!
>
> Great catch Rahul !!!
>
>
>
> Pascal
>
>
>
> Le 5 juin 2020 à 04:08, Rahul Jadhav <rahul.ietf@gmail.com> a écrit :
>
> 
>
> Thanks Rabi, I missed/forgot the IP-in-IP encap part. So source routing is
> not needed to be supported in RPL network even if RUL is advertised to root
> in NS-MOP.
>
>
>
> But still, I don't understand Figure 9 in unaware-leaves draft. It shows
> RUL target advertisement using DAO in storing MOP.
>
>
>
> On Fri, 5 Jun 2020 at 09:18, rabi narayan sahoo <
> rabinarayans0828@gmail.com> wrote:
>
> Hi
>
> I think here we have two things to address
>
> 1- Advertise the RUL address to DODAG root.
>
> 2- Data plane communication between the DODAG root and RUL.
>
>
>
> Irrespective of RPL network operate in storing and non-storing mode
> advertisement of RUL target address to the DODAG root will happen using
> Non-Storing mode DAO.
>
> For data packets, from DODAG root to RUL, the root needs to use
> Ipv6-in-Ipv6 encapsulation if the RPL network is operating in storing mode
> of operation and Source routing in case of a non-storing mode of operation.
>
>
>
> Thanks
>
> Rabi
>
>
>
> On Fri, Jun 5, 2020 at 6:23 AM Rahul Jadhav <rahul.ietf@gmail.com> wrote:
>
> Thanks Pascal,
>
>
>
> But I am more confused now.
>
> Figure 5 [1] attaches the RUL in the RPL network in Non-storing mode.
>
> Figure 9 attaches the RUL in the RPL network using storing mode.
>
> This is what I always thought.
>
>
>
> If RUL "always" uses non-storing signalisation then what does figure 9
> represent?
>
>
>
> Also if RUL always uses NS-MOP even if the RPL network is in storing mode,
> doesn't it raise a basic question that the RPL network has to mandatorily
> support source-routing regardless of the MOP? Currently in my network
> source-routing is not enabled if RPL is operating in storing MOP.
>
>
>
> [1]
> https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.1
>
>
>
>
> On Thu, 4 Jun 2020 at 23:34, Pascal Thubert (pthubert) <pthubert=
> 40cisco.com@dmarc..ietf.org <40cisco..com@dmarc.ietf.org>> wrote:
>
> Hello Rahul
>
>
>
> You should look at fig. 5 in
> https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.1 not
> fig. 9 since we are using Non Storing signalisation for RULs in all cases.
> IOW the root ack problem does not exist for RULs.
>
>
>
> More details:
>
>
>
> The idea is for the root to answer a non storing DAO with a DAO ack to the
> sender.
>
>
>
> Normally In NS mode the sender is the RAL that advertises its parent as
> transit and the DAO Ack serves as root ack and confirms reachability.
>
>
>
> In the RUL case, the Root answers to the parent. That answer confirms to
> the parent that the RUL is reachable and serves as root ack. Then the
> parent sends the NA(EARO) which confirms reachability to the RUL.
>
> Are we good or do I miss something?
>
>
>
> Pascal
>
>
>
> Le 4 juin 2020 à 15:00, Rahul Jadhav <nyrahul@outlook.com> a écrit :
>
> 
>
> Hi Pascal,
>
>
>
> Last we discussed handling storing mode RUL flow with RootACK in a way
> that NA is sent to the RUL after it gets the RootACK. This way RUL can
> initiate its app traffic once e2e path is established.
>
>
>
> Figure 9 in
> https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.2
> handles Storing mode First registration flow for RULs.
>
>
>
> My problem is (consider the figure 9), how will the Root know whom to send
> the RootACK. In the regular cases, the target node in DAO is the
> destination for RootACK. But in this case, the target is RUL and RootAck
> cannot be sent to RUL. For external targets, can we use ParentAddr in
> Transit Information Option to send this field? Anyways the 6LR indeed is
> the parent node for RUL.
>
>
>
> Any thoughts/suggestions?
>
>
>
> Thanks,
>
> Rahul
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>