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

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Sep 2012 15:04:26 +0100

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].

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 6 Sep 2012 15:26:17 +0000

Will read your draft,,,

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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

PROPOSED NEW TEXT:

OLD TEXT:

   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
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops