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

[Dino Farinacci]

I can add that text.

Dino

> On May 24, 2023, at 11:38 AM, Joel Halpern  wrote:
> 
> If you want to start the draft by saying "this describes a shortcut we took, 
> which works among consenting parties when no one else is using the particular 
> values in nay other way, but we do not recommended it for arbitrary 
> deployments" then I would probably have fewer concerns.  As you say, you did 
> indeed do it.
> 
> Yours,
> 
> Joel
> 
> On 5/24/2023 1:55 PM, Dino Farinacci wrote:
>>> Trimmed, In line.
>>> 
>>> On 5/24/2023 1:45 PM, Dino Farinacci wrote:
> there are a few things to ponder:
> 
> - Looking at lispers.net the 254 value choice, it looks like a quick hack.
 I would refer to it as a convienent solution that doesn't violate the spec.
>>> claiming that this alternative meaning is not a violation is quite a 
>>> stretch.
>> As an implementor, it was convienent. I'm not saying anything more than 
>> that. I should have used an alternative mechanism.
>> 
> - What about backward compatibility? If we allow overloading, there is no 
> way to understand whether a value indicates a “true” priority or 
> something else, different implementations may interpret the value in 
> different ways with unpredictable results.
 It always means a true value from an xTR point of view.
>>> It is the true value because you said so.  The important point however 
>>> is that you decclare that otehr nodes can tell that the advertiser is an 
>>> RTR from the priority.  That is adding additional inappropriate, and 
>>> overloading meaning to the priority.  
>> I don't know what you mean. The map-server will return RLOCs with 
>> priorities. The ITR uses them according the spec. There isn't anything more 
>> complciated than that.
>> 
>> I do not declare that from an ITR point of view. It is true from an ETR 
>> point of view.
>> 
>> I'm trying to provide clarity and details so the working group understands 
>> how it works not the motivation for using the solution or why it was chosen.
>> 
>> 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]

If you want to start the draft by saying "this describes a shortcut we 
took, which works among consenting parties when no one else is using the 
particular values in nay other way, but we do not recommended it for 
arbitrary deployments" then I would probably have fewer concerns.  As 
you say, you did indeed do it.


Yours,

Joel

On 5/24/2023 1:55 PM, Dino Farinacci wrote:

Trimmed, In line.

On 5/24/2023 1:45 PM, Dino Farinacci wrote:

there are a few things to ponder:

- Looking at lispers.net the 254 value choice, it looks like a quick hack.

I would refer to it as a convienent solution that doesn't violate the spec.

claiming that this alternative meaning is not a violation is quite a 
stretch.

As an implementor, it was convienent. I'm not saying anything more than that. I 
should have used an alternative mechanism.


- What about backward compatibility? If we allow overloading, there is no way 
to understand whether a value indicates a “true” priority or something else, 
different implementations may interpret the value in different ways with 
unpredictable results.

It always means a true value from an xTR point of view.

It is the true value because you said so.  The important point however is that 
you decclare that otehr nodes can tell that the advertiser is an RTR from the priority.  
That is adding additional inappropriate, and overloading meaning to the priority.  


I don't know what you mean. The map-server will return RLOCs with priorities. 
The ITR uses them according the spec. There isn't anything more complciated 
than that.

I do not declare that from an ITR point of view. It is true from an ETR point 
of view.

I'm trying to provide clarity and details so the working group understands how 
it works not the motivation for using the solution or why it was chosen.

Dino





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

> Trimmed, In line.
> 
> On 5/24/2023 1:45 PM, Dino Farinacci wrote:
>>> there are a few things to ponder:
>>> 
>>> - Looking at lispers.net the 254 value choice, it looks like a quick hack.
>> I would refer to it as a convienent solution that doesn't violate the spec.
> claiming that this alternative meaning is not a violation is quite a 
> stretch.

As an implementor, it was convienent. I'm not saying anything more than that. I 
should have used an alternative mechanism.

>> 
>>> - What about backward compatibility? If we allow overloading, there is no 
>>> way to understand whether a value indicates a “true” priority or something 
>>> else, different implementations may interpret the value in different ways 
>>> with unpredictable results.
>> It always means a true value from an xTR point of view.
> 
> It is the true value because you said so.  The important point however 
> is that you decclare that otehr nodes can tell that the advertiser is an RTR 
> from the priority.  That is adding additional inappropriate, and overloading 
> meaning to the priority.  

I don't know what you mean. The map-server will return RLOCs with priorities. 
The ITR uses them according the spec. There isn't anything more complciated 
than that.

I do not declare that from an ITR point of view. It is true from an ETR point 
of view. 

I'm trying to provide clarity and details so the working group understands how 
it works not the motivation for using the solution or why it was chosen.

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]

Trimmed, In line.

On 5/24/2023 1:45 PM, Dino Farinacci wrote:

there are a few things to ponder:

- Looking at lispers.net the 254 value choice, it looks like a quick hack.

I would refer to it as a convienent solution that doesn't violate the spec.
claiming that this alternative meaning is not a violation is quite 
a stretch.



