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

Robert Raszuk <robert@raszuk.net> Mon, 01 March 2021 10:48 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 9E21D3A19BF for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 02:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.402
X-Spam-Level:
X-Spam-Status: No, score=0.402 tagged_above=-999 required=5 tests=[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, 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 9PyrymakhY5h for <lsr@ietfa.amsl.com>; Mon, 1 Mar 2021 02:48:12 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 948AF3A19BD for <lsr@ietf.org>; Mon, 1 Mar 2021 02:48:11 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id r25so17854062ljk.11 for <lsr@ietf.org>; Mon, 01 Mar 2021 02:48:11 -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=W4fzxnDkq9O5zo9aN6na7EmdwTKLnRe0cpQUI0heUcs=; b=V/NUitoQTmiqXkZlh1gIPGBrLdywrxt7004cvFwRJz3yvu7L7spuEINeeMbyXcwl/e P5yiI69XsMUXzAuYiyQo0x/AysUbTjPhLOUbH73H1mlGq3WFslhDKhxhzru5j0JihzLK D1lLpFqt0tGYRUlxNmnHvV/YOf127X64ytTbgKtGau983bkkkRau3Pg95Jwa7ReR00Yn S3Uwz7TGTBkScq8Ko/I4Sg474ZFb5UwuU+L2cnySgB4NJc7iR6Dg3KpiBKjznutSUSUw fvTuFARHLia5Q33TtesXmDIq2lmATwcRh2ZqJDr0pI6MDtl7kZRWTN5NHOQGGM3oagav n5MA==
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=W4fzxnDkq9O5zo9aN6na7EmdwTKLnRe0cpQUI0heUcs=; b=LQpe5T/1apYM8dIl+INFWmth98fHsmZ41U0nxOJY5C6ubJcoVhWqbLLb2y5MOJrdDz H6gAOspDTyQMO0SkGXUiGVVID52rNsnTPYIRrRr/BvNvf+r/77g3ntRC8vZqtWCcscSx /20afOe5E2gGJvRjtJcEvbtAJOceGJ66QM4AK6UUqLbFb9PQft7pPsqJF68rnatNg3ZD URHPtz1IMGvBPDKvypbTS0gR3E+PSDGbimVCPZvjYJitj156zUdDuHj4D2l3h+6WVGha r0jNdbU60Gk5wYXRK/J2TFWMya3rsvvXAtIYtXGxlkvWvK61ZIadhS8LjUNBRDzMvpFz lAYw==
X-Gm-Message-State: AOAM530opOUbMNrw9uEedH7cw5F61UiOBAxO6MwF6w8RA/dpayEupIWe frwsSgdcYIhyyXw4ON1Qul9OuZwpZYUoQt/hveePvQ==
X-Google-Smtp-Source: ABdhPJy6t7XV90VKV/CNj/MBFZJga3pLlAOoYwfPLcsmbjTw7dkAs9qct4Y1zpAlr0wRFWxRJKbIjWKguNiTRiqNfb0=
X-Received: by 2002:a2e:300d:: with SMTP id w13mr6378086ljw.199.1614595688453; Mon, 01 Mar 2021 02:48:08 -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> <DM5PR0501MB38008ADCECE28C2695C67CA5CD9A9@DM5PR0501MB3800.namprd05.prod.outlook.com>
In-Reply-To: <DM5PR0501MB38008ADCECE28C2695C67CA5CD9A9@DM5PR0501MB3800.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 1 Mar 2021 11:48:02 +0100
Message-ID: <CAOj+MMGcm3Zf2jqyBEnT_9YGsiOu+=3r5a170EO0BFHLiCOyAA@mail.gmail.com>
To: William Britto A J <bwilliam@juniper.net>
Cc: "lsr@ietf.org" <lsr@ietf.org>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, "DECRAENE Bruno IMT/OLN" <bruno.decraene@orange.com>
Content-Type: multipart/alternative; boundary="000000000000776b3b05bc775aa5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/N3U7rf_JRZOTiUT8udvZa8qQIhA>
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 10:48:15 -0000

Hi Wiliam,

I get yr point on bw. I was not saying to make any changes in the draft on
this. I was more hinting that perhaps deployment scenarios could better
articulate pros and cons of use of such static bw parameter.

Regarding the delay - Oh so the delay is a dynamic variable here ? I was
under the impression that this would be a static cfg based value.

Can you clarify ?

Thx,
R.


On Mon, Mar 1, 2021 at 11:16 AM William Britto A J <bwilliam@juniper.net>
wrote:

> Hi Robert,
>
>
>
> Thanks for your comments.
>
>
>
> Currently there are customers who deploy separate networks, of which one
> could be assigned metrics relative to the interface bandwidths, while other
> could be based on other parameters like latency, etc. Flex-Algo which
> facilitates different metric-types for SPF, is a very useful feature for
> such network consolidation use-cases. We are trying introduce the protocol
> constructs to simplify the use of metric based on bandwidth via Flex-Algo.
>
>
>
> Any existing tools and techniques used by operators who configure metric
> relative to link bandwidth to optimize the network can be used with these
> Flex-Algo constructs too. The Flex-Algo bandwidth constraints defined here
> can be used to automatically derive a metric based on reference bw vs link
> bw; and if required, this can be overridden using the individual link
> bandwidth-metric sub-TLV. We will make this clear in the next version.
>
>
>
> RFC 8570 support advertising link delay parameters in ISIS. Protocols like
> TWAMP support dynamically measuring the delay. Whether egress queueing
> delay is included in the link delay depends on the measuring mechanism. The
> Exclude Max Delay sub-TLV introduced in this draft is only meant for
> pruning out high latency links from a Flex-Algo, and it is upto the
> operator to define the maximum bounds based on the measuring mechanisms
> deployed in his network.
>
>
>
> Thanks,
>
> William
>
>
>
> *From: *Robert Raszuk <robert@raszuk.net>
> *Date: *Saturday, 27 February 2021 at 5:54 PM
> *To: *William Britto A J <bwilliam@juniper.net>
> *Cc: *lsr@ietf.org <lsr@ietf.org>rg>, Rajesh M <mrajesh@juniper.net>et>,
> Shraddha Hegde <shraddha@juniper.net>et>, DECRAENE Bruno IMT/OLN <
> bruno.decraene@orange.com>
> *Subject: *Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
>
> *[External Email. Be cautious of content]*
>
>
>
> 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!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKV2Tba5Qg$>
>
>
>
> 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!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKXnuJRcew$>
> .
>
> 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!WgwtY1NpSXZkAtkBfmMRfgZABaIBWv534VYF7vvI4eGGuMbmdKMK_VpWFKV0XHjSNQ$>
>
>
> Juniper Business Use Only
>