Maybe I can provide some color, so folks know why this design decision was made.
(1) An xTR behind a NAT will register its global RLOC (and port) and the RTRs it has learned to the mapping system. (2) When another ITR wants to encapsulate to this xTR, it CANNOT do so with the global RLOC. (3) When an RTR wants to encapsulate to this xTR, it CAN do so with the global RLOC. (4) So when either the ITR or RTR do a Map-Request lookup, the map-server returns a PARTIAL RLOC-set to the requester. That is, it returns the global RLOC(s) to the RTR and the RTR RLOC(s) to the ITR. For the map-server to know in an RLOC-set which RLOCs belong to RTRs, they are registered with RLOC priority 254. Dino > On May 23, 2023, at 7:07 AM, Luigi Iannone <g...@gigix.net> wrote: > > Hi All, > > > TL;DR: Should the priority associated to RLOCs be used to indicate something > else? > > Long Version: > > As you may (or may not) know Dino submitted the lispers.net NAT traversal > solution > (https://datatracker.ietf.org/doc/draft-farinacci-lisp-lispers-net-nat/ ) for > publication on the Independent Stream > (https://www.rfc-editor.org/about/independent/). > > Current ISE Editor is Eliot Lear (well known by old lispers like me ;-) ) > > During the review of the document an interesting question came up: > > Lispers.net NAT traversal uses priority 254 to indicate that the RLOC belongs > to a RTR. > > No text in old and new specs suggest a usage of the priority to deliver > something different than the priority itself. > Even the value 255 is related to priority: do not use this RLOC = no priority. > > It goes without saying that there is no IANA registry about special value of > priority associated to RLOCs. > > At the same time there is no text that explicitly states “priority indicates > only the priority and CANNOT be used for something else”. > > So the question is: Should we (the WG) consider that priorities can be used > to indicate something different from priority? > > If not: we may want to write it down somewhere. > > If yes: Well…. This deserves a longer discussion (may be to be included in > the new charter…). > > Thoughts ? > > Ciao > > Luigi > _______________________________________________ > 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
