Return-Path: 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 ; 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 ; 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 ; Thu, 4 Jun 2020 19:07:44 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id k11so8306437ejr.9 for ; 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: In-Reply-To: From: Rahul Jadhav Date: Fri, 5 Jun 2020 10:07:31 +0800 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000f60c4005a74cb99d" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 02:07:47 -0000 --000000000000f60c4005a74cb99d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 mod= e > of operation and Source routing in case of a non-storing mode of operatio= n. > > Thanks > Rabi > > On Fri, Jun 5, 2020 at 6:23 AM Rahul Jadhav 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 m= y >> 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) > 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 cas= es. >>> 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 t= o >>> 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 =C3=A0 15:00, Rahul Jadhav a =C3= =A9crit : >>> >>> =EF=BB=BF >>> 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 RootAc= k >>> cannot be sent to RUL. For external targets, can we use ParentAddr in >>> Transit Information Option to send this field? Anyways the 6LR indeed i= s >>> 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 > --000000000000f60c4005a74cb99d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Rabi, I missed/forgot the IP-in-IP encap part. So s= ource routing is not needed to be supported in RPL network even if RUL is a= dvertised to root in NS-MOP.

But still, I don't = understand Figure 9 in unaware-leaves draft. It shows RUL target advertisem= ent using DAO in storing MOP.

On Fri, 5 Jun 2020 at 09:18, rabi naraya= n sahoo <rabinarayans0828@= gmail.com> wrote:
Hi
I think here we have two things to addre= ss
1- Advertise the RUL address to DODAG root.
2- Data = plane communication between the DODAG root and RUL.

Irrespective=C2=A0of 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=C2=A0needs to use Ipv6-in-Ipv6 encapsulation if the RPL network is ope= rating in storing mode of operation and Source routing in case of a non-sto= ring mode of operation.

Thanks
Rabi
On Fri, Jun 5, 2020 at 6:23 AM Rahul Jadhav <rahul.ietf@gmail.com> wro= te:
Thanks Pascal,

But I=C2=A0am more confused now.
Figure 5 [1] atta= ches the RUL in the RPL network in Non-storing mode.
Figure 9 attaches = the RUL=C2=A0in the RPL network using storing mode.
This is what = I always thought.

If RUL "always" uses n= on-storing signalisation then what does figure 9 represent?

<= /div>
Also if RUL always uses NS-MOP even if the RPL network is in stor= ing 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.


On Thu, 4 Jun 2020 at 23:34, Pascal Thubert (pthubert) <pthubert=3D= 40cisco.co= m@dmarc..ietf.org> wrote:
Hello Rahul=C2=A0

You should look at fig. 5 in=C2=A0https= ://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.1= =C2=A0not fig.=C2=A09 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 a= s 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 pa= rent sends the NA(EARO) which confirms reachability to the RUL.

Are we good or do I miss something?

Pascal

Le 4 juin 2020 =C3=A0 15:00, Rahul Jadhav <nyrahul@outlook.com> a =C3=A9crit=C2=A0:

=EF=BB=BF
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 ini= tiate its app traffic once e2e path is established.

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 desti= nation 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? An= yways 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
--000000000000f60c4005a74cb99d--