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