Hi Dino, > On 24 May 2023, at 19:45, Dino Farinacci <[email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lisp >> >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
