Subject: Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document

From: Linda Dunbar <[email-masked]>
Date: Tue, 5 Jan 2021 00:11:54 +0000

Support WG adoption.

Linda Dunbar

-------------------
From: Sri Gundavelli (sgundave) <sgundave=[email-masked]<mailto:[email-masked]>>
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-masked]<mailto:[email-masked]>>

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://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-08&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C6af4a1ce1b62454eb25d08d8b0350e40%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637453089238313897%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SsBq92wzWCggc5r7r96NPHV2cAan2tjtvoYF2LEBtqY%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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C6af4a1ce1b62454eb25d08d8b0350e40%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637453089238323895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3CAVTNOGuuKjj0rAJcv54OPPObzMj6YSnPf2tsfKYG4%3D&reserved=0>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Jan 2021 19:22:54 -0500

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=[email-masked] 
> <mailto:[email-masked]>>
> To: dmm <[email-masked] <mailto:[email-masked]>>
> 
> 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://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-08&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C6af4a1ce1b62454eb25d08d8b0350e40%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637453089238313897%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SsBq92wzWCggc5r7r96NPHV2cAan2tjtvoYF2LEBtqY%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.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dmm 
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C6af4a1ce1b62454eb25d08d8b0350e40%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637453089238323895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3CAVTNOGuuKjj0rAJcv54OPPObzMj6YSnPf2tsfKYG4%3D&reserved=0>
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 5 Jan 2021 01:39:28 +0000

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-masked]> On Behalf Of Joel M. Halpern
> Sent: Monday, January 4, 2021 4:23 PM
> To: [email-masked]
> 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.
> 
> 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
> 
> > 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.
> >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> > s.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-
> 08&amp;data=04%7C0
> >
> 1%7Ckiranm%40futurewei.com%7C93dbff7d775842c2409108d8b1101f02%7C
> 0fee8f
> >
> f2a3b240189c753a1d5591fedc%7C1%7C0%7C637454030107896985%7CUnkn
> own%7CTW
> >
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6
> >
> Mn0%3D%7C3000&amp;sdata=34KQ%2Fo0EvC8uta4EF1pa3i1N5etAd6RKUcU
> 8%2BH72rW
> > I%3D&amp;reserved=0
> > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
> > ls.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-
> 08&amp;data=04%7C
> >
> 01%7Ckiranm%40futurewei.com%7C93dbff7d775842c2409108d8b1101f02%7
> C0fee8
> >
> ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454030107906979%7CUnk
> nown%7CT
> >
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI
> >
> 6Mn0%3D%7C3000&amp;sdata=YR1gDCJtkfwjBxxsBtSYbbbQZpUlDzp3IXraMq
> BXA0w%3
> > D&amp;reserved=0>
> >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;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&amp;reser
> ved=0
> >
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> >
> .ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Ckiranm%40f
> utur
> >
> ewei.com%7C93dbff7d775842c2409108d8b1101f02%7C0fee8ff2a3b240189c7
> 53a1d
> >
> 5591fedc%7C1%7C0%7C637454030107906979%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoi
> >
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> &amp;
> >
> sdata=pB%2BBZs2OGGMd3ILvAJxiSyA6vRt%2Brmi9tapfTKY771c%3D&amp;rese
> rved=
> > 0>
> >
> >
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;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&amp;reser
> ved=0
> >
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Ckiranm%40fut
> urewei.com%7C93dbff7d775842c2409108d8b1101f02%7C0fee8ff2a3b240189
> c753a1d5591fedc%7C1%7C0%7C637454030107906979%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI
> 6Mn0%3D%7C3000&amp;sdata=pB%2BBZs2OGGMd3ILvAJxiSyA6vRt%2Brmi9t
> apfTKY771c%3D&amp;reserved=0

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 4 Jan 2021 20:46:17 -0500

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

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Tue, 5 Jan 2021 08:59:51 +0000

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-masked]> On Behalf Of Joel M. Halpern
Sent: Tuesday, January 5, 2021 3:46 AM
To: Kiran Makhijani <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]
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:
>> 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.
>>
>> was confusing and misleading.  Which is why the work is now called 
>> IETF network slicing.
>>
>>> Subject: [DMM] Call for adoption of 
>>> draft-clt-dmm-tn-aware-mobility-08
>>> as a WG document
>>> 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.
>>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
>> .ie tf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Ckiranm%40fut

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 5 Jan 2021 16:09:51 +0000

Joel, 
I should let authors clarify further. 
>From what I understood, TN-mobility is non-conflicting to IETF-slice definitions/framework. Because, in TEAS, we create a logical IETF slice by mapping underlying network infrastructure (IP/optical), mobility document does not care about that part. It does the connection of this existing IETF logical slice to RAN-slice with the help of management entity above the network slice controller. This is inline with IETF-NS framework and progressing in parallel.

