Robert,

Pls see inline...



Juniper Business Use Only
From: Robert Raszuk <[email protected]>
Sent: Wednesday, March 3, 2021 6:50 PM
To: Shraddha Hegde <[email protected]>
Cc: Peter Psenak <[email protected]>; Gyan Mishra <[email protected]>; 
Rajesh M <[email protected]>; DECRAENE Bruno IMT/OLN 
<[email protected]>; Tony Li <[email protected]>; [email protected]; William 
Britto A J <[email protected]>
Subject: Re: [Lsr] New draft on Flex-Algorithm Bandwidth Constraints

[External Email. Be cautious of content]

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.
<Shraddha> The Maximum delay in FAD is compared against min delay advertised 
per link as  in RFC 8570.
                       so maximum delay is not required to be generated and 
flooded  for every link.

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 ?
<Shraddha> If statically configured link delay values are used in production, 
the existing exclude link affinity FAD constraints will be good enough to 
achieve any required  topology pruning in the Flex-algo. The "Exclude maximum 
link delay" defined in this document is useful when dynamic link-delay 
measurement is used.

Many thx,
R.






On Wed, Mar 3, 2021 at 2:03 PM Shraddha Hegde 
<[email protected]<mailto:[email protected]>> 
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 <[email protected]<mailto:[email protected]>>
Sent: Wednesday, March 3, 2021 4:12 PM
To: Peter Psenak <[email protected]<mailto:[email protected]>>
Cc: Tony Li <[email protected]<mailto:[email protected]>>; Gyan Mishra 
<[email protected]<mailto:[email protected]>>; DECRAENE Bruno IMT/OLN 
<[email protected]<mailto:[email protected]>>; Shraddha Hegde 
<[email protected]<mailto:[email protected]>>; Rajesh M 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>; William Britto A J 
<[email protected]<mailto:[email protected]>>
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 
<[email protected]<mailto:[email protected]>> 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 
> <[email protected]<mailto:[email protected]>
> <mailto:[email protected]<mailto:[email protected]>>> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/lsr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!RV3wuZC53zWIexlY8lVqmUuzLvZyHt4Z5gUf91AdddmCAXzdENrH84mBLZU0lVDO$>
_______________________________________________
Lsr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to