On Tue, May 24, 2016 at 8:48 PM, Xuxiaohu <[email protected]> wrote: > Tom, > >> -----Original Message----- >> From: Tom Herbert [mailto:[email protected]] >> Sent: Wednesday, May 25, 2016 10:42 AM >> 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 Tue, May 24, 2016 at 7:01 PM, Xuxiaohu <[email protected]> wrote: >> > Joe, >> > >> > >> > >> > Please see my response inline with [Xiaohu] >> > >> > >> > >> > From: Joe Touch [mailto:[email protected]] >> > Sent: Wednesday, May 25, 2016 1:15 AM >> > To: Xuxiaohu; Fred Baker (fred); Wassim Haddad >> > Cc: [email protected] >> > Subject: Re: [Int-area] Call for adoption of >> > draft-xu-intarea-ip-in-udp-03 >> > >> > >> > >> > Two things below: >> > >> > On 5/24/2016 1:54 AM, Xuxiaohu wrote: >> > >> > Hi Joe, >> > >> > >> > >> > The draft is only intended to introduce one additional Softwires >> > encapsulation technology referred to as IP-in-UDP. >> > >> > >> > You had a similar draft that expired last summer targeted at the >> > Softwires WG (draft-xu-softwire-ip-in-udp). Why is this now targeted at >> Intarea? >> > >> > >> > >> > [Xiaohu] I was told by the Softwires WG co-chairs that the Softwires >> > WG is going to be shut down and therefore would not accept any new >> > draft. Hence, I think the Intarea WG should be the right place for this >> > work >> now. >> > >> > >> > >> > In other words, this encapsulation is only intended to be used within >> > Softwires networks which are well-managed by a service provider. This >> > encapsulation technology is not intended to be used within the >> > Internet. As such, it seems absolutely possible to configure the I-IP >> > transit core to carry an MTU at least large enough to accommodate the >> > added encapsulation headers. >> > >> > Although it has been said in the draft that “IP-in-UDP is just >> > applicable in those Softwires network environments where fragmentation >> > on the tunnel layer is not needed.” I can add a dedicated >> > Applicability Statement section to emphasize that this Softwires >> > encapsulation technology must only be used within Softwires networks >> > which are well-managed by a service provider and must not be used >> > within the Internet. Can this application statement address your concerns >> > on >> fragmentation and reassembly? >> > >> > >> > Here's the issue - >> > >> > I still do not think that this document should be a WG doc, and I >> > frankly don't think it's constructive for you to try to address each >> > flaw as it is raised. >> > >> > [Xiaohu] Trying to address each flaw as it is raised is not what we >> > IETF attendees are expected to do for any draft in the IETF? >> > >> > >> > Consider the following: >> > >> > A- you go to a restaurant and eat dinner >> > B - I ask you if you like it, and you say "no" >> > C- I ask why, and you say "it was too salty" >> > >> > Now, does that mean that if the cook corrects the salt level that you >> > would now like the food? >> > >> > Probably not. The same is true here. >> > >> > >> > >> > [Xiaohu] It’s a good example. Hence, for those people who say no to >> > the WG adoption of this draft due to technical reasons, please tell us >> > those technical reasons frankly. Let’s see whether those reasons are >> > true in the target scenario. And if they are true let’s see whether >> > they are addressable. >> > >> > >> > >> > I've given reasons I don't think it should be a WG doc. IF it is >> > accepted as a WG doc, I might decide how much resources I want to >> > devote to trying to address its deficiencies. >> > >> > [Xiaohu] I had expressed clearly that this Softwires encapsulation >> > technology is just targeted for Softwires networks which are well managed. >> > Therefore, fragmentation on the tunnel layer is not needed at all. I >> > don’t understand why you are still concerned about those things that >> > would not be issues at all in the target scenario. >> > >> Xiaohu, >> >> The technical issue has already been pointed out: there are already existing >> protocols that provide the same functionality, are generic and not >> restricted for >> a narrow use case, and have already seen significant effort into resolving >> all the >> issue with UDP encapsulation that Joe mentioned. This has been pointed out >> several times now and you haven't provided any explanation why these >> protocols are not sufficient for your use case. Hence this is why you're not >> seeing support to make it WG item. > > What's the existing and generic protocols that provide the same functionality > in your mind? GUE? If so, it seems reasonable for those X-in-UDP (X could be > VXLAN, VXLAN-GPE, GEVENE, NSH, TRILL) proposals to move forward to being > built on GUE rather than UDP since the former has resolved all the issues > with UDP encapsulation. However, have you seen any X that is moving towards > that direction?
The existing protocols that provide the same functionality are GUE and GRE/UDP. GUE allows encapsulation of any IP protocol over UDP, GRE will allow encapsulation of any Ethertype of UDP. Both of these provide a means to encapsulate of IPv4 and IPv6 in UDP. Tom > > Xiaohu > >> Tom >> >> > Best regards, >> > >> > Xiaohu >> > >> > Joe >> > >> > >> > _______________________________________________ >> > Int-area mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/int-area >> > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