I 100% agree with the basic sentiment that TEAS should be informed about this work and document should explain alignment with IETF NS framework. 
-Kiran

> From: Joel M. Halpern <[email-masked]>
> Sent: Monday, January 4, 2021 5:46 PM
> 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
> 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
> 
> > 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
> >
> >> .ie

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 5 Jan 2021 14:13:31 -0800

Hi Kiran,

Thanks for your support and  your inputs as a co-authoring member of TEAS
ongoing  work.

See in-line [Uma]:

--
Uma C.

On Mon, Jan 4, 2021 at 5:39 PM Kiran Makhijani <[email-masked]> wrote:

> 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.
>
> 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.
>

Thanks for your observation. The content in the sections was not changed
much from early stages of the draft (may by in early 2019). I
definitely look forward to your specific input to further update.

>
> 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.
>

[Uma]: Noted and keep this in our TBD item(s) for future updates. Shall
respond to Joel's email in a bit.

> in the
> competing

---

From: "Muley, Praveen (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 5 Jan 2021 22:28:21 +0000

As co-author

Support WG adoption.

-Praveen

-------------------

Folks:

Regards
DMM WG Chairs

---

From: Kaippallimalil John <[email-masked]>
Date: Tue, 5 Jan 2021 22:33:40 +0000

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-masked]> On Behalf Of Joel M. Halpern
Sent: Monday, January 04, 2021 6:23 PM
To: [email-masked]
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:
> document as a DMM WG document, to be moved on Informational Standards track.
> 
> s.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-08&amp;data=04%7C0
> 1%7Cjohn.kaippallimalil%40futurewei.com%7C5c225b50684e46709e2108d8b110
> 1135%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454029863264662%7
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=nMZamYoSrcrbkf0cipy5f8UTqedSBdHb7
> Wx5%2F2nUqkI%3D&amp;reserved=0 
> ls.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-08&amp;data=04%7C
> 01%7Cjohn.kaippallimalil%40futurewei.com%7C5c225b50684e46709e2108d8b11
> 01135%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454029863264662%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=nMZamYoSrcrbkf0cipy5f8UTqedSBdHb
> 7Wx5%2F2nUqkI%3D&amp;reserved=0>
> 
> ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Cjohn.kaippallim
> alil%40futurewei.com%7C5c225b50684e46709e2108d8b1101135%7C0fee8ff2a3b2
> 40189c753a1d5591fedc%7C1%7C0%7C637454029863274628%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000&amp;sdata=Wox%2B4qgSrNicZW7Nu4fYeg8L5kc2mcFk6LHcMU6RpLM%3D&amp
> ;reserved=0 
> .ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Cjohn.kaippalli
> malil%40futurewei.com%7C5c225b50684e46709e2108d8b1101135%7C0fee8ff2a3b
> 240189c753a1d5591fedc%7C1%7C0%7C637454029863274628%7CUnknown%7CTWFpbGZ
> sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
> D%7C3000&amp;sdata=Wox%2B4qgSrNicZW7Nu4fYeg8L5kc2mcFk6LHcMU6RpLM%3D&am
> p;reserved=0>
> 
> 
> ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Cjohn.kaippallim
> alil%40futurewei.com%7C5c225b50684e46709e2108d8b1101135%7C0fee8ff2a3b2
> 40189c753a1d5591fedc%7C1%7C0%7C637454029863274628%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C3000&amp;sdata=Wox%2B4qgSrNicZW7Nu4fYeg8L5kc2mcFk6LHcMU6RpLM%3D&amp
> ;reserved=0
> 

_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C5c225b50684e46709e2108d8b1101135%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454029863274628%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Wox%2B4qgSrNicZW7Nu4fYeg8L5kc2mcFk6LHcMU6RpLM%3D&amp;reserved=0

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 5 Jan 2021 17:40:38 -0500

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.

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.  I would not expect DMM to need to 
get into how to map to the mechanisms, as that is an ever-evolving 
domain and one that is dealt with by the various domain WGs (TEAS, MPLS, 
SPRING, ...)

Yours,
Joel

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 5 Jan 2021 15:22:44 -0800

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) <
[email-masked]> 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.
> >> mechanisms) for IETF network slices.  That work is explicitly intended
> to support 3GPP end-to-end network slices.
> >>

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 5 Jan 2021 15:59:44 -0800

Hi Joel,

I would let John reply to you further , but a quick comment:

--
Uma C.

> terminology differences.  It would be helpful before adoption if there

