Subject: Mirja Kühlewind's No Objection on draft-ietf-rtgwg-rlfa-node-protection-10: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Mon, 16 Jan 2017 08:33:34 -0800

Mirja Kühlewind has entered the following ballot position for
draft-ietf-rtgwg-rlfa-node-protection-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Overall comment: This reads rather like an informational rfc; however
given that rfc7490 is standards track, I guess that's fine.

More specific comments:
- More abbreviations could be spelled out to make it easier to read.
- Not sure what section 3 tells me; but I'm also not an expert. 
- Also section 3: "As already specified in Section 2.3.4 to limit the
computational
   overhead of the proposed approach, forward SPF computations MUST be
   run on a selected subset from the entire set of PQ-nodes computed in
   the network, with a finite limit on the number of PQ-nodes in the
   subset."
   I guess you don't need the upper case MUST here.
- Also then in section 2.3.4: "To limit the computational overhead of the
approach proposed, this
   document proposes that implementations MUST choose a subset from the
   entire set of PQ-nodes computed in the network, with a finite limit
   on the number of PQ-nodes in the subset."
   Saying "this doc recommends" and "MUST" in the same sentence seem
inaccurate.
- And also section 2.3.4: Could you maybe suggest or discuss an
appropriate default value?

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 18 Jan 2017 08:12:10 +0530

Hi Mirja,

Thanks a lot for the comments. And sorry for not being able to reply
earlier. Please find some comments  inline.

Thanks
-Pushpasis

> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/
[Pushpasis] I will try to add as many as I can in the next version :)

> - Not sure what section 3 tells me; but I'm also not an expert.
[Pushpasis] Section 3 is about a using the same solution proposed to find a
node-protected R-LFA path by running a forward-SPF on the PQ node(s) to
select parameters of the same paths discovered, so that the computing
router on discovering multiple R-LFA backup paths to a single destination
can run some backup-path-selection policies on the same path parameters
collected (while doing computing F-SPF) to select one or more best suited
R-LFA backup paths for the destination. Hope it explains :) You may also
want to refer to RFC7916 for more explanation.

>    I guess you don't need the upper case MUST here.
[Pushpasis] Actually this was suggested to be exactly a MUST in WG
discussions on the WG mail

>    Saying "this doc recommends" and "MUST" in the same sentence seem
[Pushpasis] Should I replace 'recommends' with 'specifies' then?

> appropriate default value?
[Pushpasis] I have myself implemented it for Juniper and the default value
as 16. I can specify the same as a suggested default. But I am not sure it
will be raise any concern in the WG or not. If you suggest, I can go ahead
and put this in the next version.

Thanks once again
-Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Wed, 18 Jan 2017 08:21:44 +0530

Hi Mirja,

Actually, I don't see the term 'recommends' anywhere in the current
version. So now I am not sure what was the comment about :( Request you to
clarify this a bit, so that I can take the right resolution..

Thanks and regards,
-Pushpasis

On Wed, Jan 18, 2017 at 8:12 AM, Pushpasis Sarkar <[email-masked]>
wrote:

> [Pushpasis] Section 3 is about a using the same solution proposed to find
> a node-protected R-LFA path by running a forward-SPF on the PQ node(s) to

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 18 Jan 2017 16:24:13 +0100

Sorry, it was 'this document proposes' (not recommends)... yes better to use 
'specifies' instead!

On 18.01.2017 03:51, Pushpasis Sarkar wrote:
> Actually, I don't see the term 'recommends' anywhere in the current version.
> So now I am not sure what was the comment about :( Request you to clarify
> this a bit, so that I can take the right resolution..
>
> Thanks and regards,
> -Pushpasis
>
> On Wed, Jan 18, 2017 at 8:12 AM, Pushpasis Sarkar <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Mirja,
>
>     On Mon, Jan 16, 2017 at 10:03 PM, Mirja Kuehlewind <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         Please refer to
>         https://www.ietf.org/iesg/statement/discuss-criteria.html
>         <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>         <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-rlfa-node-protection/>
>
>
>
>     [Pushpasis] I have myself implemented it for Juniper and the default
>     value as 16. I can specify the same as a suggested default. But I am not
>     sure it will be raise any concern in the WG or not. If you suggest, I can
>     go ahead and put this in the next version.
>
>     Thanks once again
>     -Pushpasis
>
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 18 Jan 2017 16:32:26 +0100

Hi Pushpasis,

thank for your replies. Please see below!

Mirja

On 18.01.2017 03:42, Pushpasis Sarkar wrote:
> Hi Mirja,
>
> Thanks a lot for the comments. And sorry for not being able to reply earlier.
> Please find some comments  inline.
>
> Thanks
> -Pushpasis
>
> select parameters of the same paths discovered, so that the computing router
> on discovering multiple R-LFA backup paths to a single destination can run
> some backup-path-selection policies on the same path parameters collected
> (while doing computing F-SPF) to select one or more best suited R-LFA backup
> paths for the destination. Hope it explains :) You may also want to refer to
> RFC7916 for more explanation.

Still not clear to me. Anyway I'm not an expert and maybe I'm missing 
something. Or let me ask the questions differently: What does this part add 
to the rest of the doc and why is this a separate section?

> discussions on the WG mail

My point was, given this is a MUST in section 2.3.4 and this sentence starts 
with "As already specified in Section 2.3.4" it does have to be an upper case 
MUST here again (because it's correctly normatively specified in section 
2.3.4). However not a big issue.

> [Pushpasis] I have myself implemented it for Juniper and the default value as
> 16. I can specify the same as a suggested default. But I am not sure it will
> be raise any concern in the WG or not. If you suggest, I can go ahead and put
> this in the next version.

If you think this could raise any concerns in the wg, you should go back to 
the wg mailing list and ask for feedback/confirmation.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 19 Jan 2017 17:08:36 +0530

Hi Mirja,

Thanks for your comments once again.. Please find some more answers inline

-Pushpasis

On Wed, Jan 18, 2017 at 9:02 PM, Mirja Kühlewind <[email-masked]>
wrote:

>> a
>> router

[Pushpasis] The solution proposed to solve the first problem in section 2
(i.e. ensuring node-protection with R-LFA) can also be extended to solve
another problem (i.e. collecting parameters used by
backup-selection-algorithm RFC7916 wrt to R-LFA backup paths (this is more
detailed in section 6.2.5.4 of RFC7916). Since the same solution in a
extended form also solved a separate but related problem, this was curved
out as separate section. In summary this document proposes to two separate
but related problems and hence two different sections..  Hope I could
answer this satisfactorily this time.. :)

> My point was, given this is a MUST in section 2.3.4 and this sentence
> starts with "As already specified in Section 2.3.4" it does have to be an
> upper case MUST here again (because it's correctly normatively specified in
> section 2.3.4). However not a big issue.

[Pushpasis] Got it. Will do so..

>> value as
> If you think this could raise any concerns in the wg, you should go back
> to the wg mailing list and ask for feedback/confirmation.
>
[Pushpasis] I dont think it will raise a concern. Just wanted to avoid
unwarranted discussion.. :) Anyways I will provide some text in the next
version and ask WG to let know any comments or opinion.

