Re: [Roll] RUL and RootACK
rabi narayan sahoo <rabinarayans0828@gmail.com> Mon, 08 June 2020 16:33 UTC
Return-Path: <rabinarayans0828@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0B43A0CF1 for <roll@ietfa.amsl.com>; Mon, 8 Jun 2020 09:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50umiMWJriYa for <roll@ietfa.amsl.com>; Mon, 8 Jun 2020 09:33:49 -0700 (PDT)
Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AEC93A0CD9 for <roll@ietf.org>; Mon, 8 Jun 2020 09:33:49 -0700 (PDT)
Received: by mail-il1-x12b.google.com with SMTP id c75so5489035ila.8 for <roll@ietf.org>; Mon, 08 Jun 2020 09:33:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=9YpNRHJJ4V28mvItDQUWC868gEex1wtkLQivqIxyWHQ=; b=V2ATn+P37GNnlxDPy/f230UDHBoGlYssvwTSqXjpmga4lyh4s0pdNXWx8lnFpjLBGF jdN3Uqt/Bgjj37to5PP8eB+HR0n4dVSYjAzrgfJs4jwA0iIY8gH7+WRTyUUd3hStDut/ 0YwCFqsK0dT9ZtIyY3pAQjFtnXUep5FpiYEhOFvTk9+XmQE/NaUAIN7yY1cgnrJCgIcD 8vo09c7PeUU1d+ZtqaV30Y+TwDbsH6eNto2oEpGVpGSgnVH/6jg38W/QpcY7c00LnnbS jwxxasXF+k843Nq7LxOgBWUDHFL/9BFQnMtkcOf2Bmc6aZ6DzbVGdPtbLPZEe59JHHYs aSbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=9YpNRHJJ4V28mvItDQUWC868gEex1wtkLQivqIxyWHQ=; b=AL4r9/LPm3BvXxMocxp4k9M4V4lb5ATtGtRDYx7ZEZvWgi27A2CY54OhO/MyOYY1Wl kjm4UtBdjNTG3HrciT+uL0yZqcM3uiSxGQGHcjLva8L8CIrg7yDakt7lyh4xzu8zXY0W QVXX5fReypEUtK4pn1W5pjUMQB8MyumXwizHSQDz06eg60YCk6wPkvfgvenXWTKkDhTA QpLSzyRYSpiymcRrIrrgRAWViV8mTcT2ccwURHxTWNmc2iFowTP/9N4oU6v0EDobx/kx IpXD7dHej+0lCK/QojqKypzDhEDXcCiZJNiQZvIZEucbsQrJGcS1jo8BaxMiLfTN66v3 XvfA==
X-Gm-Message-State: AOAM531SLkxDbOsqNhOdC3DU5TEN2YIpUg0Pwn1eHTVpnUJKDMu+FFJp 8Fah0YnredtdM5Ii29ILkDIaSVNCf1kNN0FEZSJF1sj6ijc=
X-Google-Smtp-Source: ABdhPJxjJxtR2sAaRi6C1X/ro9Qups/bm12/NWPJFaPZY4CyzgZk2ZH/s6wIcsB0nJk1MMIR6KlESP6eJtoCed1h3HI=
X-Received: by 2002:a92:2a06:: with SMTP id r6mr22092529ile.121.1591634028064; Mon, 08 Jun 2020 09:33:48 -0700 (PDT)
MIME-Version: 1.0
References: <MAXPR01MB249312F154F630F433508545A9890@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM> <CC2F1028-BA6A-4A0E-AB2B-1613A210B0FD@cisco.com> <CAO0Djp3muuc9aE4xoc-BXR_BU5R=N095F0q8Xv0MWPaMSYgpaA@mail.gmail.com> <CAPT0++0OiULCGdTdEKwoBagFoHr7Bs-Fg-gjhMaj9W6qwx7SJg@mail.gmail.com> <CAO0Djp1xFyevjU+1hdSpDMkW2K5bAmNKeeHbDeSaMfesLjHy_A@mail.gmail.com> <091B6759-8C67-4B05-8814-8D94CABBD062@cisco.com> <MAXPR01MB2493735DB90290626D5A59AAA9860@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM> <MN2PR11MB3565C8A816E3D6427F76671DD8850@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565C8A816E3D6427F76671DD8850@MN2PR11MB3565.namprd11.prod.outlook.com>
From: rabi narayan sahoo <rabinarayans0828@gmail.com>
Date: Mon, 08 Jun 2020 22:03:36 +0530
Message-ID: <CAPT0++04Wrv1T1OYHRqcWbvPtDNbkhQ62MkvzDPQ1eaWy_3QTQ@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000daf41e05a7952cf3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/bxuvjjRVZeHIxoZJlAACZr-r_V4>
Subject: Re: [Roll] RUL and RootACK
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2020 16:33:52 -0000
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 >
- [Roll] RUL and RootACK Rahul Jadhav
- Re: [Roll] RUL and RootACK Pascal Thubert (pthubert)
- Re: [Roll] RUL and RootACK Rahul Jadhav
- Re: [Roll] RUL and RootACK rabi narayan sahoo
- Re: [Roll] RUL and RootACK Rahul Jadhav
- Re: [Roll] RUL and RootACK Pascal Thubert (pthubert)
- Re: [Roll] RUL and RootACK Rahul Jadhav
- Re: [Roll] RUL and RootACK Pascal Thubert (pthubert)
- Re: [Roll] RUL and RootACK Rahul Jadhav
- Re: [Roll] RUL and RootACK rabi narayan sahoo
- Re: [Roll] RUL and RootACK Pascal Thubert (pthubert)
- Re: [Roll] RUL and RootACK Rahul Jadhav