- What about backward compatibility? If we allow overloading, there is no way 
to understand whether a value indicates a “true” priority or something else, 
different implementations may interpret the value in different ways with 
unpredictable results.

It always means a true value from an xTR point of view.


It is the true value because you said so.  The important point 
however is that you decclare that otehr nodes can tell that the 
advertiser is an RTR from the priority.  That is adding additional 
inappropriate, and overloading meaning to the priority.  



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

> there are a few things to ponder:
> 
> - Looking at lispers.net the 254 value choice, it looks like a quick hack. 

I would refer to it as a convienent solution that doesn't violate the spec.

> - What about backward compatibility? If we allow overloading, there is no way 
> to understand whether a value indicates a “true” priority or something else, 
> different implementations may interpret the value in different ways with 
> unpredictable results.

It always means a true value from an xTR point of view.

> - What about weight? In the lispers.net NAT traversal it is used as defined 
> in the main specs, but this means that all RTR have the same priority all the 
> time. And what if a future value will indicate not to use weight? Or use it 
> in a different way?  

This solution does not violate the LISP spec on how ITRs/RTRs use priorities 
and weights.

> - With the above we end up having RLOCs priorities that can be priority or 
> something else. In this latter case weight can or cannot be meaningful (or 
> even be something else altogether). Architecturally speaking it looks to me 
> less clean. 

This is simply not true.

I think you are overstating the problem.

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

> The answer to me is RFC 8060. Just use LCAF! The LCAF format has 16 reserved 
> bits. One can be allocated to indicate whether the RLOC address belongs to an 
> RTR.

That could be too specific to this use-case. What an ETR needs to know is if it 
should tag RLOCs it gets back from the map-server in Info-Reply messages with 
this bit.

It actually could not tag it at all since the map-servers know the addresses of 
RTR RLOCs when they advertise them. But that means all map-servers need to have 
the same info and there is configuration coordination required.

> A side benefit of this choice would be that older implementations will just 
> ignore the bit, hence taking no action, rather than interpreting the bit in a 
> different way. Looks like a safer situation to me. You can even use a whole 
> new type, so that an implementation either knows how to handle it or does 
> nothing at all.

No that won't be the case. The way it works is that the RTR will give an 
RLOC-set to the ITR. So the ITR doesn't know if an RLOC is an ETR RTR pETR, 
etc. But the ETR side registeres the RTR RLOCs with 254. That is what is 
implemented today. If the ETR DOES NOT do this the map-server could figure it 
out on its own (as I mention above).

Dino

> 
> Thoughts from the WG folks?
> 
> Ciao
> 
> L.
> 
> 
>> 
>> 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
> 

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

> So... I think it's good to document what people will see in the wild.  A 254 
> priority is probably a good signal that one is dealing with a lispers.net 
> implementation.  To me at least, the goal here should be to permit the 
> documenting of that use.  Documenting that in an RFC seems like a good idea, 
> but publishing such "squatting" in an RFC doesn't seem like a good idea.  So 
> how to move forward?  I'm seeking pragmatic answers to that question.

That is not true. A value of 254 means that the RLOC has a pretty low priority 
in usage. That is, if an ITR receives an RLOC-set with 254 in it, it will use 
it. Note, a lispers.net map-server will return ONLY 254 RLOCs to an ITR in 
which the ITR uses spec rules to decide which one to use.

Also note, the WG cannot say how priorities are used. It is a deployment and 
policy issue for the LISP overlay operater. All the spec says is that 1 takes 
priority over 255 in selecting which RLOCs are used for encapsulation.

The implementation is really NOT violating the spec and the decision of the 
extra semantic meaning on 254 is only in a lispers.net map-server.

Dino


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

So... I think it's good to document what people will see in the wild.  A 
254 priority is probably a good signal that one is dealing with a 
lispers.net implementation.  To me at least, the goal here should be to 
permit the documenting of that use. Documenting that in an RFC seems 
like a good idea, but publishing such "squatting" in an RFC doesn't seem 
like a good idea.  So how to move forward?  I'm seeking pragmatic 
answers to that question.


Eliot

On 24.05.23 14:01, Luigi Iannone wrote:

Errata!


On 24 May 2023, at 13:48, Luigi Iannone  wrote:




On 23 May 2023, at 23:05, Dino Farinacci  wrote:

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.


Dino,



The fact that you use that specific value in a particular way does 
mean that the WG should agree to use priority values to indicate 
other things.


There is a missing NOT.

The right sentence is:

The fact that you use that specific value in a particular way does NOT 
mean that the WG should agree to use priority values to indicate other 
things.


L.



The LISP WG is free to decide to deprecate such usage.



What follows is my personal opinion.

About overloading priority with other meanings:

Having 256 values to define priority is quite large and (according to 
my experience) we can live with a lot less. So from that perspective 
it is not a big deal.


YET

there are a few things to ponder:

- Looking at lispers.net  the 254 value choice, 
it looks like a quick hack.


- What about backward compatibility? If we allow overloading, there 
is no way to understand whether a value indicates a “true” priority 
or something else, different implementations may interpret the value 
in different ways with unpredictable results.


