Working Group Drafts
Architecture Discussion on SRv6 Mobile User plane,
draft-ietf-dmm-srv6mob-arch,
Jakub Horn, 10min.
Future work part: slicing overlaps with other points mentioned
Question on whether the focus of SRv6 is suitable to DMM MUP arch;
Some comments are 'this draft might not be suitable for further DMM WG
objective': one argument is SRv6 is just for transport, nothing
differnet from MPLS, native IP, etc.; should not be targeting for
generic MUP. -- while chairs suggests 'unless out of scope, this draft
should stay as is'.
Tianji: for slicing, computing, consider relation
Jeffrey: this draft needs more work. Session info into routing
information: however this is not specific to SRv6.
Don't see any difference when it comes to mobility.
Jakub: see this as the best fit technology
Jeffrey: the document should clarify that this is not specific to SRv6
Sri: how do we move forward?
Jeffrey: don't have a suggestion. One option is to use the other
work/draft that is related.
Sri: given that this is adopted how do we progress
Jeffrey: we do need to make it clear that this is not unique to SRv6
Jakub: will add a para to generalize this information
Suresh: re: SRv6 vs tunnel based approach, this text is already there.
THis is a follow up to RFC 9433
Sri: suggest to make the draft clear.
Jeffrey: better word is that is not unique to SRv6
Renwei Li: share opinion with Jeffrey. No change to the MUP in 3GPP -
can use any transport technology. All the architectural interfaces are
the same
Jakub: this is showing the value and motivation. But agree that MUP can
run over any protocol.
Renwei: we'll need Srv6 per application
Tianji: timeframe is quite critical for this as there is 6G discussion
on this. This draft should proceed and provide details to 6G discussions
MUP Architecture, draft-ietf-dmm-mup-architecture
Satoru Matsushima, 10min.
Satoru: Authors requests WG last call
Jeffrey: in this draft of the previous one, there is no change in the
3GPP architecture. This is implementing in a way that conforms to that
architecture
Mobility aware Transport Network Slicing for 5G
draft-ietf-dmm-tn-aware-mobility
John Kaippallimalil, 10 min.
Authors explained the draft has been split into 2 drafts: (a) this one;
and (2) Not-yet WG draft: 'A YANG Data Model for Attachment Circuit as a
Service with UDP Tunnel Support'.
Authors went thru review comments (details are in slides). One
particularly concerned comment is the tn-aware draft can NOT have
normative dependance on non-WG draft (i.e., the YANG-model draft). So,
the solution from the author is to make the YANG-model an informational
draft.
John: Comment on progressing these 2 related drafts: does this draft
depend on draft-jlu-dmm-udp-tunnel-acaas?
Sri: Revise to have no normative dependency in tn-aware-mobility.
John: will revise to have no Normative drafts/dependency
Sri: how will the comments be resolved?
John: will respond on mailing list and update draft.
Chairs discussed the latest reviews of the draft and agreed to proceed
with the completion of the WGLC
Individual Drafts
A YANG Data Model for Attachment Circuit as a Service with UDP Tunnel
Support
draft-jlu-dmm-udp-tunnel-acaas
John Kaippallimalil, 10 min.
Author went thru the YANG-model draft.
John: draft has been reviewed. Request WG adoption
Sri: will issue an WG adoption call
Mobile Traffic Steering
draft-liebsch-dmm-mts
Marco Liebsch, 15min.
Author went to the background, objectives and the latest status of the
draft.
John: clarify flexible deployment as it can be understood
Sri: Flexible and other qualifiers should be explained.
John: steering vs. QoS. QoS is a problem that needs a solution in 6G
Sri: Treat steering and QoS separately.
Marco: 3GPP terminology or general termionology
Sri: keep it as distinct termonology
Lionel: the real value for this draft is whether it is for existing
deployment (5G) or new deployment (6G) - i.e., does it have impact on
control architecture of 3GPP.
If it does have impact, it should be done before the next gen /6G is
developed
Marco: ack
Satoru: what is meant by E2E
Marco: user to service instance, e.g. TCP sender and receiver.
Marco: also received comments from Carlos - also commented that this is
useful
Sri: don't document triggers for the mobility?
Marco: this is beyond the scope of this draft - control plane, policy,
maybe UE but all of that is in the control plane.
Distributed Roaming and Mobility Problem Statement
draft-grayson-distributed-roaming-mobility
Mark Grayson, 15min.
License and deployment of small federations and private networks and
'cellular hotspots' going forward.
GSMA IR.21 registers IP addresses of access endpoints and that scales
for about the current 900 public cellular organizations.
For the millions of private networks with dynamic discovery, it is a
different approach and problem.
Also has security implications.
ERic: is RADEXT looking at this?
Mark: RADEXT has some discussion on QUIC but it is immature
Eric: Reverse CLA draft?
Mark:
Sri: do the different solution options need protocol extensions?
Mark: could use DIAMETER traversal, etc
Sri: documenting this is useful as it spans multiple standardization
domains.
Renwei: depends on how many identity providers are required, but WiFi is
very different in that when roaming each network has identity
information.
Mark: scale of identity providers. some the characteristics are
appearing in cellular with NPN, etc.
Renwei: now there are many access points, but that is just the physical
access. (vs provider). i.e., charging, etc are centralized (??)
Mark: yes, we are talking of different administrative domains.
Lionel: from the SNPN point of view, it may be 3GPP specific solution
For Diameter any approach should be possible
Mark: thats good feedback to consider different approach
Sri: is this worth documenting this problem?
Lionel: problem would be documented in 3GPP TR.