Subject: Re: [DMM] New Version Notification for draft-rokui-5g-transport-slice-00.txt

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 2 Jul 2019 14:06:33 +0000

Hi all,

This is to inform you that the following new draft has been submitted to ietf.
The goal of this draft is to demonstrate the role of ietf for 5g network slicing in area of transport slices.

Your review and feedback would be greatly appreciated.

Thanks,

Reza Rokui

On 2019-07-02, 9:30 AM, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-rokui-5g-transport-slice-00.txt

    has been successfully submitted by Reza Rokui and posted to the

    IETF repository.

    Name:           draft-rokui-5g-transport-slice

    Revision: 00

    Title:          5G Transport Slice Connectivity Interface

    Document date:  2019-07-02

    Group:          Individual Submission

    Pages:          28
    URL:            https://www.ietf.org/internet-drafts/draft-rokui-5g-transport-slice-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-rokui-5g-transport-slice/
    Htmlized:       https://tools.ietf.org/html/draft-rokui-5g-transport-slice-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-rokui-5g-transport-slice

    Abstract:

       The 5G Network slicing is an approach to provide separate independent

       E2E logical network from user equipment (UE) to applications where

       each network slice has different SLA requirements.  Each E2E network

       slice consists of multitude of RAN-slice, Core-slice and Transport-

       slices, each with its own controller.  To provide automation,

       assurance and optimization of the network slices, an E2E network

       slice controller is needed which interacts with controller in RAN,

       Core and Transport slices.  The interfaces between the E2E network

       slice controller and RAN and Core controllers are defined in various

       3GPP technical specifications.  However, 3GPP has not defined the

       same interface for transport slices.

       The aim of this document is to provide the clarification of this

       interface and to provide the information model of this interface for

       automation, monitoring and optimization of the transport slices.

    Please note that it may take a couple of minutes from the time of submission

    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

---

From: Takuya Miyasaka <[email-masked]>
Date: Wed, 3 Jul 2019 20:54:24 +0900

Hi Reza,

Thanks for sharing this draft. I'm curious about how to bind/associate 
3GPP(RAN/Core) slice instance and Transport slice instance and section 
5.2 of this draft describes as follows:

       o In order to have the connectivity between RAN1 and UPF1, the RAN
          and Core slices should be associated to Transport slice. This is
          also a by-product of the Transport slice connectivity interface
          when all allocated resources for access points (such as allocated
          VLAN IDs, IP addresses etc) are conveyed to RAN and Core Slices.
          This will be done by cordiantion between transport slice
          controller and E2E network slice controller.

As for this sentences, could you confirm if following procedures will be 
conducted between controllers in order to associate independent slice 
instances or not?
  - E2E Network Slice Controller sends a request on transport slice 
creation to Transport Controller (interface 10 of Fig.2)
  - Transport Controller creates transport slice instance and sends 
access point information(e.g. VLAN ID) to E2E Network Slice Controller
  - E2E Network Slice Controller sends a request on access point 
creation/modification to RAN/Core Controller
  - RAN/Core Controller create/modify access point on gNB/UPF 
respectively, which means gNB/UPF starts to attach adequate access point 
information(e.g. VLAN ID) on their user plane packet

Thanks,
Takuya Miyasaka
KDDI Research

On 2019/07/02 23:06, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> The goal of this draft is to demonstrate the role of ietf for 5g 
> network slicing in area of transport slices.
>
>     URL: 
> https://www.ietf.org/internet-drafts/draft-rokui-5g-transport-slice-00.txt
>
>     Status: 
> https://datatracker.ietf.org/doc/draft-rokui-5g-transport-slice/
>
>     Htmlized: 
> https://tools.ietf.org/html/draft-rokui-5g-transport-slice-00
>
>     Htmlized: 
> https://datatracker.ietf.org/doc/html/draft-rokui-5g-transport-slice
>
>     Abstract:
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 4 Jul 2019 14:51:43 +0000

Hi Takuya,
Very good question. The response is inline.

Reza

From: Takuya Miyasaka <[email-masked]>
Date: Wednesday, July 3, 2019 at 7:54 AM
To: Reza Rokui <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [DMM] New Version Notification for draft-rokui-5g-transport-slice-00.txt

Hi Reza,

Thanks for sharing this draft. I'm curious about how to bind/associate 3GPP(RAN/Core) slice instance and Transport slice instance and section 5.2 of this draft describes as follows:

