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

Peter Psenak <ppsenak@cisco.com> Tue, 18 August 2020 17:33 UTC

Return-Path: <ppsenak@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 91AE73A08DE; Tue, 18 Aug 2020 10:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.55
X-Spam-Level:
X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.949, 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
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 akayyDM1_GbF; Tue, 18 Aug 2020 10:33:07 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1078E3A0890; Tue, 18 Aug 2020 10:33:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7744; q=dns/txt; s=iport; t=1597771987; x=1598981587; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=qbo+GGyFQPSlE2lN4rKQZFTuaosH4d4nsvRB1XPqy2M=; b=UPrpwrTKZ5686dTn3Vx0SSo4aC8crSsCLieP+9gveALlrFAL50hXNevf WsPtQR30GmsqN6LOqkdA4tHly4eUdKidQESmgNXQKQ7Q68CG9fqOQdsbw V+//mXhGwP8MfPZZ+nwtZYdB0yplG5On6NWMDkJ2yf6GtJ5ShzCIjNfRG 4=;
X-IronPort-AV: E=Sophos;i="5.76,328,1592870400"; d="scan'208";a="28852289"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Aug 2020 17:33:05 +0000
Received: from [10.60.140.51] (ams-ppsenak-nitro2.cisco.com [10.60.140.51]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id 07IHX4Th023118; Tue, 18 Aug 2020 17:33:04 GMT
To: Robert Raszuk <robert@raszuk.net>, Tony Li <tony.li@tony.li>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>, Christian Hopps <chopps@chopps.org>, "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-lsr-flex-algo.all@ietf.org" <draft-ietf-lsr-flex-algo.all@ietf.org>
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> <CAOj+MMGDTTW7mpq0JsWL2Xu58C2RassvRrxH9nDOuY5c5QKtBQ@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <d3c1e569-8b5f-8f9b-f785-3bbf5a997119@cisco.com>
Date: Tue, 18 Aug 2020 19:33:03 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <CAOj+MMGDTTW7mpq0JsWL2Xu58C2RassvRrxH9nDOuY5c5QKtBQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.51, ams-ppsenak-nitro2.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/o3xnrnJgl0FYuaoA6iiQlErRWxg>
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 17:33:17 -0000

Hi Robert,

On 18/08/2020 19:10, Robert Raszuk wrote:
> Hi Tony,
> 
> I am not sure what the deal is :)
> 
> But fact is that we never defined a type which this draft is referring to
> 
> "Min Unidirectional Link Delay" just does not exist in any IANA registry 
> so even any search for that will fail.
> 
> Perhaps authors assumed that:
> 
> Min/Max Unidirectional Link Delay means both "Min Unidirectional Link 
> Delay" & "Max Unidirectional Link Delay" but this is just asking 
> for ambiguity.

yes, Min/Max Unidirectional Link Delay advertise both Min and Max and we 
use Min out of that.

I'll make the clarification in the draft, so we can close this discussion.

thanks,
Peter

> 
> Cheers,
> R.
> 
> On Tue, Aug 18, 2020 at 7:02 PM <tony.li@tony.li 
> <mailto:tony.li@tony.li>> wrote:
> 
> 
>     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
>