IETF Logo Mail Archive

Re: [lisp] LISP EID Block Size

jnc@mercury.lcs.mit.edu (Noel Chiappa) Thu, 31 October 2013 17:08 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 E64D121E808D for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 10:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.522
X-Spam-Level:
X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 e9vGZVeEPHu5 for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 10:08:24 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4A011E8179 for <lisp@ietf.org>; Thu, 31 Oct 2013 10:08:18 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 385BC18C124; Thu, 31 Oct 2013 13:08:18 -0400 (EDT)
To: lisp@ietf.org
Message-Id: <20131031170818.385BC18C124@mercury.lcs.mit.edu>
Date: Thu, 31 Oct 2013 13:08:18 -0400
From: jnc@mercury.lcs.mit.edu
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 17:08:30 -0000

    > From: Dino Farinacci <farinacci@gmail.com>

    > We are not saying this entire block is being used for global deployment
    > of LISP.  And no one is saying LISP can't succeed without this block.
    > ...
    > It does not mean that the current forwarding paradigm does not work
    > or cannot work.
    > We must not and will not require reassignment of addresses to use
    > LISP. ... existing allocations and futures allocations can be EIDs.

These are all _really_ excellent points, and the document should make them
clearly, and at the top. (Sorry if it already does this - haven't read any
recent versions, too busy.) And also the point about how the special prefix
is not going to be the way we determine whether an address is an EID.

    > An address becomes an EID when it no longer is advertised by an edge BGP
    > router (from a tail or stub portion of the Internet topology).

Minor quibble, because I prefer the 'is there a mapping available' as the
'gold standard' test for EID-ness.

For backward compatability with 'legacy' hosts, many EIDs _are_ advertized
into the global routing (either by the ETR, or a PITR, etc), so 'in/not-in
the global routing table' doesn't tell us much about EID-ness.

   Noel

v2.23.0 | Report a Bug | By Email