Re: [lisp] AD Review: draft-ietf-lisp-eid-block

Brian Haberman <brian@innovationslab.net> Fri, 31 August 2012 18:09 UTC

Return-Path: <brian@innovationslab.net>
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 DD68221F8551 for <lisp@ietfa.amsl.com>; Fri, 31 Aug 2012 11:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level:
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 2gmrvrsHvppG for <lisp@ietfa.amsl.com>; Fri, 31 Aug 2012 11:09:38 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 458EE21F855B for <lisp@ietf.org>; Fri, 31 Aug 2012 11:09:38 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 260D488090; Fri, 31 Aug 2012 11:09:38 -0700 (PDT)
Received: from clemson.local (nat-gwifi.jhuapl.edu [128.244.87.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9E502130019; Fri, 31 Aug 2012 11:09:37 -0700 (PDT)
Message-ID: <5040FE3D.50207@innovationslab.net>
Date: Fri, 31 Aug 2012 14:11:09 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: Luigi Iannone <ggx@gigix.net>
References: <503F63F5.7030309@innovationslab.net> <503F6B1A.3000104@innovationslab.net> <D5926F7C-7C16-441F-99E1-B4D3214A514A@gigix.net>
In-Reply-To: <D5926F7C-7C16-441F-99E1-B4D3214A514A@gigix.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-lisp-eid-block@tools.ietf.org, lisp@ietf.org
Subject: Re: [lisp] AD Review: draft-ietf-lisp-eid-block
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: Fri, 31 Aug 2012 18:09:39 -0000

On 8/31/12 4:30 AM, Luigi Iannone wrote:
> Hi Brian,
>
> thank you for the review. Few comments inline.
>
> On 30 Aug. 2012, at 15:31 , Brian Haberman <brian@innovationslab.net>
> wrote:
>
>> Ok, so I typed too soon...
>>
>> On 8/30/12 9:00 AM, Brian Haberman wrote:
>>> All, As a part of the publication process, I have completed my
>>> initial review of draft-ietf-lisp-eid-block.  The draft is
>>> well-written and concise and I thank you for that.
>>>
>>> The only suggestion I would make for this document is to drop
>>> the use of the 2119 language.  It is only used in a few places
>>> and those uses are not really appropriate for 2119 language.  I
>>> would suggest re-writing those guidelines with normal prose and
>>> drop the 2119 boilerplate from the document.
>
> We tried not to use so much the 2119 language, but if you think it is
> better to drop it completely, this can be done.

Given the places it is used and the goal of this document, I don't see 
the need for 2119 language.

>
> But, what do you think about section 8 "Routing Consideration" ?
> There, with 2119 language, we recommend that routers that do not
> support LISP do not handle the prefix in any special way. WOuldn't be
> better to maintain that part?
>

Not really, for two reasons.  One, this type of guidance is trying to 
tell operators how to run their networks.  The IETF has a very poor 
track record of doing that and I can assure you that such direction will 
raise a few ADs eyebrows.  Second, any guidance harvested from this 
section by equipment vendors does not need 2119 keywords.  Those terms 
are not meant to dictate implementations, they are for interoperability.

>
>>
>> This draft would benefit from the addition of enhanced text on why
>> a /16 is needed.  What prefix lengths are expected to be allocated
>> to end-sites?
>
> IMHO, this is something that should not be discussed in the document.
> Prefix length allocation will be based on operational reasons and
> allocation policies that may change in time.
>

I disagree.  There needs to be some justification for why the particular 
request is being made.  For example, 6to4 is allocated an IPv6 prefix 
and its RFC (3056) describes why its particular prefix size is needed.

Moreover, this request is wading into a new area.  It is asking for a 
block of addresses from IANA which will then be sub-delegated to end 
networks.  Who will manage these allocations?  Using what guidelines?

And given the statements in section 8 about these EIDs being routed 
natively, are you treading into the RIR space?  I will have to discuss 
with my fellow ADs what their understanding was with respect to the 
routability of EIDs during the LISP rechartering.

>
>> How many networks are expected to participate in this experiment?
>
> Very difficult to say, participants are steadily growing.  But let's
> have a long term viewpoint, if the LISP "experiment" is successful
> and widely adopted wouldn't be better if the reserved prefix does not
> have to change and has sufficient space to accommodate any future
> growth?

I have no issues with planning for success, but one of the key issues 
with allocating addresses is justifying the request.  Typical allocation 
policies, at least from the RIR perspective, take total number of 
networks/devices into account when responding to an address block request.

>
> In addition, I know that all LISP work is marked as "experimental"
> but let's also keep in mind that there are companies out there that
> start making business out of LISP.
>

That is their choice.

>
>> Should there be a termination date for this allocation?
>
> I do not see IPv6 addressing space as a scarce resource, and for the
> same reasons I cited above I wouldn't put a termination date.
>
> Obviously, IANA may decide to allocate the prefix only for a limited
> amount of time and decide in few years whether or not to make it a
> definitive allocation.
>

That is definitely one possibility.

Regards,
Brian