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

SM <sm@resistor.net> Wed, 21 November 2012 10:40 UTC

Return-Path: <sm@resistor.net>
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 E336921F8624; Wed, 21 Nov 2012 02:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.51
X-Spam-Level:
X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, 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 5faPZZWASsps; Wed, 21 Nov 2012 02:40:27 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0655021F8440; Wed, 21 Nov 2012 02:40:17 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qALAeA3B015359; Wed, 21 Nov 2012 02:40:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1353494416; bh=XRdU9Pqp3mKfHt3EmHsvTw+10GvMaizVw5iPeiRMw2I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=E3gW6oCvksJww+o2DfAuXOpj9jxUxnb1hSpzivt2adHU53XDfrexqzfKeHeh/RLIU kwwUa5xrScHlDxG2qYRy/cKstzBlOKhDPowWfY7pmbqq6vBA5+mszy+ap6A72Olb/v +kKBtBc/zuM10NVNlZM0SpMCuuU2MmW2H3moh0BI=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1353494416; i=@resistor.net; bh=XRdU9Pqp3mKfHt3EmHsvTw+10GvMaizVw5iPeiRMw2I=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=UekhTUtD8yphtTBIX3tKiy1LZEE/8iCa592YgGTqOKgQ80XdJ+QF/rXU2/7AHS9BG mKB4z4vldHKkwGca/lRRQP4ltMYu/hagT+X89Z6flKwWlgDqWsWh7uejJ3yeQL6JBu O0GCVzbxD2OmIKZDT/dueZwI3+IRmKa1wOnBDTBc=
Message-Id: <6.2.5.6.2.20121121005659.0a1349a8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 21 Nov 2012 02:29:24 -0800
To: ietf@ietf.org
From: SM <sm@resistor.net>
Subject: Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
In-Reply-To: <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net>
References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <CAKFn1SF4+k5gWip-WBNfbjt-qAafPbTSY8L_EBLA9Pqvbw4=kQ@mail.gmail.com> <50A66313.9090002@joelhalpern.com> <50A66B67.5000609@gmail.com> <50A67758.8000001@joelhalpern.com> <33C6C196-B881-4BAA-8E57-082B266C831A@steffann.nl> <50A6ADD0.3040000@joelhalpern.com> <45813A84-7BE9-4D21-AE3E-F3401D6E1B50@apnic.net> <99B9866C-41D6-4784-AA69-CD25E5910F4B@apnic.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: lisp@ietf.org
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: Wed, 21 Nov 2012 10:40:29 -0000

At 22:16 20-11-2012, Geoff Huston wrote:
>The guidelines for IP address allocations were documented in RFC2050,
>adopted in November 1996 as a Best Current Practice. This document

Some parts of RFC 2050 could be considered as Historic.   As a FYI 
there is only one IANA policy about IPv6 [1].

>It is noted that the LISP experiment already makes use of a /32 prefix,
>"with more than 250 sites using a /48 sub prefix", as noted in
>draft-ietf-lisp-eid-block-03.txt. Even with an overall 50% utilisation
>rate of this prefix there is scope in the current /32 address block to
>address some 32,000 further sites using a /48 sub prefix.

Yes.

>If the LISP experiment fills this /32 prefix to such a level of
>utilisation then there would be reasonable grounds to make the case that
>at such a time the LISP activity would no longer be an experimental
>effort, as it would be an instance of an application that makes use of
>the global unicast address pool. In this case the provisions of RFC
>4773, and the applicability of a special purpose address allocation
>would not be expected to apply, as this would fall under the terms of
>RFC2050 and the address allocation function would be administered by the
>Regional internet Registries, according to RFC2860.

There is ample material in the Last Call comments to generate 
DISCUSSes.  The question is how many DISCUSSes will be filed.  It's 
easier to leave the progress of the draft to a matter of IETF 
consensus than to invoke the RFC 4773 or RFC 2860.  IANA is bound to 
follow technical guidance exclusively from the IESG.  It is 
improbable that IANA would invoke the dispute clause.

>A possible course of action for the LISP Working Group and the IESG to
>consider would be for the existing /32 address be documented as an IANA
>Special Purpose Address allocation for use in supporting the current
>LISP experiment, and for the LISP advocates to make their case for
>particular requirements in the handling of global unicast address
>allocations in IPv6 to the regional addressing communities. This would

Anything more than a /32 might have to be a global policy 
proposal.  It would likely take over a year to get such a proposal 
through all the RIRs.

Regards,
-sm

P.S. Don't boil the ocean to kill a single fish (credits - Noel Chiappa)

1. 
https://www.icann.org/en/news/in-focus/global-addressing/allocation-ipv6-rirs