Re: [ippm] Rtgdir last call review of draft-ietf-ippm-route-08

J Ignacio Alvarez-Hamelin <ihameli@cnet.fi.uba.ar> Tue, 07 July 2020 13:25 UTC

Return-Path: <ihameli@cnet.fi.uba.ar>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00433A0C9B; Tue, 7 Jul 2020 06:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 wH2dXT1xWlvQ; Tue, 7 Jul 2020 06:25:52 -0700 (PDT)
Received: from cnet.fi.uba.ar (cnet.fi.uba.ar [157.92.58.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC2A3A0C84; Tue, 7 Jul 2020 06:25:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by cnet.fi.uba.ar (Postfix) with ESMTP id 16709140077; Tue, 7 Jul 2020 10:25:47 -0300 (ART)
X-Virus-Scanned: Debian amavisd-new at cnet.fi.uba.ar
Received: from cnet.fi.uba.ar ([127.0.0.1]) by localhost (cnet.fi.uba.ar [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rD_KFsVpE07B; Tue, 7 Jul 2020 10:25:40 -0300 (ART)
Received: from [192.168.1.34] (unknown [181.27.209.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cnet.fi.uba.ar (Postfix) with ESMTPSA id 0FB2A140068; Tue, 7 Jul 2020 10:25:40 -0300 (ART)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: J Ignacio Alvarez-Hamelin <ihameli@cnet.fi.uba.ar>
In-Reply-To: <LEXPR01MB1040618FB8A6172B5FFBE8D39C660@LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE>
Date: Tue, 07 Jul 2020 10:25:40 -0300
Cc: ippm@ietf.org, last-call@ietf.org, draft-ietf-ippm-route.all@ietf.org, rtg-dir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B4D393EC-5F7B-4888-987C-0F8FECEA3B4E@cnet.fi.uba.ar>
References: <159379480523.17387.10085582756294278431@ietfa.amsl.com> <LEXPR01MB1040618FB8A6172B5FFBE8D39C660@LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE>
To: Ruediger.Geib@telekom.de, stewart.bryant@gmail.com
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/nLregG0-Ibet-Ts-Vyy3BM1GqE4>
Subject: Re: [ippm] Rtgdir last call review of draft-ietf-ippm-route-08
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2020 13:25:55 -0000

Dear Stewart,

Here is the correction on the previous part:

======
This procedure requires to compute quartile values "on the fly" using
the algorithm presented in [P2].

Minor English issue - missing text after requires
======
NEW

This procedure requires the algorithm presented in [P2] to compute quartile values "on the fly”.


Regards, 

	J. Ignacio


_______________________________________________________________

Dr. Ing. José Ignacio Alvarez-Hamelin
CONICET and Facultad de Ingeniería, Universidad de Buenos Aires
Av. Paseo Colón 850 - C1063ACV - Buenos Aires - Argentina
+54 (11) 5285 0716 / 5285 0705
e-mail: ihameli@cnet.fi.uba.ar
web: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
_______________________________________________________________


P.D. Thanks Rüdiger!




> On 7 Jul 2020, at 02:27, Ruediger.Geib@telekom.de wrote:
> 
> Hi Stewart,
> 
> Thanks, you are right, there are more options and the text should reflect that. I've reviewed the section and suggest some more clarifications below.
> 
> Regards, Ruediger
> 
> OLD
> Early deployments may support a so called
>   "Entropy label" for this purpose.  State of the art deployments base
>   their choice of an ECMP member based on the IP addresses (see
>   Section 2.4 of [RFC7325]). Both methods allow load sharing
>   information to be decoupled from routing information. Thus, an MPLS
>   traceroute is able to check how packets with a contiguous number of
>   ECMP relevant addresses (and the same destination) are routed by a
>   particular router.  The minimum number of MPLS paths traceable at a
>   router should be 32.  Implementations supporting more paths are
>   available.
> 
> NEW
> Late deployments may support a so called
>   "Entropy label" for this purpose.  State of the art deployments base
>   their choice of an ECMP member interface on the complete MPLS label stack 
>   and on IP addresses up to the complete 5 tuple IP header information (see
>   Section 2.4 of [RFC7325]). Load Sharing based on IP information decouples 
>   this function from the actual MPLS routing information. Thus, an MPLS
>   traceroute is able to check how packets with a contiguous number of
>   ECMP relevant IP addresses (and an identical MPLS label stack) are forwarded by a
>   particular router.  The minimum number of equivalent MPLS paths traceable at a
>   router should be 32.  Implementations supporting more paths are
>   available.
>  .
> 
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Stewart Bryant via Datatracker <noreply@ietf.org> 
> Gesendet: Freitag, 3. Juli 2020 18:47
> An: rtg-dir@ietf.org
> Cc: ippm@ietf.org; last-call@ietf.org; draft-ietf-ippm-route.all@ietf.org
> Betreff: Rtgdir last call review of draft-ietf-ippm-route-08
> 
> Reviewer: Stewart Bryant
> Review result: Has Issues
> 
> This is a well written document with a technical point that needs addressing and a couple of small nits, other than that it is ready to go.
> 
> ========
> Early deployments may support a so called
>   "Entropy label" for this purpose.  State of the art deployments base
>   their choice of an ECMP member based on the IP addresses (see
>   Section 2.4 of [RFC7325]).
> 
> The entropy label is a relatively modern concept and I am not sure how widely it is deployed. Older routers used either a hash on the labels as far down the stack as they could reach (the goal was to include the BoS label this was a VPN or a PW), or (more commonly) reached over the label stack (sometimes
> incorrectly) and hash on the five tuple of the payload.
> 
> ======
> This procedure requires to compute quartile values "on the fly" using the algorithm presented in [P2].
> 
> Minor English issue - missing text after requires ====== For reasons pointed out by one of the other reviewers, it is a pity that Class C is used, but it seems to be well embedded in the technology and would be difficult to change.
> =======
> Nits says that there is a requirements language problem. I think that may be that it is simply in the wrong place. It would be good if it were fixed to prevent other reviewers also needing to deal with this point
> 
> 
>