> 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. > - 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. > - 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. I think you are overstating the problem. > 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. > 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. > 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). 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
