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

2023-05-26 Thread Dino Farinacci
> "this describes a shortcut we took, not compliant with [RFC9300] and 
> [RFC9301], 
> which works among consenting parties when no one else is using the particular 
> values in any other way, but we do not recommended it for arbitrary 
> deployments.”

I will add in next revision.

Dino


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


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

2023-05-26 Thread Luigi Iannone


> On 25 May 2023, at 20:34, Dino Farinacci  wrote:
> 
> 
 
 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.
> 
> Well to be specific, if you put a dist-name with the RLOC it is encoded as an 
> AFI-list LCAF.  But I know what you mean. You are proposing/considering a new 
> LCAF type that identifies an RTR.
> 

This could be one solution. But we do not need to do it if there is no 
interest. 
For this document the text suggested by Joel clarifies the peculiar usage of 
the priority field.
I would just amend the text as follows:

"this describes a shortcut we took, not compliant with [RFC9300] and [RFC9301], 
which works among consenting parties when no one else is using the particular 
values in any other way, but we do not recommended it for arbitrary 
deployments.”

Ciao

L.


> Dino
> 

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