Hi Uma Thanks for this, in line below.
From: Uma Chunduri <[email protected]> Sent: Friday, July 23, 2021 12:04 PM To: David Allan I <[email protected]> Cc: [email protected] Subject: Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13 Hi Dave, Very good list and I am sure there could be a bit more functionalities GTP overlay has been supporting over a period of time *and* still currently being used in various parts of the cellular networks. Replacing overlays may be a good goal if we can bring the same technical benefits different underlays (L2, L2.5, IPv4, IPv6) bring to the table in various parts of the networks, in this case cellular deployments. We(IETF) should develop tools towards the objective but I suspect we are there to replace any overlay (if this is the central goal) with a single underlay mechanism. Dino presented multiple times on this topic in various WGs/pre-bofs/BoFs and also asked to "get over with it" (a thin overlay). One of the things that we all should ask ourselves is - what overlay functionalities we want to bring to underlay (L3/L2.5) as opposed to complete replacement of the overlay. IMO, this is a better question than "replacing". Appreciate your thoughts and views on this. DA> I think we are in a situation where what we need to bring forward in a solution mirrors what is there ESPECIALLY if the goal is a transparent stunt double to the higher level 5G System. From what I can tell 3GPP already has a bit of a winnowing process if not from release to release, at least from generation to generation. So we are not in a situation like for example, the early days of pseudowires where the deployed protocol landscape was massive and triage was definitely called for. What is more then there was complete divergence in systems as you moved up the stack whereas transport for 5G serves a common higher level system. The sorts of features we are seeing in the larger 3GPP picture AFAIK are more recent additions for URLLC, CIoT etc. So picking and choosing based on convenience is not an option; the problem space is not a matter of choosing what to support, but in replicating the functionality exists and having similar extensibility. A further note is that GTP is not in isolation, and some functionalities are UE to UPF (e.g. QMP), so interworking between “whatever” and RLC etc on the radio link is also table stakes. At least that is the view from here Regards Dave On Fri, Jul 23, 2021 at 10:50 AM David Allan I <[email protected]<mailto:[email protected]>> wrote: Hi: Looking over this draft it strikes me that IF you are discussing a GTP replacement, there are a few unaddressed gaps...or at least I see no mention of them. - adding X2 to the list of interfaces to be supported - support for end-marker for handoff stream synchronization (probably could fit the unused bit in Args.Mob.Session but frankly I have not studied this in detail) - support for QMP (quality measurement protocol), which I believe needs to also extend across the radio interface so is not simply local to the GTP domain and can be "stunt doubled" - support for paging policy presence/indication If this has come up elsewhere, let me know Cheers Dave _______________________________________________ dmm mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
