Perhaps, I should have been more careful with the word "variable". Initially, I meant allowing either 24 or 32 bits size (to me making it 32 just covers both the bases). But then the discussions on delay brought to my mind that perhaps even 64-bit metric might be useful. So the variable in my mind was either 32 or 64.
And I agree that there is no impact on FAPM if we picked the Generic Metric of 32-bit (or even kept it 24-bit). And yes, thanks Shraddha for agreeing to cover the applicability and aspects of FAPM in this document. Similar also applies for the OSPF FAAM, btw. Thanks, Ketan -----Original Message----- From: Peter Psenak <ppse...@cisco.com> Sent: 27 May 2021 18:20 To: Shraddha Hegde <shrad...@juniper.net>; Tony Li <tony...@tony.li>; Ketan Talaulikar (ketant) <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 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
