From: Carlos Pignataro (cpignata) [mailto:[email protected]] Sent: Monday, May 30, 2016 10:57 PM To: Xuxiaohu Cc: Wassim Haddad; [email protected] Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03
Xiaohu, Please see inline. On May 30, 2016, at 6:09 AM, Xuxiaohu <[email protected]<mailto:[email protected]>> wrote: Carlos From: Int-area [mailto:[email protected]] On Behalf Of Carlos Pignataro (cpignata) Sent: Saturday, May 28, 2016 10:34 PM To: Wassim Haddad Cc: [email protected]<mailto:[email protected]> Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 Wasim, Juan Carlos, Back to your original request, I do not support adoption of draft-xu-intarea-ip-in-udp. I also did not support draft-xu-softwire-ip-in-udp. I do not believe there’s a case for this new tunnel type. I also believe that a deeper look at the potential problem space can yield better solutions, as opposed to a solution looking for a problem. The problem associated with the LB approach as proposed in [RFC5640<https://tools.ietf.org/html/rfc5640>] is obvious. Obviousness implies some qualitative form of value judgement. As a technical term, it falls largely short. If you feel it is obvious, and you feel t’s important, make it so, because it is not. RFC7510 proposes to use UDP tunnels instead of GRE or L2TPv3 tunnels to carry MPLS traffic so as to provide fine-grained load balancing of MPLS traffic over well-managed IP networks (by leveraging the widely supported UDP-based LB capability). It seems that you are a proponent of the above rationale as you are a contributor of that RFC. Now draft-xu-intarea-ip-in-udp just extends that rationale to another well-managed IP network environment(i.e., Softwires network). Why that rationale becomes “a solution looking for a problem” suddenly? Does the efficiency of GRE key or L2TPv3 session ID based LB approaches as proposed by RFC5640 depend on the payload type of those tunnels? Best regards, Xiaohu You mention RFC 5640. We seem to have managed since 2009 (publishing date) without a new tunnel type. But more importantly, RFC 5640 concerns itself with a different problem space: augmenting BGP signaling, not defining a new tunnel type and UDP port. Thanks, — Carlos. In other words, there is no need for looking for at all. With regard to whether or not the IP-in-UDP encapsulation is the best solution to that problem, it is another thing. Xiaohu Thanks, — Carlos Pignataro. On May 19, 2016, at 1:03 PM, 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
