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

Dino Farinacci <farinacci@gmail.com> Fri, 02 October 2020 15:22 UTC

Return-Path: <farinacci@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B9D3A10AB for <lisp@ietfa.amsl.com>; Fri, 2 Oct 2020 08:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbXtqhDfqEi3 for <lisp@ietfa.amsl.com>; Fri, 2 Oct 2020 08:22:13 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E6F3A10D3 for <lisp@ietf.org>; Fri, 2 Oct 2020 08:22:13 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id o25so989088pgm.0 for <lisp@ietf.org>; Fri, 02 Oct 2020 08:22:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3KN0uOfsspythTe0PkPsChxEqrzfrtFPO6dVIoZo+5g=; b=npXYWS+9kg9eNvwPG2wh/yICN+4bYzPU46/U5BOwnOVWaloQM4mRTrHwrGHV8L2roO tV86RyiYRLhRlxXRr5PfaRFku613S4f8hgnjeDvOFUTWCWnt2KbwoVl7KbbUWpbTdRAq DBJ+pf29mtjCo1vFAOmB6FLSJUaoFpwKYroKD1DuVb4ZBMq3uz3n2CnDsaLzT4s1axRf ZaLLGCRnkOTmnu1oqUF8tNBxZSNrJ0CBaSAg1TEW5dKeeNHXc9986Hr+zXSwhI80lFou mBDQvlnKdjgFW57M+9BOXXf/FDNxKaL4ZGWYTVJLvfMPp9qIGovEhhSS2qVCPaub/8Sa T+Ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3KN0uOfsspythTe0PkPsChxEqrzfrtFPO6dVIoZo+5g=; b=qTertcYRgsu5vZcX/2YPGKIm6/BR+QoCnxElCGxCacuYHMobfwDC1hfjKqTqWMI2dP j0vCNLpry4iqYR+egP0U/f3102J0IOjaZiy+qmOJXzMAucfRgmD5PkBPxjpRild5Q2bd nH6jE5mZfl/MtjnBiPmRttXE4Pn7fdDgr65Xzt840vGq3D+sdy1/JAnL6cUNqZ/Sq6pR 3tBIy3de6X/Pc0Oku2R7wpT4w2mp8pxE/eHZmGqD05XUPFJzoEF5Pawn0XWDFF9pkuXI Rd/fP9dl1KMJ/Pvm6Y796EkcvVUh3vxH5h/EJ8fkkvBrqqqsXmnuzqyxIEzKxwoI4K/X 6dWQ==
X-Gm-Message-State: AOAM531N+idgkaCLJGyQvM5GY0TFP467NJk6PIsrk4R+OdeVSA08qTDH QlaUIon/j1+u5E39pbnrE7c=
X-Google-Smtp-Source: ABdhPJw80Oep63kbypJAKQuOoMsdcMr1tVArP6Vdr1IKGYJmqgJlwbMiqK+obHcrU+D9o+cJYCeGaA==
X-Received: by 2002:a62:26c1:0:b029:142:2501:35ef with SMTP id m184-20020a6226c10000b0290142250135efmr3215033pfm.79.1601652131264; Fri, 02 Oct 2020 08:22:11 -0700 (PDT)
Received: from ?IPv6:2601:646:9600:af10:38a8:c2c2:4a71:75aa? ([2601:646:9600:af10:38a8:c2c2:4a71:75aa]) by smtp.gmail.com with ESMTPSA id 16sm1873777pjl.27.2020.10.02.08.22.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Oct 2020 08:22:10 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <18C66CDF-7714-4258-9D0C-EF4E5CEBC438@gigix.net>
Date: Fri, 02 Oct 2020 08:22:08 -0700
Cc: "Joel M. Halpern" <jmh@joelhalpern.com>, "lisp@ietf.org list" <lisp@ietf.org>, Dino Farinacci <farinacci@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C85A0223-83A1-498B-A3BD-C878E73CB462@gmail.com>
References: <921b82e9-ea40-bab9-eb3e-809375528741@joelhalpern.com> <88FFF16F-1E5F-4B41-B4A1-D3E02750F9BA@gmail.com> <18C66CDF-7714-4258-9D0C-EF4E5CEBC438@gigix.net>
To: Luigi Iannone <ggx@gigix.net>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/aLZGA47evxkQAd749jkUgCCogfQ>
Subject: Re: [lisp] Request for WG document - draft-farinacci-lisp-name-encoding
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2020 15:22:14 -0000

> 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