Les, >> If you don’t want application B to use metric M, then you create metric N and >> use that for application B. > > [LES:] The issue is...how do I indicate that Metric M is for App A (and NOT > for App B) and that Metric N is for App B (and not for App A)?
That does not need to be signaled. Configuration information SHOULD NOT be signaled. Yes, I realize that there is a great deal of precedent. No, I don’t agree with it. It’s a lot of unnecessary development overhead. > For Flex-algo this is possible because there is a FAD which specifies > metric-type. > But in general, applications do NOT have the equivalent of FAD. Correct. Future applications can be configured on a per-node basis as to what metric to use. > ASLA exists to address the generic problem of how do I establish the > association of a link attribute with an application - NOT just how do I do > this for Flex. It exists to mask over a problem by creating separate spaces of attributes for identical TLVs. In the case of the generic metric, you do NOT need separate spaces because you don’t have an issue with overlap. >> The generic metric is NOT one metric. It’s a whole host of them. Plenty to >> go >> around. Multiple metrics per application, all out of the single space. > > [LES:] Sooo, why do we actually need a "Generic Metric sub-TLV"? I believe that the draft explained the desire to route on bandwidth pretty well. From there, it seemed best to generalize. If we are going to have an additional metric, why should we add them one at a time? Computer science rule 2: One, two, many. We’re past two. :) > We could do the same thing by defining a new sub-TLV code point for each new > metric-type that gets defined. Yes, but that seems pretty silly. Let’s just create a space and allow administrators to route on any metric that they come up with. Dollars per mile might well be a good metric. :-) > The only thing the generic metric sub-TLV does for us is allow a single > sub-TLV codepoint to be used and let the metric-type within the > Generic-Metric sub-TLV specify which metric type it is. > But this also comes with limitations. You can only use the Generic Metric > advertisement for metric types which are represented by an integer metric > value. If we look at the existing metrics defined in the IGP Metric Types > Registry we see that not all metric types match - for example you cannot > encode delay metric in the Generic Metric sub-TLV. The draft does not discuss > this point - but it surely needs to do so. You could encode delay as an integer. Just use the correct units. Number of microseconds or nanoseconds might be appropriate. > I do not object to the Generic Metric sub-TLV definition, but you need to > understand that it is not usable for all types of metrics that may be defined. It’s true, if your metric is non-deterministic or temporal, yes, you need something more expressive. The point here is to encode integers. That’s what SPF is already set up to handle. Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
