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

Peter Psenak <ppsenak@cisco.com> Thu, 04 March 2021 09:25 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 D0CD83A1765 for <lsr@ietfa.amsl.com>; Thu, 4 Mar 2021 01:25:09 -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=ham 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 NcT3DB1o8a78 for <lsr@ietfa.amsl.com>; Thu, 4 Mar 2021 01:25:08 -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 85D4C3A176A for <lsr@ietf.org>; Thu, 4 Mar 2021 01:25:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5494; q=dns/txt; s=iport; t=1614849907; x=1616059507; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4UEspLVkYl+6JVUBCaFm1BJomLvIqQPS1SUdl0o1jFw=; b=gJHjle288cQTy69sNp4Bbz3b4wMQDNVH44H7yeqvNjorPW6jmr9R5hf+ EJV1zijOpLOK/dNQEuDFUGyxmPq0E30tVufYRnMMoBnURCXiBQURio5uL P/qVnlNCJTKaC6inDnaulUgSXysnRmFTTnOZG+/O8PTKvdish1LH8Z6Bl w=;
X-IPAS-Result: =?us-ascii?q?A0B/AACypkBglxbLJq1iGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFPgyFWAScSMYRBiQSIKS0DiiSSJwsBAQEPHQsMBAEBhE0Cg?= =?us-ascii?q?XsmOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DYZEAQEBAwEBA?= =?us-ascii?q?SEPAQU2CwUHBAsRBAEBAQICIwMCAiEGHwkIBgEMBgIBAYJsAYJVAw4hD616d?= =?us-ascii?q?oEyhViCWA1igT4GgQ4qjUNCgUlCgREngkUuPoIaQgEBAoR0gl8EghMtBgFnL?= =?us-ascii?q?yQgMAcEDTAsP0IvkAMEU4I7AaVNW4MGgy+TRYI3gmkFBwMfgzeKT4VPkAGUV?= =?us-ascii?q?Y4/jyaEYYFrIYFZMxoIGxU7gmlQGQ2OOIccgU6FRkADLwI2AgYBCQEBAwmME?= =?us-ascii?q?wEB?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,222,1610409600"; d="scan'208";a="33845491"
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; 04 Mar 2021 09:25:03 +0000
Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id 1249P2As029182; Thu, 4 Mar 2021 09:25:02 GMT
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "'Peter Psenak'" <ppsenak=40cisco.com@dmarc.ietf.org>, "'Robert Raszuk'" <robert@raszuk.net>
Cc: "'Gyan Mishra'" <hayabusagsm@gmail.com>, "'DECRAENE Bruno IMT/OLN'" <bruno.decraene@orange.com>, "'Shraddha Hegde'" <shraddha@juniper.net>, "'Rajesh M'" <mrajesh@juniper.net>, "'Tony Li'" <tony.li@tony.li>, lsr@ietf.org, "'William Britto A J'" <bwilliam=40juniper.net@dmarc.ietf.org>
References: <161401476623.19237.3808413288895066510@ietfa.amsl.com> <DM5PR0501MB380079CFD75C78610130D81BCD9D9@DM5PR0501MB3800.namprd05.prod.outlook.com> <CAOj+MMHKazMG3wnUA+Kd2wg2hfr01CdF5w5YYKdFaHU4_V+0SA@mail.gmail.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> <52B3A5ED-6ACC-4772-BEF7-085A33A53F31@tony.li> <e5190522-3a8b-2d6e-c2fe-646049689cc4@cisco.com> <1EABA651-2F05-415B-97EF-054507FADEAC@tony.li> <f935dbc4-6220-5f47-65a4-f642823f594f@cisco.com> <CAOj+MMHXd5j8B9a13E90HQVB=SUOkQ=fqhyJEgTf-Y7Tp5eiBQ@mail.gmail.com> <9d66e5af-414a-42b7-6af5-388974785b8f@cisco.com> <014301d710d7$0afee910$20fcbb30$@tsinghua.org.cn>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <571d7120-721f-546d-a4a5-ca5b3f849547@cisco.com>
Date: Thu, 4 Mar 2021 10:25:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <014301d710d7$0afee910$20fcbb30$@tsinghua.org.cn>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.60.140.53, ams-ppsenak-nitro4.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/xbaJ_eI838V2iuzgJ4cPC7j9jak>
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: Thu, 04 Mar 2021 09:25:10 -0000

Aijun,

On 04/03/2021 10:16, Aijun Wang wrote:
> Hi, Peter:
> 
> If we use such unpredicted parameters for the dynamic IGP calculation, 

I'm not sure what unpredicted parameters you are talking about.

