I can add that text. Dino
> On May 24, 2023, at 11:38 AM, Joel Halpern <[email protected]> wrote: > > If you want to start the draft by saying "this describes a shortcut we took, > which works among consenting parties when no one else is using the particular > values in nay other way, but we do not recommended it for arbitrary > deployments" then I would probably have fewer concerns. As you say, you did > indeed do it. > > Yours, > > Joel > > On 5/24/2023 1:55 PM, Dino Farinacci wrote: >>> 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 [email protected] https://www.ietf.org/mailman/listinfo/lisp
