Hi Ole, > -----Original Message----- > From: lisp [mailto:[email protected]] On Behalf Of [email protected] > Sent: Friday, May 27, 2016 6:50 PM > To: Xuxiaohu > Cc: Softwires WG; [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [lisp] [Softwires] Is it feasible to perform fragmentation on UDP > encapsulated packets. > > > <Note that I have changed the subject of the email hence it has nothing to > > do > with the WG adoption call now. It's just a discussion on a particular issue > which is > related to those WGs which are working on UDP tunnels. The reason for > containing the old email is to use it as a background which may be useful for > better understanding of this particular issue> > > > > The possible side-effect of performing fragmentation on UDP encapsulated > packets is to worsen the reassembly burden on tunnel egress since fragments of > UDP encapsulated packets are more likely to be forwarded across different > paths towards the tunnel egress than those of IP or GRE encapsulated packets. > > > > It seems that most X-over-UDP proposals choose to prohibit the tunnel > > ingress > from performing fragmentation on UDP encapsulated packets. See the following > quoted text regarding fragmentation from those X-over-UDP drafts: > > > > LISP: > > > > When an ITR receives a packet from a site-facing interface and adds H > > octets worth of encapsulation to yield a packet size greater than L > > octets, it resolves the MTU issue by first splitting the original > > packet into 2 equal-sized fragments. A LISP header is then prepended > > to each fragment. > > > > VXLAN: > > > > VTEPs MUST NOT fragment VXLAN packets. Intermediate routers may > > fragment encapsulated VXLAN packets due to the larger frame size. > > The destination VTEP MAY silently discard such VXLAN fragments. > > > > VXLAN-GPE: > > > > VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when > > the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer > > IPv4 header. > > > > GEVENE: > > > > To prevent fragmentation and maximize performance, the best practice > > when using Geneve is to ensure that the MTU of the physical network > > is greater than or equal to the MTU of the encapsulated network plus > > tunnel headers. > > > > GUE: > > > > If a packet is fragmented before encapsulation in GUE, all the > > related fragments must be encapsulated using the same source port > > (inner flow identifier). An operator may set MTU to account for > > encapsulation overhead and reduce the likelihood of fragmentation. > > > > GRE/UDP > > > > Regarding packet fragmentation, an encapsulator/decapsulator SHOULD > > be compliant with [RFC7588] and perform fragmentation before the > > encapsulation. > > > > However, the above choice seems conflict with the requirements as described > in https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02 > > > > > > I wonder whether the IETF should reach a consensus on whether or not the > fragmentation on UDP encapsulated packets should be allowed. > > Having just implemented fragmentation and reassembly support in a MAP BR... > > MAP does IPv4 over IPv6 tunnels with shared IPv4 address (aka routing on > ports). > > - Inner IPv4 fragmentation is relatively easy, cause you don't need to > reassemble > you can do virtual reassembly > - Outer IPv6 reassembly is much harder, cause you have to do it on the tunnel > egress. > > It is not possible to implement reassembly complying with IETF RFCs. > The IPv4 reassembly buffer is specified in IPv4 as 15 seconds, in IPv6 as 60 > seconds. > My implementation does upwards of 100Mpps, you do the numbers.
Thanks a lot for sharing your implementation experience! > If you can: > - Guarantee always in sequence > - Maximum fragment chain of 2 > - Maximum time and packet gap between first and last fragment of > _very_small_ > > Then sure it is implementable, but if not then you're just setting yourself > up for a > DOS attack. > And if you have that much control over the environment, just increase the MTU > in the tunnel domain. I couldn't agree more. > Code is here: > https://git.fd.io/cgit/vpp/tree/vnet/vnet/map/ip6_map.c#n530 > > So in short, IETF can say whatever they like, that's not going to change > reality. Wouldn't it be better if the IETF guidelines on tunnel fragmentation could be more in conformity with the reality? Best regards, Xiaohu > Best regards, > Ole > > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
