On 27/05/2021 14:36, Shraddha Hegde wrote:
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
nor do I.
thanks,
Peter
for inputs from WG.
Rgds
Shraddha
Juniper Business Use Only
-----Original Message-----
From: Peter Psenak <ppse...@cisco.com>
Sent: Wednesday, May 26, 2021 10:27 PM
To: Tony Li <tony...@tony.li>; Ketan Jivan Talaulikar <ket...@cisco.com>
Cc: lsr@ietf.org; draft-hegde-lsr-flex-algo-bw-...@ietf.org; Acee Lindem (acee)
<acee=40cisco....@dmarc.ietf.org>
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
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
