[DMM] comments on draft-camarilloelmalky-springdmm-srv6-mob-usecases-00

[John Kaippallimalil <[e-mail]>]

Hi,
(re: draft-camarilloelmalky-springdmm-srv6-mob-usecases-00)
Folllowing up with detailed comments as suggested in dmm meeting.

General comments:

a)      Draft discusses about simplification and control plane (CP).However it is confusing which CP (SRv6 or 3GPP) and the corresponding use case.
Section 2 refers to architecture as in 23.501 (where SMF directly controls UPF).
Other places in the draft seem to imply 3GPP control plane changes ("path head end manipulating intermediate hops")
It would be good to identify which use cases need 3GPP CP changes and ones that  do not.


b)       "state" is being reduced by SRv6 is confusing.
Each UE and PDU session has its own state - for charging, policy, QoS, etc.
When the draft talks about reducing "state" - is it state in 3GPP control plane? That would imply a change in 3GPP architecture.

More specific comments:

1.       Draft marked as "standards track". Should perhaps be informational?

2.       3.1.1.1, "RAN end of a GTP tunnel may appear as a single end point ....but the actual realization is substantially more complex"
What is the "actual realization" and what is the "complexity".

3.       3.1.1.1, "modern radio scheduling .... rich path can be ephemeral .... parasitic in overall system behavior"
Not clear what this is about wrt SRv6 ? Is this about transport between two 3GPP functions?

4.       3.1.1.1.1, CoMP, etc. - "In both cases the radio controller is required to be able to instantly redirect traffic based on radio measurements ..."
This is radio controller behavior. What does it have to do with SRv6?
If the point is that a transport with SRv6 between radio CU and DU has some benefits, that does not come across.

5.       3.1.1.2.1. (downstream) .."The PGW/UPF may decide to hairpin the traffic through multiple application (service chain) ...."
This is not true. Traffic steering nodes in the market already avoid hairpinning.
And, there is no such requirement in 3GPP N3/N9 or S5/S8 (i.e., these are not first class entities in 3GPP)

6.       3.1.1.2.2 /Serving State:  ".. Depending on the applied policy, a significant portion of the serving-state can be embedded in the data-flow as metadata (in the form of SID-list)"
Each SID is only 128 bits. How many SIDs are likely to be needed to carry serving state?
Please provide some examples.

7.       Section 3.1.1.2.3 State mutation points are not clear.
What "state" are we talking about - if it is UE state (policy, charging, mobility, services) - how can SRv6 do this?
Some examples can help.

8.       In 3.2.2.1, ".. 3GPP GTP tunnel/bearer based connection-oriented architecture does not scale for billions of IoT devices ...."
This is a result of business/operator requirements related to policy and charging.
If these requirements are relaxed, any protocol can be adapted and will not have scaling problems.


John