Hi Fred, Thanks for your comment. Please see my response inline.
From: Int-area [mailto:[email protected]] On Behalf Of Fred Baker (fred) Sent: Friday, May 20, 2016 1:53 AM To: Wassim Haddad Cc: [email protected] Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 I, for one, am opposed. I have two issues. One is summarized fairly succinctly in RFC 1326; there are technical issues in mutual encapsulation. The other is in the general form of "good grief". I don't think the draft adequately [Xiaohu] I’m confused by your intention of raising the technical issues in mutual encapsulation as described in RFC1326. Are you against the necessity of Softwire services (e.g., IPv6-over-IPv4)? argues for yet-another-tunnel format.It tells how to do it and asks for a port number, but the arguments for doing it don't make sense to me. [Xiaohu] The argument for doing IP-in-UDP is clearly described in the Introduce section as follows: To fully utilize the bandwidth available in IP networks and/or facilitate recovery from a link or node failure, load balancing of traffic over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG) across IP networks is widely used. [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. 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. In addition, the use of UDP tunnels with source port being used as an entropy field has been widely accepted in the IETF community (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/> ] GUE [draft-ietf-nvo3-gue<https://tools.ietf.org/wg/nvo3/draft-ietf-nvo3-gue/> ] It seems very straightforward to use the UDP tunnels to carry IP traffic as well in the Softwire scenarios. Best regards, Xiaohu On May 19, 2016, at 10:03 AM, Wassim Haddad <[email protected]<mailto:[email protected]>> wrote: Dear all, The authors of draft-xu-intarea-ip-in-udp-03 (“Encapsulating IP in UDP”) have requested that the working group adopt this work as a WG work item. So far, WG chairs have not seen widespread support and considering that lack of opposition does not qualify as support, we’re starting a working group adoption call until June 3rd. If you consider that the draft should be adopted as a WG work item, please indicate the reason. Regards, Wassim & Juan Carlos _______________________________________________ Int-area mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
