> -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Thursday, June 02, 2016 4:23 AM > To: Xuxiaohu; Joe Touch > Cc: joel jaeggli; Fred Baker (fred); Wassim Haddad; [email protected] > Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 > > Hi, > > > I would like to add a dedicated Applicability Statement section > > I think that would be very useful. Indeed, the whole Softwires concept needs > an > Applicability Statement.
Hi Brian, Thanks for your advice. Best regards, Xiaohu > Regards > Brian > > > On 01/06/2016 18:26, Xuxiaohu wrote: > > > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:[email protected]] > >> Sent: Wednesday, June 01, 2016 1:14 PM > >> To: Xuxiaohu; Joe Touch > >> Cc: joel jaeggli; Fred Baker (fred); Wassim Haddad; [email protected] > >> Subject: Re: [Int-area] Call for adoption of > >> draft-xu-intarea-ip-in-udp-03 > >> > >> I think I detest fragmentation, or rather re-assembly, as much as > >> anybody, whether designing hardware or software solutions. And of > >> course, in a closely managed environment, you can ensure that the > >> outer MTU is sufficient to contain the inner MTU. That isn't the > >> point. The point is that designing a protocol > > > > It said in the draft that "... this specification defines an IP-in-UDP > > encapsulation > method dedicated for Softwire service (including both mesh and hub-spoke > modes). " Softwire networks are well-managed SP networks. I would like to add > a dedicated Applicability Statement section to emphasize it if the current > statement seems not enough. > > > > Best regards, > > Xiaohu > > > >> proposed as a general-purpose protocol for the Internet, that might > >> be used for a hundred years, we can't guarantee that it will always > >> be deployed in such a managed environment. In fact, we can pretty > >> much guarantee that it will be used in completely unmanaged (or badly > managed) ways. > >> > >> This isn't theory. We've seen it a lot where IPv6 has been tunneled > >> across > >> IPv4 islands, with lots of MTU and fragmentation failures. That's > >> even simpler than IP in UDP in IP. > > > >> Regards > >> Brian > >> > >> On 01/06/2016 16:09, Xuxiaohu wrote: > >>> > >>> > >>>> -----Original Message----- > >>>> From: Brian E Carpenter [mailto:[email protected]] > >>>> Sent: Wednesday, June 01, 2016 4:01 AM > >>>> To: Xuxiaohu; Joe Touch > >>>> Cc: joel jaeggli; Fred Baker (fred); Wassim Haddad; > >>>> [email protected] > >>>> Subject: Re: [Int-area] Call for adoption of > >>>> draft-xu-intarea-ip-in-udp-03 > >>>> > >>>> On 31/05/2016 20:13, Xuxiaohu wrote: > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Brian E Carpenter [mailto:[email protected]] > >>>>>> Sent: Tuesday, May 31, 2016 4:46 AM > >>>>>> To: Joe Touch > >>>>>> Cc: joel jaeggli; Xuxiaohu; Fred Baker (fred); Wassim Haddad; > >>>>>> [email protected] > >>>>>> Subject: Re: [Int-area] Call for adoption of > >>>>>> draft-xu-intarea-ip-in-udp-03 > >>>>>> > >>>>>> And being pedantic... > >>>>>> On 31/05/2016 06:12, Joe Touch wrote: > >>>>>>> > >>>>>>> > >>>>>>> On 5/29/2016 4:23 PM, joel jaeggli wrote: > >>>>>>>>>> I.e., you MUST support source fragmentation at the ingress at > >>>>>>>>>> the outer > >>>>>>>>>> IPv6 layer (because UDP doesn't have support for > >>>>>>>>>> fragmentation and reassembly). If you make this requirement, > >>>>>>>>>> you can handle > >>>>>>>>>> IPv6 over the tunnel. > >>>>>>>> Yeah I don't support it for this reason. getting IP fragments > >>>>>>>> back together in the same place a reassembled is hard is in > >>>>>>>> some cases especially when you hash. (see frag drop) given > >>>>>>>> alternatives that better address such situations it seems hard to > justify. > >>>>>>> > >>>>>>> If you intend to support recursive IP tunneling* and believe > >>>>>>> that IP has a minimum MTU, then you have to accept reassembly. > >>>>>> > >>>>>> If you intend to support recursive datagram tunneling and believe > >>>>>> that any path has a minimum MTU, then you have to accept reassembly. > >>>>>> > >>>>>> This is physics, and nothing to do with design details. > >>>>>> > >>>>>> (Something I discovered in about 1983, when implementing OSI/CLNP > >>>>>> at CERN over a homebrew network with 128 byte packets.) > >>>>> > >>>>> Reassembly on the tunnel egress may be acceptable at that old time. > >>>>> However, > >>>> due to the considerable improvement in network bandwidth > >>>> capability, the practice acceptable at the old time may have become > outdated today. > >>>> > >>>> I don't understand what network capacity has to do with the > >>>> physical and mathematical fact that packets larger than N bytes > >>>> will not fit into a packet limited to N bytes. > >>> > >>> This article > >> (http://learning.nil.com/assets/Tips-/The-Never-Ending-Story-of-IP-Fr > >> agmentati > >> on.pdf) may be useful for you to understand why network capability is > >> a key factor to be considered for fragmentation and reassembly on > >> routers (here routers are not software routers or CPU-only routers > >> which were dominant in the old time). Of course, you could also have > >> a look at the current fragmentation and reassembly implementations of > >> major router vendors if you believed that article is a little bit old. > >>> > >>> Xiaohu > >>> > >>>> That was true in 1983 and will still be true in 2083. > >>>> > >>>> Brian > >>>> > >>>>> See the MAP implementation experience shared by Ole recently. > >>>>> > >>>>> Xiaohu > >>>>> > >>>>>> Brian > >>>>>> > >>>>>>> > >>>>>>> Joe > >>>>>>> > >>>>>>> * where "recursive IP tunneling" is IP in [zero or more other > >>>>>>> protocols] in IP. > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> Int-area mailing list > >>>>>>> [email protected] > >>>>>>> https://www.ietf.org/mailman/listinfo/int-area > >>>>>>> _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
