IETF Logo Mail Archive

Re: [lisp] LISP EID Block Size

Dino Farinacci <farinacci@gmail.com> Thu, 31 October 2013 23:14 UTC

Return-Path: <farinacci@gmail.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 2370A11E81E6 for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 16:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level:
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 sKr45Z+qPuAs for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 16:14:10 -0700 (PDT)
Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B798E21E8119 for <lisp@ietf.org>; Thu, 31 Oct 2013 16:14:09 -0700 (PDT)
Received: by mail-oa0-f42.google.com with SMTP id k14so3886310oag.15 for <lisp@ietf.org>; Thu, 31 Oct 2013 16:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QPIfXEWGYj+2h/sEIiAUJLModi/bK+xXVvIpmMq/mA0=; b=rRMGUXmlYL0XKgkM0BASVmz0e3vp8z3Na0i7i3gFpdzltBsOSpM5P7cJSV2Wd/pnoI ysjR09Ga3bvcHXewKoj8kQQ+efTQh6QhzsIH5SabAExABGoiPa7/+bF7XCVlR8rMuQu3 1FvWS/JDeaex1tGi6+zBdCBLFSL+gr54DzKlBIG6u9/7T34VVRpz2riWAqa8ve8E6R+k TJDMYE5tQnUEOLC7Bj2U6wcnKFk483ntDJrc8UUuMQd7TOtwGlxaWBftXWb5aMGqTgSo G4yHtDfeQNh5jUhcQrNZGrBIuSCRC/Sb9OH79pLqkV4Zf4dUxwrizmKbefcT6H9UohBo h3tg==
X-Received: by 10.182.104.36 with SMTP id gb4mr117682obb.43.1383261249177; Thu, 31 Oct 2013 16:14:09 -0700 (PDT)
Received: from [10.199.255.71] (mobile-198-228-197-188.mycingular.net. [198.228.197.188]) by mx.google.com with ESMTPSA id eg8sm9417079obd.6.2013.10.31.16.14.08 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 31 Oct 2013 16:14:08 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Dino Farinacci <farinacci@gmail.com>
X-Mailer: iPhone Mail (11B511)
In-Reply-To: <20131031170818.385BC18C124@mercury.lcs.mit.edu>
Date: Thu, 31 Oct 2013 19:14:09 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <20B68DD5-C6AF-4930-B7D0-EEB879BE3F52@gmail.com>
References: <20131031170818.385BC18C124@mercury.lcs.mit.edu>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Cc: "lisp@ietf.org" <lisp@ietf.org>, "jnc@mercury.lcs.mit.edu" <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 23:14:11 -0000

Agree Noel. You must have a mapping as well. If you don't have a mapping registered and there is no route in the underlying, then the EID is not usable. 

If both are in each system, then it depends on ITR behavior which is used. 

Dino

On Oct 31, 2013, at 1:08 PM, jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote:

>> 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
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

v2.8.7 | Report a Bug | By Email