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

["Joel M. Halpern" <[e-mail]>]

On what basis would the mapping system decide if a full match or prefix 
match is appropriate?  So far, each EID has been specific on what kind 
of lookup it does.  IP (v4 or v6) lookups always do LPM lookups.  All 
other EIDs we have specified so far do exact matches.

Yours,
Joel

On 10/2/2020 11:22 AM, Dino Farinacci wrote:
>> The document looks to me underspecified.
> 
> I'm sorry, it is completely specified. I'll respond to a subjective comment with a subjective reply.
> 
>> There is no formal definition of “Distinguished Name”, for what is worth the document can be renamed "LISP LCAF String encoding”
> 
> I provided a reference in the document to th Address-Family-Identifiers document. Where it is listed. That creates the code point. And this document says how LISP will use AFI=17.
> 
>> The slides you presented during IETF 96 suggest that there some longest characters match (like longest prefix match but on strings) and this part is not documented in the draft.
> 
> You can do partial match lookups on strings. If a distinguished-name "luigi" is registered as an EID to the mapping system, and a lookup is done on "luigi-iannone", the map-server can decide if partial or exact matches are performed. I can make this more clear in the document.
> 
>> As an implementer, the fact that there is no explicit length field is worrisome, performance wise.
>> Because if I need to skip through a LCAF AFI=17 record I have anyway to parse the string since I do not know where it ends.
>> This can slow down operations.
> 
> Zero termination of the string creates the length for implementation that can support AFI=17. For implementation that do not, it uses the EID mask-length to skip over an EID in an EID-record. For RLOC-records if you don't understand an AFI, you drop the packet.
> 
>> I think the draft should include some specific use cases that prove that LCAF strings are really useful.
> 
> Strings are useful. How they are encoded is another topic.
> 
>> The ECDSA use case is not a compelling example since you can use LCAF AFI=XX that identifies public keys encoded in a specific way (the WG should think about proposing such encoding….)
> 
> That makes name uses more bytes in the packet. We want to encode a string of length 5 in 8 bytes. 2 bytes for AFI and 1 byte null-character. You can encode it more efficicently than that. And that is why AFI=17 was chosen.
> 
> Dino
> 
> 
>