As for this sentences, could you confirm if following procedures will be conducted between controllers in order to associate independent slice instances or not?
 - E2E Network Slice Controller sends a request on transport slice creation to Transport Controller (interface 10 of Fig.2)
 - Transport Controller creates transport slice instance and sends access point information(e.g. VLAN ID) to E2E Network Slice Controller
 - E2E Network Slice Controller sends a request on access point creation/modification to RAN/Core Controller
 - RAN/Core Controller create/modify access point on gNB/UPF respectively, which means gNB/UPF starts to attach adequate access point information(e.g. VLAN ID) on their user plane packet

[Reza] The above procedure is correct but this is one way to implement the binding (aka association) between RAN-Transport slices and Core-Transport slices.

There are other ways to implement the binding. For example, the transport slice controller can populate the following two tables dynamically during the transport slice creation, modification or deletion and expose access to this table using open APIs. Then, the RAN/Core network functions or RAN/Core slice controllers can access these APIs to program the VLAN/IP/Labels.

  *   RAN-Transport mapping table: Which maps the RAN VLAN/IP address/MPLS Labels etc to network slice
  *   Core-Transport mapping table: Which maps the Core VLAN/IP address/MPLS Labels etc to network slice

Thanks,
Takuya Miyasaka
KDDI Research

Thanks,

Reza Rokui

On 2019-07-02, 9:30 AM, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]> wrote:

    IETF repository.

    Revision: 00

    Pages:          28

    Abstract:

    The IETF Secretariat

dmm mailing list

[email-masked]<mailto:[email-masked]>

---

From: Takuya Miyasaka <[email-masked]>
Date: Mon, 8 Jul 2019 10:07:59 +0900

Hi Reza,

Thanks for your response and please see my comments below with [Taku].

Thanks,
Takuya

On 2019/07/04 23:51, Rokui, Reza (Nokia - CA/Ottawa) wrote:
> *From: *Takuya Miyasaka <[email-masked]>
> *Date: *Wednesday, July 3, 2019 at 7:54 AM
> *To: *Reza Rokui <[email-masked]>, "[email-masked]" 
> <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Subject: *Re: [DMM] New Version Notification for 
> draft-rokui-5g-transport-slice-00.txt
>
> Hi Reza,
>
> As for this sentences, could you confirm if following procedures will 
> be conducted between controllers in order to associate independent 
> slice instances or not?
> respectively, which means gNB/UPF starts to attach adequate access 
> point information(e.g. VLAN ID) on their user plane packet
>
> [Reza] The above procedure is correct but this is one way to implement 
> the binding (aka association) between RAN-Transport slices and 
> Core-Transport slices.
>
[Taku] OK. If such kinds of procedures are taken at Core/RAN Controller, 
it might be better to describe such procedures in Section3.
           We also have to check if these access point information can 
be conveyed at the 3GPP defined interface between E2E Controller and 
Core/RAN Controller.

> There are other ways to implement the binding. For example, the 
> transport slice controller can populate the following two tables 
> dynamically during the transport slice creation, modification or 
> deletion and expose access to this table using open APIs. Then, the 
> RAN/Core network functions or RAN/Core slice controllers can access 
> these APIs to program the VLAN/IP/Labels.
>
[Taku] That sounds good.

>  *
>     On 2019-07-02, 9:30 AM, "[email-masked]"
>     <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]> wrote:
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 8 Jul 2019 12:06:22 +0000

Sure Takuya I will add them to the new version of the draft.

Cheers,
Reza

From: Takuya Miyasaka <[email-masked]>
Date: Sunday, July 7, 2019 at 9:07 PM
To: Reza Rokui <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [DMM] New Version Notification for draft-rokui-5g-transport-slice-00.txt

Hi Reza,

Thanks,
Takuya

Reza

From: Takuya Miyasaka <[email-masked]><mailto:[email-masked]>
Date: Wednesday, July 3, 2019 at 7:54 AM
To: Reza Rokui <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: Re: [DMM] New Version Notification for draft-rokui-5g-transport-slice-00.txt

Hi Reza,

[Taku] OK. If such kinds of procedures are taken at Core/RAN Controller, it might be better to describe such procedures in Section3.
          We also have to check if these access point information can be conveyed at the 3GPP defined interface between E2E Controller and Core/RAN Controller.

[Taku] That sounds good.

  *

