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

Robert Raszuk <robert@raszuk.net> Wed, 03 March 2021 09:58 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 911083A0A69 for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 01:58:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 BlNYD6J_7be8 for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 01:58:42 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 234CE3A0A65 for <lsr@ietf.org>; Wed, 3 Mar 2021 01:58:42 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id m11so26978655lji.10 for <lsr@ietf.org>; Wed, 03 Mar 2021 01:58:42 -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=kfrzx4ARGmcFC79MGBQ9kKxt7sW4i+ZphGsI0gbNZBc=; b=NVcGCROT85JM4BKm05ugl1T9Otzeit4s2k0pOqPmLSMtrmtCdxdh+hoW5e8a5LnKC5 9ZB9aGP9wPPK4nLeMzFxMkeZNgVZquA0RflkRDbys2Oeh3rDKRmqmO1z7xv2S37SgX+M ZG6XONadQmyJBCEZoSMUGFauYJIHHx34lFQW65/Tq1Ct5X6+CFzHdp+H2mbJ2KnFuefn jtuSuiGmCpxiy0+va/7HZHKdWwn0HYCM8NJXIH32tewh4haOkj3FEhKGrTY90z/tFVoD VU864XysaYeaCeeuDE4pH8T+0S5RCHiM2XhwWwFaU36H8OyildR8rtIdgjmgwzgnb/Xa nQOw==
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=kfrzx4ARGmcFC79MGBQ9kKxt7sW4i+ZphGsI0gbNZBc=; b=lfrOkBOfP1u7F2tBvHqz8MHHw33LFq+ZXUnosNzmUNOBMut6XTtknQnpqP6PsV3A8Y q1GaT0MApQOL0zpsaNk55tGzvtrZw2a1Aq3DmPla0xK/Cc5WC/w8cDWK1Q6FhbhkKMaW 1pKJNZUkzdTTgZUX/E01DQ2fixI/EJFyJ6/qgFNzP4d/g+lWycof3pkrvMlQdwDgtPDb xqGL6wj0uCvxLhEqpP/1Fa9QGkhHhK2hp4jQFS9yZMXkPY+gCXnF3TJ930yYZcMTo+Ko YQu3FwG1l/Z2lzhvZJ3aA/PyZ5cZTGEqr5sMosKWwn9pvkA90t/1juhvOWaZ6L5pF8wL hp5w==
X-Gm-Message-State: AOAM532igeW+MzxnSqbvCEQubGD+2N4ws7mDOM8shW85GJ77mrOxU45w DH16y8dz6ROztNaRBpRcFPPL2Qo0mxtCHtslrzVNGA==
X-Google-Smtp-Source: ABdhPJzubvsru99U1owV3RyifSAmY9GDO7+ErvHqyU6MTo+BMDf1GPTfogT5j/q1PHUNTMH3PAiLhVyatgr3oWkSBT4=
X-Received: by 2002:a2e:9145:: with SMTP id q5mr15373859ljg.54.1614765518485; Wed, 03 Mar 2021 01:58:38 -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> <2c2605a8-95c6-a477-b1b5-5ae4d4de222a@cisco.com>
In-Reply-To: <2c2605a8-95c6-a477-b1b5-5ae4d4de222a@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 3 Mar 2021 10:58:28 +0100
Message-ID: <CAOj+MMGf=zQMGP+q+XX-MJi-qMrOddmq_+wmrXFS+JQX_PsudQ@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
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>
Content-Type: multipart/alternative; boundary="000000000000200b3305bc9ee557"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/yo664L7jdT3RxziueuBJUpFy8Zg>
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 09:58:45 -0000

Hi Peter,

To your last point ...

Authors stated: "Whether egress queueing delay is included in the link
delay depends on the measuring mechanism."

So sure there will be thresholds etc ... but this may very well depend on
the traffic.

Thx,
R.



On Wed, Mar 3, 2021 at 10:34 AM Peter Psenak <ppsenak@cisco.com> wrote:

> Hi Tony,
>
> On 01/03/2021 21:47, 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.
>
> TWAMP provided Min Unidirectional Link Delay is a dynamic one. On the
> other side this value is calculated based on multiple measurements over
> period of time and an average is used. Also, smart implementations can
> normalize the value so that a small fluctuation of the delay is not
> causing the traffic to shift or cause ECMP loss.
>
> What is important here is that the Min Unidirectional Link Delay is a
> link characteristic, not something that is affected by the amount of
> traffic on the link or subject to queuing delay. Same applies to Maximum
> link bandwidth.
>
> thanks,
> Peter
>
>
> >
> > Regards,
> > Tony
> >
> > _______________________________________________
> > Lsr mailing list
> > Lsr@ietf.org
> > https://www.ietf.org/mailman/listinfo/lsr
> >
> >
>
>