Re: [Roll] nsa extension comments

Rahul Jadhav <> Mon, 10 February 2020 08:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81AEC12009E for <>; Mon, 10 Feb 2020 00:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rkvRwqV1EN0H for <>; Mon, 10 Feb 2020 00:33:00 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::144]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB71D12008C for <>; Mon, 10 Feb 2020 00:32:59 -0800 (PST)
Received: by with SMTP id r14so3544167lfm.5 for <>; Mon, 10 Feb 2020 00:32:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=AdlAGt2zqJYAPDVE090qJDHDYKcw153/yd8gBixCJCc=; b=UPRJcJ1XTY7UhQ+jkGZRWiJ7ub5mKs7Dz7kGDnifXGDMZSllQzPvFJPPQQJlPGOx18 jsJ8zKJwihBAl3m9p3EFgZaq8yLXv5pljya6xfb6SQmQmhkitfp1t87pCZjGxocPwsi3 HuivaxgPsuc9aZ02sRr9ufxi4Q8hkijvafMShYoDsUim1d3h/Twx+froQRBkty0oHdbs OELJyc7i6+bSLgmAAkZGURG9KV6CKT/sKRTeU9XwMtkUohY+kqFNEo3BiBKL8/Genvmo wmF8xnV88hy7D9xtSgORXGZc+nvWkqcst1/3OVMrpAOC0Pj0qeGPBviuTyY++Mo/EGr0 jZZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AdlAGt2zqJYAPDVE090qJDHDYKcw153/yd8gBixCJCc=; b=acBAYjEgAP1lZasV16fVzU93Bryfsy8Zw/IoVxQwXKu4qxBtQIEaoa46uj9FYsYHhr YkB0WqW3r4la2qZdl/hsTrtSJ3OnclErqN95GGDaTzXLgI1QCp6I3JVbNRR6lI3QdxG9 eIouyyz7lbnlPyrvRYFufKiaQHHUe2ORh+EDKVJAIxgAHepcuna7NZmxqdfShTEZVyb8 ktNiXD1c7h7LGyRoh/D0IGNx9uqGOYo84oHgxIWxniRojAbAjqdlE0tBRRaCuGgJhD9L zbVu7UnyfR9KzqhenhXeMRdTdP43rvtthqlKF9AoGVUwY3hSbrm95/t+JlvI8racnB3I 2WDQ==
X-Gm-Message-State: APjAAAUt5wC8f8Y7fu7eBOK8vsrBY9XvJsgMG6SsUX1sAwUJXWVN1PrD IabEYAqXiY/eZlAKfX8Y6AK+ql43KDFFyskCUb4=
X-Google-Smtp-Source: APXvYqw1Z8mbj18wtOCfQAGbifQrlZ17X9XyEfRHtifYeXk4KwQ4UIrd7j+021FxMengq7IxOrTjIrH2gfqHe1qjdLY=
X-Received: by 2002:a19:a07:: with SMTP id 7mr175267lfk.66.1581323577953; Mon, 10 Feb 2020 00:32:57 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Rahul Jadhav <>
Date: Mon, 10 Feb 2020 14:02:46 +0530
Message-ID: <>
To: Remous-Aris Koutsiamanis <>
Cc: Routing Over Low power and Lossy networks <>, "Georgios Z. Papadopoulos" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Roll] nsa extension comments
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, 10 Feb 2020 08:33:02 -0000

Thanks Aris, Georgios for clarifications. Please find my responses inline.

>> o Carrying TLVs in NSA
>> RFC 6551 explains that an NSA can be used to carry TLVs but it falls short of
>> specifying the format for these TLVs. This document assumes the format of 8-bit
>> type and 8-bit length. This format is fine but future specifications will have
>> to refer to this document if they got to add new TLVs. Thus the generic TLV
>> format should be made part of different section and an IANA registry needs to
>> be created for the NSA TLV type.
> I'm not sure I fully understood correctly.
> In RFC6551, page 24, Section "6.2.  Routing Metric/Constraint TLVs" it says:
> """IANA has created a sub-registry, called "Routing Metric/Constraint
>    TLVs", used for all TLVs carried within Routing Metric/Constraint
>    objects.  The Type field is an 8-bit field whose value is comprised
>    between 0 and 255.  Value 0 is unassigned.  The Length field is an
>    8-bit field whose value ranges from 0 to 255.  The Value field has
>    value ranges depending on the Type; therefore, they are not defined
>    here, since no Type is registered at this time."""

[RJ]: The reason why I was confused is that the "Optional TLVs"  are
mentioned in NSA section but there is no reference for the TLV format.
I now realized that section 2.1 has a para that explains the TLV
format which is applicable to all the optional TLVs in 6551. I stand
corrected. Thank you.

> So yes, there is no NSA-specific TLV structure, it is common registry for all the routing metrics and constraints, including the NSA.
> See
> As I understand it, RFC6551 contains the reference definition of the TLV strucure (8bit Type, 8bit Length, variable length Value field)
> and in our draft we basically ask for the creation of a new entry in this sub-registry and specify/define the structure of the Value field only
> (since the T & V are fixed already).
> Is this maybe not sufficient?

[RJ] This is sufficient, imo. Thanks

