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

Robert Raszuk <robert@raszuk.net> Mon, 01 March 2021 20:22 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 BDD773A225B for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 12:22:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.488
X-Spam-Level:
X-Spam-Status: No, score=-1.488 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] 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 jAM1nNUGMOri for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 12:22:40 -0800 (PST)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450: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 A52363A2258 for <lsr@ietf.org>; Mon, 1 Mar 2021 12:22:39 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id 18so19029486lff.6 for <lsr@ietf.org>; Mon, 01 Mar 2021 12:22:39 -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=N8FuFYAzIsEstyzVIocjFho2t2bxKcd7kVSjOitTn6Y=; b=T4wHZcOmjMyVNbYoJeQZaSpkdbUHAuSY7Ojo6GNf2ukUm0r7YTftFQS+2cDxWb5UpB xoVxt9yv/qazTBdKmG+5J56piMoP3ZAWnoNsKHzWTzg4LzTj+wWLd9hoxc69wRh5ohJY RKUPolFOevludveWsJDbIYO6Rh1id5ZWdJFBA4YUAr/AbqiHXsdWuUPX7P3tQ4MeSCDB 92wEfsxYh23eIyOWO8V2EUmDEkXS0IJ8Y0GiR3Q3J0MYn0g0W3Pmf2zxGhz6JzrA970E A5xfaifH6rinhGVkHzWxYAI+no++N6Vx27S6uHOoK2bwo4yYwh9ojNI08TWQY+lR9d2T XvZQ==
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=N8FuFYAzIsEstyzVIocjFho2t2bxKcd7kVSjOitTn6Y=; b=sUgQ/eeSR28K43HID1jz8awhtQQyWFnOxGBI7jjpXblje/G5qyH8U8CAds04JgL4O9 G612axoKIy/s212/dB46lnxeSQumCSYNyrVW09mrMMb7pVZ34rnDZL2yMdp09V4YD4Vj c9XtFFB68e2e8SouzN1Xe4YuMqZftZkdHLD+XEMSFvxfN9hDwlXbx7JrM01I1GOBQ1bd 3ZNgB1SygGyy1rrZ4gshfNT9LATa9eK6UIRv28zaahMNSGnJXwz/FwKxs2ahPhBH+XN3 dHNg0T9Offff94BLplRI52dmvsqL+0lhiecwrHJa2R0EXV/aC+8tQEuCvfqnx0uLNBei Hkpg==
X-Gm-Message-State: AOAM5310JolxQQvimYKvc2lXSAR9U4d2W3z9RRfhh5sbFjUcs6eZWUWx q4Z/mSLdbvrzD17t2Z9qkwg/Nq9mWOSfMX9zkI5lUw==
X-Google-Smtp-Source: ABdhPJw9PHQy0e5nRXeaoNq9uMqO+x0+nLnD75glkrwSO70eWmcEhSb251hqJ7jNhoqQmXJY94Y2q+6nAAGYk3mczNE=
X-Received: by 2002:ac2:491d:: with SMTP id n29mr10045835lfi.541.1614630156912; Mon, 01 Mar 2021 12:22:36 -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>
In-Reply-To: <7C67D01F-24DB-4450-8587-E004CAFBBEBC@tony.li>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 1 Mar 2021 21:22:28 +0100
Message-ID: <CAOj+MMGZppwYtNr4t0rJoy3BKWaBYqHiJ_esM1XNFTNxbm8c5w@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>, Gyan Mishra <hayabusagsm@gmail.com>, "lsr@ietf.org" <lsr@ietf.org>, "DECRAENE Bruno IMT/OLN" <bruno.decraene@orange.com>, Shraddha Hegde <shraddha@juniper.net>, Rajesh M <mrajesh@juniper.net>
Content-Type: multipart/alternative; boundary="000000000000f25bd705bc7f6044"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Ep53t3a0z3RCYZ-zjXQb-aF_bsI>
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: Mon, 01 Mar 2021 20:22:44 -0000

Hi Tony,

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.

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.

Thx,
R.