> will the network be operated automatically in non-consistent manner and let the operator stuck in a mess, and busy to find which semi static value was changed and what's it the cause?

no, if it is done properly. We have examples of deployments in the field 
that prove it to work.

> Is this the right direction for network automation?

delay based traffic optimization has been requested from the field for 
years.

thanks,
Peter


> 
> 
> Best Regards
> 
> Aijun Wang
> China Telecom
> 
> -----Original Message-----
> From: lsr-bounces@ietf.org <lsr-bounces@ietf.org> On Behalf Of Peter Psenak
> Sent: Thursday, March 4, 2021 5:07 PM
> To: Robert Raszuk <robert@raszuk.net>
> Cc: Gyan Mishra <hayabusagsm@gmail.com>om>; Rajesh M <mrajesh@juniper.net>et>; Shraddha Hegde <shraddha@juniper.net>et>; DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>om>; Tony Li <tony.li@tony.li>li>; lsr@ietf.org; William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>
> Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
> 
> Robert,
> 
> On 03/03/2021 20:57, Robert Raszuk wrote:
>> Peter,
>>
>>   >  that differ by few microsecond
>>
>> Really you normalize only single digit microseconds ???
>>
>> What if link delay changes in milliseconds scale ? Do you want to
>> compute new topology every few milliseconds ?
> 
> let me repeat again.
> 
> Min delay is not something that changes every few milliseconds significantly. It's a semi static variable that reflects the property of the underlying physical path. It only changes when the physical path properties changes - e.g. the optical path reroutes, etc. We deliberately picked Min delay for flex-algo purposes for this semi static property.
> 
> The small, non significant changes can be filtered by the normalization.
> 
> If the min delay changes significantly every few milliseconds there's something wrong with the link itself - we have standard dampening mechanisms in LS protocols to deal with unstable links that would kick in. Similar to what we do if the link flaps every few milliseconds.
> 
>>
>> Out of curiosity as this is not a secret -  What are your default min
>> delay normalization timers (if user does not overwrite with their own).
> 
> there is no timer needed for the normalization itself.
> 
> You are likely referring TWAMP computation interval which is 30 sec,
> with probes being sent every 3 seconds in our implementation by default,
> if I'm not mistaken.
> 
> Normalization is applied to the value that come from the above.
> 
> thanks,
> Peter
> 
> 
> 
>> Likewise how Junos or Arista normalizes it today ?
>>
>> Thx,
>> R.
>>
>> On Wed, Mar 3, 2021 at 7:41 PM Peter Psenak <ppsenak@cisco.com
>> <mailto:ppsenak@cisco.com>> wrote:
>>
>>      Tony,
>>
>>      On 03/03/2021 19:14, Tony Li wrote:
>>       >
>>       > Peter,
>>       >
>>       >>> There are several link types in use that exhibit variable
>>      delay: satellite links (e.g., Starlink), microwave links, and
>>      ancient link layers that deliver reliability through retransmission.
>>       >>> Any of these (and probably a lot more) can create a noticeable
>>      and measurable difference in TWAMP. That would be reflected in an FA
>>      metric change. If you imagine a situation with multiiple parallel
>>      paths with nearly identical delays, you can easily imagine an
>>      oscillatory scenario.   IMHO, this is an outstanding concern with FA.
>>       >> yes, and that is what I referred to as "delay normalization",
>>      which can avoid that oscillation.
>>       >
>>       >
>>       > It can also negate the benefits of the feature. One might well
>>      imagine that Starlink would want to follow a min-delay path for
>>      optimality.  If the delay variations are “normalized” out of
>>      existence, then the benefits are lost.  The whole point is to track
>>      the dynamics.
>>
>>      for all practical purposes that we use it for, the two values of min
>>      delay that differ by few microsecond can be treated as same without any
>>      loss of functionality. So it's about the required normalization
>>      interval
>>      - something that can be controlled by the user.
>>
>>      thanks,
>>      Peter
>>
>>
>>
>>       >
>>       >
>>       >>> Please note that I’m NOT recommending that we back away.
>>      Rather, we should seek to solve the long-standing issue of
>>      oscillatory routing.
>>       >>
>>       >> not that I disagree. History tells us that the generic case of
>>      oscillation which is caused by the traffic itself is a hard problem
>>      to solve.
>>       >
>>       >
>>       > Any oscillation is difficult to solve.  Positive feedback
>>      certainly can exacerbate the problem. But solving hard problems is
>>      why we are here.
>>       >
>>       > Yours in control theory,
>>       > Tony
>>       >
>>       >
>>       >
>>
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> 
>