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

Gyan Mishra <hayabusagsm@gmail.com> Sat, 27 February 2021 16:10 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 3C2DD3A0C7C for <lsr@ietfa.amsl.com>; Sat, 27 Feb 2021 08:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 VWdBaH8drI_3 for <lsr@ietfa.amsl.com>; Sat, 27 Feb 2021 08:10:42 -0800 (PST)
Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 0613C3A0C7D for <lsr@ietf.org>; Sat, 27 Feb 2021 08:10:41 -0800 (PST)
Received: by mail-pl1-x629.google.com with SMTP id d11so6959318plo.8 for <lsr@ietf.org>; Sat, 27 Feb 2021 08:10:41 -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=XfjGSdtOtt8ehwOsBEyoBKA/yKU9laaKDkI/eaRyuro=; b=TWvby8tgH/EgSvJliZ4xAfL++1i9IVBRVBFady74gEoV8w0mVC8dEYZ9x9qpPYTvso DVOlkFyz7AFljPDnKSXhN+9aSO9/ciZn9EUSqvipkLUW7ZGfalUdqxtDR6Le0dGS3tTz WZMyPAjxKaGTtHSJTPAF+lEDjK8IMgr5Qhm439vIyppin/ymyS0YIy0Fwo09w5tWS2PB vhPzgUcOTPlI3EIFIJCGkIB3CjEMsYbXdAEiqUAWd96WyVI3NHu+hYVq3Ejp9VK0Neiw zuiXO0c8MjTdWtV+JpyQR515dDIzGkItAcT5llvhUK1h5zkiBsY261FaUkUfNRPGy/nB lBmw==
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=XfjGSdtOtt8ehwOsBEyoBKA/yKU9laaKDkI/eaRyuro=; b=IZPDB3vX8Ak0ZTZDCMF1fyXg/ahsBWcXt6kn76l1Q/eX8UZ0X0RCYafttgNHUcyF1Q vkCGMSMp683GAvig1pPrxP/PqQsr6vkF+YIUshRnY0HlnJfxnTK9z2Z1oEeb2sjXzygI N2z7ue6Ch/xYUYeYWRfuIe2hEd/Ccm7tlxrGyy8uJoqJ2hYDz/X0oG2e2C9V2UiPRsy7 NjxF+YQiS5k5W7IEWBorRZgonQFbMt6w8p5MGMGbk+TCbRoCoF3soX6babtqXqTeM6+4 dFRRfZLF6220Q0O323LAzLKaosKz+q5j3T89csV6qJK9oPcAqZhcppFZQvPNd+R5FQ+5 ppiA==
X-Gm-Message-State: AOAM530b3B7Kzmz2UDcYdb5NPNxemzTm9b0+qlZbh7gMUw9cy9R1BoSY LLaNK+I5YeURpnOQKbCX8TZMYZO3Ry/cmujTB3I=
X-Google-Smtp-Source: ABdhPJxp/nTklMhsPrJgDQ4GmwDh0ZIxu3W0oh6Bq4iyLk46zFuORXyAOIXwH0sCR2XSeZHFcTPulmkhK5buXqssViQ=
X-Received: by 2002:a17:902:fe09:b029:e4:951e:2d2e with SMTP id g9-20020a170902fe09b02900e4951e2d2emr1255435plj.22.1614442241190; Sat, 27 Feb 2021 08:10:41 -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>
In-Reply-To: <CAOj+MMHKazMG3wnUA+Kd2wg2hfr01CdF5w5YYKdFaHU4_V+0SA@mail.gmail.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sat, 27 Feb 2021 11:10:30 -0500
Message-ID: <CABNhwV0UKB=HaMs9eLvvp4fVLPsEtJhQ2xFmwY80sqBNDFRudQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <shraddha@juniper.net>, William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>, "lsr@ietf.org" <lsr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004bed9805bc53a0cc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/SPZFNGt63dylTCL_fciowWf1EWI>
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: Sat, 27 Feb 2021 16:10:44 -0000

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
>>
>>
>>
>> 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>, Rajesh M <
>> mrajesh@juniper.net>, Rajesh M <mrajesh@juniper.net>, Shraddha Hegde <
>> shraddha@juniper.net>, William Britto A J <bwilliam@juniper.net>,
>> 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.
>>
>> The IETF Secretariat
>>
>>
>> Juniper Business Use Only
>> _______________________________________________
>> Lsr mailing list
>> Lsr@ietf.org
>> https://www.ietf.org/mailman/listinfo/lsr
>>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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