Subject: Re: [sunset4] [v6ops] v6ops charter update discussion

From: "George, Wes" <[email-masked]>
Date: Wed, 15 Apr 2015 09:59:48 -0400

On 4/13/15, 7:57 PM, "Fred Baker (fred)" <[email-masked]> wrote:

>Lee and I are reviewing the v6ops charter. I have attached a proposed
>charter and diffs against the current one. Joel has not commented on this
>yet, and while we have run it by the sunset4 chairs, we haven’t gotten a
>reading from them. Sunset4 is relevant because possibly the
>ipv4-as-a-service discussion would be better handled there. In this
>email, I’m soliciting opinions in general
>The charter update started with Lee feeling that the fourth bullet of our
>current charter, which reads
>    4. Publish Informational or BCP RFCs that identify and analyze
>       solutions for deploying IPv6 within common network environments,
>       such as ISP Networks, Enterprise Networks, Unmanaged Networks
>       (Home/Small Office), and Cellular Networks.
>       (http://datatracker.ietf.org/wg/v6ops/charter/)
>is largely done. We know how to deploy IPv6.

WG] I agree. We're unlikely to spur additional deployment of IPv6 by
continuing to write the same document about how to deploy it for every
possible permutation of network we can think of. As others have said, I
don't think that it's explicitly prohibited if we come across a specific
case we think is useful to document, but it stops being the primary focus
of the WG.

>In addition, I think we need, collectively, to figure out how to get to
>IPv6-only.
WG] Yes, but Sunset4 is chartered for that, with enough flexibility to
cover both protocol changes and operational guidance/BCPs. I think what we
need to do is to identify in the sunset4 charter what you would either
carve off to move to v6ops, or how you would distinguish clearly between
the groups so that we all know what work goes where. When sunset4 was
being formed, the division was that v6ops was focused on transition to
IPv6 and dual-stack, and sunset4 was focused on IPv6-only including how to
actually turn off IPv4. What you're proposing blurs that line
significantly. http://datatracker.ietf.org/wg/sunset4/charter/ is a short
read, but anyone commenting on new work in this area needs to be familiar
with what it says. Sunset4 has been somewhat starved for attention, and I
think the overlap in the interested parties is a factor, so I'm not in
favor of increasing the overlap between the two WGs. It may be that
Sunset4 needs to refocus more exclusively on the IPv4 side of IPv6-only,
the turning off IPv4 part (shrinking it down to islands of ever-decreasing
size, identifying protocol changes necessary to actually disable it, etc)
while v6ops identifies gaps necessary to actually make IPv6-only work
everywhere, as well as how to get there (operational considerations on how
to use the available tools to move from dual-stack to IPv6-only).
I think in that model, IPv4-as-a-service fits in Sunset4 as one of the
transitions toward IPv6-only and shutting down IPv4, but it probably can
be debated either way. But again, I'm not convinced that any of that work
actually needs to move to v6ops.

> A large issue is “so how do we connect to IPv4 content and services from
>an IPv6-only network”, which is where ipv4-as-a-service comes in. I
>propose adding a bullet item regarding a road map to IPv6-only.
>
>    4. Describe an operational roadmap to IPv6-only network deployment,
>       with or without IPv4 delivered as an overlay or translation
>       service.

WG] this seems like a milestone rather than a charter item. i.e. Here is a
document discussing incremental moves toward IPv6-only, what tools are
available, considerations, etc.

>In my mind, that includes operational discussions of deployments and
>deployment issues in IPv4-as-a-service; one possible update would be to
>make that more explicit.
WG] yes, that would help to make this more of a charter item instead of a
single document milestone. Another possibility would be to make it clearer
that item 4 is going to discuss several areas, like mobile, enterprise,
datacenter, SP, and that those would all be separate, more in-depth, more
specific documents instead of one more generic one. But again, other than
documenting operational lessons learned from existing deployments, I'm
struggling to identify where the gap in sunset4's charter is that makes
this something that v6ops needs to take on

>The other three tasks remain unchanged - collect operational experience,
>identify operational and security risks, and turn them over to other
>working groups - notably 6man.

WG] I would rather see item 2 removed, as security discussions should
really be handled in Opsec. They're already doing a lot of good work on
IPv6 Security, and the general idea here is that IPv6 is in the deployment
phase now, such that it is an integral part of network security, and thus
should not be considered separately in most cases. There's nothing in
OpSec's charter that prevents them from addressing IPv6-specific security
issues as they arise, so it's not like we'd be limiting ourselves if we
remove this from the v6ops charter. We're dealing with a finite pool of
folks that focus on security and review security documents, and I'd rather
not spread them too thinly, so having that work consolidate into the
Operational Security WG seems like the right move.

>On another point, Lee and I have been discussing the operational reports
>we had at IETF 92, and feel that was time well spent. Those had a common
>thread, which was the deployment of Softwire’s MAP-E and MAP-T
>technologies in their networks. We are thinking about asking companies
>deploying IPv6 in Europe, Asia, and South America to make reports in the
>coming three meetings, on their IPv6 deployments and the issues they
>face. Would that be of general interest? How would you propose to tune
>that concept?

WG] I think this is a good idea, because it puts a larger focus in this
*operations* WG on operating networks and operator feedback, real
deployment experiences. Even if we're seeing duplication, it provides an
avenue to address the concerns that IETF has about not being able to
attract operators and operational feedback. That should serve as our
primary work input, because we will be able to identify places where
existing solutions maybe don't cover the problem adequately, or places
where it's clear that the existing guidance isn't being heeded, whether
because people don't know about it, or it's impractical, or whatever.

Thanks,

Wes George

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

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.