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
