Re: [lisp] Draft LISP Geo-Coordinate Use-Cases

[Joel Halpern <[e-mail]>]

Thanks Luigi.  I agree, the fact that some pre-standard implementations 
chose to change the meaning of a code pint does not make them correct.

Yours,

Joel

On 4/26/2024 7:52 AM, Luigi Iannone wrote:
> Hi,
>
> I think that the answer to the “why” question is easy. The new 
> encoding is the same as for BGP/ISIS/OSPF, so it makes sense to use it.
>
> The problem lays in the “type” value that this new encoding is using.
>
> The document should ask IANA to allocate a new code point. Values 
> 4/8/14-254 are unassigned as for: 
> https://www.iana.org/assignments/lisp-parameters/lisp-parameters.xhtml#lisp-lcaf-type
> The document can suggest a value, but not impose one (See section 9.3 
> RFC8126).
> An early allocation should also be possible according to RFC7120.
> Hence, the argument that by changing the type value implementations 
> are obsoleted does not hold.
>
> The WG can decide whether to deprecate the encoding proposed in 
> RFC8060 or let it run in parallel.
> If we deprecate the encoding in RFC8060 then this document has to 
> update RFC8060.
> (My personal opinion is that there is no usefulness in having two 
> different encodings)
>
> The fact that both geo encodings use type 5 is the real issue to me.
> Deprecating the encoding in RFC8060 does not help since there is no 
> way to make the difference and know, by looking at the type, which 
> encoding is used.
> Section 9.4 of RFC8126 discourages reclaiming values for other usage 
> except when the namespace is (almost) exhausted, which is not the case 
> here.
>
> As for the implementations… more than the number of implementations 
> what really matters is the deployments.
>
> Can anyone state that there are no deployments using RFC8060 encoding? 
> Or if they exist if it is feasible to quickly and easily switch them 
> to the new encoding.
>
> In the lack of these conditions the only reasonable action IMO is to 
> use a different type value.
>
> Ciao
>
> L.
>
>
>
>
>
>> On 23 Apr 2024, at 18:24, Joel Halpern <[e-mail]> wrote:
>>
>> From where I sit, doing nothing should be a non-starter.  We have a 
>> published RFC.  We are allowed to change our mind.
>>
>> But...
>>
>> 1) We need to be explicit about making such a change. Which involves 
>> updating the existing RFC.
>>
>> 2) Any such change needs to explain why it is being changed. Just 
>> because a later implementation did it differently, without a 
>> standard, does not justify changing the standard.  If there is an 
>> actual benefit to the change we should step up, admit we are changing 
>> it, and explain why.
>>
>> Yours,
>>
>> Joel
>>
>> On 4/23/2024 11:48 AM, Dino Farinacci wrote:
>>>> As I said, the simplest solution is to use a different type value. 
>>>> This allows to still use the old encoding and does not obsoletes 
>>>> implementations that use it.
>>> You will obsolete implementations if we do that. Which really means 
>>> you make the spec irrelevant. So I say stay with the same code point.
>>>
>>>> Option B. This document officially updates 8060, but this means 
>>>> that existing implementation of the 8060 encoding are not valid 
>>>> anymore.
>>> Right. But so much time has passed between from when the lisp-geo 
>>> spec was published I believe most implementations have done lisp-geo 
>>> encoding vs RFC 8060. My lispers.net implementation does the 
>>> lisp-geo encoding with the type defined in the draft which is the 
>>> same as RFC 8060.
>>>
>>>> How many implementation of this draft are you aware of?
>>> I think cisco and lispers.net. But cisco has to confirm.
>>>
>>> I think we should do Option C which is do nothing to RFC 8060 and 
>>> put text in the lisp-geo spec which indicates its encoding takes 
>>> precedent over RFC 8060 using the same code point and document all 
>>> implementations have evolved to the lisp-geo spec.
>>>
>>> Dino
>>>
>>>
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>