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.
Yours,
Joel
On 5/23/2023 2:57 PM, Dino Farinacci wrote:
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 <[email protected]> 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
[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
