Hi Brian, > -----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. > 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? Thanks - Fred [email protected] > Brian > > Better > > would be to initially have the CPE set an infinite MTU > > on the tunnel interface, set DF=0 on all tunneled packets, > > and have the tunnel far end report any fragmentation. > > (Note that I *did not* say that the tunnel far end has > > to reassemble.) > > > > That way, if the operator has not done something crappy > > there is a very good change that 1500+ packets will get > > through and not be blocked by the overly-conseravative > > 1480. > > > > Fred > > [email protected] > > > >> regs, > >> Alexandre > >> > >> _______________________________________________ > >> 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
