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

Robert Raszuk <robert@raszuk.net> Thu, 04 March 2021 10:52 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 6C7F53A18E8 for <lsr@ietfa.amsl.com>; Thu, 4 Mar 2021 02:52:56 -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=ham 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 GTFTUhmplXEJ for <lsr@ietfa.amsl.com>; Thu, 4 Mar 2021 02:52:53 -0800 (PST)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 47A363A18E7 for <lsr@ietf.org>; Thu, 4 Mar 2021 02:52:53 -0800 (PST)
Received: by mail-lf1-x133.google.com with SMTP id q25so22201381lfc.8 for <lsr@ietf.org>; Thu, 04 Mar 2021 02:52:53 -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=KzBlqtycu0Stojtz+p6QbFETOH2l8HIdn107aXoYzVM=; b=PZG9ohiMs8kKevZu43EiXPhw85ZD2mhNi+T4CXyccY6OtGYq6/6C6AIul3n6ZKGzG5 FpOjtm4uK3Ph/VCkjjsNhZLwnPxcBC9ALG9390AlhfIFXWkqgvPt+Ui1mlru98VOi4eM CZTERG6pyszCgcH8pLHwNWWgxw8RgYtS8pZeGjg8bolXa9eza0WsExENEu9G7+gTDWZf CqR1zUD8FZ6MksQpGp5Tzq6eDhkTkK+P3vYQtc8TaQq7C9MF3L7kOi3Q9PGVJq0kmJHF c9mn6R4uWhxH+ewB8tyUkROL50N1tpBqT21c6NGJnQlP5TKzLCT7Y+fqhFX163BlH1fn lt1g==
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=KzBlqtycu0Stojtz+p6QbFETOH2l8HIdn107aXoYzVM=; b=HQuD5oSrDrQdj18CTuBd4uVGDkgAg2Zo7gNFVM+/boipqCdglmexfByUOsGDIeC8la Z4qDpFrCs4PcZ/MVG7FvEu9NCKSXDdeJ5Ctr7Oi3zSFkgqtREENpDbvi+ZV8uT28uvdi rR65ltP3xQct8wXWp5qDqVUmM6eTBDct2l3gpVl3oquXBVGO/EQ7KCRTnhpyJO8fTNZK 7ttoCPQl4dXAt1NZuzMwxHsoajXbXpH7AzAKfyaPpFdy/Zr7ayiYs12M837QyNSX1V1p FsBOWhjMHwA5veoF4N+zvylGgt/mrZcBD//WU4eJXhAk8vRucrUxmaiph8lS/f26XCuY BR8g==
X-Gm-Message-State: AOAM530QpGPuYX7zw9gRNVuY+vEeLQ6nMq5UYMXglWHWF2nsGd92NSJt 95PgtmoI91HxpvTzqMkcwsPyHts1TE0vsj278jRO5A==
X-Google-Smtp-Source: ABdhPJxTeNhzUCigc5Krxd0uNtmjsN4EkLmzI49CDuNuk191JIsLIkY+mcs8JSq+QMUNhZfnOhdyD4VHBPB0V7J3eug=
X-Received: by 2002:ac2:46db:: with SMTP id p27mr1941932lfo.396.1614855169915; Thu, 04 Mar 2021 02:52:49 -0800 (PST)
MIME-Version: 1.0
References: <161401476623.19237.3808413288895066510@ietfa.amsl.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> <9d66e5af-414a-42b7-6af5-388974785b8f@cisco.com> <CAOj+MMGggyuzqD=ZbDxNG_10ThHykOO7y5rYWphvSk0rs+4CbQ@mail.gmail.com> <bb9555c4-8007-4d0e-2715-39c4069fc61f@cisco.com> <CAOj+MMFP+Tx13v99GaOc8vQaN6UPkSiS7UX1hRFwevKd8Oj13Q@mail.gmail.com> <532100cf-0252-73f3-046c-218de2fc26db@cisco.com>
In-Reply-To: <532100cf-0252-73f3-046c-218de2fc26db@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 4 Mar 2021 11:52:38 +0100
Message-ID: <CAOj+MMEYAc=LN6JfTto7fwcSzeQuyUdeTTC262c5LwBfPFgRRg@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="000000000000c4508105bcb3c4f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/XnsRxdVLAXut4BdWM881-5t6XVg>
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 10:52:56 -0000

I guess now you are not listening ;)

I am saying it is about finding the right normalization timers and values
which can satisfy the need. And those should reside on the senders.

That is why I was asking what is there today and so far no one gave precise
answer. You said links don't change delay characteristics which by itself
only applies to some link categories. Not satellite not even 5G.Leave alone
VPWS.

So I guess your conclusion is that this is hard problem and we should not
go there. But if so let's not pretend we are sending even min link delay as
dynamic value and redefine it as static approximated link delay.

Thx
R.






On Thu, Mar 4, 2021, 11:06 Peter Psenak <ppsenak@cisco.com> wrote:

