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://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility-16 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-16 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts > -----Original Message----- > From: Lionel Morand <lionel.mor...@huawei.com> > Sent: Wednesday, January 8, 2025 5:54 AM > To: Kaippallimalil John <john.kaippallima...@futurewei.com>; Ran Atkinson > <ran.atkin...@gmail.com>; t...@ietf.org; d...@ietf.org > Cc: opsawg@ietf.org > 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 <john.kaippallima...@futurewei.com> > Sent: vendredi 27 décembre 2024 18:30 > To: Lionel Morand <lionel.mor...@huawei.com>; Ran Atkinson > <ran.atkin...@gmail.com>; t...@ietf.org; d...@ietf.org > Cc: opsawg@ietf.org > 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 <lionel.morand=40huawei....@dmarc.ietf.org> > > Sent: Wednesday, December 18, 2024 12:45 PM > > To: Ran Atkinson <ran.atkin...@gmail.com>; t...@ietf.org > > Cc: d...@ietf.org; opsawg@ietf.org > > 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 <ran.atkin...@gmail.com> > > Sent: mercredi 18 décembre 2024 15:29 > > To: t...@ietf.org > > Cc: d...@ietf.org; opsawg@ietf.org > > 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 > > <lionel.morand=40huawei....@dmarc.ietf.org> 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 -- d...@ietf.org > > To unsubscribe send an email to dmm-le...@ietf.org > > _______________________________________________ > > Teas mailing list -- t...@ietf.org > > To unsubscribe send an email to teas-le...@ietf.org _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
