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

[Robert Raszuk <[e-mail]>]

Not sure what's the difference between the two.

But I guess let't wait for authors to clarify their intentions here.

Cheers,
R.

On Wed, Mar 3, 2021, 11:47 Peter Psenak <[e-mail]> wrote:

> Robert,
>
> On 03/03/2021 11:41, Robert Raszuk wrote:
> >
> > Sorry but to me the draft is very clear that it does not care about min
> > delay, but possible maximum delay of a link  ...
>
> "maximum link delay constraint" !=  "max link delay"
>
> You are not listening.
>
> Peter
>
> >
> > 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.
> > <http://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 <[e-mail]
> > <mailto:[e-mail]>> 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 <[e-mail]
> >     <mailto:[e-mail]>
> >      > <mailto:[e-mail] <mailto:[e-mail]>>> 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.
> >      >      >
> >      >      >
> >      >      >
> >      >      >
> >      >
> >
>
>