Hi, A colleague in the ETSI NFV has remarked to me the fact that the group has created a quite detailed spec, rooted at the ACTN ideas as well, on the interface to manage transport links among sites. I think this spec (IFA032, https://docbox.etsi.org/ISG/NFV/Open/Publications_pdf/Specs-Reports/NFV-IFA%20032v3.2.1%20-%20GS%20-%20Multi-site%20Intfaces%20and%20InfoModel%20spec.pdf) is a valuable foundation for the goals of this draft.
Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/in/dr2lopez/ e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com> Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- On 08/07/2019, 13:08, "Netslices on behalf of Rokui, Reza (Nokia - CA/Ottawa)" <netslices-boun...@ietf.org<mailto:netslices-boun...@ietf.org> on behalf of reza.ro...@nokia.com<mailto:reza.ro...@nokia.com>> wrote: Sure Takuya I will add them to the new version of the draft. Cheers, Reza From: Takuya Miyasaka <ta-miyas...@kddi-research.jp> Date: Sunday, July 7, 2019 at 9:07 PM To: Reza Rokui <reza.ro...@nokia.com>, "netsli...@ietf.org" <netsli...@ietf.org>, "rt...@ietf.org" <rt...@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, "t...@ietf.org" <t...@ietf.org>, "d...@ietf.org" <d...@ietf.org> Subject: Re: [DMM] New Version Notification for draft-rokui-5g-transport-slice-00.txt 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: Hi Takuya, Very good question. The response is inline. Reza From: Takuya Miyasaka <ta-miyas...@kddi-research.jp><mailto:ta-miyas...@kddi-research.jp> Date: Wednesday, July 3, 2019 at 7:54 AM To: Reza Rokui <reza.ro...@nokia.com><mailto:reza.ro...@nokia.com>, "netsli...@ietf.org"<mailto:netsli...@ietf.org> <netsli...@ietf.org><mailto:netsli...@ietf.org>, "rt...@ietf.org"<mailto:rt...@ietf.org> <rt...@ietf.org><mailto:rt...@ietf.org>, "opsawg@ietf.org"<mailto:opsawg@ietf.org> <opsawg@ietf.org><mailto:opsawg@ietf.org>, "t...@ietf.org"<mailto:t...@ietf.org> <t...@ietf.org><mailto:t...@ietf.org>, "d...@ietf.org"<mailto:d...@ietf.org> <d...@ietf.org><mailto:d...@ietf.org> 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: 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 [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. · 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 [Taku] That sounds good. · Thanks, Takuya Miyasaka KDDI Research On 2019/07/02 23:06, Rokui, Reza (Nokia - CA/Ottawa) wrote: 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, "internet-dra...@ietf.org"<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org><mailto:internet-dra...@ietf.org> 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 _______________________________________________ dmm mailing list d...@ietf.org<mailto:d...@ietf.org> https://www.ietf.org/mailman/listinfo/dmm ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
