Tony,
On 30/07/2021 22:08, Tony Li wrote:
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?
isn't setting a bit in the existing TLV less overhead compared to
sending a separate TLV if the same metric-type and value happens to be
used by multiple application?
thanks,
Peter
[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
