Subject: RE: Alvaro Retana's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)

From: Uma Chunduri <[email-masked]>
Date: Sat, 17 Nov 2018 00:59:40 +0000

Hi Alvaro,

Thanks for your through review and suggestions.

We tried to address most of your comments except one (still working).

Please see the attached diff file and my response in-line [Uma]:

--
Uma C.

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2018 1:19 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Stewart Bryant <[email-masked]>; [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-rtgwg-multihomed-prefix-lfa-08: 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-multihomed-prefix-lfa/

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

Thanks for doing this work!

(1) I've read rfc5286, but I still had to go back to it to refresh my memory of the Inequalities...even to make sure that I was understanding/remembering the inequalities in §2 correctly.  I think it would be good to (1) include some text to go over (in plain English) what the inequalities are saying, and, (2) "show your work" (at least reference where the corresponding Inequalities came from in rfc5286).  IOW, add text to describe the inequalities in Figures 1, 6 and 7.

[Uma]: Please see the updates in Section, Figure 1 and sections in figure 6 and 7.

(2) §3 says both that "a computing router S MUST follow one of the appropriate procedures below, for each alternate neighbor N", and "the computing router SHOULD evaluate one of the corresponding LFA inequalities, as mentioned in Figure 1, once for each remote node that originated the prefix".  First off, MUST != SHOULD.  

[Uma]: Agree and fixed. 

Also, it seems to me that "each alternate neighbor" is not the same as "each...node that originated the prefix".  However §3.1 points out that they are the same (or, I guess, at least equivalent): "[RFC5286] Section 6.1 recommends that a router computes the alternate next-hop for an IGP multi-homed prefix by considering alternate paths via all routers that have announced that prefix and the same has been elaborated with appropriate inequalities in the above section".  Please clarify what is meant with the different terminology, or (maybe better) use the same words.

[Uma]: See if the change I made addressed the above comment.

(3) The document doesn't explain what a multi-homed prefix is.  There are some
hints throughout the text, but I couldn't find a clear definition.   rfc5286
has a description in §6.1, but about "multi-homed routes".  For clarity, the document would benefit from a couple of sentences in the Introduction...

[Uma]: Added and it's based on section 6.1 text you referred (with necessary modifications).

(4) This document uses MAX_METRIC to describe constants in IS-IS and OSPF:
"0xffffff /2^24 - 1 for IS-IS and 0xffff for OSPF" (§5.1).  However neither protocol use MAX_METRIC as the name for those values: OSPF uses MaxLinkMetric
(rfc6987) and IS-IS simply "maximum link metric" (rfc5305).  I think that it is ok to use the term MAX_METRIC in this document, but please be clear on what it is from the start (in the Introduction).

[Uma]: Updated Section 5.1 to reflect your comments (also referred the same from introduction). 

BTW, Figure 8 uses MAX_MET (not MAX_METRIC)

[Uma]: Fixed.

(5) §3.1: "The approach specified here MAY also be applicable for handling default routes as explained in Section 3.2." I think that MAY is out of place because it is pointing out a fact, and there doesn't seem to be a normative behavior attached. s/MAY/may

[Uma]: Fixed.

(6) §3.2: "...when multiple ECMP L1/L2 routers are reachable in an L1 area corresponding best LFAs SHOULD be given for each primary next-hop associated with default route".  I don't know what this sentence says.  Please clarify. 
Specifically, what does "SHOULD be given" mean?

[Uma]: Clarified further. We kept here "SHOULD" because this is referring to simplified approach as defined section 3.1 (which is further extends the simplified approach specified in Section 6.1 of RFC 5286). But I am bit conflicted here, perhaps I should use MAY here to be consistent with Section 3.1. Seek your suggestion here.

(7) §4.1: "LFA evaluation for multi-homed external prefixes in IS-IS is similar to the multi-homed internal prefixes."  The text says "similar", but no differences are mentioned...is it similar, or the same?

[Uma]: "same" - Fixed.

(8) Do we really still have to worry about RFC1583Compatibility?  Just wondering...

[Uma]: May be not but don't want to change anything now.

(9) The document could benefit from a grammar-focused review as many articles (the, an, a) are missing.

[Uma]: Agree. Took care some, shall try to review further before upload (and also I presume AUTH48 would catch even more).

(10) "proceed to step 4c" in Figure 5 seems to not be needed.

[Uma]: Still working on the same, consulting with my co-authors and shall fix before the final upload..

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 20 Nov 2018 16:48:49 +0000

Hi Alvaro,

For your comment #10: (my co-author's response who owned this part of the draft)

Step 4c is required. ASBRs advertising same type2 cost but different cost to reach ASBR are considered for LFA evaluation.
This is explained in section 4.2.1.2

But we  have one small change in section 4.2.1.2. 

"When there are
   multiple ASBRs advertising same type 2 cost for the prefix, primary
   AS external route calculation as described in [RFC2328] section
   16.4.1 selects the route with lowest type 2 cost."

Change to
"When there are
   multiple ASBRs advertising same type 2 cost for the prefix, primary
   AS external route calculation as described in [RFC2328] section
   16.4 selects the route with lowest type 2 cost"

Section changed to 16.4 instead of 16.4.1.

For #6: 
No further change than indicated below (referred the earlier section in the text).

Please see the attached version which takes care of all IESG comments (including Benjamin's suggestions to improve abstract).

Hope we can upload this version.

--
Uma C. (on behalf of co-authors)

-----Original Message-----
From: Uma Chunduri 
Sent: Friday, November 16, 2018 5:00 PM
To: 'Alvaro Retana' <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; Stewart Bryant <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Alvaro Retana's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)

Hi Alvaro,

--
Uma C.

-----Original Message-----
From: Alvaro Retana [mailto:[email-masked]] 
Sent: Tuesday, October 23, 2018 1:19 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; Stewart Bryant <[email-masked]>; [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)

[Uma]: Agree and fixed. 

[Uma]: Fixed.

[Uma]: Fixed.

[Uma]: "same" - Fixed.

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 20 Nov 2018 10:14:54 -0800

On November 16, 2018 at 7:59:47 PM, Uma Chunduri ([email-masked])
wrote:

Uma:

Hi!

Just one comment:

...

(6) §3.2: "...when multiple ECMP L1/L2 routers are reachable in an L1 area
corresponding best LFAs SHOULD be given for each primary next-hop
associated with default route". I don't know what this sentence says.
Please clarify.
Specifically, what does "SHOULD be given" mean?

[Uma]: Clarified further. We kept here "SHOULD" because this is referring
to simplified approach as defined section 3.1 (which is further extends the
simplified approach specified in Section 6.1 of RFC 5286). But I am bit
conflicted here, perhaps I should use MAY here to be consistent with
Section 3.1. Seek your suggestion here.

I saw the updated text.

The part I’m having a hard time understanding is “SHOULD be given”…what
does that mean?  I think I’m ok with the SHOULD, I just don’t know what the
action (“be given”) is.  What are you specifying?

Thanks!

Alvaro.

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 20 Nov 2018 18:52:25 +0000

Hi Alvaro,

>The part I’m having a hard time understanding is “SHOULD be given”…what does that mean?  I think I’m ok with the SHOULD, I just don’t know what the action (“be given”) is.  What are you specifying?

Ok, I understand your question/concern now. In this section as we are talking about ECMP MHPs; we are suggesting better alternatives can be provided to the default route individual ECMP NHs if these are modeled as specified in Section 3.1.

I can change this to “SHOULD be computed..” or let me know if you have any other suggestion.

Thx!

--

Uma C.

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 21 Nov 2018 04:54:12 -0800

That works.  Thanks!

On November 20, 2018 at 1:52:30 PM, Uma Chunduri ([email-masked])
wrote:

Hi Alvaro,

Ok, I understand your question/concern now. In this section as we are
talking about ECMP MHPs; we are suggesting better alternatives can be
provided to the default route individual ECMP NHs if these are modeled as
specified in Section 3.1.

I can change this to “SHOULD be computed..” or let me know if you have any
other suggestion.

Thx!

--

Uma C.