Dear Satoru, all, just for clarification with respect to the descriptions in the document.
The main aim of the draft is how to map a slice for a 3GPP PDU session identified by S-NSSAI to an IETF/transport slice defined in RFC 9543 using the ACaaS concept. The description in section 3 is not intended to be prescriptive at all, just illustrative of what can be done with the artifacts we have in the IETF side (i.e., the Attachment Circuit). The goodness of the proposed approach is the fact that 3GPP already considers ATTACHMENT_CIRCUIT as part of the ConnectedInfo object in 3GPP NRM, making its usage straightforward. Definitely we can add a couple of sentences to indicate the fact that this description is not prescriptive. In fact, in TEAS, there was a similar issue/comment in regards a draft proposing to clarify functionality of Network Slice Controllers (please, refer to https://www.ietf.org/archive/id/draft-ietf-teas-ns-controller-models-04.txt). The concern raised was to avoid any prescription at the time of defining an NSC. The resolution of that concern was to add the following text: “This document describes a potential way of structuring the IETF Network Slice Controller as well as how to use different data models being defined for IETF Network Slice Service provision (and how they are related). It is not the purpose of this document to standardize or constrain the implementation the IETF Network Slice Controllers” In the DMM draft, we could add the following in section 1 (Introduction) and/or section 3: “This document describes a potential way to map user plane packets of a 3GPP PDU session identified by S-NSSAI to an IETF Network Slice Service as defined in RFC 9543 using ACaaS Layer 3 bearer (in section 5). It is not the purpose of this document to standardize or constrain the implementation of user plane nodes in 3GPP.” Best regards Luis El vie, 9 may 2025 a las 4:11, Satoru Matsushima (< [email protected]>) escribió: > From whole of device configuration view, IMHO it makes more sense if > extending the 3gpp network slicing yang model (i.e., > 3gpp_ns_nrm_networkslicesubnet.yang) by specifying udp tunnel with port > number/range could be possible, either in this draft or in > 3gpp_ns_nrm_networkslicesubnet.yang. > > Best regards, > --satoru > > > > > On Thu, May 8, 2025 at 1:02 AM Behcet Sarikaya <[email protected]> > wrote: > >> Take it to 3GPP John, they will accept it. >> >> Behcet >> >> On Wed, May 7, 2025 at 4:52 AM Satoru Matsushima < >> [email protected]> wrote: >> >>> Hi John, thanks for more clarifications. But I'm still unclear on the >>> following points: >>> >>> 1. The figure 3 in the draft does not exactly follow the info model >>> defined in TS28.541, which is confusing. >>> >>> 2. As TS28.541 defined, "ATTACHMENT_CIRCUIT" name in a >>> "connectionPointId" seems to be the glue to bind an attachment circuit with >>> UDP source port to an EP_Transport. But there is no text to describe that >>> idea in the draft, nor in TS28.541. >>> >>> 3. TS28.541 also specifies a yang model, >>> "3gpp_ns_nrm_networkslicesubnet.yang". A grouping "ConnectionPointInfoGrp" >>> has a leaf "connectionPointId" to be used in another grouping >>> "EPTransportGrp". But there is no other container or grouping using the >>> EPTransportGrp in that yang model. So how to use the attachment circuit >>> with UDP source port by TS28.541 compliant implementation is still unclear. >>> >>> Best regards, >>> --satoru >>> >>> >>> >>> On Wed, Apr 23, 2025 at 11:52 PM Kaippallimalil John < >>> [email protected]> wrote: >>> >>>> Hi Satoru, >>>> >>>> Thank you for reviewing the changes in 3.3, rev 18 and for the detailed >>>> comments. >>>> >>>> The text in the draft should be revised. Broad outline of revision: >>>> - EP_Transport/.../ATTACHMENT_CIRCUIT with UDP source port number/range >>>> is provisioned (before PDU session setup) for each slice (S-NSSAI) that the >>>> 3GPP UP node supports. >>>> This uses data structures in 28.541 (details in response - email >>>> below). >>>> - During PDU session setup, N2/N4 signaling carries S-NSSAI for the PDU >>>> session and is provided to the 3GPP user plane nodes. >>>> N2/N4 signaling is in 23.502, 4.3.2 and 38.413 (NGAP - N2), 29.244 >>>> (PFCP - N4). >>>> The ATTACHMENT_CIRCUIT /UDP source port number can thus be associated >>>> and used when forwarding a GTP-U packet. >>>> >>>> Detailed responses and proposed text changes are inline below and >>>> tagged [-- Response --]. >>>> >>>> Regards, >>>> John >>>> >>>> >>>> > -----Original Message----- >>>> > From: Satoru Matsushima <[email protected]> >>>> > Sent: Tuesday, April 22, 2025 9:40 AM >>>> > To: Kaippallimalil John <[email protected]> >>>> > Cc: dmm <[email protected]>; dmm-chairs <[email protected]>; Charles >>>> Eckel >>>> > (eckelcu) <[email protected]>; Lionel Morand < >>>> [email protected]> >>>> > Subject: Re: draft-ietf-dmm-tn-aware-mobility-18 >>>> > >>>> > Hi John, thank you for the update. >>>> > >>>> > As you mentioned, I reviewed section 3.3 in terms of both the prior >>>> to PDU >>>> > session establishment, and during PDU session establishment. >>>> > >>>> > In section 3.3 para 2, the draft says below: >>>> > >>>> > > 3GPP user plane nodes (gNB, UPF) are provisioned with GTP transport >>>> > > interface information parameters in [TS.28.541-3GPP] for an S-NSSAI. >>>> > > >>>> > >>>> > But I couldn't find exact IOC or attribute defined in TS28.541 to >>>> bind GTP >>>> > transport interface info parameters for an S-NSSAI. >>>> > Can you please indicate where the IOC and/or the attribute defined in >>>> > TS28.541? >>>> [-- Response 1--]: Good point - 3GPP only configures S-NSSAI in N4/N2, >>>> and does not carry the S-NSSAI in GTP-U. >>>> The text "for an S-NSSAI" should be removed. The sentence could be >>>> revised to: >>>> "The 3GPP user plane nodes (gNB, UPF) are provisioned with GTP >>>> transport interface information parameters in [TS.28.541-3GPP]. >>>> Each EP_Transport is configured with ATTACHMENT_CIRCUIT containing UDP >>>> source port number/range for each of the slices (S-NSSAI) supported by the >>>> 3GPP user plane node. >>>> The "ATTACHMENT_CIRCUIT" is an enumerated value in connectionPointId >>>> (externalEndPointRefList) attribute in EP_Transport." >>>> >>>> > >>>> > Also in section 3.3 para 3, the draft says below: >>>> > >>>> > > During PDU session setup, the 5G control plane configures parameters >>>> > > to setup the user plane for the PDU session across F1-U, N3 and N9 >>>> > > interfaces. They include the S-NSSAI and corresponding EP_Transport >>>> > > information which contains the IP address interface of the GTP-U >>>> > > destination and the connectionPointID with attachment circuit >>>> > > information. The 3GPP user plane node can now associate the >>>> > > provisioned slice and EP_transport to that signaled for the PDU >>>> > > session. >>>> > > >>>> > >>>> > I suppose that the above text implies N2, or N4 interface procedures >>>> since it >>>> > describes PDU session establishment. >>>> > But I couldn't find neither EP_Transport nor connectionPointID >>>> parameters in >>>> > both the N2 (TS38.413) and N4 (TS29.244). >>>> > So can you please indicate where those parameters are included in the >>>> N2 and >>>> > N4? >>>> [-- Response 2 --]: Agree, EP_Transport and connectionPointID are >>>> not configured per PDU session, only the S-NSSAI is. >>>> Will revise the text to reflect this: >>>> " During PDU session setup, the 5G control plane configures parameters >>>> to setup the user plane for the PDU session across F1-U, N3 and N9 >>>> interfaces. >>>> They include the S-NSSAI which allows for the previously configured >>>> EP_Transport/ATTACHMENT_CIRCUIT (with UDP source port number/range) >>>> to be used when forwarding a GTP-U packet belonging to the PDU session." >>>> >>>> > >>>> > In addition, the Fig.3 in the draft depicts EP_Transport info model >>>> which >>>> > includes some attributes of the connectionPointIDType, and the >>>> > connectionPointID. >>>> > But I couldn't find those attributes in EP_Transport IOC in TS28.541. >>>> > So can you please indicate where those attributes are defined in >>>> EP_Transport >>>> > IOC? >>>> [-- Response --]: TS28.541, section 6.3.18 : EP_Transport >>>> Attributes ( 6.3.18.2) refers to externalEndPointRefList (defined in >>>> 6.4.1). >>>> 6.4.1 (externalendPointRefList identifies a list of ConnectionPointInfo >>>> (6.3.41) -> connectionPointIdType (6.4.1) - one of which is >>>> "ATTACHMENT_CIRCUIT". >>>> I did not add these pointers to sections in the specification since the >>>> slice mapping concepts in the draft/RFC should be possible to use even as >>>> 3GPP standards evolve. >>>> >>>> > >>>> > Best regards, >>>> > --satoru >>>> > >>>> > >>>> > >>>> > > 2025/04/22 4:26、Kaippallimalil John >>>> > <[email protected]>のメール: >>>> > > >>>> > > Hi All, >>>> > > I do appreciate all the detailed reviews and comments after rev >>>> 17, and >>>> > during IETF 122 dmm session. >>>> > > The following updates have been made to address comments: >>>> > > • Comment that slice types listed in section 1 should be exemplary >>>> > > (updated in first para, section 1) >>>> > > >>>> > > • Clarify relation between 5QI/slices. Updated in section 2 >>>> (snippet below): >>>> > > “The TN PE does not consider 5QI in the DSCP or GTP-U header for >>>> mapping >>>> > the 5G slice. 3GPP QoS with 5QI and corresponding DSCP mapping can be >>>> > applied to traffic flows in PDU sessions in the slice independently.” >>>> > > >>>> > > • Comment in IETF 122: “S-NSSAI and relation to EP_Transport is not >>>> clear” >>>> > > Revised section 3 as follows. >>>> > > Split the original section 3.2 into 2 sections (3.2 and 3.3) as >>>> that section was >>>> > getting too long. >>>> > > Aspects of 3GPP slice configuration are now in section 3.2 and no >>>> changes to >>>> > the text there were needed. >>>> > > Text in section 3.3 is revised to describe configuration related to >>>> S-NSSAI, >>>> > EP_Transport on 3GPP nodes and IP PE, both prior to PDU session >>>> > establishment, and during PDU session establishment. >>>> > > The changes can be found in paragraphs 2 and 3 of section 3.3. >>>> > > Also, a few changes in section 5.1 to link the changes in 3.3 to >>>> the ACaaS >>>> > extension for UDP tunnel. >>>> > > >>>> > > And thank you - Charles and Lionel - for volunteering to review >>>> this new >>>> > revision. >>>> > > Links to the new revision: >>>> > > Datatracker: >>>> > > >>>> > >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata >>>> > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-tn-aware- >>>> > mobility%2F&data=05%7 >>>> > > >>>> > C02%7Cjohn.kaippallimalil%40futurewei.com%7C9ed77f1a895f42489f1b08 >>>> > dd81 >>>> > > >>>> > aba5f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63880929 >>>> > 6418346929 >>>> > > >>>> > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu >>>> > MDAwMCIsI >>>> > > >>>> > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd >>>> > ata=XMK >>>> > > db911JCtX%2BpF%2BqhPc7L2nfXCj99DoIAE3SFSHo1Y%3D&reserved=0 >>>> > > Diff: >>>> > > >>>> > >>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth >>>> > > or-tools.ietf.org >>>> %2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility- >>>> > 18&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C9ed77f1a8 >>>> > 95f42489f1b08dd81aba5f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1 >>>> > %7C0%7C638809296418401661%7CUnknown%7CTWFpbGZsb3d8eyJFbXB >>>> > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp >>>> > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qKVv9i6izqujtZF7MKe76v >>>> > aeYujCyQk0c39pFp4DQ9s%3D&reserved=0 >>>> > > Best Regards, >>>> > > John >>>> > >>>> >>>> _______________________________________________ >>> dmm mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> _______________________________________________ > dmm mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- ___________________________________________ Luis M. Contreras [email protected] [email protected] Global CTIO unit / Telefonica
_______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
