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

"Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com> Thu, 06 September 2012 15:26 UTC

Return-Path: <gvandeve@cisco.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 207F421F86B6 for <v6ops@ietfa.amsl.com>; Thu, 6 Sep 2012 08:26:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.916
X-Spam-Level:
X-Spam-Status: No, score=-9.916 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315]
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 xN5dmziL8liW for <v6ops@ietfa.amsl.com>; Thu, 6 Sep 2012 08:26:19 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4C821F84E1 for <v6ops@ietf.org>; Thu, 6 Sep 2012 08:26:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3710; q=dns/txt; s=iport; t=1346945179; x=1348154779; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=S9U1Y/6/b0BiSWsLYm7xjb6ZIvWMTh++U2fZ+nVi/lc=; b=lCeBqjLe/ROkNS/ljGtdNE8tpZxPw/ahrPayWODXFt6SEzEXmaxF9wZe 6/+nL78BCY3aUleqZAkJo7BHid3mBly37NWLrcXbRZGzPQ3rrs5soxy5K zLYaqVEQdIdxjXcZ34/CijhgT0fG/58Pxw8e+2yIpbueVSDFxEaxdXy98 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EALi/SFCtJXG9/2dsb2JhbABFux6BB4IgAQEBBAEBAQ8BJysJFwQCAQgRBAEBCxQJBycLFAkIAgQBEggTB4drC5p4oBwEixEUAYVQYAOkDIFngmOBWAE
X-IronPort-AV: E=Sophos;i="4.80,380,1344211200"; d="scan'208";a="118947800"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 06 Sep 2012 15:26:18 +0000
Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q86FQI2c028193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Sep 2012 15:26:18 GMT
Received: from xmb-aln-x12.cisco.com ([169.254.7.191]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.001; Thu, 6 Sep 2012 10:26:18 -0500
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]
Thread-Index: AQHNh1bRjv0kb3+Bik+pUKIZVF+MRJd0D4OAgAAItQCAABMjAIAAI8eAgAAQw4CACVZLAP//wtQA
Date: Thu, 06 Sep 2012 15:26:17 +0000
Message-ID: <67832B1175062E48926BF3CB27C49B24081378F3@xmb-aln-x12.cisco.com>
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> <5048AD6A.7080601@gmail.com>
In-Reply-To: <5048AD6A.7080601@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.83.57]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.005
x-tm-as-result: No--28.963100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 15:26:20 -0000

Will read your draft,,,

G/



-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter
Sent: 06 September 2012 16:04
To: IPv6 Operations
Subject: Re: [v6ops] [Fwd: I-D Action: draft-ietf-v6ops-icp-guidance-03.txt]

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 mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops