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
