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 784CD3A085A; Sun, 21 Jun 2020 18:10:58 -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 Em1mVp0ovdWQ; Sun, 21 Jun 2020 18:10:56 -0700 (PDT) Received: from mail-ej1-x632.google.com (mail-ej1-x632.google.com [IPv6:2a00:1450:4864:20::632]) (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 5D71F3A0859; Sun, 21 Jun 2020 18:10:56 -0700 (PDT) Received: by mail-ej1-x632.google.com with SMTP id p20so16270551ejd.13; Sun, 21 Jun 2020 18:10:56 -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=SdOkcd50OcdX4+YUhRcCOfF+Qa8NADx9OfCOyD/C09Y=; b=QDZLB8jNBCEPMOB7nPu/B0cmGc/LY2BP4X8MVuQkCgQLfRLCTnj+Kjlnvp7j05tR2Q 9ew77fKKajGdxGZBqlocaN3duhR4Lbhp9SG0qLMwlk+vFSPBulbT+CQ9xZ+qRs+X+LWw 4cgVwoyOLf5rj9599qR2BKgso28xBj3R/wXLBeLuwzgUPlYmqKa8fuRbA1AUogHCBSXz 2zd60mJbV5IUSJDkNdVJ/bzJbx7ipNbAa535GLVMmpURRQcW9WC0KhWCcHNnqX1iULVw 6zaLxAuDQ0Qd4E6eC6o+7L7/kWZ9o+br3RBEG0BjiXPzMZhUPIn+N8jSv2SBfmBXkA7u CElg== 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=SdOkcd50OcdX4+YUhRcCOfF+Qa8NADx9OfCOyD/C09Y=; b=Kp6p7CTDTgly/dHM+4b0yo7w30t067j8G35fDLp4Qq6SdmpIwUXdDwyIXu3XeIPV8c Et38yiI3iGLh8BSBAfQ8tsihiK6G/DroLDISlp8kqoF+swfCNolAcwdVifsdrUJRe9Ua nBS9e3KfVsirCPY2o8/wJ001qTHJW3I1gsJINDopYy3lWtjYI03Ae68QicWlX26aKuua NpC4cG+x9uVMSfial3Cw6jzOZcDyeRXQ9E8Cbcs/5bwYqtalI7nJkNe6k2VLNa9kN8g7 JGZVG4CV9/nowH1r+ns3OYPuc36z4A+FwEqWb4QCCoPMKaT/Swo0Z4Xy9T6NWQc7kwfd na0Q== X-Gm-Message-State: AOAM531G1i6WUGIEKkK5OoujMsZsUrbjiZGIobomCiXQGNdi6Pxz/XWy RIIBo+BN0AkxdTvYdLeQehK8A/msI/CVIuYf+8EzeQ== X-Google-Smtp-Source: ABdhPJyE5BboXraZ4tz/6nZKSvpduMcxT5Kj1mfvQMgT3DC4D8Fz8g1lqWJWnvd5VPuFAOcHX/AeQuKFdW2LQ75NdCs= X-Received: by 2002:a17:906:4c81:: with SMTP id q1mr13837776eju.273.1592788254655; Sun, 21 Jun 2020 18:10:54 -0700 (PDT) MIME-Version: 1.0 References: <159134282158.9958.9959185769917010945@ietfa.amsl.com> In-Reply-To: From: Rahul Jadhav Date: Mon, 22 Jun 2020 09:10:43 +0800 Message-ID: To: Routing Over Low power and Lossy networks Cc: i-d-announce@ietf.org Content-Type: multipart/alternative; boundary="0000000000001f085705a8a1ea9e" 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: Mon, 22 Jun 2020 01:10:59 -0000 --0000000000001f085705a8a1ea9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 node 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 option join (as 6LN/6LR) that instance. There are several other possibilities even for non-root nodes. 2. Will fix the typo. Thanks, Rahul On Sun, 21 Jun 2020 at 16:58, rabi narayan sahoo 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 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- I didn't get why the whole message needs to be ignored if an option i= s > 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 > --0000000000001f085705a8a1ea9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Rabi for the review.

1. The = 'I' bit was introduced recently so that a node not understanding th= e option ignores the whole message. This could potentially lead to a=C2=A0n= ode 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 t= he nodes understanding a given option join (as 6LN/6LR) that instance. Ther= e are several other possibilities even for non-root nodes.

2. Will fix the typo.

Thanks,
R= ahul



On Sun, 21 Jun 2020 at 16:58, rabi = narayan sahoo <rabinarayan= s0828@gmail.com> wrote:
Hi Rahul

In section 4 it= s mentioned=C2=A0
"I" (Ignore) bit in Option Flags: A n= ode which does not understand the Option Type MUST ignore this whole messag= e if the =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 b= its are irrelevant and the message MUST be ignored."

1-=C2=A0 I didn't get why the whole message needs to be ignore= d if an option is not understood?=C2=A0 I think this bit MUST say if the op= tion=C2=A0is optional or mandatory. If it's mandatory then 'J' = flag will control=C2=A0
=C2=A0 =C2=A0 =C2=A0if the node can join = as a leaf or an LR.
=C2=A0 =C2=A0 Am=C2=A0I missing something her= e?

2- There is a typo error (Than)

Thanks
Rabi


On Fri, Jun 5, 2020= at 1:11 PM <internet-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
--0000000000001f085705a8a1ea9e--