Hello I raised the same concern in the last meeting as Joel now in his mail. The authors then told that the work is aligned with TEAS. But it seems not to be clear after all. It would help to start the alignment by adding a refer to TEAS slicing drafts. And the use it in the text...
Best regards Hannu -----Original Message----- From: dmm <[email protected]> On Behalf Of Joel M. Halpern Sent: Tuesday, January 5, 2021 3:46 AM To: Kiran Makhijani <[email protected]>; Joel M. Halpern <[email protected]>; [email protected] Subject: Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document Kiran, the TEAS work is focused on defining the structures and semantics for an interface to request services from what 3GPP calls a transport network. It seems really odd for another working group to define how to map to the "transport" network differently from the way TEAS is defining it. If the TEAS definitions are wrong, we need to fix them. If they are right, we need to use them. Having another document that attempts to define the mapping separately seems like a recipe for difficulties. Yours, Joel On 1/4/2021 8:39 PM, Kiran Makhijani wrote: > Hi Joel, > The IETF network slices work under teas focuses on control and managing > slices 'with in' the IP/MPLS networks. Actually, in TEAS 3GPP is just one of > the use cases not the only use case. Also, TEAS wanted to replace "transport" > because it could mean different things. > > But this document only focuses on 3GPP mobility scenarios and heavily relies > on terms and components used in 5G architecture - here 'transport network' is > a standard term. The work presented here is new and covers mobility > procedures and corresponding mappings between AN and UPFs. > > I have read this document and I agree the relationship between the 2 > activities should be discussed (once TEAS adopts slice > terminology/framework), maybe in section 2.7. But I feel this is not a major > change to the way procedures are described in the document. > > I support this work. > FWIW, I think a bit restructuring of the document will improve its > readability. For example, section 2 should be split into 'xhaul background' > and 'TN mobility procedure' - things related to mapping and management of TN > context and its mobility. > > -Kiran > >> -----Original Message----- >> From: dmm <[email protected]> On Behalf Of Joel M. Halpern >> Sent: Monday, January 4, 2021 4: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%2Fto >>> ol >>> s.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility- >> 08&data=04%7C0 >>> >> 1%7Ckiranm%40futurewei.com%7C93dbff7d775842c2409108d8b1101f02%7C >> 0fee8f >>> >> f2a3b240189c753a1d5591fedc%7C1%7C0%7C637454030107896985%7CUnkn >> own%7CTW >>> >> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC >> I6 >>> >> Mn0%3D%7C3000&sdata=34KQ%2Fo0EvC8uta4EF1pa3i1N5etAd6RKUcU >> 8%2BH72rW >>> I%3D&reserved=0 >>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ft >>> oo >>> ls.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility- >> 08&data=04%7C >>> >> 01%7Ckiranm%40futurewei.com%7C93dbff7d775842c2409108d8b1101f02%7 >> C0fee8 >>> >> ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454030107906979%7CUnk >> nown%7CT >>> >> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX >> VCI >>> >> 6Mn0%3D%7C3000&sdata=YR1gDCJtkfwjBxxsBtSYbbbQZpUlDzp3IXraMq >> BXA0w%3 >>> D&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%7Ckiranm%40f >> uture >>> >> wei.com%7C93dbff7d775842c2409108d8b1101f02%7C0fee8ff2a3b240189c75 >> 3a1d5 >>> >> 591fedc%7C1%7C0%7C637454030107906979%7CUnknown%7CTWFpbGZsb3d >> 8eyJWIjoiM >>> >> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000& >> amp;s >>> >> data=pB%2BBZs2OGGMd3ILvAJxiSyA6vRt%2Brmi9tapfTKY771c%3D&reser >> ved=0 >>> >> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww >> w >>> >> .ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=04%7C01%7Ckiranm%40f >> utur >>> >> ewei.com%7C93dbff7d775842c2409108d8b1101f02%7C0fee8ff2a3b240189c7 >> 53a1d >>> >> 5591fedc%7C1%7C0%7C637454030107906979%7CUnknown%7CTWFpbGZsb3 >> d8eyJWIjoi >>> >> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000 >> & >>> >> sdata=pB%2BBZs2OGGMd3ILvAJxiSyA6vRt%2Brmi9tapfTKY771c%3D&rese >> rved= >>> 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%7Ckiranm%40f >> uture >>> >> wei.com%7C93dbff7d775842c2409108d8b1101f02%7C0fee8ff2a3b240189c75 >> 3a1d5 >>> >> 591fedc%7C1%7C0%7C637454030107906979%7CUnknown%7CTWFpbGZsb3d >> 8eyJWIjoiM >>> >> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000& >> amp;s >>> >> data=pB%2BBZs2OGGMd3ILvAJxiSyA6vRt%2Brmi9tapfTKY771c%3D&reser >> ved=0 >>> >> >> _______________________________________________ >> dmm mailing list >> [email protected] >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> .ie tf.org%2Fmailman%2Flistinfo%2Fdmm&data=04%7C01%7Ckiranm%40fut >> urewei.com%7C93dbff7d775842c2409108d8b1101f02%7C0fee8ff2a3b240189 >> c753a1d5591fedc%7C1%7C0%7C637454030107906979%7CUnknown%7CTWF >> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI >> 6Mn0%3D%7C3000&sdata=pB%2BBZs2OGGMd3ILvAJxiSyA6vRt%2Brmi9t >> apfTKY771c%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
