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

Tony Przygienda <tonysietf@gmail.com> Tue, 02 March 2021 06:47 UTC

Return-Path: <tonysietf@gmail.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 686463A2718 for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 22:47:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AHhFODVZdvrU for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 22:47:28 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6003A2713 for <lsr@ietf.org>; Mon, 1 Mar 2021 22:47:28 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id d5so17085927iln.6 for <lsr@ietf.org>; Mon, 01 Mar 2021 22:47:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AI4gwwudm6w++W9bFcqIpB9HCgr+nWd2odLVrUguofo=; b=jkokabzrXqZ7+K71aoSWgfvLdIOa93M4DmEvamQg2e0igaJOWgK6AS9/eFQYVll0hr 61sHCh0ZkZoov+vOpHfhI08NwlAdUDF4CySMh0MetAJawmHFSsbtRqjSJhTj0DM6LDvl clIple7BN8dMAVQiRmHIjvVEXyjNbzhPIwkRYw9mMqSM47iwnYtPvpsGHA6RUm3tmfDT P4u43S6zBh+SDm1C1/L854JgSBfrAKF+ouNO2M8tN0K6SHHE00CxyEGvbhzjmfKWF9u2 WqtG++lVATBz941ZFbmzVvHtkqyz0bSMhj/ccSCooiginqPM3W7G3mYInE/+iixvziCA 8DHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AI4gwwudm6w++W9bFcqIpB9HCgr+nWd2odLVrUguofo=; b=f8rxUvQ97+P4AnaZOJGjfhEbFJv9WSrcQxN0EmLKprNXUsRNbV/fF/B6J0jUD1ZDyI rsQsJLMxKu4Zk8R3k9xCSbgE6mtoa+3WUd2mYNa8D1+jBuw66qFUKs7hisAhAdfwuWxv DTr42ERgMQIFrZLUhtH8TtBynynznWgyKcY9Cff+66F9qBzOYMVwA4xS8Dg8+lCBIlzN nbXNfZiI1N2S9JqyhvUxWbKOknqYABCfVd6fAWfvC+7F9oRyOOMlz3D9ivoH22OyMSJH W31mjnsNmmV1+MK5vOO3U17QrTvF7O3/YlNvC74kUxwtg4O+sBRHdgEycCWVZxd7YZjH R+ew==
X-Gm-Message-State: AOAM533OgTpoF2EvMdJL6x+UBoIu58dfjoYA8ArcAi3P8dLCqknbiwLU GHRgjJ6C8KTf75MGQ00Wmv026cl6HJReRMXkQWs=
X-Google-Smtp-Source: ABdhPJww5FASSsNqrLbfZigOBr3qNtkQ+FgOJdITSQCCK36mUiXk3H+RRgmu0jknNvy+3P/EKEdD5FEdJs6RawNP0/4=
X-Received: by 2002:a92:ce03:: with SMTP id b3mr16931220ilo.302.1614667646568; Mon, 01 Mar 2021 22:47:26 -0800 (PST)
MIME-Version: 1.0
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> <26ed8492-8b38-46a9-9482-0f381ab8ca66@Spark>
In-Reply-To: <26ed8492-8b38-46a9-9482-0f381ab8ca66@Spark>
From: Tony Przygienda <tonysietf@gmail.com>
Date: Tue, 2 Mar 2021 07:46:50 +0100
Message-ID: <CA+wi2hOsy38CBpiMFUJ40hE5uYN1vzst-JheaKdKmi_aUeSXXg@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Robert Raszuk <robert@raszuk.net>, Tony Li <tony.li@tony.li>, Gyan Mishra <hayabusagsm@gmail.com>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, "DECRAENE Bruno IMT/OLN" <bruno.decraene@orange.com>, "lsr@ietf.org" <lsr@ietf.org>, William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000810cf705bc881b46"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/vdknf1nu4sg1gPZ77nhZ3c3RNyI>
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: Tue, 02 Mar 2021 06:47:30 -0000

the pesky operational issue of those computations to suddenly partition the
graph (if used with dynamic resource updates) or otherwise pile everything
on the same link that led to RFC5120 being built the way it is. It is one
thing to get from RSVP-TE a "no resources to get there" indication and
another for IGP to magically not be getting there anymore while in terms of
best-effort functionality the destination looks perky and happy. One could
argue that you just need a routing table to see whether it's there but the
nature of those algorithms is that people show up with "I want 100MB" and
the answer there is very different from another request for "I want 1GB".
In Fore systems we basically had bunch of pre-defined/configurable profiles
we were pre-computing the answers (obviously also for performance purposes)
and comibned with the Q.2931 doing roughly what RSVP-TE is doing  +
crankback to do low catches stuff was working pretty well. There is a
patent for that still somewhere AFAIR.

-- tony

On Mon, Mar 1, 2021 at 10:48 PM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> In ol’ good RSVP-TE days we already used “severity/relevance indicator” to
> decide whether changes in link  attributes (BW/etc) are significant enough
> and should be propagated in into TED and trigger re-optimization/rerouting,
> this is no different,  define your threshold for a trigger.
> Note - flex-also requires contiguous topology to work, self isolation as
> the result of (dynamic) topology re-computation would not be a great thing.
>
> Cheers,
> Jeff
> On Mar 1, 2021, 12:48 PM -0800, Tony Li <tony.li@tony.li>li>, wrote:
>
>
> Robert,
>
> Constructing arbitrary topologies with bw constrain is useful work. For
> example I want to create a topology without links of the capacity less then
> 1 Gbps. All cool. Of course if I have a case where two nodes have 10 L3
> 1Gbps links nicely doing ECMP I will not include those which may be a
> problem.
>
>
>
> I agree that it may be a problem. Maybe it’s not the right tool for the
> job at hand. That doesn’t make it a bad tool, just the wrong one. I try not
> to turn screws with a hammer. And I try not to drive nails with a
> screwdriver.
>
> I will happily stipulate that we need more tools and that these are not
> enough. We should not reject a tool simply because it doesn’t solve all
> problems. Let’s work towards the right set of tools. Linear algebra tells
> us that we want an orthogonal set of basis vectors. What are they? Adding
> them one at a time is not horrible progress.
>
>
> However my observation is precisely related to your last sentence.
>
> Is this extension to be used with static or dynamic data ? If static all
> fine. But as William replied to me earlier link delay may be dynamically
> computed and may include queue wait time. That to me means something much
> different if Flex-Algo topologies will become dynamically adjustable. And I
> am not saying this is not great idea .. My interest here is just to
> understand the current scope.
>
>
>
> Link delay was dynamic before this draft. As William mentioned, TWAMP can
> already be used to provide a dynamic measurement of link delay. That,
> coupled with the link delay metric already gave us dynamic path computation
> requirements and the possibilities of oscillation and instability. We have
> chosen to charge ahead, without addressing those concerns already.
>
> Regards,
> 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
>