Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

Peter Psenak <ppsenak@cisco.com> Wed, 03 March 2021 11:11 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 EA6B93A0D58 for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 03:11:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.602
X-Spam-Level:
X-Spam-Status: No, score=-9.602 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.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
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 V6xnpcnR6CO6 for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 03:11:36 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4163A0D4D for <lsr@ietf.org>; Wed, 3 Mar 2021 03:11:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6371; q=dns/txt; s=iport; t=1614769896; x=1615979496; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=PqS5qn3fd+VgAR/WncuIhAc3IvfFB8u+gUNBA+pmQXY=; b=IDg8/npAUuR58qQIEqJ6dMAzQUDapZcdU11z89iSsu4yYrm3NKEDQNRr oD4IANQUa3pmz2YZvL1owIEzCWwragSxU0/4cViSgn2I7nsQI7U+UJEYi L6D/cpSMrmv66p1xUYJfCTnOq6my40ZGIUd2sw6cUpbzsJAvvYmNRuho4 M=;
X-IPAS-Result: =?us-ascii?q?A0BXAAAebj9glxbLJq1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBPgMBAQELAYF1gStWAScSMYRBiQSIKQglA5xLCwEBAQ8oDAQBAYRNA?= =?us-ascii?q?oF7JjcGDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAQEBhjYNhkUBBSMPA?= =?us-ascii?q?QVBEAsYAgIjAwICRhEGDQYCAQGCbAGDBw+sVxd2gTKEQwKBE4NOgT4GgQ4qA?= =?us-ascii?q?Y1CQoFJQoE4DII5Lj6CXAEBA4Rzgl8EgkZkBC8iAQFQdBmULAGmKIMGgy+GE?= =?us-ascii?q?JJVBQcDH4M3kB4sj1WgEpcJgWoigVkzGggbFYMkUBkNjjiIaoVGQAMvOAIGA?= =?us-ascii?q?QkBAQMJjBMBAQ?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,219,1610409600"; d="scan'208";a="33814835"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Mar 2021 11:11:31 +0000
Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 123BBUEg014306; Wed, 3 Mar 2021 11:11:31 GMT
To: Robert Raszuk <robert@raszuk.net>
Cc: Tony Li <tony.li@tony.li>, Gyan Mishra <hayabusagsm@gmail.com>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Shraddha Hegde <shraddha@juniper.net>, Rajesh M <mrajesh@juniper.net>, "lsr@ietf.org" <lsr@ietf.org>, William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>
References: <161401476623.19237.3808413288895066510@ietfa.amsl.com> <CABNhwV0UKB=HaMs9eLvvp4fVLPsEtJhQ2xFmwY80sqBNDFRudQ@mail.gmail.com> <DM5PR0501MB38006C4B638AD2AB6A7731B5CD9A9@DM5PR0501MB3800.namprd05.prod.outlook.com> <7C67D01F-24DB-4450-8587-E004CAFBBEBC@tony.li> <CAOj+MMGZppwYtNr4t0rJoy3BKWaBYqHiJ_esM1XNFTNxbm8c5w@mail.gmail.com> <08882555-009B-4068-ABB0-20B0D165D722@tony.li> <2c2605a8-95c6-a477-b1b5-5ae4d4de222a@cisco.com> <CAOj+MMGf=zQMGP+q+XX-MJi-qMrOddmq_+wmrXFS+JQX_PsudQ@mail.gmail.com> <25a8853a-72a3-3013-6a87-d8049ed7a3da@cisco.com> <CAOj+MMH2a=T-vBsD6QVChmybmdQhQXFcDg1np+v+bpKOWPbtKA@mail.gmail.com> <8be3198f-4c9c-2bae-9ce9-f283ac5305a1@cisco.com> <CAOj+MMFf_QymQLOG4mR9F_3h-njo0k2Le6eE1bKUkK6NmcLboQ@mail.gmail.com> <42fbaa46-7434-39fb-b5a1-97fe0c7866d3@cisco.com> <CAOj+MMG5j=HcZhtni+ROVU4zjzgHDKQhNmgxpBqpx97Jf3uU4w@mail.gmail.com> <18735f3e-9a41-5ab7-edc9-75c3ac65f8bf@cisco.com> <CAOj+MMEpJDMXb3STRns6zbKDtJs0Em1CBPeOPh8kseVTejBdrA@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <8a55822f-df03-4034-5569-1c55362a4406@cisco.com>
Date: Wed, 3 Mar 2021 12:11:30 +0100
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+MMEpJDMXb3STRns6zbKDtJs0Em1CBPeOPh8kseVTejBdrA@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.52, ams-ppsenak-nitro3.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/yqRRfe_5ROsgW_4sNdzBZwj01Vg>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
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: Wed, 03 Mar 2021 11:11:39 -0000

Robert,

looking at the text from the draft:

    "The link delay [RFC8570].as advertised by the sub-TLV 33
    of the TLV 22/222/23/223/141 is compared against the Max link delay
    advertised in FAEMD sub-TLV."

