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
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
