Re: [lisp] LISP EID Block Size

jnc@mercury.lcs.mit.edu (Noel Chiappa) Thu, 31 October 2013 22:21 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
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 EAE5B11E8254 for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 15:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.527
X-Spam-Level:
X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 M8+r+kZGShXW for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 15:21:05 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id E3C5F11E8244 for <lisp@ietf.org>; Thu, 31 Oct 2013 15:21:04 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1999F18C180; Thu, 31 Oct 2013 18:21:04 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20131031222104.1999F18C180@mercury.lcs.mit.edu>
Date: Thu, 31 Oct 2013 18:21:04 -0400 (EDT)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [lisp] LISP EID Block Size
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: Thu, 31 Oct 2013 22:21:22 -0000

    > From: George Michaelson <ggm@algebras.org>

    > code should be written to be agile and be able to be TOLD what prefix
    > is the magic prefix. Nobody should be reifying prefixes into anything

That path makes sense if there's a good chance the experiment is going to
succeed, and the code is going to wind up going into service.

If not, though, you're mandating that _other people_ have to spend more of
their engineering time writing code that's basically totally irrelevant to the
experiment at hand. Hopefully needless to say, you wouldn't like it if other
people started allocating _your_ engineering time in ways that made sense to
them.

But that's not the worst problem with your proposal:

    > And work the experiment in a /32

Let's suppose the experiment is a success (i.e. your suggested coding
investment will have paid off). If a /32 is allocated, you've basically now
mandated that there's going to have to be a flag day, or something, to
transition from the /32 to some more suitable space. That's going to be a
massive hassle.


Look, you can't have it both ways. Your 'make the code flexible' concept only
makes sense if this experiment is going to succeed - but if it succeeds,
allocating such a small prefix is guaranteeing a massive operational headache
down the line.

	Noel