Hi Ted, From: Ted Lemon [mailto:[email protected]] Sent: Friday, May 20, 2016 8:32 PM To: Xuxiaohu Cc: Joe Touch; Fred Baker (fred); Wassim Haddad; [email protected] Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03
On Fri, May 20, 2016 at 6:13 AM, Xuxiaohu <[email protected]<mailto:[email protected]>> wrote: Thanks for your comment. Note that it’s WG adoption call rather than WGLC. If I understand it correctly, as long as it’s worthwhile to provide fine-grained load-balancing of Softwire service traffic by leveraging the UDP tunnels, the WG should adopt it and then work on it, e.g., addressing those issues as you mentioned. The WG shouldn't adopt it unless there is a clear motivation for doing so, and no existing solutions to the same problem. That is the case you need to make. What various people are saying is that they don't believe you have made that case. That is how it appears to me as well. There are existing solutions to the same problem (i.e., how to improve the load-balancing efficiency for softwire traffic) and they are described in RFC5640. However, as it has been mentioned in the draft (see below), the existing solutions is are not adequate for efficient load balancing of Softwire service traffic across IP networks. “[RFC5640<https://tools.ietf.org/html/rfc5640>] describes a method for improving the load balancing efficiency in a network carrying Softwire Mesh service [RFC5565<https://tools.ietf.org/html/rfc5565>] over Layer Two Tunneling Protocol - Version 3 (L2TPv3) [RFC3931<https://tools.ietf.org/html/rfc3931>] and Generic Routing Encapsulation (GRE) [RFC2784<https://tools.ietf.org/html/rfc2784>] encapsulations. However, this method requires core routers to perform hash calculation on the "load- balancing" field contained in tunnel encapsulation headers (i.e., the Session ID field in L2TPv3 headers or the Key field in GRE headers), which is not widely supported by existing core routers.” The motivation has been explained clearly in the draft as follows, “Most existing routers in IP networks are already capable of distributing IP traffic "microflows" [RFC2474<https://tools.ietf.org/html/rfc2474>] over ECMP paths and/or Xu, et al. Expires August 3, 2016 [Page 2] ________________________________ <https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp-03#page-3> Internet-Draft Encapsulating IP in UDP January 2016 LAG based on the hash of the five-tuple of User Datagram Protocol (UDP) [RFC0768<https://tools.ietf.org/html/rfc0768>] and Transmission Control Protocol (TCP) packets (i.e., source IP address, destination IP address, source port, destination port, and protocol). By encapsulating the Softwire service traffic into an UDP tunnel and using the source port of the UDP header as an entropy field, the existing load-balancing capability as mentioned above can be leveraged to provide fine- grained load-balancing of Softwire service traffic traffic over IP networks. This is similar to why LISP [RFC6830<https://tools.ietf.org/html/rfc6830>] , MPLS-in-UDP [RFC7510<https://tools.ietf.org/html/rfc7510>] and VXLAN [RFC7348<https://tools.ietf.org/html/rfc7348>] use UDP encapsulation. ” If the GRE key or L2TPv3 session ID based LB approaches as described in RFC5640, and even the flow label based approach were good enough, it seems hard to understand why the IETF community is so wild about using UDP as a tunnel technology (note that it’s not intended for IPv4 underlay case only. Instead, it’s intended for both IPv4 and IPv6 underlay cases), see the following examples: p LISP [RFC6830] p VXLAN [RFC7348] p MPLS-in-UDP [RFC7510] p TRILL-in-UDP [draft-ietf-trill-over-ip-05] p NSH-in-UDP [draft-kumar-sfc-nsh-udp-transport] p VXLAN-GPE [draft-ietf-nvo3-vxlan-gpe<https://tools.ietf.org/wg/nvo3/draft-ietf-nvo3-vxlan-gpe/> ] p GENEVE [draft-ietf-nvo3-geneve<https://tools.ietf.org/wg/nvo3/draft-ietf-nvo3-geneve/> ] p GUE [draft-ietf-nvo3-gue<https://tools.ietf.org/wg/nvo3/draft-ietf-nvo3-gue/> ] p … If the above motivation seems still not enough to you, could you please explain the reason why you believe it’s not enough? Best regards, Xiaohu
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