Thanks,
Takuya Miyasaka
KDDI Research

Thanks,

Reza Rokui

    IETF repository.

    Revision: 00

    Pages:          28

    Abstract:

    The IETF Secretariat

dmm mailing list

---

From: Kaippallimalil John <[email-masked]>
Date: Wed, 10 Jul 2019 18:59:39 +0000

Hi, Takuya, Reza,
A couple of drafts that have some details on Takuya’s question on association of RAN and core slices to transport slices.
- https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/?include_text=1 (section 2.2) and  https://tools.ietf.org/pdf/draft-lee-teas-actn-5g-transport-00.pdf.

The Transport Slice controller functionality in draft-rokui is present in the transport domain SDN-C in these drafts.
The slice controller in the 5G/3GPP domain (functionality identified by TNF, TPM in the drafts) establishes a context that maps between 3GPP/5G and transport slice and path.
The context mapping across 3GPP/ transport network is proportional to number of sites, classes of service, etc. --> much lower than number of PDU sessions, i.e., much less provisioning than per session.

The other related issue is about how to carry this “context” info in PDU /IP packets between 2 mobile network functions (gNB, UPF).
The gNB/UPF may not be part of the transport network (i.e., terminate MPLS, VLAN,..).
The drafts outline a couple of ways to carry this “context” as meta-data – which the transport network PE can inspect/grant the level of service provisioned.

BR,
John

This e-mail and any attachments may contain confidential information from Futurewei, which are intended only for the person or entity whose email address appears above. Any use of the information attached or contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or any unapproved dissemination) by persons other than the intended recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender by phone or response email immediately and delete this original message.

From: OPSAWG <[email-masked]> On Behalf Of Rokui, Reza (Nokia - CA/Ottawa)
Sent: Monday, July 08, 2019 7:06 AM
To: Takuya Miyasaka <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] [DMM] New Version Notification for draft-rokui-5g-transport-slice-00.txt

Cheers,
Reza

From: Takuya Miyasaka <[email-masked]<mailto:[email-masked]>>
Date: Sunday, July 7, 2019 at 9:07 PM
To: Reza Rokui <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] New Version Notification for draft-rokui-5g-transport-slice-00.txt

Hi Reza,

Thanks,
Takuya

Reza

Hi Reza,

[Taku] That sounds good.

  *

Thanks,
Takuya Miyasaka
KDDI Research

Thanks,

Reza Rokui

    IETF repository.

    Revision: 00

    Pages:          28
    URL:            https://www.ietf.org/internet-drafts/draft-rokui-5g-transport-slice-00.txt<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-rokui-5g-transport-slice-00.txt&data=02%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cf8a9695bd06e4694d1af08d7039d0689%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636981845288575400&sdata=B0m7KRQc6i7oTvk%2F4edGqLzIjVwkvX2M6C50ZpOrSvs%3D&reserved=0>
    Status:         https://datatracker.ietf.org/doc/draft-rokui-5g-transport-slice/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-rokui-5g-transport-slice%2F&data=02%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cf8a9695bd06e4694d1af08d7039d0689%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636981845288575400&sdata=jBiun27SmWI35zhWeMctpK8eN3K3dAMSckb%2FPuzEYLI%3D&reserved=0>
    Htmlized:       https://tools.ietf.org/html/draft-rokui-5g-transport-slice-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-rokui-5g-transport-slice-00&data=02%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cf8a9695bd06e4694d1af08d7039d0689%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636981845288585394&sdata=vkFMtSPJIx%2BknMM%2B%2Bsij3zNRpFeR67Qg3KjV7%2BtMmsE%3D&reserved=0>
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-rokui-5g-transport-slice<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-rokui-5g-transport-slice&data=02%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cf8a9695bd06e4694d1af08d7039d0689%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636981845288585394&sdata=LubuNd%2BzawBS44%2B6EhtS9%2FyLh8MRi9VjjL%2FFQKWnFbw%3D&reserved=0>

    Abstract:

    The IETF Secretariat

dmm mailing list

https://www.ietf.org/mailman/listinfo/dmm<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm&data=02%7C01%7Cjohn.kaippallimalil%40futurewei.com%7Cf8a9695bd06e4694d1af08d7039d0689%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636981845288595390&sdata=%2BxI1%2B8VF5S2cd9gcekghLh7mtP3zdrn94NzhG5cGjU0%3D&reserved=0>