Dear Hannu,
Indeed you raised this point w.r.t terminology in IETF109 and I responded
we will consider that as appropriate. I would note the following w.r.t
"transport network" aspect:
a. Till last quarter TEAS draft was referring to "transport slices
terminology" -
as in
https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-04#section-3
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-nsdt-teas-transport-slice-definition-04%23section-3&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C74e5144e6e1644cb306108d8b1c2d2ec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454797621482934%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tdrsLKnZAZUM7SR4IrYuOVXp1OQ0aHSqGFBAxBQXXPE%3D&reserved=0>
b. However most recently we do see the change to IETF Network Slice in Q42020
https://tools.ietf.org/html/draft-nsdt-teas-ietf-network-slice-definition-00
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-nsdt-teas-ietf-network-slice-definition-00&data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C74e5144e6e1644cb306108d8b1c2d2ec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454797621492892%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=aQnsRUQ2hTE24lV8YTygfwvS5Mb7kfbd6JL7ZPXTAco%3D&reserved=0>
c. I have also gone through other ongoing individual documents in
TEAS and they still refer to transport slices, transport networks.
AFAIU, from the TEAS discussion earlier, when you work on generic slicing
effort transport network terminology may be confusing to some folks (with
transport layer?).
However, if the scope is a mobility domain(3GPP network) it is obvious as
the context it is discussed will be very
specific w.r.t other parts of the networks, viz., RAN and 5GC/Core
Network.
But, I still see an issue with the latest terminology in #b (though it's
more appropriate for me to comment there in TEAS).
IETF Network slice may not represent all segments in fronthaul or F1U/W1U
in L2 switched environments or even in N3 and N9 which may be deployed
without IP/MPLS.
I also requested in the IETF109 DMM WG meeting, to give specific comments
or suggestions w.r.t terminology or any other aspects and we will consider
those and we haven't received any.
Any ways, we will keep this as TBD and we change it eventually as agreeable
to the DMM and IETF TEAS community.
Many Thx,
--
Uma C.
On Tue, Jan 5, 2021 at 1:00 AM Flinck, Hannu (Nokia - FI/Espoo) <
hannu.fli...@nokia-bell-labs.com> wrote:
> 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 <dmm-boun...@ietf.org> On Behalf Of Joel M. Halpern
> Sent: Tuesday, January 5, 2021 3:46 AM
> To: Kiran Makhijani <kir...@futurewei.com>; Joel M. Halpern <
> j...@joelhalpern.com>; dmm@ietf.org
> 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 <dmm-boun...@ietf.org> On Behalf Of Joel M. Halpern
> >> Sent: Monday, January 4, 2021 4:23 PM
> >> To: dmm@ietf.org
> >> 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)*
> >>> <sgundave=40cisco....@dmarc.ietf.org
> >>> <mailto:40cisco....@dmarc.ietf.org>>
> >>> 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 <dmm@ietf.org <mailto:dmm@ietf.org>>
> >>>
> >>> 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
> >>> dmm@ietf.org <mailto:dmm@ietf.org>
> >>> 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
> >>> dmm@ietf.org
> >>> 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
> >> dmm@ietf.org
> >> 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
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
