[lisp] LCAF

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 13 September 2013 07:51 UTC

Return-Path: <jmh@joelhalpern.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 A948A11E815C for <lisp@ietfa.amsl.com>; Fri, 13 Sep 2013 00:51:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P1c5+-9H2Y9 for <lisp@ietfa.amsl.com>; Fri, 13 Sep 2013 00:51:11 -0700 (PDT)
Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) by ietfa.amsl.com (Postfix) with ESMTP id 9645721E8097 for <lisp@ietf.org>; Fri, 13 Sep 2013 00:51:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 2D076661A60 for <lisp@ietf.org>; Fri, 13 Sep 2013 00:51:02 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id A3DF4661A5F for <lisp@ietf.org>; Fri, 13 Sep 2013 00:51:01 -0700 (PDT)
Message-ID: <5232C3E4.2000207@joelhalpern.com>
Date: Fri, 13 Sep 2013 03:51:00 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "lisp@ietf.org" <lisp@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [lisp] LCAF
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 13 Sep 2013 07:51:30 -0000

I was reminded in recent discussion that the LCAF AFI is allowed both 
for RLOCs and for EIDs.

For RLOCs, I have raised the concern that when an ETR injects RLOCs 
using various LCAFs, it has no way to know whether the receiving ITRs 
will be able to understand the LCAF.  For some cases, this is actually a 
benefit.  But particularly if the structure within the LCAF gets more 
diverse, it seems to get difficult.  I do see the argument for 
flexibility here.

But then my naive participant head exploded when I tried to apply this 
to an EID.  Are all mapping systems required to handle all LCAFs?  At 
first, this seems reasonable.  As long as you are just doing pure prefix 
matching, it is just a variable length "address".

But then we see things which have internal mask lengths.  Or might need 
prefixing on multiple fields.  Or might have even more complex match 
criteria.

If the mapping system can always treat and LCAF EID as a prefix-matched 
bit string, I get it.  But if not, how is this supposed to work?

Sorry for a basic question,
Joel