Tony - I assure you I am not talking about ASLA vs non-ASLA. I am responding to your statement:
" That does not need to be signaled. Configuration information SHOULD NOT be signaled." Where "that" refers to the mapping of link attributes to an application. I am saying not advertising this association is an interoperability disaster and has been proven to be so - and I pointed to the summary of cross-vendor RSVP-TE behavior as a definitive example of one such disaster. If we disagree on that - so be it - but it is important to understand on what we disagree - otherwise the arguments we make on the consequences of that choice make no sense to each other. Les > -----Original Message----- > From: Tony Li <[email protected]> On Behalf Of Tony Li > Sent: Friday, July 30, 2021 1:08 PM > 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, > > >> 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. > > > > We’re talking past each other. I objected to ASLA in it’s entirety. I have > been > reprimanded by Acee and am trying to comply. Please consider that closed. > > > I am now trying to make a different point entirely. Please hear this. > > > My understanding is that we are still allowed to create TLVs outside of ASLA. > If not, then we have a much bigger discussion. ;-) > > Assuming that you agree that we are allowed to do some things outside of > ASLA, then we need to decide whether generic metrics should be inside or > outside of ASLA. The point that I’m trying to make is that > there is no practical benefit to putting it inside of ASLA. With 256 > different > metrics, there is enough room to play. We do not need 256 metrics for RSVP, > 256 for FlexAlgo, etc. etc. > > Yes, I will happily stipulate that you COULD do it that way, but you don’t > have > to and it adds overhead, so why would you? > > > > [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. > > > This is wholly orthogonal to the point of the discussion, so I will take this > to a > separate thread. > > Tony _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
