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:46 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 681ED3A08EA; Thu, 9 Jul 2020 14:46:09 -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 aNcYO25gn0bO; Thu, 9 Jul 2020 14:46:03 -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 769B53A097B; Thu, 9 Jul 2020 14:46:00 -0700 (PDT)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 069LgTD4025041; Thu, 9 Jul 2020 17:45:59 -0400
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049458.ppops.net-00191d01. with ESMTP id 326b8gg5s6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Jul 2020 17:45:59 -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 069LjwWC074784; Thu, 9 Jul 2020 16:45:58 -0500
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [135.46.181.159]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 069Ljuvi074775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 9 Jul 2020 16:45:56 -0500
Received: from zlp30494.vci.att.com (zlp30494.vci.att.com [127.0.0.1]) by zlp30494.vci.att.com (Service) with ESMTP id 833754005C34; Thu, 9 Jul 2020 21:45:56 +0000 (GMT)
Received: from clph811.sldc.sbc.com (unknown [135.41.107.12]) by zlp30494.vci.att.com (Service) with ESMTP id 60CE54005C32; Thu, 9 Jul 2020 21:45:56 +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 069Ljurt012060; Thu, 9 Jul 2020 16:45:56 -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 069LjkBB011010; Thu, 9 Jul 2020 16:45:46 -0500
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTPS id 0DFB310A207A; Thu, 9 Jul 2020 17:45:46 -0400 (EDT)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Thu, 9 Jul 2020 17:45:45 -0400
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: "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: Rtgdir last call review of draft-ietf-ippm-route-08
Thread-Index: AQHWUVmSxZcKzKoaV0qZKr5QGRoDbaj73wAAgAPyqrA=
Date: Thu, 09 Jul 2020 21:45:44 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF0108A6EB77@njmtexg5.research.att.com>
References: <159379480523.17387.10085582756294278431@ietfa.amsl.com> <LEXPR01MB1040618FB8A6172B5FFBE8D39C660@LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE>
In-Reply-To: <LEXPR01MB1040618FB8A6172B5FFBE8D39C660@LEXPR01MB1040.DEUPRD01.PROD.OUTLOOK.DE>
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 lowpriorityscore=0 bulkscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 spamscore=0 malwarescore=0 phishscore=0 priorityscore=1501 suspectscore=0 clxscore=1011 impostorscore=0 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/3Xp-HGSbXh9ZLcs_NlL5x4RJ-c4>
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:46:12 -0000

Thanks Rüdiger, your NEW text is in the working version.
Al


> -----Original Message-----
> From: ippm [mailto:ippm-bounces@ietf.org] On Behalf Of
> Ruediger.Geib@telekom.de
> Sent: Tuesday, July 7, 2020 1:28 AM
> To: 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
> 
> 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=qNM9jZFj-
> xxOd1SGl1pwVCkR4PTrs1m7OAeEE5RYB54&s=DoM7hYZ2yxM0ntZm-
> QfGsfFEAfpfX8HGP86rl-bttPc&e=