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

Robert Raszuk <robert@raszuk.net> Wed, 03 March 2021 13:19 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 6F3DE3A110B for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 05:19:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Level:
X-Spam-Status: No, score=-6.998 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, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 7pkabTVTSL2k for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 05:19:54 -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 CD2243A110A for <lsr@ietf.org>; Wed, 3 Mar 2021 05:19:53 -0800 (PST)
Received: by mail-lf1-x12c.google.com with SMTP id e7so37078480lft.2 for <lsr@ietf.org>; Wed, 03 Mar 2021 05:19: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=ISlZRtvf2IjOFDDnPHVQ40dMp1yIpC/k1eDvJrAxYeQ=; b=PNQEO2mD/xJG6jeZQ4Cp621E8kHfNjVc7W4v4/lfvYtI8tZnbpHaK6rlzAr4PY4zjP 7BQmuSptbgqmO76QVG5DjsNUN9JoEuFNBqtuIjjzh/k/xGevD/xK/dYPlpq/5BvGS/UF 5s8CoVvaog/gCfo7S1vms/oZeINxsPtl5KtH2cdA57PCIxHxNhUoOfmPrDH4BBAeLEgM pw1L39C7Qb5Oe29lB97HWmzDqnJP0wRh2haeNzzRArEB3FXjocnU7hWKY6ImPXZX0+KI HStPJcHSsr4ZYoKh5GjKEKgOxuhnaM+3Vi6NMpWLy417e4GUNQ7ufZ8pC/gtz+Vbni6v jTHg==
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=ISlZRtvf2IjOFDDnPHVQ40dMp1yIpC/k1eDvJrAxYeQ=; b=Eu+17PUHIMmlsuUC0pCaQ7PjNhZr6QwaxYmXai9gQe4v5UM9Nw45Smegm69teyXtX6 nfePsmdNFWBfbSfgXJ+OsBarntmKzwYnxiqPrd0zEx4h0HnIxz9uUYn+NR0lIKav2Uzs bvC2lxgMYltvcZD9n4sW+V5Vakc/GLxywMeLMQ4cK89mRfikk2OM24gtywnE+2nfXkiX ROXzL04Edc2GlktqCRWl8PG5HvtSlpHt1z28krMNdf97G0WcJ9YYpggbv4m5ks0dPn7o xdQ8ouCxa2P+2WKEcNAMqpV+RsgHoz0rpwAZMF7t4XzLNPeNllqiXAH7rWPo5VZQak1/ CX2g==
X-Gm-Message-State: AOAM532w+93yEQS6kno1gqVSZOSvH7b7PzK03ploiHJ5E8uLgjutwdM5 XuxCwa/LDh4x2ylisxKPpI0y3OLzTNdt9kDqeVXfOA==
X-Google-Smtp-Source: ABdhPJx2/vfxAYyAotie/15T9T/uH4+sIRbN379gWOrPhqyLzvjy/jSV2H/XNy9BxajVgjZbVo72WJvU2jBlOi+kY7o=
X-Received: by 2002:a19:651b:: with SMTP id z27mr9527784lfb.517.1614777588129; Wed, 03 Mar 2021 05:19:48 -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> <CAOj+MMGZppwYtNr4t0rJoy3BKWaBYqHiJ_esM1XNFTNxbm8c5w@mail.gmail.com> <08882555-009B-4068-ABB0-20B0D165D722@tony.li> <2c2605a8-95c6-a477-b1b5-5ae4d4de222a@cisco.com> <CAOj+MMGf=zQMGP+q+XX-MJi-qMrOddmq_+wmrXFS+JQX_PsudQ@mail.gmail.com> <25a8853a-72a3-3013-6a87-d8049ed7a3da@cisco.com> <CAOj+MMH2a=T-vBsD6QVChmybmdQhQXFcDg1np+v+bpKOWPbtKA@mail.gmail.com> <8be3198f-4c9c-2bae-9ce9-f283ac5305a1@cisco.com> <CAOj+MMFf_QymQLOG4mR9F_3h-njo0k2Le6eE1bKUkK6NmcLboQ@mail.gmail.com> <42fbaa46-7434-39fb-b5a1-97fe0c7866d3@cisco.com> <CAOj+MMG5j=HcZhtni+ROVU4zjzgHDKQhNmgxpBqpx97Jf3uU4w@mail.gmail.com> <CY4PR05MB3576051C31A5A8DD704B8378D5989@CY4PR05MB3576.namprd05.prod.outlook.com>
In-Reply-To: <CY4PR05MB3576051C31A5A8DD704B8378D5989@CY4PR05MB3576.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 3 Mar 2021 14:19:39 +0100
Message-ID: <CAOj+MMG5PkA6tsSNUu54HWBYrrWW5FgZzvndm5wTY5L8PXm8iw@mail.gmail.com>
To: Shraddha Hegde <shraddha=40juniper.net@dmarc.ietf.org>
Cc: Peter Psenak <ppsenak@cisco.com>, Gyan Mishra <hayabusagsm@gmail.com>, Rajesh M <mrajesh@juniper.net>, "DECRAENE Bruno IMT/OLN" <bruno.decraene@orange.com>, Tony Li <tony.li@tony.li>, "lsr@ietf.org" <lsr@ietf.org>, William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008839e505bca1b441"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/xRhwqweNwb80UoglXDnN3DSdRbo>
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 13:19:56 -0000

