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? 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
