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 987333A118E; Fri, 26 Jun 2020 04:09:39 -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 Xxkahh60d_eh; Fri, 26 Jun 2020 04:09:37 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 A19CD3A0B30; Fri, 26 Jun 2020 04:09:37 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id k23so9324000iom.10; Fri, 26 Jun 2020 04:09:37 -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 :cc; bh=bc1n8By9UIiLS66uQztkY8yQT4prteu4o59cMTlJQWo=; b=T9EiTE7BocL4AbHB7BJhILJ6D9TPP434kfT4+1Zsa0+xFXMtN9Q6BqEiPmYTNtpTWd dckrD5adcUrMVidGLWrnq7aRQO5/3QS1pWupfYZMSU1tMKPxWGEaKrz/wXCVyT+9CjJu pMu+ML29aNY7CnXNZCXjlTZPtoFZDJKskZU1AhvJjbOWrc2/lCwXa4wtxY5F6dzZxrcQ WNBjG2k1VzYIJ2BlGFh6uM3QC8+nWc6hhqVftLJ3RHU6D6N9C/M0v4itOPVKfuPwHsGJ P8shjD0e2Mcqy/hcZivZ2rq0T3Q/B5+E2PKqQlN1nrsfUIZYZsU8NE6soRM1WjSGm85J Cn6w== 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:cc; bh=bc1n8By9UIiLS66uQztkY8yQT4prteu4o59cMTlJQWo=; b=Dw5jpltDFdjrARFcJlvE87gAcjgSB2FC03RYUcX5c+R2dbfj9B72xXypExeXVSCH+i ajTCOAXHtnGNRQg8Gg+/geiWheam7LgbIavtxEzGAcAJUMiiGX8CaBbF0EvB+HQj9yh3 vhUC4f9mZhi9MmSVxPyaIIxixUW0rb3QPspkwj7cCsAAIGIk+O0cvMVFdkV8mWVKJIDu aOGuWXQfY46gLrx+govGVnY0qB8DRcOjjC+cc+awF0/omkbWrCmSwjJ6K4oWnFPi4VkY D9uWpRzYUwJ50mXRepGXe8GN2n7pQjCDqOAG4q+XBkjxmyCyLYf3UOs8oX5rSnQ5d4v8 sizA== X-Gm-Message-State: AOAM532uNL/bwTm35R9hLeimm2DoaFGEPuBmCIGi8iXtinDjLusDGpZG 1WYWFTKgCse8KaOP3SY4DWuM4tkoYFhOLg3qTwkAE76u X-Google-Smtp-Source: ABdhPJyPkQugaf443n9faPGJM5ebscsP33eAUe7/Eee9+eHxkuCQw6fXG572M+GMe5zR5HPWTi3256RJR+sCrrhIUg4= X-Received: by 2002:a6b:b785:: with SMTP id h127mr2884825iof.161.1593169776670; Fri, 26 Jun 2020 04:09:36 -0700 (PDT) MIME-Version: 1.0 References: <159134282158.9958.9959185769917010945@ietfa.amsl.com> In-Reply-To: From: rabi narayan sahoo Date: Fri, 26 Jun 2020 16:39:25 +0530 Message-ID: To: Routing Over Low power and Lossy networks Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="0000000000009afa5e05a8fabed4" Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-mopex-01.txt 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, 26 Jun 2020 11:09:40 -0000 --0000000000009afa5e05a8fabed4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rahul Find my comments inline. On Mon, Jun 22, 2020 at 6:41 AM Rahul Jadhav wrote: > Thanks Rabi for the review. > > 1. The 'I' bit was introduced recently so that a node not understanding > the option ignores the whole message. This could potentially lead to a no= de > not joining as a 6LR or a 6LN. The J flag decides only for node joining a= s > 6LR. As an example, the I bit can be used by root to ensure that only the > nodes understanding a given option join (as 6LN/6LR) that instance. There > are several other possibilities even for non-root nodes. > > [Rabi]-: I got this point. I feel this is very very specific to DIO. Even the J bit. This will be the new Control Option format that is going to be used in RPLv2 . This will be used to define new options meant for DIS, DIO, DAO, DAO-ACK, DCO or other new messages to be added in future. I have one suggestion: can we let such flag bits be part of the option data itself? We have one flag bit to indicate if this option is mandatory or optional. Maybe the 'J' flag can make M to serve the purpose. If an option is mandatory to be understood then let the particular option take a decision about what action to be taken. If the option is part of DIO it can define join as leaf or don't join. What do you think? 2. Will fix the typo. > > Thanks, > Rahul > > > > On Sun, 21 Jun 2020 at 16:58, rabi narayan sahoo < > rabinarayans0828@gmail.com> wrote: > >> Hi Rahul >> >> In section 4 its mentioned >> "I" (Ignore) bit in Option Flags: A node which does not understand the >> Option Type MUST ignore this whole message if the =E2=80=99I=E2=80=99 bi= t is >> set. If =E2=80=99I=E2=80=99 bit is set* than* the value of =E2=80=99J=E2= =80=99 and =E2=80=99C=E2=80=99 bits are >> irrelevant and the *message MUST be ignored.*" >> >> 1- I didn't get why the whole message needs to be ignored if an option >> is not understood? I think this bit MUST say if the option is optional = or >> mandatory. If it's mandatory then 'J' flag will control >> if the node can join as a leaf or an LR. >> Am I missing something here? >> >> 2- There is a typo error (Than) >> >> Thanks >> Rabi >> >> >> On Fri, Jun 5, 2020 at 1:11 PM wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Routing Over Low power and Lossy >>> networks WG of the IETF. >>> >>> Title : Mode of Operation extension >>> Authors : Rahul Arvind Jadhav >>> Pascal Thubert >>> Michael Richardson >>> Filename : draft-ietf-roll-mopex-01.txt >>> Pages : 8 >>> Date : 2020-06-05 >>> >>> Abstract: >>> RPL allows different mode of operations which allows nodes to have a >>> consensus on the basic primitives that must be supported to join the >>> network. The MOP field in [RFC6550] is of 3 bits and is fast >>> depleting. This document extends the MOP for future use. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-roll-mopex/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-roll-mopex-01 >>> https://datatracker.ietf.org/doc/html/draft-ietf-roll-mopex-01 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-mopex-01 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> _______________________________________________ >>> 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 > --0000000000009afa5e05a8fabed4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rahul
Find my comments inline.

