Re: [lisp] LISP EID Block Size (Noel Chiappa) Thu, 31 October 2013 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E64D121E808D for <>; Thu, 31 Oct 2013 10:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.522
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e9vGZVeEPHu5 for <>; Thu, 31 Oct 2013 10:08:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9B4A011E8179 for <>; Thu, 31 Oct 2013 10:08:18 -0700 (PDT)
Received: by (Postfix, from userid 11178) id 385BC18C124; Thu, 31 Oct 2013 13:08:18 -0400 (EDT)
Message-Id: <>
Date: Thu, 31 Oct 2013 13:08:18 -0400 (EDT)
From: (Noel Chiappa)
Subject: Re: [lisp] LISP EID Block Size
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2013 17:08:30 -0000

    > From: Dino Farinacci <>

    > 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.