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
- [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