Re: [6gip] IP Address Mobility Project

[Alexandre Petrescu <[e-mail]>]

Le 22/02/2023 à 19:43, Hesham ElBakoury a écrit :
> Are there proposals to replace GTP?

I can try to find that out.  I remember some relatively recent 
presentations at IETF about replacing GTP, or reducing the number of 
headers.  It might have been in the (precursor?) of the DMM WG. 
(distributed mobility mgmt).

A related question, IMHO, would be too whether there is an RFC for GTP 
in a first place...

I can remember an Internet Draft of year 2000 about GTP - named simply 
draft-casati-gtp - but it was not pursued at IETF.

If there were a GTP RFC, then we could think about improving it, 
replacing it, etc.

When there is no GTP RFC, one can think about what should an ideal xGPP 
(3GPP) network use instead.

Or maybe another way...

Alex

> Hesham
> 
> On Wed, Feb 22, 2023, 10:39 AM Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     David, Giles,
> 
>     Le 22/02/2023 à 14:35, David Lake a écrit :
>      > This:
>      >
>      > “…the 5G UPF terminates the GTP tunnel but also does QoS, charging,
>      > lawful intercept etc. ”
>      >
>      > … is a VERY important point.  GTP enables a number of very low-level
>      > RF features which MNOs need to control their allocation of spectrum
>      > and more importantly the numerology associated with an application.
>      > It is also used in shared solutions such a CoMP.
> 
>     I can agree with the importance of the point above.  I can agree about
>     improvements there might be necessary.
> 
>     I can say that QoS can also be done with flow labels and traffic classes
>     in IPv6 headers, without GTP.
> 
>     But I agree with the importance of the topic.
> 
>      > If we are to replace GTP (and I think there is a reason to do that)
>      > we have to provide the interactions to the layer 1 that MNOs need.
> 
>     I agree.
> 
>     [...]
>     Giles said:
>      > I’m not sure that your electricity analysis is correct.
>      >
>      > Doing e.g. an MPLS exact match lookup across a FIB with a few
>      > thousand labels rather than an IPv6 longest-match lookup across a FIB
>      > with a few million prefixes, for example, may well more than offset
>      > the extra electricity consumption caused by the extra 4 bytes of
>      > header.
>      >
>      > And then of course there’s all the electricity consumed by the
>      > control plane updates hitting the router CPUs.
> 
>     I can agree.  But I do not take that as an invitation to ignore
>     electricity consumption.  Rather, all points you mention (exact match
>     lookup consumption, ctl plane) should be measured and told who consumes
>     more, and then decide what to reduce.
> 
>     I do not take your remark as giving up electricity savings in front of
>     too much complexity of understanding what's happening.
> 
>     I do not take your remark as freedom to add more headers when it becomes
>     necessary to add more functionality.
> 
>     [...]
> 
>      >> More details about this performance degradation can be provided if
>      >> absolutely necessary, but some times trust might also help for a
>      >> quicker understanding towards realizing a common goal.  (the
>      >> development of trust is another matter that we can discuss
>      >> separately :-)
>      >
>      > Trust takes time to earn, and I’d tend to suggest that arguing that
>      > it makes sense to inject a host route for a UE into OSPF may not be
>      > the best way to earn it.
> 
>     Given this apparent disparate understanding about routing - you seem to
>     be more people to be saying the contrary of what I say - I give up this
>     topic discussion on host based routes.  Maybe for later for another G,
>     maybe never.
> 
>     Alex
> 
>     -- 
>     6gip mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/6gip
>     <https://www.ietf.org/mailman/listinfo/6gip>
>