On Fri, May 27, 2016 at 7:59 PM, Xuxiaohu <xuxia...@huawei.com> wrote: > Hi Tom, > >> -----Original Message----- >> From: Tom Herbert [mailto:t...@herbertland.com] >> Sent: Friday, May 27, 2016 11:06 PM >> To: Xuxiaohu >> Cc: int-a...@ietf.org; Softwires WG; n...@ietf.org; lisp@ietf.org; >> ts...@ietf.org >> Subject: Re: [Int-area] Is it feasible to perform fragmentation on UDP >> encapsulated packets. >> >> > 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. >> > >> >> Xiaohu, >> >> I don't understand why UDP encapsulation would make things worse than other >> encapsulations. Fragmentation would be needed at tunnel ingress when packet > > When performing fragmentation after UDP encapsulation (a.k.a., outer > fragmentation), the first fragment (still a UDP packet) and the subsequent > fragments (not a UDP packet anymore) of a given UDP encapsulated packet are > more likely to be routed over different paths in contrast to IP or GRE > encapsulated packets. As a result, the reordering issue on the tunnel egress > which is required to do reassembly would become even worse. > Presumably you are referring to ECMP and devices that parse the transport header to use port information in the hash. There are two ways this can be "fixed" in devices that do ECMP. 1) If the packet is a fragment don't parse the transport header. This way all fragments will be ECMP routed based on just L3 information so they all take the same path. 2) Use non-zero IPv6 flow label and don't parse L4 header to do ECMP. This means all fragments and all non-fragments of a flow will follow the same path. The flow label approach also works with protocols other than TCP and UDP as well as any arbitrary list of extension headers. Both of these techniques have been implement in Linux stack.
>> size exceeds MTU of the tunnel. RFC4459 describes the issues and general >> solutions that apply to the different techniques of IP tunneling. > > Partially agree. The use of UDP as a tunneling protocol was not popular at > the time when RFC4459 was published. Otherwise, the worse recording issue > associated with the outer fragmentation of UDP encapsulated packets may need > more attention in that RFC. > Yes, but UDP was popular long before it was used for tunneling and the problems with it of fragmentation/reassembly were well known. Considering tunneling with UDP doesn't really change anything, the same solutions (like those listed in RFC4459) still apply. > By the way, RFC4459 has illustrated the risk of performing [outer] > fragmentation on tunneled packets clearly and said clearly that "... So, if > reassembly could be made to work sufficiently reliably, this would be one > acceptable fallback solution but only for IPv6." However, I just occasionally > noticed that in section 3.3.2.1 (Tunneling GRE over IPv4) of RFC7588, it said > "By default, the GRE ingress node does not fragment delivery packets. > However, the GRE ingress node includes a configuration option that allows > delivery packet fragmentation." Does it mean there is a conflict between > those two RFCs regarding whether outer fragmentation is needed for GRE over > IPv4? > >> > 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: >> > >> Please look a draft-herbert-gue-fragmentation-02. This is a method where the >> fragmentation/reassembly is performed in the encapsulation layer instead of >> (outer or inner) IP layer. > > It's an interesting idea. However, since it needs a dedicated fragmentation > field in the GUE header, it seems that this approach is not suitable for the > compressed GUE packet (a.k.a., in the same format of IP-in-UDP) where the > fragmentation field and even the whole GUE header is gone. > Different header formats can be used for different packets in the same flow. The outer UDP header and flow label are sufficient for ECMP, as long devices aren't parsing into the GUE payload to do ECMP then all packets for a flow (fragmented or not) should follow the same path. Tom > Best regards, > Xiaohu > >> Tom _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