- What about weight? In the lispers.net  NAT 
traversal it is used as defined in the main specs, but this means 
that all RTR have the same priority all the time. And what if a 
future value will indicate not to use weight? Or use it in a 
different way?


- With the above we end up having RLOCs priorities that can be 
priority or something else. In this latter case weight can or cannot 
be meaningful (or even be something else altogether). Architecturally 
speaking it looks to me less clean.


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?
Or in a more general way: How to deliver RLOC-related informations 
that go beyond priority and weight?


The answer to me is RFC 8060. Just use LCAF! The LCAF format has 16 
reserved bits. One can be allocated to indicate whether the RLOC 
address belongs to an RTR.
A side benefit of this choice would be that older implementations 
will just ignore the bit, hence taking no action, rather than 
interpreting the bit in a different way. Looks like a safer situation 
to me. You can even use a whole new type, so that an implementation 
either knows how to handle it or does nothing at all.


Thoughts from the WG folks?

Ciao

L.




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





___
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

[Luigi Iannone]

Errata!

> On 24 May 2023, at 13:48, Luigi Iannone  wrote:
> 
> 
> 
>> On 23 May 2023, at 23:05, Dino Farinacci  wrote:
>> 
>>> 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. 
> 
> Dino,
> 
> 
> 
> The fact that you use that specific value in a particular way does mean that 
> the WG should agree to use priority values to indicate other things.

There is a missing NOT.

The right sentence is:

The fact that you use that specific value in a particular way does NOT mean 
that the WG should agree to use priority values to indicate other things.

L.


> The LISP WG is free to decide to deprecate such usage.
> 
> 
> 
> What follows is my personal opinion.
> 
> About overloading priority with other meanings:
> 
> Having 256 values to define priority is quite large and (according to my 
> experience) we can live with a lot less. So from that perspective it is not a 
> big deal.
> 
> YET 
> 
> there are a few things to ponder:
> 
> - Looking at lispers.net  the 254 value choice, it looks 
> like a quick hack. 
> 
> - What about backward compatibility? If we allow overloading, there is no way 
> to understand whether a value indicates a “true” priority or something else, 
> different implementations may interpret the value in different ways with 
> unpredictable results.
> 
> - What about weight? In the lispers.net  NAT traversal 
> it is used as defined in the main specs, but this means that all RTR have the 
> same priority all the time. And what if a future value will indicate not to 
> use weight? Or use it in a different way?  
> 
> - With the above we end up having RLOCs priorities that can be priority or 
> something else. In this latter case weight can or cannot be meaningful (or 
> even be something else altogether). Architecturally speaking it looks to me 
> less clean. 
> 
> 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? 
> Or in a more general way: How to deliver RLOC-related informations that go 
> beyond priority and weight?
> 
> The answer to me is RFC 8060. Just use LCAF! The LCAF format has 16 reserved 
> bits. One can be allocated to indicate whether the RLOC address belongs to an 
> RTR.
> A side benefit of this choice would be that older implementations will just 
> ignore the bit, hence taking no action, rather than interpreting the bit in a 
> different way. Looks like a safer situation to me. You can even use a whole 
> new type, so that an implementation either knows how to handle it or does 
> nothing at all.
> 
> Thoughts from the WG folks?
> 
> Ciao
> 
> L.
> 
> 
>> 
>> 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
> 

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

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

[Luigi Iannone]

> On 23 May 2023, at 23:05, Dino Farinacci  wrote:
> 
>> 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. 

Dino,



The fact that you use that specific value in a particular way does mean that 
the WG should agree to use priority values to indicate other things.
The LISP WG is free to decide to deprecate such usage.



What follows is my personal opinion.

About overloading priority with other meanings:

Having 256 values to define priority is quite large and (according to my 
experience) we can live with a lot less. So from that perspective it is not a 
big deal.

YET 

there are a few things to ponder:

- Looking at lispers.net  the 254 value choice, it looks 
like a quick hack. 

- What about backward compatibility? If we allow overloading, there is no way 
to understand whether a value indicates a “true” priority or something else, 
different implementations may interpret the value in different ways with 
unpredictable results.

- What about weight? In the lispers.net  NAT traversal it 
is used as defined in the main specs, but this means that all RTR have the same 
priority all the time. And what if a future value will indicate not to use 
weight? Or use it in a different way?  

- With the above we end up having RLOCs priorities that can be priority or 
something else. In this latter case weight can or cannot be meaningful (or even 
be something else altogether). Architecturally speaking it looks to me less 
clean. 

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? 
Or in a more general way: How to deliver RLOC-related informations that go 
beyond priority and weight?

The answer to me is RFC 8060. Just use LCAF! The LCAF format has 16 reserved 
bits. One can be allocated to indicate whether the RLOC address belongs to an 
RTR.
A side benefit of this choice would be that older implementations will just 
ignore the bit, hence taking no action, rather than interpreting the bit in a 
different way. Looks like a safer situation to me. You can even use a whole new 
type, so that an implementation either knows how to handle it or does nothing 
at all.

Thoughts from the WG folks?

Ciao

L.


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

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