Re: [lisp] On the use of priority associated to RLOCs

> On 23 May 2023, at 23:05, Dino Farinacci <farinacci@gmail.com> 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.
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
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp