Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 18 August 2020 20:15 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649073A0B6D; Tue, 18 Aug 2020 13:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=A/NoExEo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sjDmsGeR
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 JmfRvv6nofGG; Tue, 18 Aug 2020 13:15:15 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE173A0B86; Tue, 18 Aug 2020 13:15:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47992; q=dns/txt; s=iport; t=1597781715; x=1598991315; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FyMk/nr5vZI8AiSzWp7RdDwWxIepJag8KqhBLueXzh4=; b=A/NoExEoxzTeBDu/cUxbwbjIoJd4/db0+29DDkxQPcK30yYdv2YpD3HO 8BwLiFJlf9KRk7wdAulEpHLSEGwiFnFGcSVBGoTR/2GNZhjVQhcj9cNpC pEpzJFxZuiyEsMa2vQiZASrS0M9pkUOAzXuXeKbncd5wtTho0FrYt7Yhm k=;
IronPort-PHdr: 9a23:/jn2pRALVosR58m2ohNqUyQJPHJ1sqjoPgMT9pssgq5PdaLm5Zn5IUjD/qw01A3VWoPKrfZF2KLasKHlDGoH55vJ8HUPa4dFWBJNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YlRSHte4Y1yB6nG35CQZTxP4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AiBgClNTxf/5tdJa1fHAEBAQEBAQcBARIBAQQEAQGCCoEjLyMuB3BYLywKhC2DRgONWYoIjmGBQoERA1AFAwgBAQEMAQEYAQoKAgQBAYRMAheCCAIkOBMCAwEBCwEBBQEBAQIBBgRthVwBC4VxAQEBBAEBEAsGChMBASUHCwEPAgEGAhEEAQEhAQYDAgICHwYLFAkIAgQOBQgagwWBfk0DLgEOlh+QaAKBOYhhdoEygwEBAQWFKw0LgSNrAwaBOIJxg2KGTBuBQT+BEUOCTT6CGkIBAQIBgScBCwcBIxUWCYJhM4Itj2iDG4ZhJos3kCFRCoJiiGSFfIZChSCDAIlck0eSO4pEgmWSFwIEAgQFAg4BAQWBaiNncHAVO4JpUBcCDY4fDBeDToNGgU6FQnQCNQIDAwEJAQEDCXyNKoE1AYEQAQE
X-IronPort-AV: E=Sophos;i="5.76,328,1592870400"; d="scan'208,217";a="543734486"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2020 20:15:12 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07IKF391018129 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 18 Aug 2020 20:15:11 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 15:15:08 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 15:15:08 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 18 Aug 2020 16:15:07 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WG2MhKV4vnfx+zYBEmaHrndXdsFQWhI/R5rkR2wtZXEpEWAgYXLw1TFYV1K1LEOfTt+SxuWOpJ/46B9nFx9LoD6YsJD9e6h8uRfFtRxT4ULnOSnfC95I9dRGRdUdzMTTOSipEsF8C84ePJARw1ZES5piD0Bqnaru/+mgLGA0XGsUCsk3P/o/6/caAWnaF3Ruprnlhp/IjfSNReyMwh/fZ14xgfy0P+KIUpQ5JLYLDsd/c9V0Bm1dQkVvqMyzeAZ9KOY2bSixc4GaGwnGZjHcs9maLOsez3e6bxWxHnioqxriGSmQMMjaZk5zS0ft5FnVEvwOAy8shs2qtP0akfB91g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FyMk/nr5vZI8AiSzWp7RdDwWxIepJag8KqhBLueXzh4=; b=MIlVZ6VbBtnSFlWm9q4UbP4hqxjI7KWI14t4OrdO+gf414J5On8pfBMXCXTTXSX8yPg8D82REggek/Wk8hSHD+S+B/73zVoYAUTuHfdwfifZHpxWwxmR3jBhzs20P1Dau8D7POULPpl7NMXYbz9WMpICAZx9GcfBbmgVM3js+wpiRrN/wuwChZft/dNP34yUe2ERgFC8ZqLdmnd3JwqMQ8ayoHZDVEodmDhgQz5XGFnw37haOKbF8YhZVmK2Lt4Wiwz+T7IX+hoKP6W6o2/aPtGag+5docc1qtP7uzMhACmzA4wmnlzPSYPezPSc7MKSQdjO5/gf+isFSR/5r/1fKw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FyMk/nr5vZI8AiSzWp7RdDwWxIepJag8KqhBLueXzh4=; b=sjDmsGeRjm1SXivSntmwLGGIiDZ4vfwSABcCOBxeMw53o6HutA2y8HK/4VlC4QDfJcQetxxjHDekq165U6gUCzjJnttmSh8K8VA2txSg5/yrEGQc6gq33lHVEZYIkesgP6Fp7L+4aqExXI9gPuGI6uISvz3EVV6rkTcaptBnQT8=
Received: from BY5PR11MB4337.namprd11.prod.outlook.com (2603:10b6:a03:1c1::14) by BYAPR11MB3157.namprd11.prod.outlook.com (2603:10b6:a03:75::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.26; Tue, 18 Aug 2020 20:15:06 +0000
Received: from BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf]) by BY5PR11MB4337.namprd11.prod.outlook.com ([fe80::418a:3b0a:d7e1:a3cf%3]) with mapi id 15.20.3283.028; Tue, 18 Aug 2020 20:15:06 +0000
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: "tony.li@tony.li" <tony.li@tony.li>
CC: Robert Raszuk <robert@raszuk.net>, Christian Hopps <chopps@chopps.org>, "draft-ietf-lsr-flex-algo.all@ietf.org" <draft-ietf-lsr-flex-algo.all@ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>, "Acee Lindem (acee)" <acee@cisco.com>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>
Thread-Topic: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
Thread-Index: AQHWdO51MQpjMYVPmkGrSI2v6t8U86k898AAgACasICAAF/ZAIAAFHVwgAAG5ICAAAtMgIAAIi7AgAAHsYCAAAuk0A==
Date: Tue, 18 Aug 2020 20:15:06 +0000
Message-ID: <BY5PR11MB4337CA956A5DC6807AAC992DC15C0@BY5PR11MB4337.namprd11.prod.outlook.com>
References: <9094873B-3A03-4F48-B438-55AB0CA75396@chopps.org> <E9DF9CDA-D031-4995-BB69-7A9CEE312707@tony.li> <dff9ca08-8950-ef1c-5926-39944e94c98b@cisco.com> <E6A4AB1E-6A37-4424-8E27-2F0BFE7E3313@tony.li> <BY5PR11MB4337D97F838FFD8B250BACB1C15C0@BY5PR11MB4337.namprd11.prod.outlook.com> <CAOj+MMG9_yBK7-qWLA6Xfsq-4u4hpXz4x5FSdLA0arBw9cdc+g@mail.gmail.com> <7D686875-46CA-4E3C-8F1A-3A02DB162499@tony.li> <BY5PR11MB4337563B637688679BC847A1C15C0@BY5PR11MB4337.namprd11.prod.outlook.com> <BC568CAB-AB04-4656-950B-9E38318ADB7F@tony.li>
In-Reply-To: <BC568CAB-AB04-4656-950B-9E38318ADB7F@tony.li>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: tony.li; dkim=none (message not signed) header.d=none;tony.li; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [99.108.166.100]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: afcf288d-f37d-4354-6dcd-08d843b36663
x-ms-traffictypediagnostic: BYAPR11MB3157:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB3157F9C4BE77ED5060BEF7B1C15C0@BYAPR11MB3157.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: jxagEOC1yTvRhVCYqrj+kus/inlnFwmfdy89ZTE8+mLK7JRyI0fBRW2/GMR5FQgwkdMM6gLm+oh2W5m1hW7YyyXozPGSXz3SlzGEPgcJRwq111e0T2DR1hCcE/jSMjia7NKEJws2AjlCbzeQqJ2RSUHt6uDRvsaDU5tbhZQN597VtB57Y52rlOZYIwakkIw/vxUrxqJqwayvd2O8xPbMOnj6q8Z6Y0HgJQ+CM0Fm6w9mz+Of2EKV6p3n67i9S++rxVs9H/PNoOvYDVsZona19Fl8XwAtkkd9sgF/m065qKn4d/RSoglKILElcyvuqMPIIvuJvWbLX4sFWTtcYSOg9Co3WJGQHIyH3dLf7HT8EzpYbGRLc7rzhFWbJ6tIdclIHgGZNwOv20lh5hPIuDN/aQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4337.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(136003)(376002)(396003)(366004)(966005)(166002)(83380400001)(86362001)(54906003)(6916009)(33656002)(316002)(52536014)(8936002)(8676002)(9686003)(66476007)(66446008)(2906002)(66946007)(107886003)(76116006)(478600001)(6506007)(55016002)(64756008)(26005)(5660300002)(7696005)(53546011)(186003)(71200400001)(4326008)(66556008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: d71p5aRu6UPhi/QETWuzPuneEdJ5fN3nkIxnfTuYYLeoOy1FpltjUFjL6fqz0nWDRUsRbUu05YOh5IzvAfkZ64jQm/ToETp7i68KUfdG+GNcvVeR6J6oSJ520y76qe+pdeEao7sExuy6f+5qcJbk9e/RjfQqAdMhINUCoLZ1hCui//AWcSeIWuqw8xUqLfNekVKTjP4RRtptzGjBuo5ejLt7lCUhx12A/Ejjsh1xA8J4ZjxVnI9IrHRHbph/Ut6XkCRK6ZfG9erc81FjxTQoydfRpoT3ecp+Wc3spw5iJCUxmRfvf5fAtH6exKG7rDhVTEBeSsrUKCY8InQhW8JpN5zVakWXzCKXiILyc7zoFxJY/iXiEbA2fM8sI8vLMFvY95NaIPnuDOCwqcuupszLtcwzgiMnqTbhhnzvpnHz4FHQzQcx147p3iZjni9zs1u9uYKTWOMwcc2dx4+cZgUfzMRaZZKlLhNPCC1OOlhzEbRme1wqdJy9Q0bmAGFXo2tCUVXGsGE2Vs+HQtxxcFrr5fxFiQ8mPWoPZaJiomtPAX9lGNaNPum4Cbbg1Ab0O7Bqxb1SX/BRr2iLGNkdsSMS2uwq/T5PGAzDMW7r6Vo1di5TC43AgyBeUKmHFtZWRuyZJkYFZk/tv0mSaI9m6AJGqQ==
Content-Type: multipart/alternative; boundary="_000_BY5PR11MB4337CA956A5DC6807AAC992DC15C0BY5PR11MB4337namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4337.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: afcf288d-f37d-4354-6dcd-08d843b36663
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2020 20:15:06.7245 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jEwPyJUEkwKF9hWLLR/GG9fowpJJDkZ+FrXUy0afQahArUCRtLyjn5sKmv6j1l6EafhOEVdhDVvis2VdhescKA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3157
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/t7xbpToT3UN1wAhnOqyr3yXI1is>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2020 20:15:18 -0000

Tony –

I am not “fighting”.
I just found your interpretation very hard to follow.

Moving on…

   Les


From: Tony Li <tony1athome@gmail.com> On Behalf Of tony.li@tony.li
Sent: Tuesday, August 18, 2020 12:33 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>; Christian Hopps <chopps@chopps.org>; draft-ietf-lsr-flex-algo.all@ietf.org; Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; lsr@ietf.org; lsr-ads@ietf.org; Acee Lindem (acee) <acee@cisco.com>; Peter Psenak (ppsenak) <ppsenak@cisco.com>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Les,

There is no TLV called the Min Unidirectional Link Delay.

If the document had said “The min delay of the Min/Max Unidirectional Link Delay” then there would be no confusion.

Instead, it is the sloppy writing of ignoring the full name of the TLV that has created ambiguity.

Now, Peter has agreed to make a clarification, so:

              Why are we still fighting?

Tony



On Aug 18, 2020, at 12:18 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:

Tony/Robert –

Whatever clarification Peter may choose to make would be fine – but I do question your casual ignoring of adjectives. 😊

There are three values being advertised:

33 - Unidirectional Link Delay
34 – Min/Max Unidirectional Link Delay
         Meaning two values are advertised in this codepoint:
         Min Unidirectional Link Delay
         Max Unidirectional Link Delay

Now, the flex algo draft states: Min Unidirectional Link Delay

If you want to argue that “Min Unidirectional Link Delay” != “Min/Max Unidirectional Link Delay” – I think you are pedantically correct.

But how that leads you to simply truncate “Min” and conclude that this is really “Unidirectional Link Delay” is a leap that I cannot follow.

Perhaps you don’t really like the fact that RFC 8570 encoding combined Min/Max in a single codepoint – but that ship sailed years ago.

Given that RFC 8570 is very clear in showing that the encoding includes:

<snip>
   0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Type        |     Length    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |A| RESERVED    |                   Min Delay                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   RESERVED    |                   Max Delay                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<end snip>

my ability to see your POV is somewhat limited.

Perhaps you could own that a more careful reading is possible?

   Les


From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of tony.li@tony.li<mailto:tony.li@tony.li>
Sent: Tuesday, August 18, 2020 10:03 AM
To: Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>>
Cc: Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>; draft-ietf-lsr-flex-algo.all@ietf.org<mailto:draft-ietf-lsr-flex-algo.all@ietf.org>; Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org<mailto:ginsberg=40cisco.com@dmarc.ietf.org>>; lsr@ietf.org<mailto:lsr@ietf.org>; lsr-ads@ietf.org<mailto:lsr-ads@ietf.org>; Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>; Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Robert,

Thank you, exactly.

We just need a clarification of the document.  I don’t understand why this is such a big deal.

Tony




On Aug 18, 2020, at 9:22 AM, Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:


      Type    Description

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

       33     Unidirectional Link Delay



       34     Min/Max Unidirectional Link Delay

That means that is someone implementing it reads text in this draft literally (meaning Minimum value of Unidirectional Link Delay) it may pick minimum value from ULD type 33 :)

