Re: [i2rs] Warren Kumari's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)

"Susan Hares" <shares@ndzh.com> Thu, 05 April 2018 14:30 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C3D12D94E; Thu, 5 Apr 2018 07:30:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level:
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 uoZ9yH-4Upvs; Thu, 5 Apr 2018 07:30:43 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F302C12D94A; Thu, 5 Apr 2018 07:30:42 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.170.24.89;
From: Susan Hares <shares@ndzh.com>
To: warren@kumari.net
Cc: i2rs@ietf.org, 'The IESG' <iesg@ietf.org>, i2rs-chairs@ietf.org, draft-ietf-i2rs-rib-info-model@ietf.org
Date: Thu, 05 Apr 2018 10:30:17 -0400
Message-ID: <048601d3ccea$9f108570$dd319050$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0487_01D3CCC9.17FFF6E0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdPM6cLt/ut98NjJRSGC13rjZOJEJw==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/Y5IDo8TwQqukluYM3d4XsLGV9Pg>
Subject: Re: [i2rs] Warren Kumari's No Objection on draft-ietf-i2rs-rib-data-model-10: (with COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 14:30:46 -0000

Warren:

 

I cannot find your original text - so I hope this email finds you quickly.  

 

As the shepherd reviewer, I'll encourage the authors to fix the nits.  Thank
you.  Do you want re-review any of issues before publication? 

 

Susan Hares 

--------------

 

On the large question, see below. 

 

I do have a large question, a comment,  and a bunch of nits:

1: Question:

o  NEXTHOP_LB_WEIGHT: This is used for load-balancing.  Each list

      member MUST be assigned a weight between 1 and 99.  The weight

      determines the proportion of traffic to be sent over a nexthop

      used for forwarding as a ratio of the weight of this nexthop

      divided by the weights of all the nexthops of this route that are

      used for forwarding.  To perform equal load-balancing, one MAY

      specify a weight of "0" for all the member nexthops.  The value

      "0" is reserved for equal load-balancing and if applied, MUST be

      applied to all member nexthops.

 

I'm confused what makes 0 special -- if I have e.g 17 links and I assign a
weight of e.g 42 to each of them I'll still get equal load-balancing, yes?

 

Why is 0 reserved? I get that having one link with a weigh of e.g 12 and
another link with a weight of 0 that would cause issues, but perhaps 0
should simply be unusable?

I a: really don't understand and b: thing the document should have some text
answering this.

 

Sue: I agree the document should have text that resolves discusses why zero
is unique.  

 

My recollection of 3 years ago - is that that "0" was utilized by many RIB
functions as a unique case.  In order to ease gluing this to the current
operational RIBS, the "zero" value was deemed as reserved. In doing the text
update, I will go back to past chairs (Alia Atlas and Jeff Haas) to get
context.  Or you can send Alia an Email. 

[Sigh - this would have been easier in March]. 

 

2: Comment: Section 7.1.  Using route preference

The entire "Route preference can also be used..." paragraph, while true,
feels very out of place. I'd suggest jsut removing it. 

 

I'll review this with the authors and send  proposed text.   This paragraph
was suggested to be insert in some past reviews.  [Sigh]