MIME-Version: 1.0
From: Remous-Aris Koutsiamanis <aris@ariskou.com>
Date: Tue, 10 Mar 2020 17:24:33 +0100 (CET)
Message-ID:
 <CAK76PrmKVKXhPpcH6eq=f5O_rE0k0z-8dZouDeZddBbznftZPQ@mail.gmail.com>
To: roll <roll@ietf.org>, dominique barthel <dominique.barthel@orange.com>, 
 INES ROBLES <mariainesrobles@googlemail.com>
Cc: "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>, 
 "Pascal Thubert (pthubert)" <pthubert@cisco.com>,
 Rahul Jadhav <rahul.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d5828205a0828d81"
Archived-At:
 <https://mailarchive.ietf.org/arch/msg/roll/8Wf9JAQoUY2puFtxI3nRERox9Hs>
Subject: [Roll] Remaining issues on draft-ietf-roll-nsa-extension
Precedence: list

--000000000000d5828205a0828d81
Content-Type: text/plain; charset="UTF-8"

Dear roll,

we have now submitted all the agreed upon changes to the
draft-ietf-roll-nsa-extension-07 (will present them at the meeting).

One small mistake is the reversal of a CAN to MAY that Dominique made, but
we found that we had missed that after the submission system closed, so we
will fix in -08 once the submission system re-opens.

Two small issues remain:

a) Compression of the PS IPv6 addresses.
Rahul brought this up in his review, we mentioned that this was proposed
before, implemented and then re-removed because of the plan to have a draft
that performs compression on all RPL control traffic packets (following
Pascal's and Dominique's advice).
*Question: is there any chance this has changed and we might want to
perform compression on the PS field specifically after all?*

b) Change of the context of the PS NSA object from a constraint to a metric.
Following  Dominique's suggestion we changed it from a constraint to a
recorded (R=1), partial (P=1) metric (C=0).
The issue is that we are extending MRHOF and MRHOF supports the use of a
single metric for computing the rank.
It is true that the PS NSA object is not used for rank calculation, and we
have clarified this.
However, there might be still a conflict or a point to be clarified.
See in MRHOF Section 2 Terminology
<https://www.rfc-editor.org/rfc/rfc6719.html#section-2>:
"Selected metric:  The metric chosen for path selection by the network
operator.  MRHOF supports using a single metric for path selection."

VS our draft Section 5.1 "Usage"
<https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-07#section-5.1>:
"It is important that the PS does not affect the calculation of the rank
through candidate neighbors.  It is only used with the CA OF to remove
nodes which do not fulfill the CA OF criteria from the candidate neighbor
list."
*Question: Is this sufficient in terms of explanation?*

We would really appreciate answers on these, if possible of course, before
the ROLL meeting so that we can update/finalize the drafts.

Kind regards,
Aris & Georgios

--000000000000d5828205a0828d81
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Dear roll,</div><div><br></div><div>we have now submi=
tted all the agreed upon changes to the draft-ietf-roll-nsa-extension-07 (w=
ill present them at the meeting).<br></div><div></div><div><br></div><div>O=
ne small mistake is the reversal of a CAN to MAY that Dominique made, but w=
e found that we had missed that after the submission system closed, so we w=
ill fix in -08 once the submission system re-opens.</div><div><br></div><di=
v>Two small issues remain:</div><div><br></div><div>a) Compression of the P=
S IPv6 addresses.</div><div>Rahul brought this up in his review, we mention=
ed that this was proposed before, implemented and then re-removed because o=
f the plan to have a draft that performs compression on all RPL control tra=
ffic packets (following Pascal&#39;s and Dominique&#39;s advice).</div><div=
><i>Question: is there any chance this has changed and we might want to per=
form compression on the PS field specifically after all?</i></div><div><br>=
</div><div>b) Change of the context of the PS NSA object from a constraint =
to a metric.</div><div>Following=C2=A0 Dominique&#39;s suggestion we change=
d it from a constraint to a recorded (R=3D1), partial (P=3D1) metric (C=3D0=
).</div><div>The issue is that we are extending MRHOF and MRHOF supports th=
e use of a single metric for computing the rank.</div><div>It is true that =
the PS NSA object is not used for rank calculation, and we have clarified t=
his.</div><div>However, there might be still a conflict or a point to be cl=
arified.</div><div>See in <a href=3D"https://www.rfc-editor.org/rfc/rfc6719=
.html#section-2">MRHOF Section 2 Terminology</a>:</div><div>&quot;Selected =
metric: =C2=A0The metric chosen for path selection by the network operator.=
=C2=A0 MRHOF supports using a single metric for path selection.&quot;</div>=
<div><br></div><div>VS our <a href=3D"https://tools.ietf.org/html/draft-iet=
f-roll-nsa-extension-07#section-5.1">draft Section 5.1 &quot;Usage&quot;</a=
>:</div><div>&quot;It is important that the PS does not affect the calculat=
ion of the rank through candidate neighbors.=C2=A0 It is only used with the=
 CA OF to remove nodes which do not fulfill the CA OF criteria from the can=
didate neighbor list.&quot;</div><div><i>Question: Is this sufficient in te=
rms of explanation?</i><br></div><div><br></div><div>We would really apprec=
iate answers on these, if possible of course, before the ROLL meeting so th=
at we can update/finalize the drafts.</div><div><br></div><div>Kind regards=
,</div><div>Aris &amp; Georgios<br></div><div><br></div><div><br></div></di=
v>

--000000000000d5828205a0828d81--