On Mon, Mar 1, 2021 at 7:42 PM Tony Li <tony.li@tony.li> wrote:

>
> Hi William, Gyan, Robert, Tony, et. al.,
>
> Please permit me to wax a bit philosophic here.
>
> William is exactly correct that the goal is not to make FlexAlgo deal with
> reservations like RSVP does.  Without some kind of setup protocol or global
> computation, that’s simply not possible. Moreover that’s not the real
> problem that we’re out to solve.
>
> Reservations are just a first order approximation to a traffic flow in any
> case. We characterize them as having a fixed constant bandwidth, but we all
> know that that is far from the truth. Each flow is diurnal and fractally
> bursty. Every user who ever clicks on a link creates bandwidth demand and
> while the Law of Large Numbers helps us out with some averages we all know
> that we have no good way of characterizing the traffic that we’re trying to
> carry. Claiming that it is a single 12Gbps LSP is truly a huge over
> simplification and a good step towards solving the real problem.
>
> So what is the real problem that we’re trying to solve?
>
> We are trying to not drop packets.
>
> Dropping packets is bad because it forces retransmissions and impacts
> someone’s Internet experience. Dropping packets is our response to
> congestion events. If we could manage to have a network that never
> congested and always delivered packets without giant latency, all would be
> good.
>
> To date, we have created traffic engineering mechanisms to help us steer
> traffic so that we could delivery traffic without congesting. It has been a
> means to an end. The mechanisms that we’ve created have a non-trivial
> overhead and approximate our goals, but they do NOT preclude, anticipate,
> or avoid congestion. They do not react when we have unexpected inputs. We
> do extensive pre-computation to deal with even single failures and have no
> serious mechanisms that handle multiple failures.
>
> Right now, FlexAlgo does nothing to help with bandwidth management.
> Wiilliam et. al., are proposing some first steps, which are to be
> encouraged. Much more will be needed, not to recreate legacy mechanisms but
> because we should be striving for a more sophisticated, real-time approach
> to bandwidth management and congestion avoidance.
>
> Regards,
> Tony
>
>
> On Mar 1, 2021, at 2:24 AM, William Britto A J <
> bwilliam=40juniper.net@dmarc.ietf.org> wrote:
>
> Hi Gyan,
>
> This draft aims to provide the protocol constructs to define a
> flex-algorithm which is suitable for sending high bandwidth traffic. Flex-Algo
> is a very useful feature for network consolidation use-cases which requires
> different metric-types for SPF. We are trying introduce the protocol
> constructs to simplify the use of metric based on bandwidth via Flex-Algo.
>
> This draft does not attempt to do bandwidth management nor reservation
> like what RSVP does. For LDP based networks that use igp metric relative to
> bandwidth, Flex-Algo provides an easy alternate.
>
> Thanks,
> William
>
>
> *From: *Gyan Mishra <hayabusagsm@gmail.com>
> *Date: *Saturday, 27 February 2021 at 9:40 PM
> *To: *Robert Raszuk <robert@raszuk.net>
> *Cc: *DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>om>, Rajesh M <
> mrajesh@juniper.net>gt;, Shraddha Hegde <shraddha@juniper.net>et>, William
> Britto A J <bwilliam@juniper.net>et>, lsr@ietf.org <lsr@ietf.org>
> *Subject: *Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
> *[External Email. Be cautious of content]*
>
>
> Hi William & Co-authors
>
> From first read of the draft it does appear your are trying to apply RSVP
> TE PCALC path and reserve message link attributes constraints such as
> concept of affinity bits to exclude low bandwidth or delay of individual
> links without taking into account all of what RSVP TE is reserving of
> bandwidth in the end to end path with the Path and Reserve message.  As
> mentioned Looking at individual links will not provide the end to end path
> view or bandwidth requirements for the entire path to be reserved as
> accomplished by RSVP TE.
>
> As Tony and Robert have mentioned I agree this is a good first step but
> does need more refinement to make useful.
>
> Kind Regards
>
> Gyan
>
> On Sat, Feb 27, 2021 at 7:24 AM Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi William & co-authors,
>
> I read the draft and have two basic questions.
>
> 1.
> Both bw & delay can be used as defined in the draft to construct new
> forwarding topologies. But how practical such topologies would be in the
> real life when 40GB links may be heavily occupied with bursty traffic and
> 10G links can sit idle ? I suppose you are trying to address the case where
> say 12 gbps holographic stream needs to be sent across a network.. But then
> I don't think if sending it in a single flow instead of spreading into many
> sub-flows and use as much as possible ecmp would not be a better option.
>
> 2.
> Likewise how good is my accumulated link delay value if in between there
> are deep buffer network elements and say egress queuing to each link (which
> max is unaccounted for in your draft) can significantly alter the end to
> end delay ? Have you consider to add MAX_EGRESS_QUEUE_DELAY on a per link
> basis (still as static value).  So if some traffic is delay sensitive we
> will have a much better accuracy not to get into a trap of queuing related
> delays.
>
> Thx a lot,
> Robert.
>
>
> On Fri, Feb 26, 2021 at 8:37 AM William Britto A J <bwilliam=
> 40juniper.net@dmarc.ietf.org> wrote:
>
> All,
>
>
> We would like to draw your attention to a new ID:
> https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8sz2YPxkw$>
>
>
> The draft talks about introducing link bandwidth related constraints in
> Flex-Algorithm which can be used to define a Flex-Algorithm based on
> bandwidth based metric.
>
>
> Please review. Any questions and comments are welcome.
>
>
> Thanks,
> William
>
>
>
>
>
> *From: *internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Date: *Monday, 22 February 2021 at 10:56 PM
> *To: *Bruno Decraene <bruno.decraene@orange.com>om>, Rajesh M <
> mrajesh@juniper.net>gt;, Rajesh M <mrajesh@juniper.net>et>, Shraddha Hegde <
> shraddha@juniper.net>gt;, William Britto A J <bwilliam@juniper.net>et>, William
> Britto A J <bwilliam@juniper.net>
> *Subject: *New Version Notification for
> draft-hegde-lsr-flex-algo-bw-con-00.txt
>
> [External Email. Be cautious of content]
>
>
> A new version of I-D, draft-hegde-lsr-flex-algo-bw-con-00.txt
> has been successfully submitted by Shraddha Hegde and posted to the
> IETF repository.
>
> Name:           draft-hegde-lsr-flex-algo-bw-con
> Revision:       00
> Title:          Flexible Algorithms Bandwidth Constraints
> Document date:  2021-02-22
> Group:          Individual Submission
> Pages:          21
> URL:
> https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-hegde-lsr-flex-algo-bw-con-00.txt__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3v6TruoA$>
> Status:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD1VexjHPQ$>
> Htmlized:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-hegde-lsr-flex-algo-bw-con__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD3X5nPQbA$>
> Htmlized:
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-hegde-lsr-flex-algo-bw-con-00__;!!NEt6yMaO-gk!QGg36p91zPfVMznYY91xs-zx70Qp5BE1nJx-Thnl14sTCkvwgOjEzjGBtD2aqSYcuQ$>
>
>
> Abstract:
>    Many networks configure the link metric relative to the link
>    capacity.  High bandwidth traffic gets routed as per the link
>    capacity.  Flexible algorithms provides mechanisms to create
>    constraint based paths in IGP.  This draft documents a set of
>    bandwidth related constraints to be used in Flexible Algorithms.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org
> <https://urldefense.com/v3/__http:/tools.ietf.org__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8vQC8uTvg$>
> .
>
> The IETF Secretariat
>
>
> Juniper Business Use Only
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8umPEf2Zg$>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8umPEf2Zg$>
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!U3HBQwaZL7T4mjz-MUHE7VjFtnOyNghGDh5vwJXUXkHdMxlravmRvJwdZ8vByLZnBg$>
> *Gyan Mishra*
> *Network Solutions Architect *
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
>
> Juniper Business Use Only
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
>
>