If you want to be precise this draft may say minimum value of Min/Max Unidirectional Link Delay (34) and be done.

That's all.

Cheers,
R.



On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Tony –

As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why you are confused – nor why you got misdirected to code point 33.

RFC 8570 (and its predecessor RFC 7810) define:

34           Min/Max Unidirectional Link Delay

This sub-TLV contains two values:

“Min Delay:  This 24-bit field carries the minimum measured link delay
      value (in microseconds) over a configurable interval, encoded as
      an integer value.

   Max Delay:  This 24-bit field carries the maximum measured link delay
      value (in microseconds) over a configurable interval, encoded as
      an integer value.”

It seems clear to me that the flex-draft is referring to Min Unidirectional Link Delay in codepoint 34.

I agree it is important to be unambiguous in specifications, but I think Peter has been very clear.
Please explain how you managed to end up at code point 33??

   Les



From: Lsr <lsr-bounces@ietf.org<mailto:lsr-bounces@ietf.org>> On Behalf Of tony.li@tony.li<mailto:tony.li@tony.li>
Sent: Tuesday, August 18, 2020 7:44 AM
To: Peter Psenak (ppsenak) <ppsenak@cisco.com<mailto:ppsenak@cisco.com>>
Cc: lsr@ietf.org<mailto:lsr@ietf.org>; lsr-ads@ietf.org<mailto:lsr-ads@ietf.org>; Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>; Acee Lindem (acee) <acee@cisco.com<mailto:acee@cisco.com>>; draft-ietf-lsr-flex-algo.all@ietf.org<mailto:draft-ietf-lsr-flex-algo.all@ietf.org>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo


