John: are you considering aspects of session other than routing - for
e.g., charging, QoS, etc.
Teppei: will follow up online.
Satoru: do we have to mention charging, other session aspects?
Eric: no we don't, but we can have a passing reference if needed.
Keyur: we don't need to add other session aspects.
Should the draft be INFO or STD?
Eric: this draft can remain as INFO
Sri, Satoru: chairs will check and confirm that it can remain INFO.
Satoru: S-NSSAI and relation to EP_Transport is not clear
Luis: data structures in 3GPP to TEAS can be explained in the draft.
5QI to S-NSSAI relationship (comment from Tianji)
John clarifies that S-NSSAI should be the basis for classification, and
DSCP will be applied as necessary
Sri: this is a good comment. Slice and QoS should be distinct.
Sri: we need further reviews to complete last call
Charles Eckel, Lionel Morand volunteered to review.
Sri: the terminology cannot be too 3GPP specific.
Tianji: the draft is generic but the framework/example is where it is
applied to 3GPP.
Sri: the aggregation gateway and N6, other aspects should be generalized
Satoru: better to clarify the difference between steering and routing?
Tianji: the MCS steers based on the information in the routing side.
Satoru: the draft should say clearly what steering is.
Sri: can you do steering if there is more than one router on path?
Does steering state need to be realized in each router?
Tianji: No
Jeffrey: does this require a stand alone draft?
Why not relate to other draft ( SrV6 MUP?)
Yuya: This draft does not change BGP behavior
Keyur: MUP Safi??? may be a carrier, may be one option
Sri: reviewers/review needed before adoption.
Keyur, Lionel, Suresh volunteered
Consider for adoption
Keyur: note to working group chairs and AD. There are 5 implementations
being deployed, and so it is very important to adopt and make progress.
Sri: WG participation and reviews are needed.
Suresh: we need to have a read of the charter to see if re-charter is
needed. (it does not look like it is needed, but good to see)
Sri: all of these items come under the charter.
Keyur: reiterates that there are stable implementations and so this
draft should progress.
Sri: volunteers to review?
Keyur, Lionel
Sri: can this be generalized to apply to any mobile architecture?
Minh: yes.
Sri: reviewers?
Luis, Lionel, Tianji volunteered
Satoru has this been presented in CATS?
Minh: No.
Sri: it would be usefull to get feedback from the CATS side.
Various presentations [see links in presentation] give the view from
different companies (vendors, operators, verticals, ..)
DMM relevant aspects - new services - private networks, V2X, sensing,
etc that is difficult to realize with GTP.
Fresh solution to slicing? (since it is very complex to
implement/deploy)
Many presentations sought simplicity in the network (given that there
are so many fns and many combinations)
AI as services and for the network itself.
Sri: for AI native, will there be new interfaces?
Lionel: TBD.
Charles: concept of needing a new data plane. Lot of information to pass
around and not an AI specific way, but a general way that is not
necessarily what is in the current User Plane.
Eric: what is the feel for SRv6?
Charles: not clear, various opinions.
Data collection - unified way is needed and one way would be a data
plane
Possibly a data plane for computing and another for other data.
Jeffrey: socializing the idea of combined gNB UPF draft proposed in dmm.
Many use cases resonated with this approach.
Tianji: NTN- TN integration came up significantly.
This is relevant to DMM work.
Lionel: any type of access network would need to be supported - same for
WiFi, etc.
Simplification and interworking is needed.
Sri: any views on simplification?
Lionel: The answer is in the question. Many operators don't want change,
but at the same time want simplification.
Charles: simplification, TCO were in many presentations. But no
agreements or discussion on it.