Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 06 September 2012 14:04 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9861021F85ED for <v6ops@ietfa.amsl.com>; Thu, 6 Sep 2012 07:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.621
X-Spam-Level:
X-Spam-Status: No, score=-101.621 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, 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 q50RxlRn4RWd for <v6ops@ietfa.amsl.com>; Thu, 6 Sep 2012 07:04:23 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D668821F8546 for <v6ops@ietf.org>; Thu, 6 Sep 2012 07:04:22 -0700 (PDT)
Received: by eekb45 with SMTP id b45so789563eek.31 for <v6ops@ietf.org>; Thu, 06 Sep 2012 07:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7uAIuLPYF0knr7WsLiqnSQhcbtl6fbtECmXWz7H9lb0=; b=qmUkruTZY1F4IYiVc1dQBHJvOgpdB+1vPivzyes4q4iPKF9D/D6+l8CkoH9c8KVnNw Sp9eSM8liXTEzgrTlPI3fyN2n947o9bPwzgDEXPn6PTNeTTic28Uk1X49I0Pnqe+Wldo gHPQU5zFDZ37n/OHV9lYVbm/XsZ+STyR4NXYTWP1ZJ6zsemrjn0UmBYEU8K4g9RDrp0b F2X9wxXx1AJaoGD8TSJHafJX9PdzP47FYzUhqzaN+BcxDpB9Pwe2b9qo0cJLNgLab23h 0w6zFZ7UHCG7WBgEFGUjebBR/wvRQZYcj1sh3cMEj9kRncDkdS7W8+fkJSesONthCpOP w2Qw==
Received: by 10.14.172.129 with SMTP id t1mr3121395eel.34.1346940261898; Thu, 06 Sep 2012 07:04:21 -0700 (PDT)
Received: from [192.168.1.65] (host-2-102-218-213.as13285.net. [2.102.218.213]) by mx.google.com with ESMTPS id e42sm4333263eem.8.2012.09.06.07.04.17 (version=SSLv3 cipher=OTHER); Thu, 06 Sep 2012 07:04:19 -0700 (PDT)
Message-ID: <5048AD6A.7080601@gmail.com>
Date: Thu, 06 Sep 2012 15:04:26 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: IPv6 Operations <v6ops@ietf.org>
References: <5040646F.6000103@gmail.com> <50407CAB.4060903@redpill-linpro.com> <504094DD.9060708@gmail.com> <50409C2A.2060805@redpill-linpro.com> <5040AC38.5080505@gmail.com> <5040CA3B.4090602@bogus.com> <5040D84B.2060201@gmail.com>
In-Reply-To: <5040D84B.2060201@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Sep 2012 14:04:23 -0000

Hi again.

Nobody answered my challenge to send text, so here is my own attempt at
rewriting the contentious paragraphs (new and old versions below). Comments
please - if this is OK, we can update the draft again.

Regards
   Brian (speaking only for myself)


PROPOSED NEW TEXT:

5.1. Address and subnet assignment


   An ICP must first decide whether to apply for its own Provider
   Independent (PI) address prefix for IPv6.  This option is available
   for a fee either from an ISP that acts as a Local Internet Registry, or
   directly from the relevant Regional Internet Registry.  The
   alternative is to obtain a Provider Aggregated (PA) prefix from an ISP.
   Both solutions are viable in IPv6.  However, the scaling properties of
   the wide area routing system (BGP4) mean that the number of PI prefixes
   should be limited, so only large content providers can justify obtaining
   a PI prefix and convincing their ISPs to route it.  Millions of
   enterprise networks, including smaller content providers, will use PA
   prefixes.  In this case, a change of ISP would necessitate a change
   of the corresponding PA prefix, using the procedure outlined in
   [RFC4192].

   An ICP that has connections via multiple ISPs, but does not have a PI
   prefix, would therefore have multiple PA prefixes, one from each ISP.
   This would result in multiple IPv6 addresses for the ICP's servers or load
   balancers.  If one address fails due to an ISP malfunction, sessions
   using that address would be lost.  At the time of this writing, there
   is very limited operational experience with this approach
   [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat].

   An ICP that has its service hosted by a colocation provider, cloud
   provider, or the like, will need to follow the addressing policy
   of that provider.

OLD TEXT:

5.1. Address and subnet assignment


   An ICP must first decide whether to apply for its own Provider
   Independent (PI) address prefix for IPv6.  This option is available
   to an ICP willing to deal directly with the relevant Regional
   Internet Registry and pay the associated fees.  The alternative is to
   obtain a Provider Aggregated (PA) prefix from an ISP.  Both solutions
   are viable in IPv6.  However, the scaling properties of the wide area
   routing system (BGP4) limit the routing of PI prefixes, so only large
   content providers can justify the bother and expense of obtaining a
   PI prefix and convincing their ISPs to route it.  Millions of
   enterprise networks, including smaller content providers, will use PA
   prefixes.  In this case, a change of ISP would necessitate a change
   of the corresponding PA prefix, using the procedure outlined in
   [RFC4192].

   An ICP that has connections via multiple ISPs, but does not have a PI
   prefix, would have multiple PA prefixes, one from each ISP.  This
   would result in multiple IPv6 addresses for the ICP's servers or load
   balancers.  If one address fails due to an ISP malfunction, sessions
   using that address would be lost.  At the time of this writing, there
   is very limited operational experience with this approach
   [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat].