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

Uma Chunduri <uma.chunduri@huawei.com> Sat, 17 November 2018 00:59 UTC

Return-Path: <uma.chunduri@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEC9128CF2; Fri, 16 Nov 2018 16:59:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level:
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=ham autolearn_force=no
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 Rd0eszr1O6UP; Fri, 16 Nov 2018 16:59:52 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670C9126CB6; Fri, 16 Nov 2018 16:59:51 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 495CA24B26190; Sat, 17 Nov 2018 00:59:46 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 17 Nov 2018 00:59:47 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.221]) by SJCEML703-CHM.china.huawei.com ([169.254.5.170]) with mapi id 14.03.0415.000; Fri, 16 Nov 2018 16:59:40 -0800
From: Uma Chunduri <uma.chunduri@huawei.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org" <draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: RE: Alvaro Retana's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)
Thread-Topic: Alvaro Retana's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)
Thread-Index: AQHUaw2nME2yvlGIw0WE7oI9sAA/g6VTRgCQ
Date: Sat, 17 Nov 2018 00:59:40 +0000
Message-ID: <25B4902B1192E84696414485F5726854136DA004@sjceml521-mbs.china.huawei.com>
References: <154032593854.31397.18305920636043363236.idtracker@ietfa.amsl.com>
In-Reply-To: <154032593854.31397.18305920636043363236.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.209.216.203]
Content-Type: multipart/mixed; boundary="_002_25B4902B1192E84696414485F5726854136DA004sjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/XRipAeQwILHoLQvGRU3BeViGLus>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Nov 2018 01:00:00 -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:aretana.ietf@gmail.com] 
Sent: Tuesday, October 23, 2018 1:19 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org; Stewart Bryant <stewart.bryant@gmail.com>; rtgwg-chairs@ietf.org; rtgwg@ietf.org
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..