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
