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. 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:[email protected]] Sent: 27 March 2018 14:25 To: Arashmid Akhavain <[email protected]> Cc: Satoru Matsushima <[email protected]>; [email protected] Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 On Tue, Mar 27, 2018 at 11:08 AM, Arashmid Akhavain <[email protected]> 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:[email protected]] On Behalf Of Tom Herbert > Sent: 27 March 2018 10:03 > To: Satoru Matsushima <[email protected]> > Cc: [email protected] > Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1 > > On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima > <[email protected]> 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 <[email protected]>のメール: >>> >>> On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima >>> <[email protected]> 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 <[email protected]>のメール: >>>>> >>>>> On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave) >>>>> <[email protected]> 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 >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/dmm >>>> >> > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
