Re: [OPSAWG] [**EXTERNAL**] Re: [Teas] A question on the definitions of SDP and SAP
Wim, As Adrian pointed out, your comment is related to IETF network slice realization. I interpret your comment that there shall be some discussions on IETF network slice framework draft about the realization. If so, I agree that we can add some texts about this to just reflect the fact that NCS can use any approach for realization including the solution you provided. We might be able to give your example to clarify the potential multiplexing by NCS. However, having said that I agree with Adrian that the framework document SHALL not talk about details of realization as IETF network slice is technology agnostics. Cheers, Reza From: Teas on behalf of Adrian Farrel Date: Tuesday, March 22, 2022 at 9:49 PM To: 'Henderickx, Wim (Nokia - BE/Antwerp)' , 'Greg Mirsky' , 'Med Boucadair' Cc: 'opsawg' , 'TEAS WG' Subject: [**EXTERNAL**] Re: [Teas] A question on the definitions of SDP and SAP Hi Wim, You’re welcome to shime whenever you want. I think it is important, in this discussion, to reflect that the service is not the realisation. For the main part, this document describes the service and, while it must allow for multiple realisations, it does not attempt detailed descriptions. Cheers, Adrian From: Teas On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp) Sent: 22 March 2022 14:09 To: Greg Mirsky ; Med Boucadair Cc: Adrian Farrel ; opsawg ; TEAS WG Subject: Re: [Teas] A question on the definitions of SDP and SAP Sorry the shime in late in this thread but there is one thing still bothering or I wanted to highlight. Maybe we can do another thread if needed. Here is the thing I am struggling with in the current draft, which is what I call multiplexing or what I sometime call mapping. My understanding so far is we have SDP and connectivity construct to represent a slice In reality I believe or in my view: we have SDP – a forwarder of some sort (it is dependent on the connectivity matrix) – a connectivity matrix On top we have some multiplexing and mapping into these constructs. So in my view you can implement the slices in various ways. I am using 3GPP as the endpoints radio in this case And my examples are not exhaustive but I am using to show what I mean with multiplexing/mapping e.g. * Slice1 -> Radio – vlan 1 – sdp 1 – fwd ctx 1 – connectivity matrix 1 * Slice2 -> radio – vlan 2 – sdp 1 – fwd ctx 2 – connectivity matrix 2 Or * Slice1 -> Radio – vlan 1 – sdp 1 – fwd ctx 1 – connectivity matrix 1 * Slice2 -> radio – vlan 2 – sdp 1 – fwd ctx 1 – connectivity matrix 2 Or * Slice1 -> Radio – flow label 1 – sdp 1 – fwd ctx 1 – connectivity matrix 1 * Slice2 -> radio – flow label 2– sdp 1 – fwd ctx 2 – connectivity matrix 2 Or * Slice1 -> Radio – flow label 1 – sdp 1 – fwd ctx 1 – connectivity matrix 1 * Slice2 -> radio – flow label 2– sdp 1 – fwd ctx 1 – connectivity matrix 2 Also would be good to see if this is covered how this maps in the current framework. From: Teas mailto:teas-boun...@ietf.org>> on behalf of Greg Mirsky mailto:gregimir...@gmail.com>> Date: Tuesday, 22 March 2022 at 14:50 To: Med Boucadair mailto:mohamed.boucad...@orange.com>> Cc: Adrian Farrel mailto:adr...@olddog.co.uk>>, opsawg mailto:opsawg@ietf.org>>, TEAS WG mailto:t...@ietf.org>> Subject: Re: [Teas] A question on the definitions of SDP and SAP Hi Med, thank you for the additional information. In my understanding, please correct me if it is off, L3 and L2 VPNs are technologies that can be used to realize an IETF Network Slice. If that is the case, then the SAP in, for example, an L3 VPN is also SDP of the IETF Network Slice. Am I missing something? Kind regards, Greg On Tue, Mar 22, 2022 at 5:43 AM mailto:mohamed.boucad...@orange.com>> wrote: Hi Greg, Other examples can be an L3 VPN network access (RFC9182) or L2 VPN network access (draft-ietf-opsawg-l2nm). FWIW, the SAP spec include these notes: (1) For example, this concept is used to decide where to attach and, thus, deliver the service in the Layer 3 VPN Service Model (L3SM) [RFC8299] and the Layer 2 VPN Service Model (L2SM) [RFC8466]. It can also be used to retrieve where services, such as the Layer 3 VPN Network Model (L3NM) [RFC9182], and the Layer 2 VPN Network Model (L2NM) [I-D.ietf-opsawg-l2nm], are delivered to customers. (2) For example, 'sap-id' may be the VPN network access identifier in Section 7.6 of [RFC9182]. An example to illustrate the use of this attribute during service creation is provided in Appendix D. Cheers, Med De : Greg Mirsky mailto:gregimir...@gmail.com>> Envoyé : mardi 22 mars 2022 10:34 À : BOUCADAIR Mohamed INNOV/NET mailto:mohamed.boucad...@orange.com>> Cc : Adrian Farrel mailto:adr...@olddog.co.uk>>; TEAS WG mailto:t...@ietf.org>>; opsawg mailto:opsawg@ietf.org>> Objet : Re: A question on the definitions of SDP and SAP Hi Med, thank you for pointing this out to me. I have a follow-up question. If I understand
[OPSAWG]shepherd review for draft-boro-opsawg-teas-common-ac
Hi authors, I am document shepherd for draft-boro-opsawg-teas-common-ac. I am preparing the shepherd writeup and have following questions. Question 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc; * Referring to https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-10.txt . It seems there a few warnings and errors. Are these resolved? If so, please send a summary. Question 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. * Please confirm this Question 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? * [ISO10589]. Is this reference essential to be part of the RFC? Question 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. - Please comment on following normative RFCs: RFC 8174 category is BCP RFC 7348 category is Informational and is already in DOWNREF registry RFC 3688 category is BCP RFC 2119 category is BCP Question 19. Will publication of this document change the status of any existing RFCs? If so, does the Data tracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. * IMO the answer is NO. Please confirm. Reza ___ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
[OPSAWG]Re: shepherd review for draft-boro-opsawg-teas-common-ac
Thanks Med. One more question. 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? [Reza] The document is well-written. Having said that the following suggestion communicated with authors. - Any reason that the tree format of "module ietf-ac-common" is not included. IMO, it provides more clarity to the reader. Reza From: mohamed.boucad...@orange.com Date: Tuesday, May 14, 2024 at 9:05 AM To: Rokui, Reza , Joe Clarke (jclarke) , opsawg@ietf.org , Wubo (lana) , Richard Roberts , Oscar González de Dios , samier.barguil_gira...@nokia.com Subject: [**EXTERNAL**] RE: shepherd review for draft-boro-opsawg-teas-common-ac Hi Reza, Thank you for preparing the writeup. Please see inline. Cheers, Med De : Rokui, Reza Envoyé : lundi 13 mai 2024 21:35 À : Joe Clarke (jclarke) ; opsawg@ietf.org; BOUCADAIR Mohamed INNOV/NET ; Wubo (lana) ; Richard Roberts ; Oscar González de Dios ; samier.barguil_gira...@nokia.com; Rokui, Reza Objet : shepherd review for draft-boro-opsawg-teas-common-ac Hi authors, I am document shepherd for draft-boro-opsawg-teas-common-ac. I am preparing the shepherd writeup and have following questions. Question 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc; [Med] pyang is integrated in our tooling to validate the YANG module. This is also reflected in the Datatracker: 0 errors, 0 warnings [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/__;!!OSsGDw!PPw4N8lmRYYhkJIAAwgUtUJ9WBVdDaxSHmi3qihFpYWelFOcNNC2nnAF28SL8jsIcL-s04wN4NA-grpZMpZE2Pc$> · Referring to https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-10.txt [author-tools.ietf.org]<https://urldefense.com/v3/__https:/author-tools.ietf.org/api/idnits?url=https:**Awww.ietf.org*archive*id*draft-ietf-opsawg-teas-common-ac-10.txt__;Ly8vLy8!!OSsGDw!PPw4N8lmRYYhkJIAAwgUtUJ9WBVdDaxSHmi3qihFpYWelFOcNNC2nnAF28SL8jsIcL-s04wN4NA-grpZ27hyUxY$> . It seems there a few warnings and errors. Are these resolved? If so, please send a summary. [Med] Most are false negatives. The only valid one is the RFC 2119 boilerplate text. Will remove it in the next iteration. Question 15. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16]. · Please confirm this [Med] I think we are OK, but please let us know if we misclassified any. Question 16. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? · [ISO10589]. Is this reference essential to be part of the RFC? [Med] Yes, because this is the authoritative ref for ISIS. Question 17. Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them. - Please comment on following normative RFCs: RFC 8174 category is BCP RFC 7348 category is Informational and is already in DOWNREF registry RFC 3688 category is BCP RFC 2119 category is BCP [Med] ACK. I confirm in particular that 7348 is already in the DOWNREF registry. Question 19. Will publication of this document change the status of any existing RFCs? If so, does the Data tracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. · IMO the answer is NO. Please confirm. [Med] ACK. Reza Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for mes
[OPSAWG]Re: shepherd review for draft-boro-opsawg-teas-common-ac
Thanks Med. Reza From: mohamed.boucad...@orange.com Date: Wednesday, May 15, 2024 at 3:41 PM To: Rokui, Reza , Joe Clarke (jclarke) , opsawg@ietf.org , Wubo (lana) , Richard Roberts , Oscar González de Dios , samier.barguil_gira...@nokia.com Subject: [**EXTERNAL**] RE: shepherd review for draft-boro-opsawg-teas-common-ac Hi Reza, Thank you for the review. We don’t provide the full structure but snippets per the guidance in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11#name-tree-diagrams [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-11*name-tree-diagrams__;Iw!!OSsGDw!NjxoQSzN_CWfDiwhz7FB8LOTs4vPQXPNW46d9sRZwky_MMvHjIJy_A7v-DyWkd1e8KosIc4yep8JmNNZo1zl-3I$>. We provided the following in Section 4: == The full tree diagram of the module can be generated using the "pyang" tool [PYANG] with "-f tree --tree-print-groupings" command- line parameters. That tree is not included here because it is too long (Section 3.3 of [RFC8340]). Instead, subtrees are provided for the reader's convenience. The full tree of the "ietf-ac-common" module is available at [AC-Common-Tree]. == Cheers, Med De : Rokui, Reza Envoyé : mercredi 15 mai 2024 21:29 À : BOUCADAIR Mohamed INNOV/NET ; Joe Clarke (jclarke) ; opsawg@ietf.org; Wubo (lana) ; Richard Roberts ; Oscar González de Dios ; samier.barguil_gira...@nokia.com; Rokui, Reza Objet : Re: shepherd review for draft-boro-opsawg-teas-common-ac Thanks Med. One more question. 9. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? [Reza] The document is well-written. Having said that the following suggestion communicated with authors. - Any reason that the tree format of "module ietf-ac-common" is not included. IMO, it provides more clarity to the reader. Reza From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> mailto:mohamed.boucad...@orange.com>> Date: Tuesday, May 14, 2024 at 9:05 AM To: Rokui, Reza mailto:rro...@ciena.com>>, Joe Clarke (jclarke) mailto:jcla...@cisco.com>>, opsawg@ietf.org<mailto:opsawg@ietf.org> mailto:opsawg@ietf.org>>, Wubo (lana) mailto:lana.w...@huawei.com>>, Richard Roberts mailto:rrobe...@juniper.net>>, Oscar González de Dios mailto:oscar.gonzalezded...@telefonica.com>>, samier.barguil_gira...@nokia.com<mailto:samier.barguil_gira...@nokia.com> mailto:samier.barguil_gira...@nokia.com>> Subject: [**EXTERNAL**] RE: shepherd review for draft-boro-opsawg-teas-common-ac Hi Reza, Thank you for preparing the writeup. Please see inline. Cheers, Med De : Rokui, Reza mailto:rro...@ciena.com>> Envoyé : lundi 13 mai 2024 21:35 À : Joe Clarke (jclarke) mailto:jcla...@cisco.com>>; opsawg@ietf.org<mailto:opsawg@ietf.org>; BOUCADAIR Mohamed INNOV/NET mailto:mohamed.boucad...@orange.com>>; Wubo (lana) mailto:lana.w...@huawei.com>>; Richard Roberts mailto:rrobe...@juniper.net>>; Oscar González de Dios mailto:oscar.gonzalezded...@telefonica.com>>; samier.barguil_gira...@nokia.com<mailto:samier.barguil_gira...@nokia.com>; Rokui, Reza mailto:rro...@ciena.com>> Objet : shepherd review for draft-boro-opsawg-teas-common-ac Hi authors, I am document shepherd for draft-boro-opsawg-teas-common-ac. I am preparing the shepherd writeup and have following questions. Question 8. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc; [Med] pyang is integrated in our tooling to validate the YANG module. This is also reflected in the Datatracker: 0 errors, 0 warnings [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-opsawg-teas-common-ac/__;!!OSsGDw!PPw4N8lmRYYhkJIAAwgUtUJ9WBVdDaxSHmi3qihFpYWelFOcNNC2nnAF28SL8jsIcL-s04wN4NA-grpZMpZE2Pc$> Referring to https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-opsawg-teas-common-ac-10.txt [author-tools.ietf.org]<https://urldefense.com/v3/__https:/author-tools.ietf.org/api/idnits?url=https:**Awww.ietf.org*archive*id*draft-ietf-opsawg-teas-common-ac-10.txt__;Ly8vLy8!!OSsGDw!PPw4N8lmRYYhkJIAAwgUtUJ9WBVdDaxSHmi3qihFpYWelFOcNNC2nnAF28SL8jsIcL-s04wN4NA-grpZ27hyUxY$> . It seems there a few warnings and errors. Are these resolved? If so, please send a summary. [Med] Most are false negatives. The only valid one is the RFC 2119 boilerplate text. Will remove it in the next iteration. Question 15. Should any informative references be normative or vice-versa? See the [IESG S
Re: [OPSAWG] New Version Notification for draft-rokui-5g-transport-slice-00.txt
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" 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 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] [DMM] New Version Notification for draft-rokui-5g-transport-slice-00.txt
Hi Takuya, Very good question. The response is inline. Reza From: Takuya Miyasaka Date: Wednesday, July 3, 2019 at 7:54 AM To: Reza Rokui , "netsli...@ietf.org" , "rt...@ietf.org" , "opsawg@ietf.org" , "t...@ietf.org" , "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. 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 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> <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
Re: [OPSAWG] [DMM] New Version Notification for draft-rokui-5g-transport-slice-00.txt
Sure Takuya I will add them to the new version of the draft. Cheers, Reza From: Takuya Miyasaka Date: Sunday, July 7, 2019 at 9:07 PM To: Reza Rokui , "netsli...@ietf.org" , "rt...@ietf.org" , "opsawg@ietf.org" , "t...@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 <mailto:ta-miyas...@kddi-research.jp> Date: Wednesday, July 3, 2019 at 7:54 AM To: Reza Rokui <mailto:reza.ro...@nokia.com>, "netsli...@ietf.org"<mailto:netsli...@ietf.org> <mailto:netsli...@ietf.org>, "rt...@ietf.org"<mailto:rt...@ietf.org> <mailto:rt...@ietf.org>, "opsawg@ietf.org"<mailto:opsawg@ietf.org> <mailto:opsawg@ietf.org>, "t...@ietf.org"<mailto:t...@ietf.org> <mailto:t...@ietf.org>, "d...@ietf.org"<mailto: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> <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
