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

"MORTON, ALFRED C (AL)" <acm@research.att.com> Thu, 09 July 2020 21:51 UTC

Return-Path: <acm@research.att.com>
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 46D223A08ED; Thu, 9 Jul 2020 14:51:47 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Rod6w3fWx8gz; Thu, 9 Jul 2020 14:51:44 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 146EC3A08EA; Thu, 9 Jul 2020 14:51:43 -0700 (PDT)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 069LXSRR048267; Thu, 9 Jul 2020 17:51:40 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049463.ppops.net-00191d01. with ESMTP id 325wwd23g6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jul 2020 17:51:40 -0400
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 069Lpduf083924; Thu, 9 Jul 2020 16:51:39 -0500
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [135.46.181.157]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 069LpXRj083790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jul 2020 16:51:34 -0500
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [127.0.0.1]) by zlp30496.vci.att.com (Service) with ESMTP id 0B2E4403A425; Thu, 9 Jul 2020 21:51:33 +0000 (GMT)
Received: from clph811.sldc.sbc.com (unknown [135.41.107.12]) by zlp30496.vci.att.com (Service) with ESMTP id D8145403A420; Thu, 9 Jul 2020 21:51:32 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 069LpU61042935; Thu, 9 Jul 2020 16:51:32 -0500
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 069LpMxt042499; Thu, 9 Jul 2020 16:51:24 -0500
Received: from exchange.research.att.com (njmtcas1.research.att.com [135.207.255.86]) by mail-azure.research.att.com (Postfix) with ESMTPS id 1A70E10A207A; Thu, 9 Jul 2020 17:51:19 -0400 (EDT)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas1.research.att.com ([fe80::e881:676b:51b6:905d%12]) with mapi id 14.03.0487.000; Thu, 9 Jul 2020 17:51:19 -0400
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: J Ignacio Alvarez-Hamelin <ihameli@cnet.fi.uba.ar>, "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>, "stewart.bryant@gmail.com" <stewart.bryant@gmail.com>
CC: "draft-ietf-ippm-route.all@ietf.org" <draft-ietf-ippm-route.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: [ippm] Rtgdir last call review of draft-ietf-ippm-route-08
Thread-Index: AQHWUVmSxZcKzKoaV0qZKr5QGRoDbaj73wAAgACFkgCAA22l8A==
Date: Thu, 09 Jul 2020 21:51:17 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF0108A6EB9C@njmtexg5.research.att.com>
References: <159379480523.17387.10085582756294278431@ietfa.amsl.com> <LEXPR01MB1040618FB8A6172B5FFBE8D39C660@LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE> <B4D393EC-5F7B-4888-987C-0F8FECEA3B4E@cnet.fi.uba.ar>
In-Reply-To: <B4D393EC-5F7B-4888-987C-0F8FECEA3B4E@cnet.fi.uba.ar>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [69.141.203.172]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-09_11:2020-07-09, 2020-07-09 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 impostorscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 spamscore=0 suspectscore=0 phishscore=0 priorityscore=1501 adultscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007090144
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/yTbpbknS4V44ZGlbaEZQvnm3yUk>
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: Thu, 09 Jul 2020 21:51:48 -0000

Thanks Ignacio, I have added your NEW text to the working version.
Al


> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of J Ignacio Alvarez-
> Hamelin
> Sent: Tuesday, July 7, 2020 9:26 AM
> To: Ruediger.Geib@telekom.de; stewart.bryant@gmail.com
> Cc: draft-ietf-ippm-route.all@ietf.org; last-call@ietf.org; rtg-
> dir@ietf.org; ippm@ietf.org
> Subject: Re: [ippm] Rtgdir last call review of draft-ietf-ippm-route-08
> 
> 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: https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__cnet.fi.uba.ar_ignacio.alvarez-2Dhamelin_&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=M3YmjIQx0fRYuePHMB4-
> eL81RTxXhx9rxjCedmHPofU&s=dxdbx5s1hKosBmwmgPBmyO4gtTyx34fo4_WDVZizodU&e=
> _______________________________________________________________
> 
> 
> 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
> >
> >
> >
> 
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ippm&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=M3YmjIQx0fRYuePHMB4-
> eL81RTxXhx9rxjCedmHPofU&s=jc0Qu5cvjWUUk-9ni2TMhivNPh4-Th1f62BrChzmkwk&e=