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

Roger Jørgensen <rogerj@gmail.com> Fri, 16 November 2012 11:57 UTC

Return-Path: <rogerj@gmail.com>
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 1EA6921F893C; Fri, 16 Nov 2012 03:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 JPovIDKDwfLf; Fri, 16 Nov 2012 03:57:34 -0800 (PST)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A197721F8524; Fri, 16 Nov 2012 03:57:33 -0800 (PST)
Received: by mail-wi0-f178.google.com with SMTP id hm14so1494388wib.13 for <multiple recipients>; Fri, 16 Nov 2012 03:57:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HlfwgW+KVPE5fz7Uo97DepTITgjWfd8Ld9aMCN/+ZHM=; b=AoMzRppe3xOO5UunmuE9HtlRzQ9mIvA48CDrsrBMh1vOO31PyY7b3gI0a+VbBiSSED yTKzAOVKX8MuHX/ZuieDMGSIPemEq9l+KPT1JoLwa77CTZgeeH6MdVzfibp8Fofw2xPN bbIdhB1eOBF52/tAhf9MgVuykUujRVNYtV5GA+Cc1Y6t4iCDTDlW5qFaFOMTB03yR05r zz08tKv7qQBt/DEBw0WkZ696K/5IAnlyNXrvj+xIHl0F5BPmnJmcrW9ibrSiQ7ExXcFr xhuGuNugfFapjQQ5gdhLnHFK9isu8m3zKrjehd9T9WvX0F3fspL/LR+Ry5sgRLxZMVAo oDjQ==
MIME-Version: 1.0
Received: by 10.180.19.197 with SMTP id h5mr4698792wie.22.1353067052713; Fri, 16 Nov 2012 03:57:32 -0800 (PST)
Received: by 10.217.83.4 with HTTP; Fri, 16 Nov 2012 03:57:32 -0800 (PST)
In-Reply-To: <20121113144545.12836.71935.idtracker@ietfa.amsl.com>
References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com>
Date: Fri, 16 Nov 2012 12:57:32 +0100
Message-ID: <CAKFn1SF4+k5gWip-WBNfbjt-qAafPbTSY8L_EBLA9Pqvbw4=kQ@mail.gmail.com>
Subject: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
From: Roger Jørgensen <rogerj@gmail.com>
To: ietf@ietf.org, lisp@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
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 11:57:35 -0000

On Tue, Nov 13, 2012 at 3:45 PM, The IESG <iesg-secretary@ietf.org> wrote:
>
> The IESG has received a request from the Locator/ID Separation Protocol
> WG (lisp) to consider the following document:
> - 'LISP EID Block'
>   <draft-ietf-lisp-eid-block-03.txt> as Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2012-11-27. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.


I think LISP is an important factor in the future of Internet and I do
support the idea of having different IP block for LISP based network.

However, I can not support the publication of this document, it has
some unclear issues that need good answers first.



Anyhow, I see two issues that need to be addressed better

1.) How should the address space be administrated, RIR structure or
something else closer to 6bone? I support the suggested idea of
discussing this part with the different RIRs to look more into how
this are going to work in practice.
And as Dino said, "No, I am not making any assumptions either way. How
allocation gets done is subject to more work." the document should
state this.




2.) The interaction between none-LISP and LISP Internet. This problem
has two sub-problems within it

a.) Why is there a need for a special LISP block. This is partly
answered in section 3.  Rationale and Intent. Is this the entire
reason?

<start copy'n'paste>
   With the current specifications, if an ITR is sending to all types of
   destinations (i.e., non-LISP destinations, LISP destinations not in
   the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the
   only way to understand whether or not to encapsulate the traffic is
   to perform a cache lookup and, in case of cache-miss, send a Map-
   Request to the mapping system.  In the meanwhile, packets can be
   dropped.
<end copy'n'paste>



b.) 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. Are there
an assumption that some ISPs will announce the entire LISP space (/16
are mention) for free ?
If each and every EID space holder (/32 or similiar) each have to
connect to Internet and get their address space routed, then it's
nothing different than regular RIR allocated /32's.



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



-- 

Roger Jorgensen           | ROJO9-RIPE
rogerj@gmail.com          | - IPv6 is The Key!
http://www.jorgensen.no   | roger@jorgensen.no