Hi Lionel, Ran, all, Thank you for the comments.
Please see new version that addresses the comments: https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/ A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-15 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
