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

Robert Raszuk <robert@raszuk.net> Wed, 03 March 2021 10:42 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 54F963A0C7C for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 02:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.856
X-Spam-Level:
X-Spam-Status: No, score=-0.856 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, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 KWvqNZHvBOVo for <lsr@ietfa.amsl.com>; Wed, 3 Mar 2021 02:42:03 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 31AAD3A0C66 for <lsr@ietf.org>; Wed, 3 Mar 2021 02:42:03 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id r25so27005674ljk.11 for <lsr@ietf.org>; Wed, 03 Mar 2021 02:42:03 -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=uniLTqlL37UT5FhlQ3vpV0OaH0IiAQD91is8HnKKSBY=; b=cdtFn44H/e5AEGX5i5zshcdJ5ux5fOydqR8Wa1kOcWNYSXsZBFBWbC/hT2z2lJUixc ndswT/JAgJKrz4z3E6NW25sTb/3W2Y5rwRia4KjuonsvDUfZhAaJa07RDOaiqZUB1uXI ZfcyaLqUFz5W/D60Tpqc0o624BK/bM/9ql8IJTC++0EC5EbpKKQlOuiFDnCB572KqjD1 O3nGDdoOudKJJsbQToxOQR37gdXFPi/N3R4/1xnv4oywakPIwsXqwKL4nb2ANo1scPGW 49ESNB3zcJdzmruaJZ/7g83b825CJifGRfg2Rz1qP1xlgHCU1stFFpbf+x/Y6C4TKQe7 XDsQ==
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=uniLTqlL37UT5FhlQ3vpV0OaH0IiAQD91is8HnKKSBY=; b=MTzMWrTX+/UboBTcNLKsrCzsLVSRnYWTZz2Ki05WyXVqS2P/2ersoXe5cNo1ZRYcGG LZkhwU7rflzhAbPB9mKzG/77FEhwNcz+MiAe8FOxVNnDMDKRJGXG6hJ6kNlmNFC9WwL8 P10khunJZQfTA3mWXOKtLq0HNZOaNmC+Eh1Ue8A+KMU/FiTFyUD30AUAPt7zk787qRyX UmFO2Y+sb0QjoIUap1ANtgqTV9t6u8CtevyGPNsepRkxoKjmPINVO/gaXjWSL7fJeLrT xm/ClAwj5OxY5bxA9gLBWwiAC8nElsDIPf6EvI7YUFzyFTz7YDrbS0qEKgnK3HJWqKKW 2DZQ==
X-Gm-Message-State: AOAM533duHpZNSdjTwvxF3/7AZ/2yKjgJnkTP5k4pWZ+M9dVhqCB7dS3 Q234fv445kgYrFcg+YFHqI+6RPJONElv0CuAz7tEpQ==
X-Google-Smtp-Source: ABdhPJxUVUYRpe3N6pkyIIbGCrkHGVgwAu48kgzvC2MvOr/XYhxgDfqw72hegd74L4D9aKf8+2lQ8zg2YRLEGdCsjUI=
X-Received: by 2002:a2e:87c9:: with SMTP id v9mr10011355ljj.321.1614768117284; Wed, 03 Mar 2021 02:41:57 -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>
In-Reply-To: <42fbaa46-7434-39fb-b5a1-97fe0c7866d3@cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 03 Mar 2021 11:41:47 +0100
Message-ID: <CAOj+MMG5j=HcZhtni+ROVU4zjzgHDKQhNmgxpBqpx97Jf3uU4w@mail.gmail.com>
To: Peter Psenak <ppsenak@cisco.com>
Cc: Tony Li <tony.li@tony.li>, Gyan Mishra <hayabusagsm@gmail.com>, DECRAENE Bruno IMT/OLN <bruno.decraene@orange.com>, Shraddha Hegde <shraddha@juniper.net>, Rajesh M <mrajesh@juniper.net>, "lsr@ietf.org" <lsr@ietf.org>, William Britto A J <bwilliam=40juniper.net@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="00000000000006914005bc9f80e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/IbgCYDRDwG-ybyyZPK-bqQrdPto>
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 10:42:07 -0000

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.:

   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
> 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.
> >      >
> >      >
> >      >
> >      >
> >
>
>