> -----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.
In the above case, there are three FEASIBLE ways: 1) Configure the transit core to carry an MTU at least large enough to accommodate the added encapsulation headers. Note that this is the dominant and mature choice in most MPLS networks; 2) Fragment the packet before encapsulation if allowed; 3) Drop it if inner fragmentation is not allowed. > That was true in 1983 and will still be true in 2083. Could you give a concrete example in real network environment where outer fragmentation is widely enabled and works very well before making such an assertion? It would be better if the reassembly buffer size needed in the tunnel egress could be given as well. Xiaohu > 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
