Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03

[Xuxiaohu <[e-mail]>]

> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Wednesday, May 25, 2016 12:05 PM
> To: Xuxiaohu
> Cc: Joe Touch; Fred Baker (fred); Wassim Haddad; [e-mail]
> 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 <[e-mail]> wrote:
> > Tom,
> >
> >> -----Original Message-----
> >> From: Tom Herbert [mailto:[e-mail]]
> >> Sent: Wednesday, May 25, 2016 10:42 AM
> >> To: Xuxiaohu
> >> Cc: Joe Touch; Fred Baker (fred); Wassim Haddad; [e-mail]
> >> 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 <[e-mail]>
> wrote:
> >> > Joe,
> >> >
> >> >
> >> >
> >> > Please see my response inline with [Xiaohu]
> >> >
> >> >
> >> >
> >> > From: Joe Touch [mailto:[e-mail]]
> >> > Sent: Wednesday, May 25, 2016 1:15 AM
> >> > To: Xuxiaohu; Fred Baker (fred); Wassim Haddad
> >> > Cc: [e-mail]
> >> > 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
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/int-area
> >> >