[sunset4] dionne-sunset4-v4gapanalysis and zhou-sunset4-scenarios

["George, Wes" <[e-mail]>]

Some comments on the two referenced drafts...

I put them both in the same email, because I think that the scenarios and gap analysis are closely related, even if the current drafts may not necessarily be today.
I think that we have two ways to go with this, either we have two drafts that are separate and interlinked, one that discusses scenarios and the other that covers the gaps in those scenarios that are necessary for IPv4 sunset,
or one combined document that briefly sets up a scenario, and then discusses the gaps associated with the scenario. It's possible that the decision as to which way this goes is related to whether there is a lot of commonality in the gaps, where they apply to multiple scenarios vs being specific to a given scenario.
I'm open to opinions, but I'd like to get some discussion started on that, either on list or during the meeting.

That said - I don't think that the current scenario draft really is covering the scenarios around IPv4 sunset. It actually looks like it is more about CGN scenarios, and common problems in CGN. I would like to see us those separated, because they really are a separate set of problems to solve. One of the things that we need to be clear on when looking at work in this WG is that IPv4 CGN != IPv4 sunset. CGN is a bridge to get us through the point where we must maintain support for legacy IPv4 now that addresses have exhausted, but in fact one of the scenarios for IPv4 sunset will be how to *turn off* the CGN IPv4 service, either all at once or in phases as a part of an orderly shutdown of IPv4 on a given network.

As with my comments on draft-li-behave-nat444-test, if we are going to put together a list of scenarios/gaps/problems for CGN, we need to be very clearly focused on the things that are both common to a generic type of application/traffic/protocol rather than a specific site/application, and that can be fixed either via BCP recommendations or standardizing CGN work (ALG or implementation guidance). In other words, we need to be able to articulate a problem for IETF to solve, rather than a problem for an individual implementer to solve. Further, we need to be thinking about whether the scenario and problems are applicable to IPv4 NAT  (like NAT44/NAT444) only, or whether it's more generic to NAT and address sharing (including things like DSLite, NAT64, etc). If it's not specific to IPv4, it may be a better candidate for BEHAVE, since they have already written multiple drafts covering BCP and requirements for applications to function properly through generic NATs. That work would need to serve as a starting point, where the authors would need to identify specific gaps and needs requiring us to bolster what's already there, but we're not necessarily chartered to do it if it's not a problem specific to IPv4.

Thanks,

Wes George, speaking mostly as Sunset4 co-chair

________________________________
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.