Presenter: John Kaippallimalil
Slicing draft
Updates provided for revision 9, List provided in the slide deck,
notable:
Added control plane slices using UDP source port just like user
plane. UP slice is offered to users, CP slices are not for users.
Private and public network is covered by the draft as is.
QnA
Satoru: No implementations, and no specification available for using
source port, so why is this document needed.
Answer: L3 Attachment circuit may be used, and this draft can provide
guidance for 3GPP, so 3GPP could use this as a base.
Satoru: Who is proposing this in 3GPP
Answer: No name of a person in 3GPP asking for this is known
Satoru: Should 3GPP be notified of this capability?
Answer: yes that would be good
Satoru: So is the expectation that 3GPP will modify protocols once this
capability is known?
Answer: Yes
Taihei: Slicing example in user plane is streaming, what is use case for
Control plane?
Answer: no specific use case - contract is between user and 3GPP
network, but question last time was "can the CP be sliced?" and the
answer is yes
Next steps: Present in TEAS and understand the scope of the slicing
documents
Presenter: Satoru Matsushima
Updates include (details in slides)
Added architecture principles
Architecture requirements are defined in RFC
Next: Verify Architecture principles vs architecture, then update the
draft, then request adoption.
Weiqiang: Are protocol guides available?
Satoru: SRv6 implementaiton is almost available in open source (VPP
GOBGP)
After MTG edit: draft-mpmz-bess-mup-safi, and RFC9433 are
protocol specs for SRv6MUP.
Low number of WG participants have reviewed the doc: Suresh and Marco
volunteered to review.
Presenter: Minh Ngoc Tran
Problem statement provided (details in slides)
Proposed Architecture was discussed (see slides)
Tianji: Is MUP architecture specific or general
Satoru: General
Tianji: This puts overlay over MUP, so is this based on proposed MUP
architecture from Satoru?
Minh: It can co-work together with MUP-C or be an overlay.
Satoru: Looks clear to leverage MUP controller to inform routing
information from CATs... what format do you expect for anycast?
Minh: IP Address
Satoru: is it server addr or mobile network entity address
Minh: Not the server address
Yuya: SRv6 already supports anycast over transport layer. So don't
understand what problem this solves? does this do the same with CATS?
Note taker: Unclear what the answer was ... please listen to
recording.
Minh (Edited after meeting): SRv6 can route anycast packet. However, we
need to chose an optimal service instance to route to. CATS capabilities
can assist MUP-C to do this job.
Tianji: re CAT integration part. Has CAT specified a central controller
to distribute metrics?
Note taker : unclear response.
Minh (Edited after meeting): CATS WG opens to both distributed and
centralized implementation methods.
Presenter: Tianji
Reviewed previous discussion and resolutions (see slides) during
adoption call.
Summary: Received comments from participants, but spec work needs to
happen to 3GPP. This can be used as a reference for that work.
John K: Observed changes, lots of information on modes etc., good to add
info about "how to use this draft" - what can a reader do with it? Is it
a survey, is it identifying gaps?
Tianji: 3GPP use
Chairs: please track closure of each thread on the mailing list.
Muhammad: Is this discussed in 3GPP?
Tianji: no it is now discussed there yet. Belief is 6G may benefit from
this draft.
Muhammad: what is impact of implementing these on the protocol stack
Tianji: Implementation is on N3 - Maybe GTP is not needed with this.
Muhammad: Assuming a sliced network - how is this architecture relevant?
Tianji: this is independent.
Yuya: need to bring this doc to 3GPP
Tianji: yes.
Presenter: Tianji
Updates presented (see slides) - significant restructuring.
Summary:
Asked for WG adoption
Chairs: there is no client stack implementation - need to discuss
offline to understand why this is required.
Presenter: Sri
Problem statement: Where no public network is available can an endpoint
use local WIFI witout credentials make an emergency call?
Proposed solution based on any roaming architecture.FCC is reviewing the
technical work
Scenario described in detail (see presentation)
Key technical elements discussed to permit access to only an emergency
voice service ensuring location identifiable.
Marco: non-3GPP access is important. Does this depend on 3GPP or
cellular backend?
Sri: yes, its key to make it clear that IETF protocols can provide whats
needed.
Tianji: Authentication and authorization is critical in 3GPP, does this
matter in this use case?
Sri: I can make a 911 call with expired SIM today, there are default
device credentials. but generally we want to make this very open and
identity may not matter.
Tianji: for non-3GPP access wifi gateway needs to build an ipsec tunnel
to the voice server?
Sri: Standard AAA mechanisms are in place, no new extensions... the call
is a standard SIP call.
Tianji: No IMS is this a problem?
Sri: it's a SIP based protocol and infrastructure.
Erik K: Is it just SIP pieces required, and have you asked SIP core?
Sri: No response from group I asked, but can ask SIP core.
Antoine: Wifi is present, how is SSID chosen?
Sri: Witout access credentials the device should attach - that's the
assumption.
Antoine: IMS spec called for diameter, is RADIUS what should be used?
Sri: most wifi networks are radius.
Darren: What about bad actors wanting to steel emergency calls?
Sri: SIP terminates to PCSCF - Location is signaled twice from handset
and device.
Darren: what about spoofed access networks?
Sri: Ah yes, there is some legal requiremnent on access networks to
provide a reputable service.
Speaker: Marco
Side meeting at IETF 116 and discussion at 117
Draft is being compiled by end of the month.
Looking for feedback when the draft is out.
Taihei: Is deployment a DMM working group topic?
Marco: Mostly looking at routing aspects in data network.
Erik K: To chairs - Does it fit in the charter?
Sri: the charter should fit it, agreement to consider it with the
authors.