>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]
