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

Robert Raszuk <robert@raszuk.net> Tue, 02 March 2021 07:14 UTC

Return-Path: <robert@raszuk.net>
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 47E7C3A2768 for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 23:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 jx1we8l3Mm9o for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 23:14:01 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 780C63A2767 for <lsr@ietf.org>; Mon, 1 Mar 2021 23:14:01 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id f1so29719065lfu.3 for <lsr@ietf.org>; Mon, 01 Mar 2021 23:14:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YyBsvztomAWWkhkwV+sV53IP1tmOPtM4QA7fFoK7Is4=; b=Y68u9FLlD1ThKC4Lw/w/G5hEofZNKI/W4D/T3J/IE7mc6EBp1LgVKtMAFGXXzuFhOz MZc8HC+EWvSNq9pQsal9qfUGrfpEe8sfZ5iIfKSdRYSuJ8ZpQf6Z6p0WxRHC6UIrBQk6 OMxs/JX2OTXP0jHziuqkhtNUxKJMO3wk7TO6AZlphwoN6Z8xXT0p5DNdXITKwV6SAahj JCayk6ogb82SxNESErVGp2kCJxC9n4IBWEcMbyd+x2y/U/mkoZMDk3VJ9c2dldw0dFhC Fuyz/mGaKQY8Es/JyFabLYWEKzTgUQjLn2k3Bkk4fCAZRsJy8XtIT1SlAkHZO8end/Xm kTng==
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=YyBsvztomAWWkhkwV+sV53IP1tmOPtM4QA7fFoK7Is4=; b=fpy/FDTp8NEri33CkbTrqBuj/3D/vsQIgjpjE8Uc3kPBPkxgX8vm4gVlF5gVE0/6oY dTAeZE6tgV0avea1UIiHu9KBBQsoffVXwI5fdmungUbAIDoUKeCjU892TiasdteqMyml D+Rs+tZ4Cna9f6WnBknAfu/qPaUJyc+h0WEdHV9ASyxk+0aEQWue2krhsxtCRCLJxP+l pODutt327SPpHYAoRyTDLO9paN0kNQ3iMN5pUcNZCjto5sercq8QYlEE7p052OSlgbo+ qoxRS6jtp+q3LJsRo7GCORi55mQ7+OswSA+PQFHkCJCbsIQrVqGXkHcivlcgLXKT/kqy QcgA==
X-Gm-Message-State: AOAM532jnYsIbfnyAQxleKkzlCvgGIyHawD58nINXekTHHprMrorJG1M PQLYxEWuq4DA0EyZuK3FH67Y15JdPDBrpUxjr/0x8g==
X-Google-Smtp-Source: ABdhPJzDd/0W6Po++8k51cAWxsCYTBqx0BxevbYrEk7Ik7METavUFF0In5xoHoAwInViZzGte/pfEyY+iqx7XSVzIrw=
X-Received: by 2002:a19:ac49:: with SMTP id r9mr12389196lfc.602.1614669236385; Mon, 01 Mar 2021 23:13:56 -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> <CA+wi2hOsy38CBpiMFUJ40hE5uYN1vzst-JheaKdKmi_aUeSXXg@mail.gmail.com>
In-Reply-To: <CA+wi2hOsy38CBpiMFUJ40hE5uYN1vzst-JheaKdKmi_aUeSXXg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 02 Mar 2021 08:13:45 +0100
Message-ID: <CAOj+MMEGykUNrLULzBZGOOjuxqdKgLWymXQkwGek02AC+cf=og@mail.gmail.com>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: Jeff Tantsura <jefftant.ietf@gmail.com>, 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="00000000000043cbbe05bc887ab9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/fEpRKDWSGDdUmbaU7xZwpF9Bevk>
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 07:14:05 -0000

Hey Tony,

I think there are few things to observe here.

1.
It very much depends how one is to use Flex-Algo topologies. If you attempt
to use it as solid fixed topology for some applications I would be very
cautious not to create such topology with dynamic constraints. Not only
worrying about sudden disconnected or partitioned areas, but also that
micro loops during topology changes may not be so micro anymore. It would
be rather rear that all network elements compute topology and activate it
in the same time.

And that is quite different from local protocol convergence when typical
microloop can and do happen all the time, but rest of the topology is
unchanged.

2.
If you however are using such tools as optimizations and you can always
fall back to base topology the risks are much lower. I think there is room
for at least testing it in real scale.

3.
Of course to get #2 going we would need not only control plane topology
creation but also build in data plane ingress to egress live topology
validation - before you shift some traffic on it or remove from it
to fallback to base.


So back to the subject - we still do not know if the current proposal
assumes static bw & static delay or dynamic delay to take into
consideration.

Many thx,
R.



On Tue, Mar 2, 2021 at 7:47 AM Tony Przygienda <tonysietf@gmail.com> wrote:

> 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>, 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
>>
>