dear Yiu, i support your view on not including mss rewriting as a standard/mandatory way to solve the tunneling MTU issue. however, i have 2 observations:
1. mss rewriting could be an optional workaround for some operators in some circumstances. therefore it is worth implementing, IMHO. 2. regarding the issue of #21, fragmenting in IPv4 stack before entering the MAP module is not equal to the issue of "mss rewriting". MTU discovery can still work and help this functionality. on the other hand, as the fragment happens before the encapsulation, RFC2473 is not involved yet. it is equivalent to having a fragmenting box before the CE. as RFC2473 was written when the stateless mapping was not happening, it is reasonable that we make a new building block for the new demand of supporting anycast BR even when the datagram is to be fragmented. (is this as the same as Remi's proposal?) thanks and regards, maoke 2013/2/16 Lee, Yiu <[email protected]> > I was tasked in IETF-85 to find out why mss rewrite was removed before > publishing RFC6333. Here is my finding: > > Back in 2009-4-7, people in ML reported rewriting MSS would break TCP-AO > if TCP option flag set to 0. In IETF-75, Dave Thaler suggested to delete > mss rewrite from the draft. The argument was MTU is a generic issue for all > tunneling techniques, a separate draft should be written to address it > rather than including mss rewrite in a particular draft. Alain asked the WG > the question "Whether to remove fragmentation/mss discussion from the > document or to keep it". Dave Ward suggested to remove it. > > Discussion could be found in IETF-75 minute: > http://ietf.10.n7.nabble.com/Softwires-WG-meeting-Notes-td112138.html > > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
