Subject: [v6ops] Requesting reviews of draft-carpenter-v6ops-icp-guidance-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Dec 2011 11:36:54 +1300

Hi,

This has been updated following the comments received so far. As
discussed in Taipei, we are requesting reviews from the WG. Additional
authors with personal expertise would be welcome too.

   Brian and Sheng.

-------- Original Message --------
Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-01.txt
Date: Mon, 05 Dec 2011 14:33:13 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

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-01.txt
	Pages           : 16
	Date            : 2011-12-05

   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-01.txt

---

From: "George, Wes" <[email-masked]>
Date: Mon, 12 Dec 2011 10:07:11 -0500

A couple of comments -

Section 3 - there's a timing aspect to training. If staff are trained too far in advance of deployment, they forget everything before they have a chance to apply it. Training has a definite need to be done "just in time" in order to properly "stick."

In section 11, regarding IPv4 and IPv6 interdependence of Ops/Mgmt, a couple of points worth making here. You refer to them somewhat generally, but I bring these up because I think they're important to make more explicitly:
1) Monitoring systems must have a way to validate the IPv4 and IPv6 SLA and performance independently, so that if the network is set up as you suggest, where IPv4 could have a failure that does not affect IPv6 or vice versa, the operator is aware that one of the two address-families is having an issue. Often the tendency is to assume that since things are taking the same path, that if one is working, so is the other. A good example of where this assumption fails is covered in draft-hsingh-6man-enhanced-dad-03, where DAD may leave you with a functional IPv4 stack but dead IPv6.
2) It's worth explicitly stating that the end goal is to have a network that does not have to have major changes made to it when at some point in the future it becomes possible to transition to IPv6-only, even if only for some parts of the network. That is, if the IPv6 deployment is architected in such a way as to more or less assume that IPv4 is not present, then the network will function seamlessly when it is indeed no longer there. - Dual stack, while necessary, does have scaling and management overhead considerations, so if it's reasonably trivial to move to single-stack IPv6 (as the network and its customers can support such), that might be worth recommending in this section. You do note that it should be possible to access devices having problems on one address-family using the other (assumedly functional) AF, but I think this goes a step further along that line of logic.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian E Carpenter
> Sent: Monday, December 05, 2011 5:37 PM
> To: IPv6 Operations
> Subject: [v6ops] Requesting reviews of draft-carpenter-v6ops-icp-
> guidance-01.txt
>
> Hi,
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Dec 2011 11:24:05 +1300

Hi Wes,

Thanks for the comments. A few responses in line; otherwise we
will cover your points in the next version.

On 2011-12-13 04:07, George, Wes wrote:
> A couple of comments -
> 
> Section 3 - there's a timing aspect to training. If staff are
> trained too far in advance of deployment, they forget
> everything before they have a chance to apply it. Training
> has a definite need to be done "just in time" in order to
> properly "stick."

Agreed

> In section 11, regarding IPv4 and IPv6 interdependence of
> Ops/Mgmt, a couple of points worth making here. You refer to
> them somewhat generally, but I bring these up because I think
> they're important to make more explicitly: 1) Monitoring
> systems must have a way to validate the IPv4 and IPv6 SLA and
> performance independently, so that if the network is set up
> as you suggest, where IPv4 could have a failure that does not
> affect IPv6 or vice versa, the operator is aware that one of
> the two address-families is having an issue. Often the
> tendency is to assume that since things are taking the same
> path, that if one is working, so is the other. A good example
> of where this assumption fails is covered in
> draft-hsingh-6man-enhanced-dad-03, where DAD may leave you
> with a functional IPv4 stack but dead IPv6. 

Agreed

> 2) It's worth
> explicitly stating that the end goal is to have a network
> that does not have to have major changes made to it when at
> some point in the future it becomes possible to transition to
> IPv6-only, even if only for some parts of the network. That
> is, if the IPv6 deployment is architected in such a way as to
> more or less assume that IPv4 is not present, then the
> network will function seamlessly when it is indeed no longer
> there. 

Yes, that's always been my understanding of why "ships in the
night" is the best approach, but of course there's going to be
some back office system that breaks this principle.

> - Dual stack, while necessary, does have scaling and
> management overhead considerations, so if it's reasonably
> trivial to move to single-stack IPv6 (as the network and its
> customers can support such), that might be worth recommending
> in this section. You do note that it should be possible to
> access devices having problems on one address-family using
> the other (assumedly functional) AF, but I think this goes a
> step further along that line of logic.

That would sort of imply that the recommendations would run
backwards at a later stage (e.g. use an HTTP proxy to connect
IPv4 clients to IPv6-only servers). We could certainly suggest
that, although I doubt if ICPs will be thinking about this very
soon.

Thanks

    Brian
> 
> Thanks,
> 
> Wes George
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Brian E
>> Carpenter Sent: Monday, December 05, 2011 5:37 PM To: IPv6
>> Operations Subject: [v6ops] Requesting reviews of
>> draft-carpenter-v6ops-icp- guidance-01.txt
>> 
>> Hi,
>> 
>> This has been updated following the comments received so
>> far. As discussed in Taipei, we are requesting reviews from
>> the WG. Additional authors with personal expertise would be
>> welcome too.
>> 
>> Brian and Sheng.
>> 
>> -------- Original Message -------- Subject: I-D Action:
>> draft-carpenter-v6ops-icp-guidance-01.txt Date: Mon, 05 Dec
>> 2011 14:33:13 -0800 From: [email-masked] 
>> Reply-To: [email-masked] To:
>> [email-masked]
>> 
>> 
>> Title           : IPv6 Guidance for Internet Content and 
>> Application Service Providers Author(s)       : Brian
>> Carpenter Sheng Jiang Filename        :
>> draft-carpenter-v6ops-icp-guidance-01.txt Pages           :
>> 16 Date            : 2011-12-05
>> 
>> 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.
>> 
>> 
>> _______________________________________________ v6ops
>> mailing list [email-masked] 
> This E-mail and any of its attachments may contain Time
> Warner Cable proprietary information, which is privileged,
> confidential, or subject to copyright belonging to Time
> Warner Cable. This E-mail is intended solely for the use of
> the individual or entity to which it is addressed. If you are
> not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or
> action taken in relation to the contents of and attachments
> to this E-mail is strictly prohibited and may be unlawful. If
> you have received this E-mail in error, please notify the
> sender immediately and permanently delete the original and
> any copy of this E-mail and any printout.
>