Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
See previous emails. > How many implementations are using RFC 8060 and will be impacted? That’s too general a question because there are many use-case codepoints in it. I have to look at my notes I think there were other pending updates to RFC 8060. Dino ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
> On Apr 23, 2024, at 09:25, Dino Farinacci wrote: > > My preference is to update RFC 8060. > How many implementations are using RFC 8060 and will be impacted? Thanks Padma > Dino > >> On Apr 23, 2024, at 12:24 PM, Joel Halpern 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 ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
My preference is to update RFC 8060. Dino > On Apr 23, 2024, at 12:24 PM, Joel Halpern 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
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
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
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
> 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
Re: [lisp] Draft LISP Geo-Coordinate Use-Cases
Hi Dino, > On 23 Apr 2024, at 00:57, Dino Farinacci wrote: > >> P.s. >> >> Just noticed that this document proposes an encoding which is not the same >> as the one in RFC 8060 but use the same type number. > > That is right, we chose a format consistent with the IGPs so RFC8060 has to > updated. I made this clear when the change was made. > > Since so much time passes since we are not being productive, the same > arguments resurface years later. And its getting harder and harder for people > to remember and keep context. > > So should I submit a change to RFC 8060 and call it RFC 8060bis? You can, but this will slow down the publication of this draft because of the dependency. 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. Option B. This document officially updates 8060, but this means that existing implementation of the 8060 encoding are not valid anymore. > >> This is not possible. The best solution would be to use a different type >> number. > > The implementations use the latest in the draft. > How many implementation of this draft are you aware of? Ciao L. >> On 22 Apr 2024, at 13:23, Luigi Iannone wrote: >>> >>> Dino, >>> >>> You did put a reference to other protocols in the acknowledgement section. >>> This is not enough. >>> >>> You should put a sentence like: >>> >>> The encoding format is consistent with the encoding used in other routing >>> protocols, namely: OSPF [I-D.acee-ospf-geo-location], IS-IS >>> [I-D.shen-isis-geo-coordinates], and BGP [I-D.chen-idr-geo-coordinates] >>> protocols. > > I will add. Thanks for the text. > >>> This sentence should be placed at the end of section 5, where you describe >>> the encoding. > > Okay. See diff enclosed. > > Dino > > > > > > > >>> >>> Ciao >>> >>> L. >>> >>> >>> On 18 Apr 2024, at 17:19, Dino Farinacci wrote: You have to judge that. We do have references that point to ISIS and OSPF. Dino > On Apr 18, 2024, at 8:14 AM, Luigi Iannone wrote: > > > >> On 18 Apr 2024, at 16:19, Dino Farinacci wrote: >> >> LISP geo-location decided to use the encoding format consistent and >> coordinated with the routing protocols. >> > > Is this clearly state in the document? > > L. > >> Dino >> >>> On Apr 17, 2024, at 11:59 PM, Padma Pillay-Esnault >>> wrote: >>> >>> Hello Dino and Alberto >>> >>> The Yang Doctor review had comments on Yang -20 draft regarding the >>> geoloc. >>> For reference comment from Joe Clark >>> As to the two questions asked here, I can see some benefit of breaking >>> out the IANA parts of address-types into a module that they maintain. >>> But in its current form, I don't know that it makes sense to have them >>> maintain it. As for geoloc, I do see some overlap, but I am not a LISP >>> expert at all, so I cannot comment as to whether bringing that whole >>> module in makes sense or would even work with LISP implementations. >>> That is, it seems LISP lat and long are expressed in degrees° >>> minutes'seconds" whereas geoloc does this as a decimal64 from a >>> reference frame. I do feel that whatever direction is taken, text >>> explaining why geoloc is not used is useful. >>> >>> Per Med's comment on groupings - >>> https://mailarchive.ietf.org/arch/msg/lisp/lJ7jBJzjJNY2P4sQgCcLuSnnzds/ >>> >>> Consolidating these comments in a single thread here for resolution and >>> discussion on the list before the refresh, >>> >>> Thanks >>> Padma and Luigi >>> >>> >>> >>> >>> >>> > >>> >> > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
