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

Hi Dino,

> On 24 May 2023, at 19:45, Dino Farinacci <farinacci@gmail.com> 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.
> 
>> - 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.

Understood. So the most accurate statement is that it "indicates the priority AND additional information, i.e. it is a RTR”.  

> 
>> - What about weight? In the 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?  
> 
> This solution does not violate the LISP spec on how ITRs/RTRs use priorities and weights.

You are adding protocol actions not related to priority upon a specific priority value…. Without calling it a violation of the specs this is a not following the specs as they are for now. Hence the question what should be done. 

> 
>> - 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. 
> 
> This is simply not true.

Yes, this is not true in the lispers.net <http://lispers.net/> case.
> 
> I think you are overstating the problem.

If we open the door to the use of priority value that are different from just priority values the question is quite relevant IMO.

> 
>> 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? 
> 
> You could do it with a distinguished-name AFI that is encoded with the RLOC address.

Excellent. So we have another possibility beside LCAF.

> 
>> 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.
> 
> That could be too specific to this use-case. What an ETR needs to know is if it should tag RLOCs it gets back from the map-server in Info-Reply messages with this bit.
> 
> It actually could not tag it at all since the map-servers know the addresses of RTR RLOCs when they advertise them. But that means all map-servers need to have the same info and there is configuration coordination required.

Don’t see this. The bit (or tag) is associate to the RLOC, the same way the 254 value is.

> 
>> 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.
> 
> No that won't be the case. The way it works is that the RTR will give an RLOC-set to the ITR. So the ITR doesn't know if an RLOC is an ETR RTR pETR, etc. But the ETR side registeres the RTR RLOCs with 254. That is what is implemented today. If the ETR DOES NOT do this the map-server could figure it out on its own (as I mention above).

I was not referring to you implementation. I was referring to possible interoperability issues.

Ciao

L.
> 
> Dino
> 
>> 
>> 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
>> 
> 