Hi DMM chairs & colleagues, The authors have addressed the comments over the last several meetings on draft-ietf-dmm-tn-aware-mobility.
Major comments/resolution (compiled reverse chronologically based on my notes): - Extensive review by Lionel Morand and subsequent revision to remove duplicate information on slicing, architecture in sections 1, 2. Remove fronthaul section (old 3.1) (post IETF 121) - Revision to support ACaaS (and provide YANG extensions for GTP-U) in sections 3, 5. Addresses comments from WG that there should be no dependency on 3GPP work in future to realize the proposal in the draft. (IETF 121) - Alignment with TEAS (and subsequent review by Mohamed Boucadair). Aligns architectural sections (section 2, 3) with references to related drafts in teas. (IETF 120) - Updates to revise relation to control plane slice and private network slice mapping to transport slices. Removed PPR in transport section. (IETF 119) - Review by Satoru and relation to mobility-awareness addressed in Introduction. Alignment with teas slicing concepts in RFC 9543 (IETF 114, 116, 117) - Adoption, 3GPP EP_Transport and logicalInterfaceId concepts for mapping to UDP (note: this is now revised to use EP_Transport concepts to map to ACaaS) (IETF 112, 113). The authors would like to ask to proceed to last call for this draft. Best Regards, John > -----Original Message----- > From: Kaippallimalil John <[email protected]> > Sent: Wednesday, January 8, 2025 10:22 PM > To: Lionel Morand <[email protected]>; Ran Atkinson > <[email protected]>; [email protected]; [email protected] > Cc: [email protected] > Subject: [DMM] Re: [Teas] Re: Re: draft-ietf-dmm-tn-aware-mobility-16 > > Hi Lionel, all, > > Thank you for taking the time to review in detail and for the proposed > changes. > > I have implemented all the changes proposed: > - removed details of fronthaul and O-RAN references > - expanded context around F1-U/N3/N3, and > - consolidated mid-haul and backhaul into one section (now 3.1). > Links to version 16 are below. > > Hi, Sri, Satoru, > > All the proposals from dmm (thanks, Lionel, Hannu, Joel, Kausik, Tianji, Sri, > Satoru) and teas /ACaaS Yang model extns (thanks Med, Ran) have been > implemented and reviewed. > At this time, the authors would like the chairs to consider proceeding to > working group last call. > > Best Regards, > John > > > PS: Revision 16 posting details: > The IETF datatracker status page for this Internet-Draft is: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-tn-aware- > mobility%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C3 > e51b463cbe74015f98308dd30655a1e%7C0fee8ff2a3b240189c753a1d559 > 1fedc%7C1%7C0%7C638719934069580441%7CUnknown%7CTWFpbGZsb3 > d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2Bk%2BGjUf > Xhq3fsfPt%2Fv76Ny5Ux1oZUOMhOnt9v%2BcAb0M%3D&reserved=0 > > There is also an HTMLized version available at: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-tn-aware-mobility- > 16&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C3e51b463c > be74015f98308dd30655a1e%7C0fee8ff2a3b240189c753a1d5591fedc%7C > 1%7C0%7C638719934069597510%7CUnknown%7CTWFpbGZsb3d8eyJFbX > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cgzdEnTbeAFCNE5aakLL > kU73U2VC7VwbVovbsk5kqP4%3D&reserved=0 > > A diff from the previous version is available at: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility- > 16&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C3e51b463c > be74015f98308dd30655a1e%7C0fee8ff2a3b240189c753a1d5591fedc%7C > 1%7C0%7C638719934069608710%7CUnknown%7CTWFpbGZsb3d8eyJFbX > B0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=OLtZvsMH1MBjvJC73o1 > OaRA3xQiU8W0BHYcAk4dYsYc%3D&reserved=0 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > > > -----Original Message----- > > From: Lionel Morand <[email protected]> > > Sent: Wednesday, January 8, 2025 5:54 AM > > To: Kaippallimalil John <[email protected]>; Ran > > Atkinson <[email protected]>; [email protected]; [email protected] > > Cc: [email protected] > > Subject: RE: [Teas] Re: [DMM] Re: draft-ietf-dmm-tn-aware-mobility-14 > > > > Hi John, > > > > Thank you for this new version. > > I'm fine with the section 3.2 and the rest of the document. However, I > > still have some problems with part of the text contained in section 2 and > section 3. > > As I said, draft should be refocused on the use of GTP-U over > > F1-U/N3/N9. In that direction, please consider the following comments. > > > > Comments: > > > > #1: GTP is not used in the fronthaul and, therefore, fronthaul should > > remain out of scope of this document. > > > > OLD: > > > > 2. Scope of Transport Networks in 5G Slicing 3GPP [TS.28.530-3GPP] > > discusses transport network in the context of network slice subnets, > > but does not specify further details. This section provides an > > overview of the processes to provision and map 5G slices in backhaul, > > mid-haul and front haul network segments with GTP-U (UDP) source port > number. > > > > NEW: > > > > 2. Scope of Transport Networks in 5G Slicing 3GPP [TS.28.530-3GPP] > > discusses transport network in the context of network slice subnets, > > but does not specify further details. This section provides an > > overview of the processes to provision and map 5G slices in backhaul > > and mid-haul network segments with GTP-U (UDP) source port number. > > > > #2: in 5GS, split of gNB is only an option. As it is described, it > > seems to assume that any 5GS will have split gNB. > > > > ODL: > > > > Figure 1 depicts 5GS expanded to show the IP transport and PE > > (Provider > > Edge) providing IP transport service to 5GS user plane entities 5G-AN > > (e.g., > > gNB) and UPF. > > > > NEW: > > > > Figure 1 depicts a 5G System (5GS) in which a gNB is split into a > > gNB-CU-CP, multiple gNB-CU-UPs and multiple gNB-DUs, as described in > > TS 38.401 [x] . In addition, the figure is expanded to show the IP > > transport and PE (Provider > > Edge) providing IP transport service to 5GS user plane entities 5G-AN > > (e.g., > > gNB) and UPF. > > > > #3: maybe good to introduce N3, N9 and F1-U interfaces > > > > OLD: > > > > The N3, N9 and F1-U user planes use GTP-U specified in > > [TS.29.281-3GPP] to transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or > Unstructured). > > > > NEW: > > > > In this architecture, end-to-end user plane connectivity between the > > UE and a specific Data Network (DN) is supported by the F1-U interface > > (between gNB- DU and gNB-CU-UP) in, the N3 interface between the > > gNB-CU-CP and the UPF, and the N9 interface between UPFs in the core > > network. Over these interfaces, GTP-U is used to transport UE PDUs > > (IPv4, IPv6, IPv4v6, Ethernet or Unstructured) as specified in [TS.29.281- > 3GPP]. > > > > #4: because fronthaul is likely out of scope of this draft, the > > following paragraph could be safely removed: > > > > When gNB functionality is split between a central unit (CU) and a > > distributed unit (DU), a mid-haul transport segment provides the > > connectivity as shown in Figure 1. [...] For the front-haul described > > further in Section 3.1, an Ethernet transport with VLANs can be expected to > be the case in many deployments. > > > > #5: instead, a note can be included. > > > > NEW: > > > > The gNB-DU can also be split into two entities (O-RU and O-DU) as > > defined by O-RAN Alliance and therefore the the user plane includes > > the fronthaul interface between O-RU and O-DU. However, as this > > interface does not rely on GTP-U to transport UE PDU, the fronthaul > > interface is out of scope of this document. > > > > #6: if fronthaul is out of scope, section 3.1 should be renamed and > > the first part on O-RAN should be removed > > > > OLD: > > > > 3.1. Fronthaul and Mid-Haul Transport Network > > > > The O-RAN Alliance defined a lower layer split at the physical layer > > of the radio access network whereby the gNB-DU is split into two > > entities (O-RU and O- > > DU) and has specified the fronthaul interface between the O-RU and the > > O-DU in [ORAN-WG4.CUS-O-RAN]. The radio layer information, in the form > > of In- phase (I) and Quadrature (Q) samples are transported using > > enhanced Common Public Radio Interface (eCPRI) framing over Ethernet > > or UDP. On an Ethernet based fronthaul interface, the network slice > > instance (NSI) information is carried in the Ethernet header through > > the VLAN tags and/or PCP marking. The Ethernet switches in the > > fronthaul transport network inspects the slice information (VLAN tag > > and/or PCP marking) in the Ethernet header and provide the provisioned > > capabilities. The mapping of I and Q samples of different radio > > resources (radio resource blocks or carriers) to different slices and > > to their respective VLAN tags and or PCP marking on the fronthaul > > interface is controlled by the O-RAN fronthaul C-Plane and M-Plane > > interfaces. The fronthaul transport network is latency and jitter > > sensitive. The provisioned slice capabilities in the fronthaul > > transport network MUST take care of the latency and jitter budgets of > > the specific slice for the fronthaul interface. The provisioning of > > the fronthaul transport network is handled by the NC pertaining to the > > fronthaul transport. 3GPP functions gNB-CU (user > > plane) and gNB-DU may also be distributed and have a mid-haul > > transport between the two 3GPP network functions. [...] > > > > NEW: > > > > 3.1. Mid-Haul Transport Network > > > > As described in Figure 1, 3GPP functions gNB-CU (user plane) and > > gNB-DU may also be distributed and have a mid-haul transport between > > the two 3GPP network functions. [...] > > > > #7: As the content of the 3.1 has be simplified, section 3.1 and 3.3 > > could be merged to become 3.1 " Mid-Haul and Backhaul Transport > Networks" > > > > No further comment. > > > > Best Regards, > > > > Lionel > > > > -----Original Message----- > > From: Kaippallimalil John <[email protected]> > > Sent: vendredi 27 décembre 2024 18:30 > > To: Lionel Morand <[email protected]>; Ran Atkinson > > <[email protected]>; [email protected]; [email protected] > > Cc: [email protected] > > Subject: RE: [Teas] Re: [DMM] Re: draft-ietf-dmm-tn-aware-mobility-14 > > > > Hi Lionel, Ran, all, > > > > Thank you for the comments. > > > > Please see new version that addresses the comments: > > https://data/ > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-tn-aware- > > > mobility%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C0 > > > 17abc7128ef43135f5a08dd2fdb19f5%7C0fee8ff2a3b240189c753a1d5591f > > > edc%7C1%7C0%7C638719340312757754%7CUnknown%7CTWFpbGZsb3d > > > 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF > > > OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=QDk1ugHSO9v > > VEl5E0RlxsAVFGgi0cSvNU4NZCE%2Fj1tM%3D&reserved=0 > > > > A diff from the previous version is available at: > > https://auth/ > > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility- > > > 15&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C017abc712 > > > 8ef43135f5a08dd2fdb19f5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1 > > > %7C0%7C638719340312774889%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > > > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFp > > > bCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RrGniZfPjf2wdSBDkpdzhf > > %2FUlwcj9vq9Vhe1IEsENKk%3D&reserved=0 > > > > Some info on the changes: > > Sections 1 and 2.1 in r14 has some overlap and has been revised to > > simplify while retaining just enough to be self-contained. > > A new section 2 (derived from section 2.1 in r14) contains aspects of > > TN and 5G slicing as it relates to using GTP-U source port number for > mapping. > > (and includes aspects for 5QI, handling per user/PDU session and per > > interface for front haul). > > Redundant text between section 1 and 2.1 (in r14) have been removed. > > The changes are editorial and no changes have been made in subsequent > > sections that describe detailed mechanisms. > > > > If the WG is happy with these changes, the authors would like to > > request for WG last call. > > > > Best Regards, > > John > > > > > > > > > -----Original Message----- > > > From: Lionel Morand <[email protected]> > > > Sent: Wednesday, December 18, 2024 12:45 PM > > > To: Ran Atkinson <[email protected]>; [email protected] > > > Cc: [email protected]; [email protected] > > > Subject: [Teas] Re: [DMM] Re: draft-ietf-dmm-tn-aware-mobility-14 > > > > > > Hi Ran, > > > > > > I think that the main goal of this draft is not to describe the 3GPP > > > system architecture (fronthaul, midhaul, backhaul) nor to redefine > > > the mapping between IETF IP transport slice and 3GPP slices. It is > > > already well covered by other 3GPP/IETF documents. > > > > > > With the removed/simplified sections, the draft would still be self- > contained. > > > The key issue is addressed in section 2.4, i.e. how to ensure slice > > > Mapping when GTP-U is secured by IPsec, which is just a corner case > > > of the generic use case. And the section 3 provides a solution to > > > map GTP/UDP source ports to slice types. > > > And section 4 extends the YANG service data model defined in > > > I-D.ietf- opsawg-teas-attachment-circuit to carry UDP source port > > > number/range to support slice mapping based UDP source port when > > > GTP-U is secured by > > IPsec. > > > > > > Let me know if I've missed something. > > > > > > As I said, the goal is only to make the document simpler and more > readable. > > > People that will implement this draft will have to go anyway through > > > other companion documents from IETF or 3GPP. > > > > > > Regards, > > > > > > Lionel > > > > > > -----Original Message----- > > > From: Ran Atkinson <[email protected]> > > > Sent: mercredi 18 décembre 2024 15:29 > > > To: [email protected] > > > Cc: [email protected]; [email protected] > > > Subject: [DMM] Re: [Teas] draft-ietf-dmm-tn-aware-mobility-14 > > > > > > Hi, > > > > > > In many situations, I think it is quite helpful to have > > > self-contained > > documents. > > > > > > Often, someone who has not participated in any IETF activity will be > > > assigned by their employer to "go implement RFC-xyz" for some product. > > > Having a self- contained document greatly helps implementers who are > > > well-intentioned, but have not participated in IETF (or 3GPP or > > > whatever else) during the creation of the specification. > > > > > > Yours, > > > > > > Ran > > > > > > > On Dec 18, 2024, at 04:30, Lionel Morand > > > <[email protected]> wrote: > > > > > > > > Hi John, > > > > Thank you for the new version, taking into account the comments > > > > raised > > > after the last IETF meeting. > > > > I have been through and it could be ready for WGLC. > > > > > > > > However, if I may, I think the draft could be simplified a bit. > > > > As it is, the document is structured as a self-contained document > > > > whereas it > > > might not be required. > > > > > > _______________________________________________ > > > dmm mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > > _______________________________________________ > > > Teas 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] _______________________________________________ dmm mailing list -- [email protected] To unsubscribe send an email to [email protected]
