Fred, I agree that distinguishing between pragmatic operational practices (such as clamping the MTU) and generic solutions is correct, but as far as the current last call goes, I think that leaving the generic solution FFS is also correct.
I don't think the text in section 9.1 really needs changing. It doesn't exclude future mechanisms, it simply recommends what to do if there is no MTU discovery or management in place. Regards Brian On 2010-03-03 05:51, Templin, Fred L wrote: > Brian, > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Brian E Carpenter >> Sent: Tuesday, March 02, 2010 1:00 AM >> To: Rémi Després >> Cc: [email protected]; Templin, Fred L >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd >> >>> As far as 6rd is concerned, doing it right is IMO keeping it as is. >> Yes, given that we have just been told at APRICOT that the vast majority >> of Google and YouTube's IPv6 traffic comes from one particular ISP in >> France. It's a real success story, with a clamped MTU. > > You are right that the MTU clamping seems to be the approach > being advocated under 6rd, but I disagree that that is the > best we can (or should) do. > > During the NGTRANS days, the ISATAP team was strongly required > to include a "Domain of Applicability" statement, and I think > the same should be required of 6rd. I see a number of aspects > of 6rd that IMHO would limit its applicability, including: > > - IPv6 prefix tied to IPv4 address (renumbering implications) > - potential black holes when ICMPs can't be translated > - provider-aggregated addressing only (no provider-independent) > - not compatible with multihoming via a single, stable IPv6 prefix > - not compatible with traffic engineering (i.e., CE can't select > specific BRs) > - interactions with load balancing; ECMP within provider network > - MTU clamping exposes degenerate MTUs to the customer network > and doesn't allow for automatic discovery of larger MTUs > - requires operators to exercise tight controls on link MTUs > - requires operators to exercise tight controls on ICMP > generation and ICMP filtering > > So, while I see the 6rd stateless prefix delegation as a > highly desirable contribution, I think the implications > of these limitations should somehow be captured in an > applicability statement the same as was required for the > NGTRANS mechanisms. > > Thanks - Fred > [email protected] > >> Brian >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
