> Trimmed, In line. > > On 5/24/2023 1:45 PM, Dino Farinacci wrote: >>> there are a few things to ponder: >>> >>> - Looking at lispers.net the 254 value choice, it looks like a quick hack. >> I would refer to it as a convienent solution that doesn't violate the spec. > <jmh>claiming that this alternative meaning is not a violation is quite a > stretch.</jmh>
As an implementor, it was convienent. I'm not saying anything more than that. I should have used an alternative mechanism. >> >>> - What about backward compatibility? If we allow overloading, there is no >>> way to understand whether a value indicates a “true” priority or something >>> else, different implementations may interpret the value in different ways >>> with unpredictable results. >> It always means a true value from an xTR point of view. > > <jmh>It is the true value because you said so. The important point however > is that you decclare that otehr nodes can tell that the advertiser is an RTR > from the priority. That is adding additional inappropriate, and overloading > meaning to the priority. <jmh> I don't know what you mean. The map-server will return RLOCs with priorities. The ITR uses them according the spec. There isn't anything more complciated than that. I do not declare that from an ITR point of view. It is true from an ETR point of view. I'm trying to provide clarity and details so the working group understands how it works not the motivation for using the solution or why it was chosen. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
