Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

jnc@mercury.lcs.mit.edu (Noel Chiappa) Fri, 16 November 2012 14:00 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B941C21F8485; Fri, 16 Nov 2012 06:00:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.603
X-Spam-Level:
X-Spam-Status: No, score=-6.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkCNJ-GrOjcD; Fri, 16 Nov 2012 06:00:23 -0800 (PST)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED9921F847F; Fri, 16 Nov 2012 06:00:23 -0800 (PST)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id F2C2618C095; Fri, 16 Nov 2012 09:00:21 -0500 (EST)
To: ietf@ietf.org, lisp@ietf.org
Subject: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
Message-Id: <20121116140021.F2C2618C095@mercury.lcs.mit.edu>
Date: Fri, 16 Nov 2012 09:00:21 -0500
From: jnc@mercury.lcs.mit.edu
Cc: jnc@mercury.lcs.mit.edu
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Nov 2012 14:00:23 -0000

    > From: <rogerj@gmail.com>

    > the routing integration between none-LISP and LISP internet, how are
    > that going to work? The current document isn't clear enough on that as
    > I see it.

The way the routing will work would take a couple of PhD theses to fully
cover (I know of one that's already underway). So it's not really a topic
that can be covered in this ID.

Adding to the complexity is that if LISP becomes widely deployed, how the
routing works will likely change over time; in the early stages, when there
are small islands of LISP, it'll be one thing; later on, when there are
islands of legacy stuff, it'll be totally different. Etc, etc.

    > Address these thing somehow in the document, even just mention that
    > it's subject for other document and I'm happy... :-)

The IETF used to have this concept of 'rough consensus and _running code_';
i.e. we tried stuff out to see if it works. When did we change into an
organization that had to have every 'i' dotted, and every 't' crossed, before
we could move an inch? (Saying 'just refer to the document where it is
covered' doesn't help, if the other document isn't written yet.)

All this ID is trying to do is allocate a rather modest chunk (~ one quarter
of one tenth of one percent - .025% - if I've done the math right) of address
space for an experiment; exactly how it will be best used, and what the best
allocation process is, is to some degree part of that experiment.

	Noel