> Robert,
>
> On 04/03/2021 10:50, Robert Raszuk wrote:
> > Peter,
> >
> > Sorry but the draft does not have a disclaimer section which states:
> >
> > "Extensions defined below are only applicable to networks with not even
> > a single emulated circuit in the IGP."
> >
> >  > Obviously, if the min delay fluctuates wildly, one can not achieve
> > delay optimized
> >  > forwarding no matter what.
> >
> > If VPWS provider's IP network reconverges once per day or per hour I see
> > nothing wrong with flooding new link delays and recomputing the topology
> > of the network running on top of such constructs.
>
> the question is how much sense would it make to try to optimize based on
> delay if it fluctuates every ms and we optimize once per day. But feel
> free to give it a shot if you believe it's a good idea.
>
> Peter
>
> > My point is that
> > changes are real, pretty unpredictable and in ms or 10s of ms. And IMO
> > the proposal on the table is specifically designed to catch and address
> > those cases - not just dismiss it as you can not use it in your network
> > - sorry mr customer. >
> > Best,
> > R.
> >
> >
> >
> >
> >
> >
> > On Thu, Mar 4, 2021 at 10:41 AM Peter Psenak <ppsenak@cisco.com
> > <mailto:ppsenak@cisco.com>> wrote:
> >
> >     Robert,
> >
> >     On 04/03/2021 10:23, Robert Raszuk wrote:
> >      > Peter,
> >      >
> >      > Completely disagree.
> >
> >     that's what you seem to be doing from the beginning of this
> >     conversation ;)
> >
> >      >
> >      > Real say enterprise networks are being build with emulated
> circuits
> >      > (example VPWS). In one company I was working at it was about 80%
> of
> >      > emulated links all over the world in their WAN. Yes for me it was
> a
> >      > shock as I did not realize how much this emulated links took over
> >     the
> >      > world. In most geographies you even can not get any link of less
> >     then
> >      > 10Gbps to be real any more. Only emulated option is on the table.
> >      >
> >      > Emulated circuits run over someone's IP backbones. You can
> >     understand
> >      > the consequences of this. Not only link delay changes a lot but
> >     you run
> >      > into very interesting set of issues.
> >
> >     look at it from the opposite direction. The provider of the VPWS is
> the
> >     one who can use this technology to guarantee the delay bound of the
> >     WPWs
> >     service. And if it does, the user of the WPWs would not experience
> the
> >     wild variation in the min delay.
> >
> >     So you have to apply right set of tools at right location.
> >     Obviously, if
> >     the min delay fluctuates wildly, one can not achieve delay optimized
> >     forwarding no matter what. That does not mean that the network will
> get
> >     unstable.
> >
> >     Peter
> >
> >
> >      >
> >      > Maybe you think of the backbones of the 90s or 2000s where dark
> >     fiber or
> >      > SDH or SONET were in use for interconnects.
> >      >
> >      > Well no more. IETF came with such brilliant ideas to emulate L2
> >     over L3
> >      > and here we go.
> >      >
> >      > Reality is not what we wish it to be.
> >      >
> >      > Cheers,
> >      > R.
> >      >
> >      >
> >      > On Thu, Mar 4, 2021 at 10:07 AM Peter Psenak <ppsenak@cisco.com
> >     <mailto:ppsenak@cisco.com>
> >      > <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>> wrote:
> >      >
> >      >     Robert,
> >      >
> >      >     On 03/03/2021 20:57, Robert Raszuk 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 ?
> >      >
> >      >     let me repeat again.
> >      >
> >      >     Min delay is not something that changes every few milliseconds
> >      >     significantly. It's a semi static variable that reflects the
> >      >     property of
> >      >     the underlying physical path. It only changes when the
> >     physical path
> >      >     properties changes - e.g. the optical path reroutes, etc. We
> >      >     deliberately picked Min delay for flex-algo purposes for this
> >     semi
> >      >     static property.
> >      >
> >      >     The small, non significant changes can be filtered by the
> >     normalization.
> >      >
> >      >     If the min delay changes significantly every few milliseconds
> >     there's
> >      >     something wrong with the link itself - we have standard
> dampening
> >      >     mechanisms in LS protocols to deal with unstable links that
> >     would kick
> >      >     in. Similar to what we do if the link flaps 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).
> >      >
> >      >     there is no timer needed for the normalization itself.
> >      >
> >      >     You are likely referring TWAMP computation interval which is
> >     30 sec,
> >      >     with probes being sent every 3 seconds in our implementation
> by
> >      >     default,
> >      >     if I'm not mistaken.
> >      >
> >      >     Normalization is applied to the value that come from the
> above.
> >      >
> >      >     thanks,
> >      >     Peter
> >      >
> >      >
> >      >
> >      >      > 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>
> >      >     <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>>
> >      >      > <mailto:ppsenak@cisco.com <mailto:ppsenak@cisco.com>
> >     <mailto: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
> >      >      >      >
> >      >      >      >
> >      >      >      >
> >      >      >
> >      >
> >
>
>