> 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
