Errata! > On 24 May 2023, at 13:48, Luigi Iannone <[email protected]> wrote: > > > >> On 23 May 2023, at 23:05, Dino Farinacci <[email protected]> wrote: >> >>> Personally, I find this to be an inappropriate overlaoding of the Priority. >>> While overloading is not uncommon, it often causes problems with protocols >>> and I would prefer that we not do so. >> >> We all do. But the implementation has been deployed for nearly 10 years. The >> draft is just reporting/documenting how it is used. > > Dino, > > <chair hat on> > > The fact that you use that specific value in a particular way does mean that > the WG should agree to use priority values to indicate other things.
There is a missing NOT. The right sentence is: The fact that you use that specific value in a particular way does NOT mean that the WG should agree to use priority values to indicate other things. L. > The LISP WG is free to decide to deprecate such usage. > > <chair hat off> > > What follows is my personal opinion. > > About overloading priority with other meanings: > > Having 256 values to define priority is quite large and (according to my > experience) we can live with a lot less. So from that perspective it is not a > big deal. > > YET > > there are a few things to ponder: > > - Looking at lispers.net <http://lispers.net/> the 254 value choice, it looks > like a quick hack. > > - 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. > > - What about weight? In the lispers.net <http://lispers.net/> NAT traversal > it is used as defined in the main specs, but this means that all RTR have the > same priority all the time. And what if a future value will indicate not to > use weight? Or use it in a different way? > > - With the above we end up having RLOCs priorities that can be priority or > something else. In this latter case weight can or cannot be meaningful (or > even be something else altogether). Architecturally speaking it looks to me > less clean. > > Now, let’s take one step back: the real question seems to be how to signal in > the mapping system that an RLOC belongs to a RTR? > Or in a more general way: How to deliver RLOC-related informations that go > beyond priority and weight? > > The answer to me is RFC 8060. Just use LCAF! The LCAF format has 16 reserved > bits. One can be allocated to indicate whether the RLOC address belongs to an > RTR. > A side benefit of this choice would be that older implementations will just > ignore the bit, hence taking no action, rather than interpreting the bit in a > different way. Looks like a safer situation to me. You can even use a whole > new type, so that an implementation either knows how to handle it or does > nothing at all. > > Thoughts from the WG folks? > > Ciao > > L. > > >> >> Note this is only how the map-server operates. So existing xTRs will get >> back whatever the map-server decides. So if you are not an RTR (that must be >> configured in the said map-server) you will get back an RTR RLOC that an xTR >> will happily encapsulate to. That is, it works with existing xTRs that don't >> know anything about NAT-traversal. >> >> This implementation has interoperated with other implementations, but we >> don't claim anything in the draft. And existing xTRs can *receive* packets >> without following the control-plane procedures from the draft. We >> demostrated this with OOR by doing gleaning on the RTR. >> >> I have videos demostrating this for unicast and multicast and can send >> pointers if people are interested. >> >> Dino >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
