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. 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. If you something else, then I’m not following you. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
