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

Robert Raszuk <robert@raszuk.net> Wed, 03 March 2021 22:54 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 042583A1CCF for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 14:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.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, 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 f30UDsfjUHPj for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 14:54:35 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 EB85A3A1CCC for <lsr@ietf.org>; Wed, 3 Mar 2021 14:54:34 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id m11so29995443lji.10 for <lsr@ietf.org>; Wed, 03 Mar 2021 14:54:34 -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=F0k+p/lxdXdBcA1A63MWcPMzfxR4f/vmwDguj0GzOqk=; b=D85L7LZZrSepE6wKLrZ2d7Ui41acs5KUFjJ2uQAj3eq6oEgJYI0B8mM/hPXpM1AyE8 +8H6FujZbJ9O/fOuHR6UmAAXGwzfGBHtE9mkqjVzGiuGncBz1Ux7v+2ur8S1SE5eS0e4 TvWZIWO0qtPMU0WFWgog0TBJS1JvgZ7HTVYV3DwLfMlE5KxFB8NrsQhFPUpGGtw97+tV J7lb/fyTM1hkYIiRgt2+OlouGHTDdSmoxX0gw608ejIhJg6S0SNzagGRilkeoCjUTaX6 HReMHz6OZvcrQ2oDvSqEshQt+RZNHUI1trH33qhdpm17aL6MvgK4qI6Pq1zVy1CTulNT nlRA==
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=F0k+p/lxdXdBcA1A63MWcPMzfxR4f/vmwDguj0GzOqk=; b=YS/hpHdQ7rgc0bVdS2eJbCDVe4DjxsnOYLqscOUkJhbWQVUNJUabpWCPxA8VrDOY3I Hgv+A/rzfQWmcKCBC0R2LvLsiCEy8XNB4va2XinKPCeWgpc8DzRMUZC1SdZ4wWF7Hg1B 1bHQmIYQKwdM2PEFUe2cmA8OPeI+mVBJ6hM+xULR78oD0a2GKEH578l3mFdJCrmX1uw5 ppHtNEbmmoYrYKTGQ/Co+3qBtY0mR+DimfV+2xn9mx4fGU7DjBKDCfKkocbnegrBrROP EtnrWAcJgX0Mun7CgzmHvRF66RtnKAIwNWdq8LbKMbLnoWjisEEQobbNhURD2OuljEgG dwEA==
X-Gm-Message-State: AOAM5311xvi9viz8k7ynlgN3302AtSz9zY09+ltPq2SiVdjbD2scxlnm r+CP4GTpTammuZuAygEPLOsFVJWktcwCPS9niiQu6A==
X-Google-Smtp-Source: ABdhPJzcU8ToJI/KaatH1YyNF8a9CcoNUInjZQig0s3CdkBeW3mH8c2PJthEYfwLbF0CMtvCAKkzAk7ykgi+2kVEccM=
X-Received: by 2002:a2e:5cc7:: with SMTP id q190mr611980ljb.37.1614812071418; Wed, 03 Mar 2021 14:54:31 -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> <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>
In-Reply-To: <BBD5B678-D3B5-4E9E-8F9E-E054D9867EF9@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 3 Mar 2021 23:54:22 +0100
Message-ID: <CAOj+MMF5MsWmUwkJjYMeRMAJ9w9MUdG5ZArzGsLH0Un3hW_b2A@mail.gmail.com>
To: Tarek Saad <tsaad@juniper.net>
Cc: Peter Psenak <ppsenak@cisco.com>, 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>
Content-Type: multipart/alternative; boundary="000000000000e5735b05bca9bb70"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/XKE6YiYxvrg58lnt7B6RqASSmls>
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 22:54:37 -0000

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.

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

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.
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> 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
> on behalf of 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> 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
>