Thanks and Regards,
-Pushpasis

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 19 Jan 2017 20:06:41 +0000

One quick comment below  [Uma]:

--
Uma C.

From: rtgwg [mailto:[email-masked]] On Behalf Of Pushpasis Sarkar
Sent: Thursday, January 19, 2017 3:39 AM
To: Mirja Kühlewind <[email-masked]>
Cc: [email-masked]; rtgwg-chairs <[email-masked]>; The IESG <[email-masked]>; RTGWG <[email-masked]>
Subject: Re: Mirja Kühlewind's No Objection on draft-ietf-rtgwg-rlfa-node-protection-10: (with COMMENT)

Hi Mirja,

-Pushpasis

On Wed, Jan 18, 2017 at 9:02 PM, Mirja Kühlewind <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pushpasis,

Mirja

Thanks
-Pushpasis

On Mon, Jan 16, 2017 at 10:03 PM, Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    More specific comments:

Still not clear to me. Anyway I'm not an expert and maybe I'm missing something. Or let me ask the questions differently: What does this part add to the rest of the doc and why is this a separate section?
[Pushpasis] The solution proposed to solve the first problem in section 2 (i.e. ensuring node-protection with R-LFA) can also be extended to solve another problem (i.e. collecting parameters used by backup-selection-algorithm RFC7916 wrt to R-LFA backup paths (this is more detailed in section 6.2.5.4 of RFC7916). Since the same solution in a extended form also solved a separate but related problem, this was curved out as separate section. In summary this document proposes to two separate but related problems and hence two different sections..  Hope I could answer this satisfactorily this time.. :)

My point was, given this is a MUST in section 2.3.4 and this sentence starts with "As already specified in Section 2.3.4" it does have to be an upper case MUST here again (because it's correctly normatively specified in section 2.3.4). However not a big issue.
[Pushpasis] Got it. Will do so..

If you think this could raise any concerns in the wg, you should go back to the wg mailing list and ask for feedback/confirmation.
[Pushpasis] I dont think it will raise a concern. Just wanted to avoid unwarranted discussion.. :) Anyways I will provide some text in the next version and ask WG to let know any comments or opinion.

[Uma]: It’s important to have a knob here and as long as this is there it’s fine (and this aspect is clearly described). This purely depends on how big the ring is but this sounds fine.

Thanks and Regards,
-Pushpasis

Thanks once again
-Pushpasis

---

From: Pushpasis Sarkar <[email-masked]>
Date: Fri, 20 Jan 2017 07:36:41 +0530

Hi Uma,

Many thanks for the comments..

For the clarification for everyone, the following text in section 2.3.4
already mention about the knob you requested..

"

Implementations MUST choose
   a default value for this limit and may provide user with a
   configuration knob to override the default limit.  Implementations
   MUST also evaluate some default preference criteria while considering
   a PQ-node in this subset.  Finally, implementations MAY also allow
   the user to override the default preference criteria, by providing a
   policy configuration for the same.

"

So there is two knobs this document specifies..
- A knob to set the limit to the number of nodes in the subset of PQ-nodes.
- A policy configuration to let user control which nodes will go in the
subset of PQ-nodes

Thanks
-Pushpasis

On Fri, Jan 20, 2017 at 1:36 AM, Uma Chunduri <[email-masked]>
wrote:

> *From:* rtgwg [mailto:[email-masked]] *On Behalf Of *Pushpasis
> Sarkar
> *Sent:* Thursday, January 19, 2017 3:39 AM
> *To:* Mirja Kühlewind <[email-masked]>
> *Cc:* [email-masked]; rtgwg-chairs <
> [email-masked]>; The IESG <[email-masked]>; RTGWG <[email-masked]>
> *Subject:* Re: Mirja Kühlewind's No Objection on
> draft-ietf-rtgwg-rlfa-node-protection-10: (with COMMENT)
>
>
>
> Hi Mirja,
>
>
>
> as
> [Uma]: It’s important to have a knob here and as long as this is there
> it’s fine (and this aspect is clearly described). This purely depends on
> how big the ring is but this sounds fine.
>
>
>
> Thanks and Regards,
>
> -Pushpasis
>
>
>
>
>
>
> Thanks once again
> -Pushpasis
>
>
>