Re: [v6ops] draft-anderson-v6ops-siit-dc-01

[Ca By <[e-mail]>]

On Monday, December 8, 2014, Tore Anderson <[e-mail]> wrote:

> * Ca By <[e-mail] <javascript:;>>
>
> > I have read  draft-anderson-v6ops-siit-dc-01.
> >
> > I support the document to be republished as a WG informational document
> > with  the RFC6145 changes  moved into a new document.
>
> Thank you!
>
> > I have a one minor comments about draft-anderson-v6ops-siit-dc-01.
> >
> > The I-D identifies a real network scaling problem where dual-stack is not
> > an acceptable solution since it does not allow network operators to
> > decouple IPv4 addresses from nodes deployed, thus nodes deployed cannot
> > scale beyond IPv4 address holdings with dual-stack.  The IETF needs to
> > provide better guidance than  "dual-stack everything".  But, the I-D does
> > not address the simplest solution of simply having IPv4 nodes for IPv4
> > traffic and IPv6 nodes for IPv6 traffic.  This allows a data center
> > operator to get the most usage out of scarce IPv4 nodes since they pick
> up
> > the IPv4-only users (excluding Apple happy eyeballs!!!) while the IPv6
> > nodes pickup the IPv6 capable users.  Now, this approach of IPv4-only
> nodes
> > and IPv6-only nodes works great when you are Facebook and your smallest
> > unit of provisioning is a fully packed rack of gear.  If you are a
> smaller
> > operator, you may not have enough traffic to justify an IPv6-only node,
> yet
> > you still have to scale nodes beyond IPv4 holdings.  There is also the
> case
> > where uniformity of provisioning is seen as being a higher value than
> > having 2 flavor: v4 and v6... thus draft-anderson-v6ops-siit-dc-01
> > certainly fits a need, but it should be context of dual-stack and single
> > stack v4 and v6.
>
> I'm not so sure about having separate IPv4-only and IPv6-only
> infrastructures solves anything, actually...
>
> To continue the Facebook analogy with a rack of IPv4-only frontend
> nodes and another rack of IPv6-only frontend nodes that serve IPv4-only
> and IPv6-capable users: Presumably all those users need to be shown the
> same content, regardless of which IP version they used to request it.
> So those IPv4/IPv6-only frontend racks necessarily share a common set
> of backend servers - and if they're to be reachable from both the
> IPv4-only and the IPv6-only frontend nodes, then the backend nodes must
> necessarily be dual-stack.
>
>
Let's assume the backend is ipv6-only.

The ipv4-only front-end is in-fact dual stack but it has public v4 in
public dns to be reached by clients but no public dns entry on the ipv6
side.  This is what allows for the separation of ipv4 and v6 users


So we're back to IPv4 being a limiting factor for scaling, and in my
> experience the number of backend nodes usually greatly outnumber the
> number of frontend nodes so really this is where you primarily would
> want to avoid dual-stack. (If we're talking about Facebook or someone
> of similar size, dual-stack using RFC1918 for IPv4 in the backend
> doesn't necessarily scale well enough either.)
>
> Tore
>