Re: [3gpp-ietf-coord] IETF - 3GPP coordination @IETF#115

[[e-mail]]

Hi,

Please find below the rough minutes of our coordination meeting.

Regards,

Lionel

Attendees:

  *   Lionel Morand, CT chair, 3GPP Liaison to IETF
  *   Gonzalo Camarillo, IETF Liaison to 3GPP
  *   Lars Eggert, IETF chair
  *   Jari Arkko
  *   Suresh Krishnan
  *   Subir Das
  *   Satoru Matsushima
  *   Eric Vyncke
  *   Erik Kline
  *   Spencer Dawkins
  *   Cindy Morgan
  *   Edgar Ramos
  *   (TBC...)

Round table

Due to the number of on-site and remote participants in the room and , the round table was skipped.
People present at the  meeting are kindly asked to send an email to complete the attendees list.

Ongoing LS


  *   3GPP to IETF: LS on 3GPP 5G System acting as a Detnet node from 3GPP SA2

3GPP SA2 is working on extensions to the 5G System Time Sensitive Communications (TSC) framework for the support of IETF’s DetNet framework (Only IP, not MPLS).
3GPP SA2 seeks for info on any possible work to extend the DetNet YANG data model to include node specific traffic requirements and kindly asks guidance DetNet interface and IP configuration exposition.
Normative work should be completed by March '23. IETF guidance and feedback on possible work planned in '23 is expected before the end of '22.

No specific comment. The information has been taken into account.


  *   IETF to 3GPP: LS from the IETF LPWAN WG to 3GPP

LPWAN asks for review of the draft-ietf-lpwan-schc-over-nbiot in IETF Last calland seek for potential 3GPP/IETF collaboration and cross referencing on the use of SCHC over NB-IoT
Initial feedback from 3GPP: delegates were simply invited to review the draft and send their comments to IETF/IESG list. No official feedback from 3GPP was planned.

During the meeting, Edgar has pointed out that this work was not coming out of the blue but was actually a response to a CT1 LS received in 2016 (C1-163121), in the scope of CIoT (Cellular IoT), including the following action point:

3GPP TSG CT WG 1 is interested in co-operation with IETF in the area of LPWAN to ensure that efficient protocols for low power devices are developed and that the aforementioned 3GPP radio access technologies are considered in the LPWAN discussions initiated in IETF.

Therefore this draft is in response to the 3GPP request. And the LS was not sent only for information but for action (which was missed as the LS was not sent in response to any LS)

There are actually 2 questions from IETF that require an official 3GPP feedback:

  *   Is the content of the draft is correct, according to 3GPP point of view? In the draft, there are two part, one normative on the specific use of SCHC over NB-IoT, another informative on recommended values for 3GPP if SCHC is supported.
  *   Would/Will 3GPP update their specifications to indicate the use of SCHC for header compression (instead or in addition to ROCH)

The next CT1 meeting is next week and Lionel has indicated that he will check with them how to collect the comments from the delegates and provide a feedback to IETF before the end of IETC LC.

Ongoing IANA action


  *   IANA port number Assignment for 3GPP interfaces

3GPP was tasked to work on alternative solutions to avoid the need for port assignment for (private) 3GPP interfaces
The following documents have been approved

  *   TR 29.835: Study on Port Allocation Alternatives for New 3GPP Interfaces.
  *   TR 29.941: Guidelines on Port Allocation for New 3GPP Interfaces
  *   TS 29.641: 3GPP Registry for Service Names and Port Numbers

For the last one, it was clarified that the registry is only for 3GPP internal use. No IANA action will be required as the port numbers assigned to 3GPP interfaces are allocated in a sub-range of the Dynamic/Private Port range [49152 - 65535] for internal use. It was also clarified that for inter-domain signaling, an IANA assigned port number is still required.


  *   IANA assignment applications

The 3GPP internal process has been simplified. All the requests sent to IANA are now made by the 3GPP chair, centralizing all the requests. This eases the IANA-3GPP communication and has already proved to be more efficient.

Status of the 3GPP-IETF dependencies

The following RFCs have been published since IETF#110:

  *   RFC 8588: Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)
  *   RFC 8684: TCP Extensions for Multipath Operation with Multiple Addresses
  *   RFC 8898: Overview: Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)
  *   RFC 9027: Assertion Values for Resource Priority Header and SIP Priority Header Claims in Support of Emergency Services Networks
  *   RFC 9048: Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA’)
  *   RFC 9190: Using EAP-TLS with TLS 1.3 (EAP-TLS 1.3)
  *   RFC 9147: The Datagram Transport Layer Security (DTLS) Protocol Version 1.3

Three documents are under IESG review

  *   draft-ietf-stir-passport-rcd-22
  *   draft-ietf-stir-messaging-06
  *   draft-ietf-stir-identity-header-errors-handling-05

Two individual draft will be reactivated:

  *   draft-jesske-update-p-visited-network:
     *   This document updates RFC 7976, in order to allow inclusion of the P- Visited-Network-ID header field in responses.
     *   Next step: WG document and RFC publication


  *   draft-schwarz-mmusic-sdp-for-gw
     *   as "simplified" draft for the "UDP/DTLS" SDP codepoint assignment, with the clarification that the intended usage is only for controlling gateways and not for SDP Offer/Answer etc.

For Information


  *   Release roadmap

3GPP is currently working on the Release 18, first release of 5G-Advanced. This release should be complted in Dec '23.
The functional scope and timeline of the release 19 are not decided yet.
6G is clearly not in the 3GPP scope yet.


  *   QUIC as transport protocol in 5G Service-based Architecture

