I agree on your comment about more use cases. We should consider all those scenarios and see what fits the bill.
Arashmid -----Original Message----- From: Tom Herbert [mailto:t...@quantonium.net] Sent: 27 March 2018 15:59 To: Arashmid Akhavain <arashmid.akhav...@huawei.com> Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; dmm@ietf.org Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 On Tue, Mar 27, 2018 at 11:47 AM, Arashmid Akhavain <arashmid.akhav...@huawei.com> wrote: > ID-LOC (SRV6, ILA, LISP, ILNP) would cover these use cases easily > since UE ID remains the same no matter what access technology we use. Right, but I haven't seen anyone suggest GTP-U or CAPWAP for that list. There are more use cases now that seem to demand a more general and common encapsulation technique. Tom > Without ID-LOC, there is always going to be a need for all sort of > complicated control plane hand over procedures. > Also, we end up with n2 interworking issue as we add more access technologies > to the mix. > > Arashmid > > -----Original Message----- > From: Tom Herbert [mailto:t...@quantonium.net] > Sent: 27 March 2018 14:25 > To: Arashmid Akhavain <arashmid.akhav...@huawei.com> > Cc: Satoru Matsushima <satoru.matsush...@gmail.com>; dmm@ietf.org > Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 > > On Tue, Mar 27, 2018 at 11:08 AM, Arashmid Akhavain > <arashmid.akhav...@huawei.com> wrote: >> Tom, >> Are you referring to a use case where the UE moves between different access >> technologies? >> > I think it's possible and should be a consideration. Countless devices are > already regularly multihomed between WiFi and mobile. > > Tom > > >> Arashmid >> >>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that >>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane >>> protocol which is also a foo-over-UDP variation. >>> >> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming >> device, what protocol are they going to use? >> >> >> >> >> >> -----Original Message----- >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert >> Sent: 27 March 2018 10:03 >> To: Satoru Matsushima <satoru.matsush...@gmail.com> >> Cc: dmm@ietf.org >> Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 >> >> On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima >> <satoru.matsush...@gmail.com> wrote: >>> Thank you Tom, >>> >>> Unfortunately I couldn’t find clear advantage of GUE against GTP-U. >>> (No offensive, please don’t get me wrong.) >>> >>> I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP >>> type encapsulation in IETF. >> >> It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and >> draft-ietf-intarea-gue-extensions. >> >>> IMO Unified concept in that encapsulation doesn’t seem to work i.n that >>> circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane >>> protocol which is also a foo-over-UDP variation. >>> >> Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming >> device, what protocol are they going to use? >> >>> Nevertheless I think that that aspect would be a criteria for user plane >>> protocols comparison provided to 3GPP. But I don’t think it is good idea >>> that we provides 3GPP all kind of foo-over-UDP encapsulation protocols in >>> IETF. It would be better to pick SRv6 and some generic foo-over-UDP >>> protocol to be compared with GTP-U supported functionalities. >>> >> GUE is the generic foo-over-UDP protocol for that purpose. >> >>> Basic functionalities of GTP-U is that sequence number option, >>> extension-headers, and multicast and those should be the part of criteria. >>> IMO as you suggested, overhead size, performance, TE, extensibility and >>> encryption would be good idea for the criteria in addition to the above >>> fundamental ones. >>> >>> Best regards, >>> --satoru >>> >>> >>> >>>> 2018/03/27 11:51、Tom Herbert <t...@quantonium.net>のメール: >>>> >>>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima >>>> <satoru.matsush...@gmail.com> wrote: >>>>> Thank you Tom for your suggestion. >>>>> >>>>> Do you think that GUE has some advantages against GTP-U? >>>> >>>> I believe so. GUE is designed to be a general purposed multi use >>>> case encapsulation. The defined GUE extensions deal with problems >>>> and provide features of encapsulation (header security, >>>> fragmentation, payload security, checksum handling etc.). This is >>>> done without resorting to expensive TLV processing. GUE also allows >>>> "private data" >>>> that could be used for use case specific info-- so TLVs or GTP >>>> extensions could be encoded so in that sense it's a superset of GTP >>>> functionality. As I mentioned, GUE has a mode for encapsulating IP >>>> in UDP with minimal overhead (direct IP over UDP). >>>> >>>>> When it comes to foo over UDP capsulation, does GUE benefit user plane >>>>> beyond GTP-U? >>>>> >>>> I think so. Perhaps the biggest advantage is the GUE can be used >>>> accross different use cases and technologies. It's generic protocol >>>> so it could be used for multiple use cases in a mobile network. For >>>> instance, a UE might talk to a a low latency service application >>>> via GUE. To the server this looks much more like simple >>>> virtualization or encapsulation and GUE includes potential optimizations. >>>> Similarly, GUE also could be use to connect across different access >>>> technologies that might not be 3GPP (like roaming between WIFI and a >>>> mobile network). >>>> Conceptually, other IETF defined encapsulations could also be used >>>> for this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically >>>> designed to be multi use case, low overhead, but still extensible. >>>> >>>> We intend to use ILA in a similar multi-use case fashion, however >>>> when encapsulation is required (like SR TE is needed, or we need an >>>> encrypted tunnel) then I believe GUE is a good alternative for that >>>> case to provide necessary functionality and extensibility. >>>> >>>> Tom >>>> >>>>>> 2018/03/27 9:16、Tom Herbert <t...@quantonium.net>のメール: >>>>>> >>>>>> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave) >>>>>> <sgund...@cisco.com> wrote: >>>>>>> FYI. This is the notes that Carlos captured. Thank you Carlos!! >>>>>>> >>>>>>> We are also waiting for Lyle to share his notes. Please review >>>>>>> and comment, if you see any mistakes. >>>>>>> >>>>>> >>>>>> With regards to SR encapsulation: "this is using IP-in-IP as default. >>>>>> Why not using UDP encapsulation?" >>>>>> >>>>>> There is some rationale for UDP encapsulation here to maximize >>>>>> compatibility with the network and potentially intermediate nodes >>>>>> like firewalls. For example, in the performance numbers that >>>>>> Kalyani posted, the TPS for SR over IPIP routing was lower than >>>>>> other encapsulations. The reason for this is that the particular >>>>>> NIC (ixgbe) is not parsing over IPIP or using flow label to get a >>>>>> good hash for RSS. This is symptomatic of network devices that >>>>>> don't provide as good support for protocols outside of TCP and UDP. >>>>>> There are likely routers that would not be able to provide flow >>>>>> specific ECMP for similar reasons. There was a comment in dmm >>>>>> meeting that ECMP for IPIP was expected to by solved by using >>>>>> flow label in the hash. This is a great idea, but unfortunately >>>>>> there is significant resistance to using flow label for this >>>>>> purpose since it is not guaranteed to be persistent for a flow >>>>>> and that can cause problems for stateful devices like firewalls. >>>>>> >>>>>> UDP encapsulation is the typical answer to network protocol >>>>>> compatibility. Several UDP encapsulation techniques have been >>>>>> defined as well as some foo over UDP to run existing >>>>>> encapsulations over UDP (e.g. MPLS/UDP, GRE/UDP). >>>>>> draft-ietf-rtgwg-dt-encap gives a nice overview of considerations for >>>>>> UDP encap protocols. >>>>>> >>>>>> If a UDP encapsulation is considered for use with SR, I would >>>>>> suggest GUE is an option. GUE has some unique features: >>>>>> >>>>>> - It's extensible (both common extensions are defined and allows >>>>>> custom extensions per use case) >>>>>> - It's generic (can encapsulate any IP protocol) >>>>>> - It allows directly encapsulating IPv4 and IPv6 in UDP (to >>>>>> minimize encapsulation overhead) >>>>>> - It allows encapsulation of extension headers >>>>>> >>>>>> The last point may be of particular interest to SR. SR over IPIP >>>>>> might be more precarious compared to other encapsulations since >>>>>> it introduces two "atypical" (i.e. not TCP or UDP) protocols. GUE >>>>>> could be used to normalize SR packets to look like UDP to the >>>>>> network. This might look something like: >>>>>> >>>>>> IP|UDP|GUE|Routing_hdr|IP|payload >>>>>> >>>>>> The UDP and GUE header are effectively treated as routing shim at >>>>>> each segment hop so SR is processed as without regard to the >>>>>> encapsulation. >>>>>> To intermediate nodes these packets looks like any other UDP >>>>>> packet so there's no compatibility issue. >>>>>> >>>>>> Tom >>>>>> >>>>>> _______________________________________________ >>>>>> dmm mailing list >>>>>> dmm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
