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. Regards Brian On 01/06/2016 18:26, Xuxiaohu wrote: > > >> -----Original Message----- >> From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] >> Sent: Wednesday, June 01, 2016 1:14 PM >> To: Xuxiaohu; Joe Touch >> Cc: joel jaeggli; Fred Baker (fred); Wassim Haddad; int-area@ietf.org >> 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:brian.e.carpen...@gmail.com] >>>> Sent: Wednesday, June 01, 2016 4:01 AM >>>> To: Xuxiaohu; Joe Touch >>>> Cc: joel jaeggli; Fred Baker (fred); Wassim Haddad; int-area@ietf.org >>>> 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:brian.e.carpen...@gmail.com] >>>>>> Sent: Tuesday, May 31, 2016 4:46 AM >>>>>> To: Joe Touch >>>>>> Cc: joel jaeggli; Xuxiaohu; Fred Baker (fred); Wassim Haddad; >>>>>> int-area@ietf.org >>>>>> 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-Fragmentati >> 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 >>>>>>> Int-area@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/int-area >>>>>>> _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
