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]
