If you want to define it as always doing a strict LPM string match on
ASCII,that would as you say be well-defined. It is not what the
document says.
And it would not solve the collision problem at all.
Yours,
Joel
On 10/2/2020 2:44 PM, Dino Farinacci wrote:
The design of LISP explicitly separates the Mapping system from the Itr/EtR. Which
means that the "IT Manager configuring xTRs) does not get to define how the
mapping system works.
Right, agree, and I didn't say that.
And if there are undefined variations in how it works for AFI=17, then we have
not achieved interoperability.
There isn't. It works exactly like an IPv4 or IPv6 lookup.
And if there are potential interactions between different uses of AFI=17, then
we again have a problem.
There isn't for a given use-case within a given instance-ID. Just like VLANs,
VRFs, etc. We are not inventing anything new here. We solely want to encode
ascii strings.
If you want to define that AFI-17 is always and only used along with
instance-ID, then you solve PART of the problem. But not all
Its an EID encoding that can or not go inside an Instance-ID LCAF. And when
used as an RLOC, there is no instance-ID relationship.
of it. If different uses of the AFI clash, then we are creating problems even
for a single adminstration using it under a single instance.
IP addresses can clash. We use the same rules for avoiding IP EID clashes as
AFI=17 clashes. I mentioned this already in a previous email to you.
And from where I sit, the LISP working group is not chartered to provide a
generic string based key-value store.
Look at it this way. Should the IS-IS working group not create hostnames to map
LSPIDs to names? Allowing this makes it infinitely simpler to manage the system.
This proposal is extremely popular. Ask network operators about IS-IS
hostnames. This is the same thing. It really is.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
