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

Gyan Mishra <hayabusagsm@gmail.com> Wed, 03 March 2021 14:35 UTC

Return-Path: <hayabusagsm@gmail.com>
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 CCC033A13EC for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 06:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.487
X-Spam-Level:
X-Spam-Status: No, score=-1.487 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.com
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 Nty2Q1b75ENg for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 06:35:10 -0800 (PST)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 8B9923A13EA for <lsr@ietf.org>; Wed, 3 Mar 2021 06:35:10 -0800 (PST)
Received: by mail-pf1-x42e.google.com with SMTP id o188so9747920pfg.2 for <lsr@ietf.org>; Wed, 03 Mar 2021 06:35:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r1eLtSDCu8mA9T4Gz+K2aTmXWTf/oR9QmOMonGFZa6A=; b=vTyTWmL+X5MvNMx4UiHZrp/CKsMi9f9kpjIy7ZV78xUPZVOc5tiz1zdeKGsvkuTg4j 8a2Alfp62eFZEEev/hotZLgjbQ2XLzOqMwW3MIuy4t/7HgdSC4SpciCOCax4BkuuWvaD OInI6Fcpsk47POKweRIrmtEE2/dl6y9SJBFwNrrNvhLjkg0JO0Y3KIXUKXyfaRQvGT3M hT5A5YaFjNGeJFoNoavTR9V8JZpTMnjDpT6ystHj0IMxsoJe8IGMXfXD7TnqR0YvB3Ox GWisyjkXHUo/W1pzI1wYNXT4Zt3wj3fSbzJ07yNCZPh3EZaQym8qjvH5OHZs+b69SfRb 6bcg==
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=r1eLtSDCu8mA9T4Gz+K2aTmXWTf/oR9QmOMonGFZa6A=; b=B6EJo4ZKQwBwkCE8fMnyBeZCGKsc356l0nRmVSfO3ONrvjzxxg/cMnm2DJ0eQ+2F1d no9ktZyDoWXg0MmU5doWk1SclNqzqmC9rdtjzCCt+A48u03Ja9c/hq99gwsp2ccdUbYl eemqehgJ6bofEtAlIVQ/C4sv4vzfBGA31pK652HOJUFkRK7YNW7DVyNYh50W3mxb9gTR bcyaou0Jx0iulQ7eEmjZr4g6MeupMrTTr3W0wEpc4gDhB7l2p5P9454yTN7mV3lqKBOo 1qjgotiQ4QBPiPmhXrtJOGRGVnS2mgp1nSPGVynZLncMaMDI+bY+d5NsFGdtOcrhca0k 33Vw==
X-Gm-Message-State: AOAM533jE2OyD3q09evE7WycS/lJNcQ05lxrV5lgB1UxmRmlvgc/yFHv FVy9Ta6/4mNmcLDA7Be9dYrWj5LM4JaXMq8AcV0=
X-Google-Smtp-Source: ABdhPJwlsBTQCi/G4Sgta1Rpi7eATra6dumUK8QJ25612WYs71vNLwFhrD9XTZ5jirklk/+1DNl8u5oxBZieMwH7pQE=
X-Received: by 2002:a63:db02:: with SMTP id e2mr9505313pgg.18.1614782109125; Wed, 03 Mar 2021 06:35:09 -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>
In-Reply-To: <DM5PR0501MB38006C4B638AD2AB6A7731B5CD9A9@DM5PR0501MB3800.namprd05.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Wed, 3 Mar 2021 07:39:49 -0500
Message-ID: <CABNhwV0x7HtMd=UE4UG-CTQijLaz9pxVALWBEsTcVvL3wOC71w@mail.gmail.com>
To: William Britto A J <bwilliam@juniper.net>
Cc: Robert Raszuk <robert@raszuk.net>, "DECRAENE Bruno IMT/OLN" <bruno.decraene@orange.com>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000010d5405bca2c253"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/TPBfhVpPvIFfA_NmAV971izPXGE>
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 14:35:13 -0000

William,

Understood.  From following the thread and draft basically like the RSVP TE
ERO link attributes "include" or "exclude" or applying infinity bits to
prune off low bandwidth links from the topology graph based on either new
"exclude maximum link delays" dynamic values or existing exclude link
affinity FAD static values.  Do I have it right?

Kind Regards

Gyan

On Mon, Mar 1, 2021 at 5:24 AM William Britto A J <bwilliam@juniper.net>
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-1347 13101 Columbia Pike  *Silver Spring, MD
>
>
>
> Juniper Business Use Only
>


-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD