On 2/18/16, 1:04 AM, "Naoki Matsuhira" <[email protected]> wrote:
>Wes, > >I agree the necessity of problem statement. The draft of problem >statement must require before next Buenos Aires meeting ? or continue >on this mailing list? WG] it's always helpful to have a problem statement in a draft so that people who build a list of drafts to review prior to the meeting can review it ahead of time, but if you need to spend some time discussing it on the list to flesh it out, that's certainly fine. Either way, you need a clear problem statement and explanation of why your solution is necessary or uniquely suited to solving your problem compared with other options before the WG will be able to give you useful feedback at a meeting. >so I think GRE and IPv4 in IPv6 tunnel are the >comparison. These technology needs N^2 configuration to connect N with >fullmesh. For example, in enterprise network, there are dual stack >backbone and many dual stack stub network, and if backbone dual stack >network operation move to IPv6 only operation, M46E-FP should contribute. WG] Perhaps, but there are methods to reduce that mesh requirement through the use of hub and spoke topologies. Indeed in the case of GRE, it's possible to run routing protocols over those tunnels to make the network look like a contiguously connected IPv4 network. In fact, this is exactly what we did in the early days of the 6bone - we tunneled IPv6, BGP, and ISIS over GRE in IPv4 to build an interconnected IPv6 "backbone" network out of islands of IPv6-capable routers with IPv4-only connectivity between them. Tunneling like this has a lot of limitations, but N^2 configuration isn't necessarily one of them. I think you have some work ahead of you to convince people that interconnecting islands of legacy IPv4-only devices is best solved by encapsulating it over IPv6 (regardless of the encap/decap mechanism) rather than leaving the interconnecting network dual-stack until those legacy devices can be eliminated. If leaving the network dual-stack is impossible, I argue that the cleaner solution is using ALGs to translate to IPv6 as close to those those legacy IPv4-only devices as possible so that they can talk to the rest of the modern network and vice versa without requiring large portions of the network to remain IPv4-capable (and encapsulated over an IPv6-only backbone). The general goal in sunset4, and I think in IETF in general, is to focus on IPv6 transition technologies that increase deployment of IPv6 and enable network operators to shrink or eliminate their dependence on IPv4. The end state is an IPv6-only network, and things that indefinitely prolong the life of IPv4 and devices that require it, even if it's only in certain islands of the network, don't provide much progress toward that end state. Wes ________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/sunset4