The TR 29.893 provides an analysis of QUIC protocol and its potential use as a transport protocol for the 5GC Service Based Interfaces (instead of HTTP/TCP)
It was put on hold in 02/2021, waiting for RFC publication at this time.
The next action would be to finalize the evaluation of QUIC for the 5GC based on IETF specification sets available and check whether the issues identified in the TR are/can be solved


  *   SRv6 for Mobile User Plane

draft-ietf-dmm-srv6-mobile-uplane-21 sent to IESG for publication as Proposed Standard.
It is related to the study item FS_UPPS “Study on User Plane Protocol in 5GC” that was discussed in CT4 and concluded in Rel-16. At this time, it was considered premature to standardize the use of SRv6 for the 3GPP 5G user plane.
SRv6 is not currently discussed in 3GPP but interested CT4 delegates have been kindly invited to review and send their comments on the draft on the relevant IETF/IESG mailing lists.

AoB

Gonzalo has indicated that it will likely be soon replaced as IETF liaison to 3GPP.
Lionel has also indicated that he will leave his CT chair functions after the next March election and it is not decided who the next 3GPP liaison to IETF will be.
Both will ensure a smooth transition.

End of the meeting.

Lionel thanked the attendees and has welcomed once again the excellent coordination, cooperation and communication between 3GPP and IETF.


-----Rendez-vous d'origine-----
De : MORAND Lionel INNOV/NET
Envoyé : vendredi 14 octobre 2022 15:43
À : MORAND Lionel INNOV/NET; [e-mail]
Cc : DOLLY, MARTIN C; Eric Vyncke (evyncke); [e-mail]; [e-mail]; Giorgi Gulbani; Black, David; [e-mail]; [e-mail]; Peter Schmitt; [e-mail]; [e-mail]; Magnus Westerlund; Gonzalo Camarillo; Edgar Ramos; Pascal Thubert (pthubert); [e-mail]; 松嶋聡; Lorenzo Colitti
Objet : IETF - 3GPP coordination @IETF#115
Date : mardi 8 novembre 2022 11:30-13:00 (UTC+00:00) Dublin, Édimbourg, Lisbonne, Londres.
Où : IAB room (Richmond 5) + Remote Access (Teams)

Hi,

As you might have seen, we will have our traditional IETF-3GPP coordination at IETF#115.


  *   When: Tuesday 8 Nov from 1130 to 1300
  *   Where: IAB Room, Richmond 5, West Wing 1st Floor (1W)
  *   Remote access: Teams meeting here<https://teams.microsoft.com/l/meetup-join/19%3ameeting_OGU0YzM1MzItNDlhMS00NWFlLTk0NDUtMzBkMmI4YWM0OTMw%40thread.v2/0?context=%7b%22Tid%22%3a%2290c7a20a-f34b-40bf-bc48-b9253b6f5d20%22%2c%22Oid%22%3a%222861bd92-0820-473f-b5eb-cb750ae6a78a%22%7d>

Proposed agenda:

  *   Round table
  *   Status of the 3GPP-IETF dependencies (nothing controversial)
  *   Future Port allocation
  *   Ongoing LS

     *   Actions required from 3GPP:

        *   application of the SCHC protocol (RFC 8724/8824) on NB IOT (Liaison statement from the IETF LPWAN WG to 3GPP<https://datatracker.ietf.org/liaison/1796/>)
        *   Advice on the required scaling of network slicing in underlay network applications (Liaison from the MPLS Working Group on Network Slicing Identifier scalability<https://datatracker.ietf.org/liaison/1749/>)

Please share on the mailing list any other item that could be added to the agenda.

Regards,

Lionel
________________________________________________________________________________
Réunion Microsoft Teams
Rejoindre sur votre ordinateur ou application mobile
Cliquez ici pour participer à la réunion<https://teams.microsoft.com/l/meetup-join/19%3ameeting_OGU0YzM1MzItNDlhMS00NWFlLTk0NDUtMzBkMmI4YWM0OTMw%40thread.v2/0?context=%7b%22Tid%22%3a%2290c7a20a-f34b-40bf-bc48-b9253b6f5d20%22%2c%22Oid%22%3a%222861bd92-0820-473f-b5eb-cb750ae6a78a%22%7d>
ID de réunion : 370 195 967 654
Code secret : pZ9ndX
Télécharger Teams<https://www.microsoft.com/en-us/microsoft-teams/download-app> | Rejoindre sur le web<https://www.microsoft.com/microsoft-teams/join-a-meeting>
Ou composer le numéro (audio seulement)
[phone],,452025359#<tel:[phone],,452025359#>   France, Paris
ID Conférence Téléphone: 452 025 359#
Rechercher un numéro local<https://dialin.teams.microsoft.com/24103a92-d5ee-40b9-936f-5760fd725241?id=452025359> | Réinitialiser le code confidentiel<https://dialin.teams.microsoft.com/usp/pstnconferencing>
Pour en savoir plus<https://aka.ms/JoinTeamsMeeting> | Options de réunion<https://teams.microsoft.com/meetingOptions/?organizerId=2861bd92-0820-473f-b5eb-cb750ae6a78a&tenantId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20&threadId=19_meeting_OGU0YzM1MzItNDlhMS00NWFlLTk0NDUtMzBkMmI4YWM0OTMw@thread.v2&messageId=0&language=fr-FR>
________________________________________________________________________________


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.