Shraddha,

Yes your proposal defines constrains for FAD. But ny point is that if you
are defining such constrain called Max Link Delay you better make sure that
parameter used to measure such Maximum is well generated and flooded.
Otherwise this constrain becomes questionable.

What if implementation will choose to advertise Minimum Link Delay of
the period of 1 week or have this as constant value configured wheen you
test your link before deploying it in production ? What if it never will
include egress queueing delay. How practical will be your constrain in such
cases ?

Many thx,
R.






On Wed, Mar 3, 2021 at 2:03 PM Shraddha Hegde <shraddha=
40juniper.net@dmarc.ietf.org> wrote:

> Robert,
>
>
>
> The draft is not trying to define new delay metric.
>
> A new constraint called “ Exclude Maximum link delay “ is being defined in
> the draft.
>
> This constraint when included in the FAD should be used prune links that
> have RFC 8570 advertised
>
> Unidirectional link delay larger than the value defined in this FAD
> constraint.
>
> We will post the -01 version when the window opens. We have clearer text
> and also
>
> fixed some confusions in IANA section.
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* Robert Raszuk <robert@raszuk.net>
> *Sent:* Wednesday, March 3, 2021 4:12 PM
> *To:* Peter Psenak <ppsenak@cisco.com>
> *Cc:* Tony Li <tony.li@tony.li>li>; Gyan Mishra <hayabusagsm@gmail.com>om>;
> DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>om>; Shraddha Hegde <
> shraddha@juniper.net>gt;; Rajesh M <mrajesh@juniper.net>et>; lsr@ietf.org;
> William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>
> *Subject:* Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Sorry but to me the draft is very clear that it does not care about min
> delay, but possible maximum delay of a link  ...
>
>
>
> After all for time sensitive applications we do care how long it will take
> to actually traverse a path in practice not what would be the theoretical
> min amount of time needed for this path to be traversed.
>
>
>
> And it does define it here as brand new metric.
>
>
>
> Just read this paragraph as well as sections 3.1.2 and 3.2.2.
> <https://urldefense.com/v3/__http:/3.2.2.__;!!NEt6yMaO-gk!Qi6nctWtUC5MsX--CcSHucSj6ja5VJIBkRYNQtm3EOTpOgWBEzDcIQDmqwM1R9Mc$>:
>
>
>
>
>    Similarly, exclude maximum link delay constraint is also defined in
>
>    this document.  Links may have the link delay measured dynamically
>
>    and advertised in delay metric in IGP.  For usecases that deploy low
>
>    latency flex-algo, may want to exclude links that have delay more
>
>    than a defined threshold.
>
> Thx,
>
> R.
>
>
>
> On Wed, Mar 3, 2021 at 11:31 AM Peter Psenak <ppsenak@cisco.com> wrote:
>
> On 03/03/2021 11:27, Robert Raszuk wrote:
> >
> > I am not sure I follow your logic here ...
> >
> > If we are already advertising "Min Unidirectional link delay" as
> > described in https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-13
> <https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-lsr-flex-algo-13__;!!NEt6yMaO-gk!Qi6nctWtUC5MsX--CcSHucSj6ja5VJIBkRYNQtm3EOTpOgWBEzDcIQDmq-eiJLT-$>
> why
> > would we need to define it again here in this draft ?
>
> we are not defining the metric here, we are defining the constraint that
> says what is the maximum value of that metric that can be used.
>
> thanks,
> Peter
> >
> > Also does it really make sense to advertise maximum value of
> > minimum value ?
> >
> > Thx,
> > R.
> >
> > On Wed, Mar 3, 2021 at 11:22 AM Peter Psenak <ppsenak@cisco.com
> > <mailto:ppsenak@cisco.com>> wrote:
> >
> >     Robert,
> >
> >     On 03/03/2021 11:10, Robert Raszuk wrote:
> >      > Hey Peter,
> >      >
> >      >      > Authors stated: "Whether egress queueing delay is included
> >     in the
> >      >     link
> >      >      > delay depends on the measuring mechanism."
> >      >
> >      >     I disagree with that statement - the Min Unidirectional Link
> >     Delay is
> >      >     the value that does not include the queueing delay - that's
> >     why it is
> >      >     called Min.
> >      >
> >      >
> >      >
> >      > But draft we are discussing here does not talk about "Min" delay.
> >      > Contrary it talks about "Max"
> >      >
> >      > *Maximum*  Delay sub-TLV
> >      >
> >      > That is also I asked that very question up front.
> >
> >     I'm afraid you misunderstood it. FA uses "Min Unidirectional Link
> >     Delay"
> >     as one of its metrics. The "Maximum Delay sub-TLV"  is used to
> >     advertise
> >     the maximum value of the "Min Unidirectional Link Delay" that is
> >     allowed
> >     for the particular FA.
> >
> >     The text should be improved in that regard though, it's not obvious,
> >     but
> >     I believe that's what it is.
> >
> >     thanks,
> >     Peter
> >
> >      >
> >      > Thx,
> >      > R.
> >      >
> >      >
> >      >
> >      >
> >
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>