[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.

> 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
> > 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.
> >
> > 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
> >
> >
> 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
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 5 Jan 2021 19:10:22 -0500

Looking agin at the document, I have multiple problems with adoption of 
this document.

First, as just discussed, it seems to be laying out an archtiecture, but 
that architecture is not consistent with the other work going on in the 
IETF (specifically in the routing area, and known to many of the 
co-authors of this work.)

Second, the document states that it is Informational, and then is 
written as if it is defining the one and only way to structure the 
needed system.

Third, related to the second, this document seems to assert that there 
is a specific and correct way to use IETF technology to solve the 
problem.  Then, about three quarters of the way through it remembers 
that there are multiple alternatives for some parts.  The IETF rarely 
writes implementation specifications.  There are other SDOs that do so. 
  They can wrestle with the problem of defining something that can be 
utilized by multiple operators with varying constraints.  Why would we 
want to get into trying to have that fight?

For the WG chairs, I am trying to figure out how this even fits the DMM 
charter.  It is a LOT more than network exposure, which is the closest I 
can see in the charter.

Yours, unhappily,
Joel

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 6 Jan 2021 10:51:42 -0600

This is an excellent review.
More below.

> writes implementation specifications.  There are other SDOs that do so.

This reminds me what is happening in quic WG which keeps producing
implementation specs.

> charter.  It is a LOT more than network exposure, which is the closest I
I had raised this charter issue long time before.
I pointed out that dmm has to recharter and even maybe make a BOF before
working on these.
They have all been ignored.

Hope that they won't this time :)

Folks, +1 on all counts.

I have to clarify that this mail is nothing personal, I know some authors,
they are my friends, the chairs are my friends.
No offense to anyone.

Happy New Year!

Behcet

---

From: Kaippallimalil John <[email-masked]>
Date: Wed, 6 Jan 2021 22:29:17 +0000

Joel,
This draft is not attempting to lay out a new architecture. The figure and architecture section are there to provide context for the reader.

The draft is also not asserting that these are the only ways to solve the issue. 
The last portion of the draft only refers to applicability since several IETF technology (and even non IETF data plane like L2) may be used E2E in the transport underlay corresponding to a 3GPP overlay (F1/W1, N3, N9). 
The draft is agnostic to any specific underlay. It is concerned with how the slice type/QoS properties between 3GPP provider and subscriber (UE) is realized as the data plane GTP packets (overlay) traverse one or more transport underlay segments on path.

The dmm working group seems to be a natural choice as folks there have background and expertise in both IETF and 3GPP technologies.  

Best Regards,
John

-----Original Message-----
From: dmm <[email-masked]> On Behalf Of Joel M. Halpern
Sent: Tuesday, January 05, 2021 6:10 PM
To: dmm <[email-masked]>
Subject: Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document - Objections

Looking agin at the document, I have multiple problems with adoption of this document.

First, as just discussed, it seems to be laying out an archtiecture, but that architecture is not consistent with the other work going on in the IETF (specifically in the routing area, and known to many of the co-authors of this work.)

Second, the document states that it is Informational, and then is written as if it is defining the one and only way to structure the needed system.

Third, related to the second, this document seems to assert that there is a specific and correct way to use IETF technology to solve the problem.  Then, about three quarters of the way through it remembers that there are multiple alternatives for some parts.  The IETF rarely writes implementation specifications.  There are other SDOs that do so. 
  They can wrestle with the problem of defining something that can be utilized by multiple operators with varying constraints.  Why would we want to get into trying to have that fight?

For the WG chairs, I am trying to figure out how this even fits the DMM charter.  It is a LOT more than network exposure, which is the closest I can see in the charter.

Yours, unhappily,
Joel

_______________________________________________
dmm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C3d167f9186e74cfca90008d8b1d78d79%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454886651720444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=sTvL%2Bu5b7qLIC%2BAmJ%2FvaIgToUMLUdY4bWCcZBlFn9Kw%3D&amp;reserved=0

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 6 Jan 2021 17:40:38 -0500

In line,
Joel

> The draft is agnostic to any specific underlay. It is concerned with how the slice type/QoS properties between 3GPP provider and subscriber (UE) is realized as the data plane GTP packets (overlay)…

At the veyr least, the draft needs significant rewording so taht it 
clealry explains what you are saying here.  As currently worded, it does 
not lead the reader to that understanding.  And as such, calls into 
doubt what the supporters of adoption believe they are adopting.

> The dmm working group seems to be a natural choice as folks there have background and expertise in both IETF and 3GPP technologies.

A WG looking like "the natural place" for something does not mean that 
said working group actually has the given work in its charter. For 
example, there were quite a number of drafts which were presented in the 
SFC WG as the natural place for initial discussion, but which did not 
fit within the SFC charter and therefore were not adopted by SFC as work 
items.