sub-TLV 33 is "Unidirectional Link Delay", which defined as "average" 
link delay.

I would argue this should be Min Delay.

The draft proposes to use "Maximum link bandwidth" (TLV-9) as a metric 
(indirectly) and is using the same TLV-9 to compare against the "Min 
Bandwidth" constraint.

The same should be used for metric - it uses Min delay (TLV-34) as 
metric and it should use the same TLV-34 to compare against the "Maximum 
Delay" constraint.

Usage of the "average" delay that is subject to change depending on the 
traffic crossing the link would make the problem of traffic osculation 
much more real and I'm not sure we want to go that path - history has 
proved that to be quite difficult.

thanks,
Peter


On 03/03/2021 11:54, Robert Raszuk wrote:
> Not sure what's the difference between the two.
> 
> But I guess let't wait for authors to clarify their intentions here.
> 
> Cheers,
> R.
> 
> On Wed, Mar 3, 2021, 11:47 Peter Psenak <ppsenak@cisco.com 
> <mailto:ppsenak@cisco.com>> wrote:
> 
>     Robert,
> 
>     On 03/03/2021 11:41, Robert Raszuk wrote:
>      >
>      > Sorry but to me the draft is very clear that it does not care
>     about min
>      > delay, but possible maximum delay of a link  ...
> 
>     "maximum link delay constraint" !=  "max link delay"
> 
>     You are not listening.
> 
>     Peter
> 
>      >
>      > After all for time sensitive applications we do care how long it
>     will
>      > take to actually traverse a path in practice not what would be the
>      > theoretical min amount of time needed for this path to be traversed.
>      >
>      > And it does define it here as brand new metric.
>      >
>      > Just read this paragraph as well as sections 3.1.2 and 3.2.2.
>      > <http://3.2.2.>:
>      >
>      >     Similarly, exclude maximum link delay constraint is also
>     defined in
>      >     this document.  Links may have the link delay measured
>     dynamically
>      >     and advertised in delay metric in IGP.  For usecases that
>     deploy low
>      >     latency flex-algo, may want to exclude links that have delay more
>      >     than a defined threshold.
>      >
>      > Thx,
>      > R.
>      >
>      >
>      > On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak <ppsenak@cisco.com
>     <mailto:ppsenak@cisco.com>
>      > <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>> wrote:
>      >
>      >     On 03/03/2021 11:27, Robert Raszuk wrote:
>      >      >
>      >      > I am not sure I follow your logic here ...
>      >      >
>      >      > If we are already advertising "Min Unidirectional link
>     delay" as
>      >      > described in
>      > https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-13 why
>      >      > would we need to define it again here in this draft ?
>      >
>      >     we are not defining the metric here, we are defining the
>     constraint
>      >     that
>      >     says what is the maximum value of that metric that can be used.
>      >
>      >     thanks,
>      >     Peter
>      >      >
>      >      > Also does it really make sense to advertise maximum value of
>      >      > minimum value ?
>      >      >
>      >      > Thx,
>      >      > R.
>      >      >
>      >      > On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak
>     <ppsenak@cisco.com <mailto:ppsenak@cisco.com>
>      >     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
>      >      > <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>
>     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>>> wrote:
>      >      >
>      >      >     Robert,
>      >      >
>      >      >     On 03/03/2021 11:10, Robert Raszuk wrote:
>      >      >      > Hey Peter,
>      >      >      >
>      >      >      >      > Authors stated: "Whether egress queueing
>     delay is
>      >     included
>      >      >     in the
>      >      >      >     link
>      >      >      >      > delay depends on the measuring mechanism."
>      >      >      >
>      >      >      >     I disagree with that statement - the Min
>      >     Unidirectional Link
>      >      >     Delay is
>      >      >      >     the value that does not include the queueing
>     delay -
>      >     that's
>      >      >     why it is
>      >      >      >     called Min.
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      > But draft we are discussing here does not talk
>     about "Min"
>      >     delay.
>      >      >      > Contrary it talks about "Max"
>      >      >      >
>      >      >      > *Maximum*  Delay sub-TLV
>      >      >      >
>      >      >      > That is also I asked that very question up front.
>      >      >
>      >      >     I'm afraid you misunderstood it. FA uses "Min
>     Unidirectional Link
>      >      >     Delay"
>      >      >     as one of its metrics. The "Maximum Delay sub-TLV"  is
>     used to
>      >      >     advertise
>      >      >     the maximum value of the "Min Unidirectional Link
>     Delay" that is
>      >      >     allowed
>      >      >     for the particular FA.
>      >      >
>      >      >     The text should be improved in that regard though,
>     it's not
>      >     obvious,
>      >      >     but
>      >      >     I believe that's what it is.
>      >      >
>      >      >     thanks,
>      >      >     Peter
>      >      >
>      >      >      >
>      >      >      > Thx,
>      >      >      > R.
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >      >
>      >      >
>      >
>