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

So... I think it's good to document what people will see in the wild.  A 
254 priority is probably a good signal that one is dealing with a 
lispers.net implementation.  To me at least, the goal here should be to 
permit the documenting of that use. Documenting that in an RFC seems 
like a good idea, but publishing such "squatting" in an RFC doesn't seem 
like a good idea.  So how to move forward?  I'm seeking pragmatic 
answers to that question.

Eliot

On 24.05.23 14:01, Luigi Iannone wrote:
> Errata!
>
>> On 24 May 2023, at 13:48, Luigi Iannone <ggx@gigix.net> wrote:
>>
>>
>>
>>> 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.
>
> 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
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>>
>
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp