On 4/13/15, 7:57 PM, "Fred Baker (fred)" <f...@cisco.com> 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. _______________________________________________ sunset4 mailing list sunset4@ietf.org https://www.ietf.org/mailman/listinfo/sunset4
