Re: Consensus Call (Update): draft-weil-shared-transition-space-request

Benson Schliesser <bschlies@cisco.com> Wed, 07 December 2011 03:06 UTC

Return-Path: <bschlies@cisco.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 639E821F85A8 for <ietf@ietfa.amsl.com>; Tue, 6 Dec 2011 19:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 wksarQDIsSO8 for <ietf@ietfa.amsl.com>; Tue, 6 Dec 2011 19:06:24 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C2A6821F856F for <ietf@ietf.org>; Tue, 6 Dec 2011 19:06:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bschlies@cisco.com; l=1967; q=dns/txt; s=iport; t=1323227184; x=1324436784; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wXQjHE4+n2WYhqfTU4HKlkm0j6huu1YzZgiLty5AvvM=; b=KKLhizYC7CikY8lc7DBS7FxSWURwo9HbqXcnypiUL0RMoxo5nWFHBd6f VUSp2WrY4MTydfN1JL6rjU9bTYOZjBL9zcFSyCHtAr4GJknHIHR1nCboJ U4zG2iqH/dlMiZhVci0b/xofocEJt2S014mnYDpWQ1pnff29CqrN5eCp6 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAEHX3k6rRDoH/2dsb2JhbABDqmKBBYFyAQEBAwESASc0CwULCw44VwY1h2WXRwGeC4pPYwSILow4kj8
X-IronPort-AV: E=Sophos;i="4.71,310,1320624000"; d="scan'208";a="18154773"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Dec 2011 03:06:22 +0000
Received: from sjc-bschlies-8919.cisco.com (sjc-bschlies-8919.cisco.com [10.20.217.234]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pB736L0g008037; Wed, 7 Dec 2011 03:06:21 GMT
Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-request
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Benson Schliesser <bschlies@cisco.com>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74DD44B5F@EMBX01-WF.jnpr.net>
Date: Tue, 06 Dec 2011 21:06:20 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <67EB3BA0-433D-4A05-9FCA-65B99317FCA1@cisco.com>
References: <13205C286662DE4387D9AF3AC30EF456D74DD44B5F@EMBX01-WF.jnpr.net>
To: Ronald Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1084)
Cc: IETF Discussion <ietf@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, 07 Dec 2011 03:06:25 -0000

Hi, Ron.

On Dec 3, 2011, at 4:06 PM, Ronald Bonica wrote:

> On Thursday, December 1, the IESG deferred its decision regarding draft-weil-shared-transition-space-request to the December 15 telechat.

I support the assignment of an IPv4 /10 for shared CGN space. Most of my thoughts on this topic have already been expressed in draft-bdgks-arin-shared-transition-space. And anything that wasn't captured in draft-bdgks has been discussed (and re-discussed ad nauseum) this past week on the IETF mailing list.

However, there is one essential point that I'd like to clarify:  We need a common standard for numbering CGN NAT444 deployments.

For NAT444 deployments of CGN, we are talking about a new scope - the intermediate "CGN zone" network - that is neither global or local. Within this scope, one cannot expect end-to-end (global) address fidelity (because traffic is NATted), nor can one expect forwarding to be confined to a single organization (because it touches CPE etc).

ISPs need to use addressing within this scope that does not cause (additional) problems for their existing customers (and their customers' equipment). And in the event of an addressing conflict, operators (on both sides) need a common reference to determine who is at "fault" - i.e. who is responsible for fixing the problem.

Of the various options, only unique GUA and/or a Shared CGN Space can be reasonably expected to meet these requirements.  For the sake of conservation and operational efficiency, I recommend that we allow the assignment of a Shared CGN Space for this purpose.

Cheers,
-Benson


PS - I also support turning 240/4 into unicast, as others have recommended. But this will not help in the immediate future timeframe, for the currently deployed equipment, which is driving the need for Shared CGN Space. It may be complementary, but does not reduce the need for a /10 assignment.