Tony - > -----Original Message----- > From: Tony Li <[email protected]> On Behalf Of Tony Li > Sent: Friday, July 30, 2021 11:25 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: Peter Psenak (ppsenak) <[email protected]>; Shraddha Hegde > <[email protected]>; Robert Raszuk <[email protected]>; Van De > Velde, Gunter (Nokia - BE/Antwerp) <[email protected]>; > [email protected] > Subject: Re: [Lsr] Generic metric: application-specific vs application- > independent > > 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. > > [LES:] You are taking us back 20 years in time and reintroducing the problems that ASLA was defined to solve.
It would be instructive to look at Figure 1 in https://datatracker.ietf.org/doc/html/draft-hegde-isis-advertising-te-protocols-03#section-1 . The authors did a great job of documenting the state of affairs regarding RSVP-TE. As you can see, implementations do not agree on what the necessary conditions are to consider a link as enabled for RSVP-TE. Why didn’t we have interoperability issues? The answer is that we did have interoperability issues. But vendors/customers managed to figure out what to configure to allow Vendor X to interoperate with Vendor Y. It wasn't pretty. Keeping things that are needed for interoperability local is a recipe for trouble. I ask you (again) to read the Introduction to RFC 8919/8920 - which details the problems ASLA is trying to solve. These are not imaginary issues - they are issues actually encountered in real deployments. > > 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. > [LES:] So you are proposing that all metrics - now and in the future - be restricted to Generic-Metric format? 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. Les > > > 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
