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

"George, Wes" <wesley.george@twcable.com> Fri, 16 November 2012 13:27 UTC

Return-Path: <wesley.george@twcable.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 AA48E21F8641; Fri, 16 Nov 2012 05:27:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level:
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 JWoLXFhG29W1; Fri, 16 Nov 2012 05:27:08 -0800 (PST)
Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4621F852D; Fri, 16 Nov 2012 05:27:02 -0800 (PST)
X-SENDER-IP: 10.136.163.12
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="4.83,264,1352091600"; d="scan'208";a="471923801"
Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 16 Nov 2012 08:26:42 -0500
Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 16 Nov 2012 08:26:52 -0500
From: "George, Wes" <wesley.george@twcable.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Sander Steffann <sander@steffann.nl>
Date: Fri, 16 Nov 2012 08:26:50 -0500
Subject: RE: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
Thread-Topic: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC
Thread-Index: Ac3D2ZB7DjJwipvuSwOSIMmOy4m4IwAIWyTA
Message-ID: <2671C6CDFBB59E47B64C10B3E0BD592303373BDF01@PRVPEXVS15.corp.twcable.com>
References: <20121113144545.12836.71935.idtracker@ietfa.amsl.com> <CAKFn1SFy2+hXJLVtEpkdXfNuXA31ybmYnBFFPXj-73kb3tD+yw@mail.gmail.com> <5FCB8A98-4984-427C-9468-1DFDEBD206FD@steffann.nl> <87676878-B077-4B4C-96DC-9F755F78018A@gigix.net> <50A530E7.8@lacnic.net> <B8132154-7260-43B4-B10D-E5B95924A15D@gmail.com> <00C0245E-59D7-4552-8BB4-1C0099513D1D@steffann.nl> <D470B9D8-977F-4E8B-8EDF-7769D5773279@gmail.com> <0BC58149-A314-4AD3-80A5-DC8BF5DB0E2D@steffann.nl> <2007FD20-0EA4-4204-81A5-D9AE0201419D@gmail.com> <D40BD502-1E3A-4AAA-A040-E2E4EE83141D@steffann.nl> <8F781829-457B-4B32-B91A-46C22BC5D570@gmail.com> <22AD9545-DDC9-4FE9-A984-1D0E3987D02D@steffann.nl> <50A601D6.6080701@gmail.com>
In-Reply-To: <50A601D6.6080701@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "ietf@ietf.org" <ietf@ietf.org>, Dino Farinacci <farinacci@gmail.com>, "lisp@ietf.org" <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: Fri, 16 Nov 2012 13:27:08 -0000

> From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of
> Brian E Carpenter

> > *please*please*please* study what happened to 6to4 and the
> > 2002::/16 prefix before continuing this discussion.
>
> The problem there was that the design of 6to4 assumed, and relied on,
> altruistic cooperation between operators, to ensure that there was a
> useable route to 2002::/16 *everywhere* in the
> IPv6 network. That assumption was naive and led to black holes.

[WEG] The other problem with 6to4 is that by the time we tried to shut it down because we determined that it wasn't working acceptably and/or had fatal flaws in its design, there was a small (but extremely vocal) group of people who basically said "you can have 6to4 back when you pry it from my cold, dead fingers!!" -- perhaps we can kill two birds with one stone if you can convince those same people to let you repurpose the 2002::/16 space for LISP?

*ducks* :-)

More seriously:

I echo the concerns that others have raised about the questionable justification for a /12 or /16, the limited details around how allocation and management might work, and the recommendation to go talk to the RIRs and learn how address allocation might work so that you can give them helpful recommendations when (and if) it comes time to write RIR policy to manage this space. I'd rather this not be deferred to a later document, because there is little incentive to complete such a document once the allocation is already made. Either you know how this will be used and can articulate it, or you don't. If you don't, you aren't ready to request it.

Additionally: The LISP documents are classified as experimental (though this one is not...). Therefore I see two possible solutions that don't appear to have been discussed yet:
1) the RIRs have existing policy regarding experiments (e.g. https://www.arin.net/policy/nrpm.html#eleven ). You might consider looking at those policies to see if getting a direct allocation from one or more RIRs for your experiment would be a workable solution, rather than locking space into this via IANA.
2) Request the space (with improvements to the request as stated above and elsewhere in this thread) but include a sunset date for the allocation from IANA. If the experiment is successful, the expectation is that you will write proposed standard drafts refine the implementation and to make it not experimental, and you can make the IANA allocation permanent at the same time. If the experiment is not successful and this space is no longer needed in a few years, we don't have to fight a small vocal minority to shut it down. (c.f. RFC3701). While I'm *less* worried about us "wasting" IPv6 space, it's not infinite, and I'm having visions of the IPv4 Class E space, where we have this sizable chunk of addresses allocated for a special purpose that 10 years from now could (and should) be used for something else, and inertia means that they never do, filed under "it seemed like a good idea at the time..."

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.