>> o Preference in PS set
>> The document assumes that the parent addresses in the PS set have been added in
>> the decreasing order of preference, without making it explicit. The PS IPv6
>> address(es) field requires an explanation in Section 4.
> Thank you very much, we have amended that part of the draft accordingly. Please see if it is clear now (master branch in

[RJ] I checked the PR. All ok except one question in the new changes,
"The number of p, wearent addresses in the PS IPv6" .... What is "wearent"?

>> o DIO length
>> As per the draft, the DIO needs to carry NSA (Node State and Attributes) metric
>> with PS (parent set) TLV. As per my understanding without compression, it would
>> be a challenge to carry even two parent addresses in the PS. There has been a
>> discussion about compression and as I remember we discussed doing it.
>> Regardless, I feel we should do it if we want this to be a practical
>> proposition.
> Thank you for this comment.
> We agree that given the size of the IPv6 addresses, it would be prohibitive to include more than 2 addresses.
> When we initially pointed out this constraint ourselved, Michael pointed us in the direction of 6LoRH.
> We implemented a 6LoRH-style compression for this field and it worked well.
> However, it was becoming complicated, somewhat out-of-scope and since there was no good place to point at for our 6LoRH-style compression (a potentially blocking issue), we discussed the options with the group (see an email thread with subject "[Roll] I-D Action: draft-ietf-roll-nsa-extension-02.txt" June 24 2019 - July 2 2019).
> With input from Pascal and Dominique we decided to completely drop compression, in favour of a potential separate and more general compression draft for all control packets.
> We would actually like to contribute to that, but for the time being, a specific compression method for the PS field has been taken out of this draft.

[RJ] Sure, my concern is that it may be infeasible to use this work
without compression. I was hoping to use either 6lorh style or
P2P-RPL/AODV-RPL style (used for address vector) compression.

>> o Section 3.4 Usage:
>> "For example, using different methods can be used to vary the transmission
>> reliability in each hop."
>> This statement implies that using different CA policy implementation can
>> "control" the transmission reliability. As I understand, the strict policy is
>> the best policy (in terms of all performance metrics), the nodes will go for
>> other policy only when the strict policy cannot be used given their parent sets.
>> The above statement implies that nodes may still go for a relaxed policy when
>> strict can be used.
> Thanks for catching this, but in this case this is intentional.
> As far as we are concerned a) there is no "best" policy, and b) a new policy might be introduced in the future.
> The important aspect is that the choice of policy is a local (node) decision and different nodes can select different policies based on whichever criteria make sense for them.
> For example, depending on the required performance in jitter/delay/reliability that is desired a different policy might be used.
> An administrator might also configure nodes in a specific way.
> In any case, we do not want to reduce flexibility in this aspect by defining a spcific hierarchy/preference order on the policies.
> Maybe it makes sense to clarify this a bit?

[RJ] It would certainly help to clarify the bit. One question, is
there any reason/use-case why any node will not go for strict policy?
Why would administrator configure anything other than strict policy?
In the above response, it is suggested that to control
jitter/delay/reliability.  But the strict policy is best for any
use-case and for any metric or any group of metrics, isn't it?

>> o Configuration parameters
>> The document specifies configuration parameters such as
>> a. PARENT_SET_SIZE ... Not defined
> Thanks, we hadn't clarified that this is the same as the MRHOF PARENT_SET_SIZE variable. Updated in master.
>> b. cur_ap_min_path_cost: How can the cur_ap_min_path_cost be equated with
>> PARENT_SWITCH_THRESHOLD as mentioned in section 3.2.2
> Thank you but we are not very sure we understant the question. This section basically says that in addition to the normal MRHOF cur_min_path_cost variable, we add the cur_ap_min_path_cost variable which contains the path cost of the current AP.
> We use the same threshold PARENT_SWITCH_THRESHOLD that MRHOF uses to decide if we need to change AP.
> Just to be sure, we have now clarified here that PARENT_SWITCH_THRESHOLD is the same value that MRHOF uses. Updated in master.

[RJ] ok thanks. My confusion was that cur_ap_min_path_cost is the
aggregated cost to that AP from the root. This cost is the link local
cost of the node to that AP. Is this correct?

>> c. MAX_PATH_COST: No definition for this.
> Again, thanks, we hadn't clarified that this comes from MRHOF. We added a clarification and updated in master.
>> The parameters warrant a rationale and a default value. Also more importantly,
>> is it required that different nodes use the same value and if not what could be
>> the impact.
> The values used and their semantics should now be clear, basically in this section we either reuse existing MRHOF variables with the same MRHOF semantics, or we introduce new variables which have corresponding ones in MRHOF and similar semantics.
> Please let us know if you think we should define something in more detail, but we would like to avoid too much duplication from MRHOF, if possible.
>> o Terminology section
>> Terminology section should explain Alternative Parent, Parent Set, Preferred
>> Grand Parent.
> Thank you very much, this is a good idea. We have amended the text with this and updated in master.
>> o Section realignment
>> It is better to explain CA Strict/Medium/Relax policies before explaining the
>> CAOF because as a reader one needs to be familiar with these policies before
>> understanding the OF.
> Thank you for this comment. We had a similar concern as well.
> We are not sure what is best.
> As the text is current structured, we introduce the CAOF first, mentioning that different policies are possible and that a selection from the parent set must be made.
> We then describe the CAOF in terms of differences from/additions to MRHOF.
> And finally we describe the policies.
> To my mind, the policies are concrete, but they are also just examples, so someone can devise different ones.
> In that sense the CAOF is more "fixed" and the policies are more flexible. Thus it makes sense to describe the CAOF first.
> We are very open to changing the order, but we would like to have some additional feedback that the order is problematic as it stands now.
> We would like to hear any suggestions from the group on this topic.

[RJ] Ok, lets wait for feedback. I, for one, would like to see
policies explained first and then an OF using them. I find this the
only logical way.