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