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

Peter Psenak <ppsenak@cisco.com> Thu, 04 March 2021 09:12 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 1FAB63A172E for <lsr@ietfa.amsl.com>; Thu, 4 Mar 2021 01:12:30 -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 rnlDgTVMxQEc for <lsr@ietfa.amsl.com>; Thu, 4 Mar 2021 01:12:28 -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 266213A172F for <lsr@ietf.org>; Thu, 4 Mar 2021 01:12:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5334; q=dns/txt; s=iport; t=1614849148; x=1616058748; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=FDcmgg0boVAV4HkqInd8QMbcNk11SFa03gldxQEO4+U=; b=ZC1qKA1QnqESjG7N+q4DHYpb2gAIPqdEd7kreOq5S9juMplRYj0Iy64J 7dqnpJHnHTaiEGtMtELh1TNhiGpEb9ucfJ8RE5oyr/b4m65plcglbfPig aYfTkq6XB/MLcjuImRXVzWLVt9ycfyj5ZTFXWcr35ShL1KGLqjNA/1wIg 0=;
X-IPAS-Result: =?us-ascii?q?A0CJAABJo0BglxbLJq1iGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFPgXyBewEnEjGEQYkEiCkIJQOcSwsBAQEPNAQBAYRNAoF7J?= =?us-ascii?q?jgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGQ4ZEAQEBAwEjDwEFQ?= =?us-ascii?q?RALGAICIwMCAkYRBgEMBgIBAYIhS4JnIa4WdoEyhViDR4FEgQ4qiVCDc0KBS?= =?us-ascii?q?UKBEAEnDII5Lj6HVIJfBIFlWwZoL0QwB20kG0IGAhiQEleCOwGUW5FNgwaDL?= =?us-ascii?q?5hlBQcDH4M3ik+FT5ABlFWiRoFrIYFZMxoIGxWDJFAZDY4rDQmBAQEJjRxAA?= =?us-ascii?q?y84AgYBCQEBAwmJUS2CFQEB?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.81,222,1610409600"; d="scan'208";a="33845038"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Mar 2021 09:12:23 +0000
Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 1249CM9C006047; Thu, 4 Mar 2021 09:12:22 GMT
To: Robert Raszuk <robert@raszuk.net>, Tarek Saad <tsaad@juniper.net>
Cc: Gyan Mishra <hayabusagsm@gmail.com>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Tony Li <tony.li@tony.li>, "lsr@ietf.org" <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> <BBD5B678-D3B5-4E9E-8F9E-E054D9867EF9@juniper.net> <CAOj+MMF5MsWmUwkJjYMeRMAJ9w9MUdG5ZArzGsLH0Un3hW_b2A@mail.gmail.com>
From: Peter Psenak <ppsenak@cisco.com>
Message-ID: <9bd40d73-9740-2b97-5f5b-a8ed609a4685@cisco.com>
Date: Thu, 4 Mar 2021 10:12:22 +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: <CAOj+MMF5MsWmUwkJjYMeRMAJ9w9MUdG5ZArzGsLH0Un3hW_b2A@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.53, ams-ppsenak-nitro4.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/EOO0tYIfRU8ucDKNt1m-tGGdGoE>
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:12:30 -0000

Robert,

On 03/03/2021 23:54, Robert Raszuk wrote:
> Hi Tarek,
> 
> Yes as Tony also just indicated it is completely different game here. 
> Headend can do whatever it likes.
> 
> But I think your point and also what Peter said earlier is to actually 
> throw the baby with the bath water by suppressing  advertisements/flooding.

no, we are not throwing the baby. You seem to by trying to find the 
problem where it does not exist.


> 
> It is all subject to proper suppression tuning/timers and I think we 
> have little experience with it (yet).

I would not say so.

> 
> Most importantly we are talking about topology wide changes so IMHO 
> doing it on the receiving node is not an option. It must be done on 
> sender. 


at least we agree on the above.

thanks,
Peter

>Receiver side suppression would be only valid if timers are hard 
> in stone in the RFC.
> 
> Thx,
> R.
> 
> On Wed, Mar 3, 2021 at 11:34 PM Tarek Saad <tsaad@juniper.net 
> <mailto:tsaad@juniper.net>> wrote:
> 
>     Hi Robert,____
> 
>     __ __
> 
>     The RSVP-TE world has had to deal with such churn resulting from
>     frequent link attribute changes (e.g. specific to available BW). In
>     that case, such frequent changes made their way to the network at
>     periodic intervals and in the event they crossed a threshold. In my
>     mind, the link delay attribute is no different and IGPs can react to
>     it just like RSVP-TE did.____
> 
>     __ __
> 
>     Obviously, any path that was computed and placed on a set of links
>     based on a certain view of the network may quickly become stale.
>     However, IMO, any per-path e2e SLA need to be validated (independent
>     of the network topology) e.g., by active measurement using probes or
>     other means.____
> 
>     __ __
> 
>     My 2cents.____
> 
>     __ __
> 
>     Regards,____
> 
>     Tarek____
> 
>     __ __
> 
>     On 3/3/21, 2:57 PM, "Lsr on behalf of Robert Raszuk"
>     <lsr-bounces@ietf.org <mailto:lsr-bounces@ietf.org> on behalf of
>     robert@raszuk.net <mailto:robert@raszuk.net>> 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 ? ____
> 
>     __ __
> 
>     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). 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
>          >
>          >
>          > ____
> 
> 
>     Juniper Business Use Only
>