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].
- [v6ops] I-D Action: draft-ietf-v6ops-icp-guidance… internet-drafts
- [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-gu… Brian E Carpenter
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Tore Anderson
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Brian E Carpenter
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Tore Anderson
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Brian E Carpenter
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Nick Hilliard
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Joel jaeggli
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Brian E Carpenter
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Brian E Carpenter
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Brian E Carpenter
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Gunter Van de Velde (gvandeve)
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Arturo Servin
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Brian E Carpenter
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Arturo Servin
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Erik Nygren
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Brian E Carpenter
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Mark Smith
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… SM
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… Brian E Carpenter
- Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-ic… SM