Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding

[Dino Farinacci <[e-mail]>]

> Looking again at this draft, and at the example Dino points to, I think there is a basic problem with the work and the usage.
> 
> the problem is not a problem for the mapping system per se.  It is a problem for usage.
> 
> The draft does not define any mechanism for structuring, allocating, or otherwise managing the space of names.  It does not say "URIs".  It does not say "DNS names"  It syas "ASCII string, terminated by 0".

Because it is designed as a non-structured field where a deployment can decide what the structure is based on the mapping system it uses, or the instance-ID within a mapping system it uses.

The draft’s intent is to define a general encoding for LISP messages. How it will be used is left to other documents.

> If there is to be standard usage of this, and if there is to be more than one such usage, how are collisions avoided?  It is not sufficient to say "just don't" as different problems may end up needing overlapping name spaces.  The hash usage (below) assumes that the solution is to prepend the string "hash:' on the front.  But that is not formally defined, and as such is not actually a reliable mechanism.
> (Frankly, for the hashes I would prefer to use a different EID LCAF that carries the binary hash.)

The ecdsa-auth use-case assumes that the hash length is largest where collisions won’t happen. There are applications that use UUIDs and encodes them in distinguished-name EIDs. UUIDs do not have an allocation authority. And:



> I suspect that the people supporting this have expectations on how this will work.  But it seems sufficiently basic that the semantics, rather than the encoding, is where I would expect the WG to start.  Encodings are easy.

So lets have a look at each Internet Draft that references draft-farinacci-lisp-name-encoding and lets review those semantic encodings.

For draft-farinacci-lisp-simple-nat-00, the RLOCs are encoded with human readable RLOC-names so you can distinguish a multi-homed interface through NATs. That has proved useful for my lispers.net implementation.

> I will also acknowledge that as chair I have concerns about turning LISP into an arbitrary database system.  Our charter is a mapping system in support of routing.  I understand why the ECDSA keys need to be in there.  But I do not want to fall into the BGP trap of trying to solve every problem with the hammer in my hand.

I could encode anything I want in an IPv6 EID and make the LISP mapping system an arbitrary database. I don’t think anyone wants to do this. The mapping system is used for routing, addressing, identity, and location problems (at the network layer).

Dino