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 <[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
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