=
On Mon, Ju= n 22, 2020 at 6:41 AM Rahul Jadhav <rahul.ietf@gmail.com> wrote:
Thanks Rabi for = the review.

1. The 'I' bit was introduced re= cently so that a node not understanding the option ignores the whole messag= e. This could potentially lead to a=C2=A0node not joining as a 6LR or a 6LN= . The J flag decides only for node joining as 6LR. As an example, the I bit= can be used by root to ensure that only the nodes understanding a given op= tion join (as 6LN/6LR) that instance. There are several other possibilities= even for non-root nodes.

=C2= =A0 =C2=A0[Rabi]-: I got this point.=C2=A0I feel th= is is=C2=A0very very specific to DIO. Even the J bit.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= This will be the new Control Option format that is going to be used in RPL= v2 . This will be used to define new options meant for DIS, DIO, DAO, DAO-A= CK, DCO or other new messages to be=C2=A0=C2=A0added in future.=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I= have one suggestion: can we let such flag bits be part of the option data = itself?=C2=A0
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We have one flag bit to indicate if thi= s option is mandatory or optional. Maybe the 'J' flag can=C2=A0make= M to serve=C2=A0the purpose. If an option is mandatory to be understood th= en let the particular option=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 take a decision ab= out what action to be taken. If the option is part of DIO it can define joi= n as leaf or don't join. What do you think?
2. Will fi= x the typo.

Thanks,
Rahul



On Sun, 21 Jun 2020 at 16:58, rabi narayan sahoo <rabinarayans0828@g= mail.com> wrote:
Hi Rahul

In section 4 its menti= oned=C2=A0
"I" (Ignore) bit in Option Flags: A node whi= ch does not understand the Option Type MUST ignore this whole message if th= e =E2=80=99I=E2=80=99 bit is
set. If =E2=80=99I=E2=80=99 bit is set= than the value of =E2=80=99J=E2=80=99 and =E2=80=99C=E2=80=99 bits are= irrelevant and the message MUST be ignored."

1-=C2=A0 I didn't get why the whole message needs to be ignored if an= option is not understood?=C2=A0 I think this bit MUST say if the option=C2= =A0is optional or mandatory. If it's mandatory then 'J' flag wi= ll control=C2=A0
=C2=A0 =C2=A0 =C2=A0if the node can join as a le= af or an LR.
=C2=A0 =C2=A0 Am=C2=A0I missing something here?

2- There is a typo error (Than)

Thanks
Rabi


On Fri, Jun 5, 2020 at 1:1= 1 PM <inte= rnet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Mode of Operation extension
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Rahu= l Arvind Jadhav
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Pascal Thubert
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael Richardson
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-roll-mopex-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-06-05

Abstract:
=C2=A0 =C2=A0RPL allows different mode of operations which allows nodes to = have a
=C2=A0 =C2=A0consensus on the basic primitives that must be supported to jo= in the
=C2=A0 =C2=A0network.=C2=A0 The MOP field in [RFC6550] is of 3 bits and is = fast
=C2=A0 =C2=A0depleting.=C2=A0 This document extends the MOP for future use.=


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-r= oll-mopex/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-mope= x-01
https://datatracker.ietf.org/doc/html/= draft-ietf-roll-mopex-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-roll-mopex-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
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
--0000000000009afa5e05a8fabed4--