Tony - Thanx for separating out this thread. Inline.
> -----Original Message----- > From: Tony Li <tony1ath...@gmail.com> On Behalf Of Tony Li > Sent: Friday, July 30, 2021 1:25 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Peter Psenak (ppsenak) <ppse...@cisco.com>; Shraddha Hegde > <shrad...@juniper.net>; Robert Raszuk <rob...@raszuk.net>; Van De > Velde, Gunter (Nokia - BE/Antwerp) <gunter.van_de_ve...@nokia.com>; > lsr@ietf.org > Subject: Re: [Lsr] Generic metric: Future metrics are not constrained > > > Hi Les, > > > > [LES:] So you are proposing that all metrics - now and in the future - be > restricted to Generic-Metric format? > > > Of course not. We are simply trying to generalize. As you note, we already > have three different metric types floating around. Bandwidth would make 4. > With FA, we have the capability of using 128 different metrics > simultaneously. Let’s stop defining metrics one by one. [LES:] I do not object to the Generic-Metric TLV (I believe I stated that at the beginning). I might not have chosen to do it that way myself - but I am OK with it. But one of the consequences of this choice is that not all metric-types can be advertised in this new format. This means that for each metric type in the IGP Metric Types Registry (now and in the future) we need to state whether the type is encoded in Generic-Metric sub-TLV or not. > > An administrator might have different metrics that they might want to use. It > would be a shame to have to write up an RFC and create a new TLV every > single time an administrator came up with a different metric schema. So, > let’s define a generic set of them and give the administrator some added > capabilities. We actually don’t have to standardize what the units are or > what > the metric represents. We actually don’t care as long as we have metrics that > we can SPF over. > > As with anything that we add to the protocol, it is never a prohibition > against > future additions. If someone decides that there’s a good reason to have > floating point or double precision metrics, they are welcome to write that > RFC. > > If you’re complaining about the name “Generic” because it’s not generic > enough, well ok, we would be happy to consider alternative names. Is > “Generic Unsigned 32-Bit Integer Metric” better? :-) > > > > I do not see why that is necessary - but if that is your intent, please > > state > that explicitly in the draft so the WG can make an explicit call as to whether > that is what we want to agree to do. > > In the meantime, we already have three metric types (IGP, TE, Delay) > which cannot be encoded in Generic-Metric - please document that in the > draft. > > > If you mean that they should not be encoded in the generic metric because > that would not be backward compatible with deployed nodes, I have no > issues with that. That wasn’t ever the intent. > [LES:] For existing metric types: IGP: This is not encoded in a sub-TLV of any flavor. TE: There is an existing sub-TLV - so yes - backwards compatibility is an issue. I see no reason to reinvent the advertisement for this. Delay: The value used for this metric is derived from Min/Max Unidirectional Link Delay sub-TLV(34). This encoding does not fit in the Generic-Metric format and even if it did it would be redundant and not backwards compatible. For new metric-types: Whether they can be advertised in Generic-Metric is dependent upon the value associated with the advertisement. Since you say you do NOT want to define a restriction on new metric-types to always match Generic-Metric format, that means for each new type we will also need to indicate whether it is advertised in Generic-Metric or not. I hope this is not controversial - just a detail that needs to be attended to in the draft. Les > If you something else, then I’m not following you. > > Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
