[sunset4] v6ops charter update discussion

[Fred Baker (fred)]

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.

In addition, I think we need, collectively, to figure out how to get to IPv6-only. 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.

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.

In other respects, the update is mostly editorial.

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

Hoping for your input. Do you agree with these changes? If not, what changes, or further changes, would you recommend?

As to proposed milestones, I’d like to believe that

these are done:
draft-ietf-v6ops-6to4-to-historic
draft-ietf-v6ops-cidr-prefix

we can finalize and ship these by July:
draft-ietf-v6ops-design-choices
draft-ietf-v6ops-pmtud-ecmp-problem

and these by November:
draft-ietf-v6ops-siit-dc-*
(would like a deployment report for siit-dc and siit-dc-2xlat in support)
(would like one for 464xlat as well)

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?

[Mikael Abrahamsson]

Post by Fred Baker (fred)
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.

Hm, while I generally agree with you, does this mean that these kinds of
RFCs will be out-of-scope for v6ops going forward? I would hate for us to
take this out of the charter and then turn people away when they show up
with a document for a solution we didn't think of yet.

Or perhaps paragraph 1 is enough to allow for capturing these kinds of
documents?

Post by Fred Baker (fred)
4. Describe an operational roadmap to IPv6-only network deployment,
with or without IPv4 delivered as an overlay or translation
service.

Fully agreed.

Post by Fred Baker (fred)
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?

I think this is worthwile, as long as it's not going to be come a long
list of 10-15 minute presentations saying the same thing. For those, we
can keep it on the list. I always welcome operational reports in the
meetings, but they need to contain news, not "we experienced the same
thing as <foo> and solved it the same way".

I would like to hear from the ds.lite deployers out there, I know they
exist. Also from 464XLAT+NAT64 deployments (probably in mobile).

[Brian E Carpenter]

Post by Fred Baker (fred)
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.

Hm, while I generally agree with you, does this mean that these kinds of RFCs will be out-of-scope for v6ops going forward? I
would hate for us to take this out of the charter and then turn people away when they show up with a document for a solution we
didn't think of yet.

I agree that we should not exclude such work, and it could be that the
existing documents need corrections, but on the other hand the time
for soliciting new work in this area is past.

Or perhaps paragraph 1 is enough to allow for capturing these kinds of documents?

Yes, because it mentions "solutions".

Post by Fred Baker (fred)
4. Describe an operational roadmap to IPv6-only network deployment,
with or without IPv4 delivered as an overlay or translation
service.

Fully agreed.

Post by Fred Baker (fred)
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?

I think this is worthwile, as long as it's not going to be come a long list of 10-15 minute presentations saying the same thing.
For those, we can keep it on the list. I always welcome operational reports in the meetings, but they need to contain news, not
"we experienced the same thing as <foo> and solved it the same way".

Correct, and I don't think it needs to be strictly regional, although
that may be a travel optimisation. I would suggesting soliciting lightning
talks on ipv6-***@lists.cluenet.de. There are handy messages there from
time to time, like
http://lists.cluenet.de/pipermail/ipv6-ops/2014-December/010402.html

Brian

I would like to hear from the ds.lite deployers out there, I know they exist. Also from 464XLAT+NAT64 deployments (probably in
mobile).
_______________________________________________
v6ops mailing list
https://www.ietf.org/mailman/listinfo/v6ops

[joel jaeggli]

Post by Fred Baker (fred)
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.

not to cast aspersions in any direction in particular, but if we seem
operators running such things and have cause to provide advice on them
then by all means I'm fine with that here.

that seems consistent with work on for example 464xlat

Post by Fred Baker (fred)
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.

I largely agree that some victory can be declared there.

Post by Fred Baker (fred)
In addition, I think we need, collectively, to figure out how to get
to IPv6-only. 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.

I think we're probably front-running the community of contributors by a
fair bit, but I think there are people and projects niddling around the
edges even as they employ some transition mechanism for backwards
compatibility.

Post by Fred Baker (fred)
4. Describe an operational roadmap to IPv6-only network deployment,
with or without IPv4 delivered as an overlay or translation service.
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.
In other respects, the update is mostly editorial.
The other three tasks remain unchanged - collect operational
experience, identify operational and security risks, and turn them
over to other working groups - notably 6man.

yup

Post by Fred Baker (fred)
Hoping for your input. Do you agree with these changes? If not, what
changes, or further changes, would you recommend?
As to proposed milestones, I’d like to believe that
these are done: draft-ietf-v6ops-6to4-to-historic
draft-ietf-v6ops-cidr-prefix
draft-ietf-v6ops-design-choices draft-ietf-v6ops-pmtud-ecmp-problem
and these by November: draft-ietf-v6ops-siit-dc-* (would like a
deployment report for siit-dc and siit-dc-2xlat in support) (would
like one for 464xlat as well)
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?
_______________________________________________ sunset4 mailing list

[George, Wes]

Post by Fred Baker (fred)
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.

Post by Fred Baker (fred)
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.

Post by Fred Baker (fred)
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.

Post by Fred Baker (fred)
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

Post by Fred Baker (fred)
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.

Post by Fred Baker (fred)
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.