> KT2> Let me take a step back. Getting Geo-Prefixes in EID and RLOC records
> looks to me as a protocol specification and not a use-case. Making map
> requests for these records and the map server returning the information
> (using physical
This is true.
> distance) is also a protocol behavior specification - not a use-case.
> Therefore, I find all of this being under a "use-case" section as misleading
> and I am checking why this isn't covered as a specification - beyond just the
> encoding.
Well we are specifying how to use it for this specific use-case. I would like
to leave it as is.
> Furthermore, "there are geo libraries that compute" does not seem to fully
> specify how this works - we'll need some
The requirement how to use distance and other GPS related mechanisms is left to
the implementation. And if we wanted to give these examples, we could with a
high-level description vs documenting the math (which would be a duplicate of
other information elsewhere). I'd rather not go down a slippery slope.
> references that point to how this calculation works or it can be specified
> inline. Are there any interoperability considerations here if different
> components of the LISP control plane were to interpret or compute these
> distances in a different way?
I have not found any testing the lispers.net <http://lispers.net/>
implementation with the cisco implementation.
> > KT> That text change looks good to me. However, the justification of
> > changing the encoding that was in RFC8060 is not captured in this document
> > and that is what I am looking for. The point of consistency with other
> > protocols is moot (IMHO) since they don't exist today and those protocols
> > might as well use RFC8060 encoding (if/when someone really picks that up)
> > if consistency is all that we need. I hope you get my point.
>
> It is beacuse we added more features to the encoding. Like cm granularity and
> radius to support Geo-Prefixes. ZSo the 8060 version is obsolete and hence we
> created a new code point in this document.
>
> KT> Great. Could you please also add that as the reason for making the change
> over proposal in RFC 8060 (as opposed to the current consistency argument
> across routing protocols)?
We did in the Introduction section:
Dino
_______________________________________________
lisp mailing list -- lisp@ietf.org
To unsubscribe send an email to lisp-le...@ietf.org
