Re: [lisp] On the use of priority associated to RLOCs

[Dino Farinacci]

> 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
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] On the use of priority associated to RLOCs

[Joel Halpern]

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


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] On the use of priority associated to RLOCs

[Dino Farinacci]

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

Re: [lisp] On the use of priority associated to RLOCs

[Eliot Lear]

Hi everyone and thanks, Luigi for kicking off the subject.  I just have 
one suggestion below.


On 23.05.23 16:07, Luigi Iannone wrote:
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…).


What has been discussed is maybe borrowing a values from the top of the 
priority field that may attach other semantics (so think values 
248-254).  The lispers draft would be one such use.


Eliot

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] On the use of priority associated to RLOCs

[Luigi Iannone]

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