Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[Shraddha Hegde <[e-mail]>]

>we only need the new TLV to carry FAPM if we make the Generic Metric's size variable. If we keep it fixed size, we >should be fine with the existing FAPM.

Yes agree. 
The idea of making generic metric variable length is worth considering.
I don't see a strong enough usecase right now to make it variable length but will wait
for inputs from WG.

Rgds
Shraddha 


Juniper Business Use Only

-----Original Message-----
From: Peter Psenak <[e-mail]> 
Sent: Wednesday, May 26, 2021 10:27 PM
To: Tony Li <[e-mail]>; Ketan Jivan Talaulikar <[e-mail]>
Cc: [e-mail]; [e-mail]; Acee Lindem (acee) <acee=[e-mail]>
Subject: Re: [Lsr] LSR WG Adoption Poll for "Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints" - draft-hegde-lsr-flex-algo-bw-con-02

[External Email. Be cautious of content]


Hi Tony, Ketan,

On 26/05/2021 18:40, Tony Li wrote:

>> */[KT] Generic Metric is used for the links. When we get to the 
>> computation of inter-area or external routes, we will need to get 
>> into FAPM. The draft at a minimum should discuss the applicability of 
>> the Generic Metric and its use as FAPM. Now, if we do make the 
>> Generic Metric size variable (as suggested above), then we will 
>> likely need a new TLV for a variable size FAPM equivalent?/*
>
>
> We would need a new TLV regardless of the metric size as the FAPM TLV 
> only carries the default metric. We are not proposing that TLV at this 
> time. That’s future work.

we only need the new TLV to carry FAPM if we make the Generic Metric's size variable. If we keep it fixed size, we should be fine with the existing FAPM.


thanks,
Peter
>
> Tony
>