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

[John Mann <[e-mail]>]

Hi,

On 6 March 2012 07:47, Brian E Carpenter <[e-mail]>wrote:

> Hi John, thanks for the review,
>
> On 2012-03-05 17:23, John Mann wrote:
> > Hi,
> >
> > ---
> >
> >    An important first step in every strategy is to determine from every
> >    hardware and software supplier details of their planned dates for
> >    providing full IPv6 support, with performance equivalent to IPv4, in
> >    their products and services.
> > ---
> > I disagree with this being a _first_ step.
>
> Personally I disagree, but it's certainly a debatable point and I'd
> like to hear from other people. My experience with IT managers is that
> they hate surprises, and discovering late in the game that a key component
> doesn't work is the worst kind of surprise.


Yes, late surprises are bad.
My view is to start trying to use IPv6 as early as possible so that you can
discover early the things that don't work (the way you expected them to).

IPv6 is different enough that there will be things that you know you need
to plan for,
and other things that you *don't know* that you have to deal with until
after you have completed the previous steps.

> Asking _every_ hardware and software supplier can take a lot of time and
> effort,
> > and can lead to ICP in-action e.g. if some suppliers are not ready.
>
> Correct. I would certainly modify the statement to refer specifically to
> determining critical path items - but your exact deployment plan might
> change according to which components will be available when.


May I suggest -- several deployment phases, each of which will have
critical path items that will need IPv6 support.

> Also, "full IPv6 support" can be hard to specify and evaluate -- do
> > you mean comply with all RFCs,
> > pass specific certification tests, or just the specific list of
> > features that you use with IPv4?
>
> That is very variable. Enterprises labouring under some stupid set of
> auditable requirements might have to be very strict; others might be
> very pragmatic. Either way, the criterion is functionality needed
> for IPv6, not an IPv4-driven feature list. I agree that this should
> be more carefully phrased.
>
> >
> > My alternate view is
> >
> > a) Make a policy decision to avoid the creation of any new
> > customer-facing networks or services that are IPv4-only
> > b) Enable IPv6 on what you already have, with perhaps some tactical
> > expenditure to:
> >    i) get some IPv6 traffic flowing
>
> What traffic? There won't be any revenue-generating traffic unless
> you make the user-facing service support IPv6.


Sorry, I wasn't implying revenue-generating user-facing IPv6 traffic.

I just meant _some_ IPv6 traffic -- preferably communicating with the IPv6
Internet.
It could be as simple as dual-stacking a test FTP server in the DMZ.
Or IPv6-enabling a test user subnet.  It doesn't matter if it is only 100
packets per day!

My point was that once you have _some_ IPv6 traffic, it enables the
following steps.
IPv6 has become tangible, it is no longer hypothetical.

Getting the first bit of IPv6 working can also dispel FUD.
It shows that adding IPv6 doesn't cause the world to end, that IPv4 and
IPv6 are ships-in-the-night protocols.

>    ii) start work on the sections described below e.g. external
> > connectivity, address plan, training, operations, and security.
> >    iii) get the first IPv6 service operational
> > c) Build on the experience and success of the first service to plan
> > and justify subsequent IPv6 steps.
>
> That's not very different from what the draft proposes.


Agreed.


>  > d) Triage your hardware and software
> >    i) legacy internal IPv4-only systems that don't ever need to support
> IPv6
> >    ii) systems that can already support IPv6
> >    iii) systems due to be replaced soon -- by systems that will
> > support IPv6 (see (a) above)
> >
> >    iv) systems that will require extra effort or expenditure to get IPv6
> support
> >    v) problem systems -- e.g. none of the possible suppliers have an
> > IPv6 roadmap.
>
> You should certainly do all that; I don't understand how it can be done at
> the end.
>
> >
> > ====
> >
> > I think some mention could be made in
> >
> >    5.2. Routing
> > that running dual-stack could require twice the routing table space
> > and forwarding TCAM in the routers
>
> Well, more space, indeed.
>
> >
> > And in
> >    13. Security Considerations
> > that running dual-stack could require twice the amount of permission
> > lists, ACLs, TCAMs etc.
>
> Yes, which is why a lot of people want feature-equivalence, so that
> they only have to maintain a single config to drive both protocols.
>
> > The growth in table size hopefully won't be 5 times (32 bits to 32 + 128
> bits),
> > due to most IPv6 routing only going down to /64s, fewer IPv6 routes,
> > shorter history of IPv6 exceptions, etc.
>
> Agreed
>

Another issue is mentioned in several places in the draft, but I didn't see
it pulled together in one spot:
For tactical reasons it may be necessary to use different infrastructure to
support IPv6 than IPv4,
but there are major advantages in simplicity and maintainability if shared
common infrastructure can be used for
ISP links, routers, firewalls, load balancers, web servers, network
monitoring, security management, IPAM etc

    John

   Brian
>
> >
> > Thanks,
> >     John
> >
> > On 23 February 2012 14:41, Brian E Carpenter <
> [e-mail]>wrote:
> >
> >> Hi,
> >>
> >> This version has various updates due to comments from the WG.
> >>
> >> We are not asking for a meeting slot in Paris, but we'd like the
> >> chairs to put the question whether the WG wants to adopt this
> >> draft. In any case we still want more input to correct and
> >> expand the draft.
> >>
> >>    Brian + Sheng
> >>
> >> -------- Original Message --------
> >> Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt
> >> Date: Wed, 22 Feb 2012 14:30:09 -0800
> >> From: [e-mail]
> >> Reply-To: [e-mail]
> >> To: [e-mail]
> >>
> >>
> >> A New Internet-Draft is available from the on-line
> >> Internet-Drafts directories.
> >>
> >>        Title           : IPv6 Guidance for Internet Content and
> >> Application Service Providers
> >>        Author(s)       : Brian Carpenter
> >>                          Sheng Jiang
> >>        Filename        : draft-carpenter-v6ops-icp-guidance-03.txt
> >>        Pages           : 18
> >>        Date            : 2012-02-22
> >>
> >>   This document provides guidance and suggestions for Internet
> >> Content
> >>   Providers and Application Service Providers who wish to offer
> >> their
> >>   service to both IPv6 and IPv4 customers.  Many of the points will
> >>   also apply to any enterprise network preparing for IPv6 users.
> >>
> >>
> >> A URL for this Internet-Draft is:
> >>
> >>
> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> This Internet-Draft can be retrieved at:
> >>
> >>
> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt
> >>
> >> _______________________________________________
> >> I-D-Announce mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/i-d-announce
> >> Internet-Draft<
> https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft
> >directories:
> >> http://www.ietf.org/shadow.html
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >>
> >
>