Re: Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document
Uma Chunduri <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <CAF18ct74SRNZttHXfzARB+7RO1KFzHNE0e6ipVuzqSj4pCO-nA@mail.gmail.com> |
Hi Joel, I would let John reply to you further , but a quick comment: -- Uma C. On Tue, Jan 5, 2021 at 2:40 PM Joel Halpern Direct < [email protected]> wrote: > It is quite hard for me to understand what is itnended due to the > terminology differences. It would be helpful before adoption if there > were better alignment. > [Uma]: As I noted in the other response, I am afraid, even the latest change in terminology from 'Transport Slice' to 'IETF Network Slice' ( https://tools.ietf.org/html/draft-nsdt-teas-ietf-network-slice-definition-02 ) may not capture the full scope here. > > Also, clarity as to whether we are discussing the service interface (how > to map the 3GPP needs to the services defined by the IETF network > slicing abstraction) or the de3livery mechanisms (how to use various > IETF technologies to deliver the services defined by the abstractions > and mapped to the 3GPP structures. [Uma]: Obviously not the delivery mechanisms as you noted it can cross many WGs from LSR (for routing), TEAS, PCE (for related-TE stuff), or RTGWG (IP fast reroute) to data plane (6Man, Spring, MPLS etc). > I would not expect DMM to need to > get into how to map to the mechanisms, [Uma]: I am not sure why. We saw this is the most appropriate place when we started this work way back in 2018 (00 version, predates TEAS slicing design team started with a wider scope for generic slicing), given the mobility domain expertise and many 3GPP/IETF related items being worked out here like - a. 3GPP User plane work https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/ b. SR work which can co-exist with GTP based 3GPP user plane and vatious inter-working scenarios in https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/ c. While, not directly related to this sub-opic, another important work like https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ Again, as you pointed out TEAS has produced many pioneering works applicable here are already being referred here and make sure to align in future wherever applicable. Many Thx, -- Uma C. as that is an ever-evolving > domain and one that is dealt with by the various domain WGs (TEAS, MPLS, > SPRING, ...) > > Yours, > Joel > > On 1/5/2021 5:33 PM, Kaippallimalil John wrote: > > Joel, > > Commenting as an author: > > I too agree that the draft should use terminology on transport and > slicing that TEAS defines so that there is consistency. We can either add > it in the next revision/or put place holders now. > > > > Given that, my view is that the work in TEAS and DMM are complementary. > > > > TEAS defines transport and slicing applicable across various domains and > solutions in a more generic fashion, while the DMM draft would provide how > to apply it in a 3GPP context. > > There isn't a 1:1 mapping between TEAS /IETF slice offered to the 3GPP > provider, and a slice which the 3GPP provider provisions for its subscriber > (UE). > > The focus of the DMM draft is to define how a UE/3GPP transport packet > (GTP packet across F1/W1, N3, N9, for a slice defined between 3GPP provider > and subscriber) should be mapped to various transport network segments (SR, > MPLS, IP, L2 etc). > > > > Regards, > > John > > > > > > -----Original Message----- > > From: dmm <[email protected]> On Behalf Of Joel M. Halpern > > Sent: Monday, January 04, 2021 6:23 PM > > To: [email protected] > > Subject: Re: [DMM] Call for adoption of > draft-clt-dmm-tn-aware-mobility-08 as a WG document > > > > Hmmm. > > > > It seems to me that this document ought to align with the ongoing work > in the TEAS working group that is attempting to define terminology and > framework (and then any necessary protocol mechanisms) for IETF network > slices. That work is explicitly intended to support 3GPP end-to-end > network slices. > > > > First, the discussion there exlicitly conluded that the term "Transport" > > was confusing and misleading. Which is why the work is now called IETF > network slicing. > > > > Second, it seems that we want one IETF framework for this, not two > competing frameworks. Why is DMM doing this separately. It seems to fall > squarely into CCAMP and TEAS. I presume we want a solution that works for > 3GPP and works for other use cases? > > > > Yours, > > Joel M. Halpern > > > > On 1/4/2021 7:11 PM, Linda Dunbar wrote: > >> Support WG adoption. > >> > >> Linda Dunbar > >> > >> ------------------- > >> From: *Sri Gundavelli (sgundave)* <[email protected] > >> <mailto:[email protected]>> > >> Date: Wed, Dec 30, 2020 at 10:45 AM > >> Subject: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 > >> as a WG document > >> To: dmm <[email protected] <mailto:[email protected]>> > >> > >> Folks: > >> > >> The authors of the document, Transport Network aware Mobility for 5G, > >> have presented the proposal and the need for standardization in > >> multiple IETF WG meetings. There have been good amount of discussions > >> in the mailers and there is some level of interest for the work from > >> the community. We are therefore considering the adoption of this > >> document as a DMM WG document, to be moved on Informational Standards > track. > >> > >> *Transport Network aware Mobility for 5G* > >> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool > >> s.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-08&data=04%7C0 > >> 1%7Cjohn.kaippallimalil%40futurewei.com%7C5c225b50684e46709e2108d8b110 > >> 1135%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454029863264662%7 > >> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 > >> haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nMZamYoSrcrbkf0cipy5f8UTqedSBdHb7 > >> Wx5%2F2nUqkI%3D&reserved=0 > >> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo > >> ls.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-08&data=04%7C > >> 01%7Cjohn.kaippallimalil%40futurewei.com%7C5c225b50684e46709e2108d8b11 > >> 01135%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454029863264662% > >> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik > >> 1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=nMZamYoSrcrbkf0cipy5f8UTqedSBdHb > >> 7Wx5%2F2nUqkI%3D&reserved=0> > >> > >> With this background, we would like to ask the WG to provide some > >> feedback on their interest for this work. Please provide substantial > >> comments as why this SHOULD be adopted, or why it SHOULD NOT be adopted. > >> If there is interest, and if there are no other concerns from > >> AD/IESG/Others, then we may take up this work. > >> > >> The adoption call will end on 18th of January, 2021. > >> > >> Regards > >> > >> DMM WG Chairs > >> > >> _______________________________________________ > >> dmm mailing list > >> [email protected] <mailto:[email protected]> > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > >> ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=04%7C01%7Cjohn.kaippallim > >> alil%40futurewei.com%7C5c225b50684e46709e2108d8b1101135%7C0fee8ff2a3b2 > >> 40189c753a1d5591fedc%7C1%7C0%7C637454029863274628%7CUnknown%7CTWFpbGZs > >> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > >> %7C3000&sdata=Wox%2B4qgSrNicZW7Nu4fYeg8L5kc2mcFk6LHcMU6RpLM%3D& > >> ;reserved=0 > >> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > >> .ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=04%7C01%7Cjohn.kaippalli > >> malil%40futurewei.com%7C5c225b50684e46709e2108d8b1101135%7C0fee8ff2a3b > >> 240189c753a1d5591fedc%7C1%7C0%7C637454029863274628%7CUnknown%7CTWFpbGZ > >> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 > >> D%7C3000&sdata=Wox%2B4qgSrNicZW7Nu4fYeg8L5kc2mcFk6LHcMU6RpLM%3D&am > >> p;reserved=0> > >> > >> > >> _______________________________________________ > >> dmm mailing list > >> [email protected] > >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > >> ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=04%7C01%7Cjohn.kaippallim > >> alil%40futurewei.com%7C5c225b50684e46709e2108d8b1101135%7C0fee8ff2a3b2 > >> 40189c753a1d5591fedc%7C1%7C0%7C637454029863274628%7CUnknown%7CTWFpbGZs > >> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D > >> %7C3000&sdata=Wox%2B4qgSrNicZW7Nu4fYeg8L5kc2mcFk6LHcMU6RpLM%3D& > >> ;reserved=0 > >> > > > > _______________________________________________ > > dmm mailing list > > [email protected] > > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C5c225b50684e46709e2108d8b1101135%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454029863274628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=Wox%2B4qgSrNicZW7Nu4fYeg8L5kc2mcFk6LHcMU6RpLM%3D&reserved=0 > > > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm