Re: [Roll] RUL and RootACK

Rahul Jadhav <rahul.ietf@gmail.com> Fri, 05 June 2020 02:07 UTC

Return-Path: <rahul.ietf@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 ABE6E3A1144 for <roll@ietfa.amsl.com>; Thu, 4 Jun 2020 19:07:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_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 9ol43VDqhrSC for <roll@ietfa.amsl.com>; Thu, 4 Jun 2020 19:07:44 -0700 (PDT)
Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 848293A113D for <roll@ietf.org>; Thu, 4 Jun 2020 19:07:44 -0700 (PDT)
Received: by mail-ej1-x636.google.com with SMTP id k11so8306437ejr.9 for <roll@ietf.org>; Thu, 04 Jun 2020 19:07:44 -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=ZnWSF//nsBeP9qnTmcAlXerq87NE7W1HBE41fHSwr1Q=; b=PnHEjhEAZtXDAHuykRhYaLyRlua8MfX+fQPvxNfcevCzV9c5ijwU3V+2qVgcOy0KYb Meodts+GAfA/sigq87mgW4ePKOQI1D4ur88E1R79bbV6CnOZnlZlH2MtdrkQlIUpy/vd wjHLY0tHuFJ1L4jOee8L/tDy70hDaJ9lmaAsTMJ2T3PViWcKYHYuvKyuPxbMZ0S5WJih GGl7U38sTc5z29E2/wQlYiHb32b5QYGvTuoxguvajZIvPAVoIltNTvq1rvsZuwxCi36l c1Ejchr/QflLhiQJ+Wl9WXhPllfu7tgnhw1AiPDxd3zQXv1Q5mk2wCF+xDbQ0AwNJFAm NeOA==
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=ZnWSF//nsBeP9qnTmcAlXerq87NE7W1HBE41fHSwr1Q=; b=qJ2sSSEPJHG+ssyC5ZwHonAvrVdrnnTK/IkrycWmw9SSct1KZREtELSbc/C2FGq5sR sk3beZMsOCRAnWRh21eDygjji97foGM1PWDxAAbiydald7sCgwr538/qEhGGNmFoRUgf s80+hrOEcIWj7K0n4LAHKqGMWyRpa0jZR2GtvXTdMx4f6YIZZ7vYofDMqpxxv3vScN6h gkcwVVsgxWjSc4GbXSFg7at24/4NT75j9YE+nmeKxix9jojXmSyxbjdjegdIOU/akh7c YLrZs/lMvs1akCz3o6I96dVZI8KhW3tkCeZeUnOzSHZjcTM1VaagQAU7K4pLWl7gevHm Hg9Q==
X-Gm-Message-State: AOAM530+g1fOKHSzg3WGQBjmbLKS5DTDMWeyHE8oHFPHkIwtKCIwqWMB AEI8rL3he1sGZ3sriuo4mGHnqBvqwsGKcO925saXkA==
X-Google-Smtp-Source: ABdhPJyAAc6475ub5X+slQaKkqe5iAi/wMgEcwRW2hNO1knntRGXR8gIUeEYKtERBBzJWmha5JWC1jcsV0qFjy83E84=
X-Received: by 2002:a17:906:851:: with SMTP id f17mr6207331ejd.396.1591322862815; Thu, 04 Jun 2020 19:07:42 -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>
In-Reply-To: <CAPT0++0OiULCGdTdEKwoBagFoHr7Bs-Fg-gjhMaj9W6qwx7SJg@mail.gmail.com>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Fri, 05 Jun 2020 10:07:31 +0800
Message-ID: <CAO0Djp1xFyevjU+1hdSpDMkW2K5bAmNKeeHbDeSaMfesLjHy_A@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f60c4005a74cb99d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/zAMt7_xv1_AVqNqQjVPu1EHnjag>
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: Fri, 05 Jun 2020 02:07:47 -0000

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
>