Hi Peter,


section 5.1 of the draft-ietf-lsr-flex-algo says:

Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].

We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed with other delay values (max, average).


The problem is that that does not exactly match “Unidirectional Link Delay” or “Min/Max Unidirectional Link Delay”, leading to the ambiguity. Without a clear match, you leave things open to people guessing. Now, it’s a metriic, so of course, you always want to take the min.  So type 33 seems like a better match.



section 7.3. of ietf-isis-te-app says:

Type   Description                          Encoding
                                           Reference
---------------------------------------------------------
34      Min/Max Unidirectional Link Delay    RFC8570


And it also says:


33      Unidirectional Link Delay            RFC8570<https://tools.ietf.org/html/rfc8570>


This does not help.


So, IMHO what we have now is correct and sufficient, but I have no issue adding the text you proposed below.


What you have now is ambiguous. We have a responsibility, as writers of specifications, to be precise and clear.  We are not there yet.


BTW, before I posted 09 version of flex-algo draft, I asked if you were fine with just referencing ietf-isis-te-app in 5.1. I thought you were, as you did not indicate otherwise.


My bad, I should have pressed the issue.


Anyway, I consider this as a pure editorial issue and hopefully not something that would cause you to object the WG LC of the flex-algo draft.


I’m sorry, I think that this is trivially resolved, but important clarification.

You also have an author’s email that is bouncing, so at least one more spin is required.

Sorry,
Tony

_______________________________________________
Lsr mailing list
Lsr@ietf.org<mailto:Lsr@ietf.org>
https://www.ietf.org/mailman/listinfo/lsr