Remi, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Rémi Després > Sent: Thursday, February 25, 2010 11:04 PM > To: Ole Troan > Cc: [email protected]; Templin, Fred L > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > Hi Fred, > > Although the SEAL approach has IMHO some merit of its own for some > generalized tunneling scenarios, > using it in 6rd would defeat the objective of simplicity for "rapid > deployment" of IPv6.
There is an opportunity at hand to get tunneling done right the first time and then have a long-term quality IPv6 service. 6rd is a large piece to the puzzle, but there are other pieces that would make for a more complete solution. IMHO, we can have it both ways of doing it fast *and* doing it right on the first iteration. Fred [email protected] > The draft should therefore proceed as is on this subject. > > RD > > > Fred, > > > >>> -----Original Message----- > >>> From: Brian E Carpenter [mailto:[email protected]] > >>> Sent: Thursday, February 25, 2010 12:09 PM > >>> To: Templin, Fred L > >>> Cc: [email protected]; [email protected] > >>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >>> > >>> Hi Fred, > >>> > >>> On 2010-02-26 06:25, Templin, Fred L wrote: > >>>> > >>>>> -----Original Message----- > >>>>> From: [email protected] [mailto:[email protected]] On > >>>>> Behalf Of Alexandre > Cassen > >>>>> Sent: Wednesday, February 24, 2010 2:05 AM > >>>>> To: [email protected] > >>>>> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >>>>> > >>>>> Hi, > >>>>> > >>>>> On Mon, 22 Feb 2010 16:43:00 -0500, Durand, Alain wrote: > >>>>>> We'd like to announce the softwire WG LC on the 6rd technology. I've > >>>>>> copied both SOFTWIRE and DHC mailing lists and solicit comments from > >>>>>> both groups of experts. The draft is here: > >>>>>> > >>>>>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt > >>>>>> > >>>>>> Please reply with comments to this thread by 2010.03.08 at 1700 PST > >>>>> This document truly depict what we are running into production in our > >>>>> backbone here. I strongly support it! > >>>>> > >>>>> I read some post on the ML regarding fragmentation and MTU related. > >>>>> IMHO, section 9.1 is enough explicit, anyone playing around with > >>>>> encapsulation will face at one point MTU issues and fragmentation, it is > >>>>> really common. Any operational networking guy will/have to keep in mind > >>>>> this MTU stuff while designing/setting up its encapsulation > >>>>> architecture. What is important here, 6rd is operating inside a specific > >>>>> routing domain so that if there is MTU/fragmentation issues then it is > >>>>> networking domain designer job/responsibility to fix it ! if networking > >>>>> design has been made into a crappy way then it will transitively operate > >>>>> into a crappy way too. IMHO, it should certainly not be the focus of an > >>>>> operational protocol draft, like 6rd, to provide a networking course. > >>>>> > >>>>> In our production env, MTU is set to 1480 at CPE side. > >>>> > >>>> Here's another thing to consider wrt the 1480. Once the > >>>> CPE statically sets a 1480, it will be next to impossible > >>>> to get it to set something larger in the future. > >>> > >>> So what? 6RD is definitely a transition technique running over > >>> legacy IPv4. I think we have running code experience that > >>> defaulting the MTU to 1480 will work in most normal circumstances, > >>> whereas reliance on PMTUD is known to be problematic. > >> > >> To be clear, I am not asking for reliance on PMTUD. I am > >> instead asking for reliance on something better than that > >> (SEAL) so that no artificial limits like 1480 are needed. > > See above. > > >> > >>> If 1480 > >>> becomes an issue, it will become part of the motivation to upgrade > >>> to native IPv6. > >> > >> This kind of argument strikes me as a business-oriented > >> rather than technical viewpoint on the problem space. We > >> now have technologies by which we can deploy tunneled > >> service that is as good as or perhaps even better than > >> native (and yes, I include 6rd as part of the solution). > >> So, why not have a once-and-done deployment now as opposed > >> to putting up a temporary service which we know will need > >> replacement in the near future? So that network equipment > >> vendors can sell more products and services? > > > > I do agree that MTU handling is a general problem, and not even just for > > tunnels. > > I thought we agreed while discussing earlier versions of this draft, not to > > encumber the 6rd > specification with the general solutions to these MTU problems. > > This is IMHO the right approach. > > > 6rd references RFC4213 for most of the tunnel mechanics. could we move that > > debate to rfc4213bis or > something? > > > > cheers, > > Ole > > _______________________________________________ > > Softwires mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
