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 <j...@joelhalpern.com> 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
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
