> -----Original Message----- > From: Tom Herbert [mailto:t...@herbertland.com] > Sent: Wednesday, May 25, 2016 12:05 PM > To: Xuxiaohu > Cc: Joe Touch; Fred Baker (fred); Wassim Haddad; int-area@ietf.org > Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 > > On Tue, May 24, 2016 at 8:48 PM, Xuxiaohu <xuxia...@huawei.com> wrote: > > Tom, > > > >> -----Original Message----- > >> From: Tom Herbert [mailto:t...@herbertland.com] > >> Sent: Wednesday, May 25, 2016 10:42 AM > >> To: Xuxiaohu > >> Cc: Joe Touch; Fred Baker (fred); Wassim Haddad; int-area@ietf.org > >> 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 <xuxia...@huawei.com> > wrote: > >> > Joe, > >> > > >> > > >> > > >> > Please see my response inline with [Xiaohu] > >> > > >> > > >> > > >> > From: Joe Touch [mailto:to...@isi.edu] > >> > Sent: Wednesday, May 25, 2016 1:15 AM > >> > To: Xuxiaohu; Fred Baker (fred); Wassim Haddad > >> > Cc: int-area@ietf.org > >> > 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.
Which is more generic? If both are generic, why we need two? Xiaohu > Tom > > > > > Xiaohu > > > >> Tom > >> > >> > Best regards, > >> > > >> > Xiaohu > >> > > >> > Joe > >> > > >> > > >> > _______________________________________________ > >> > Int-area mailing list > >> > Int-area@ietf.org > >> > https://www.ietf.org/mailman/listinfo/int-area > >> > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
