Re: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

[<[e-mail]>]

Hi Cristina,

Please see inline.

Cheers,
Med

De : qiangli (D) [mailto:[e-mail]]
Envoyé : mardi 6 juin 2017 08:49
À : BOUCADAIR Mohamed IMT/OLN; [e-mail]
Cc : Susan Hares; 'Alex Galis'
Objet : RE: draft-qiang-netslices-gap-analysis-00 Uploaded

Hi Med,

Thank you very much for your comment, I will try to reply you inline.

Best regards,

Cristina QIANG

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Friday, June 02, 2017 9:59 PM
To: qiangli (D); [e-mail]<mailto:[e-mail]>
Subject: RE: draft-qiang-netslices-gap-analysis-00 Uploaded

Hi Cristina,

Thank you for sharing the draft. Please find below some comments, fwiw:

(1) Section 4.2.1 mentions the following:


"the [SLA-Exchange<https://tools.ietf.org/html/draft-qiang-netslices-gap-analysis-00#ref-SLA-Exchange>] can be used to
   negotiate the SLAs and report on SLA events.  Further analysis is
   needed to provide a complete package.
"


Actually, this is not possible with [SLA-Exchange] given that document says explicitly: "The SLA negotiation and assurance is outside the scope of this document."

[Cr] [SLA-Exchange](i.e., draft-ietf-idr-sla-exchange-10.txt) provides an in-band method to exchange the SLA parameters, and then by the receiving devices to translate SLA in technical specific provisioning languages. Our statement is indeed not accurate enough, [SLA-Exchange] could be a potential solution that INDIRECTLY implements the SLA negotiation IMHO. But also as this draft says "There does not exist any standard protocol to translate SLA agreements into technical clauses and configurations", this is a technical gap we are facing now.

[Med] Yes, the problem addressed in draft-ietf-idr-sla is worth to be solved... but it is a distinct one vs. negotiation/NSRS.


(2) Section 4.2.2. says the following:


   The NSRS requirement for reachability, direction, bandwidth

   requirements, performance metrics, traffic isolation constraints, and

   flow identification can be built utilizing protocol which can perform

   operations (read, write, notification, actions (aka rpcs)) on a yang

   service layer that supports these traffic engineer and resource

   definition at the service layers.  The network slicing service data

   model can extend existing work in the TEAS and I2RS working group for

   protocol-independent topology models.  These models support

   configuration or the dynamic datastores defined in [NMDA<https://tools.ietf.org/html/draft-qiang-netslices-gap-analysis-00#ref-NMDA>] which will

   be abbreviated as NMDA in this section.  This section provides the

   detail on how the NSRS can be built from these models and the

   RESTCONF protocol.

I'm a little bit puzzled here given that the NSRS is not about interacting with underlying network nodes. Especially, I'm not sure to understand the discussion about "protocol which can perform operations (read, write, notification, actions (aka rpcs))" in this context.

[Med] It seems that this one is to be yet discussed.


(3) Table 2:



·         Putting aside what is meant by "NS state monitoring", is there any particular reason "Mechanism/protocols for NS state monitoring;" is listed under NSRS? This is IMHO more an OAM issue.


[Cr] monitoring state (i.e. including monitoring of the resource  network functions usage) would require explicit probes dynamically configure and set up based on new mechanism. At such monitoring state and its configuration is a special and key part of the capability exposure. IMHO such monitoring is a key features which is currently not available - it is a gap.
[Med] I hear you, but all this should not be listed as part of the NSRS gap item. My comment was to move this activity to the OAM section.


·         Item "8) Mechanisms for on-demand, isolated, elastic and efficient network slice instantiation and resource association" is mysterious. I failed to find where that item is discussed in Section 6.



[Cr] The second paragraph of Sec. 6.1 simply discusses this point. The relevant discussion could be enhanced in next version.

[Med] OK, thanks.



·         I'm not sure to understand what is meant by "10) Mechanisms for customized network slices".

[Med] What about this one?



·         Items 12 and 13 are not related to NS identification. Further, those are not discussed in the corresponding section.



[Cr] Item 12, NS identification is essential for determining/discovering the corresponding network slice for coming flows, OAM operations, etc. ;

[Med] Yes, but discovery is discussed in Section 9, not Section 8:


   o  Ability to automatically discover the underlying service functions
      and the slices they are involved in or they belong to.



The table should be consistent with the core text. Thanks.



Item 13, the E2E repository for NS includes the mechanisms for name of NS translations when needed.

[Med] Not sure to get the point, especially I don't understand what you meant by "name of NS translations"



The relevant discussion will be enhanced in next version.

[Med] OK, thanks.

Thank you.

Cheers,
Med

De : Netslices [mailto:[e-mail]] De la part de qiangli (D)
Envoyé : vendredi 2 juin 2017 11:36
À : [e-mail]<mailto:[e-mail]>
Objet : [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded


Dear All,



We have upload "Gap Analysis for Network Slicing" draft 00 on https://datatracker.ietf.org/doc/draft-qiang-netslices-gap-analysis/?include_text=1

Your comments and reviews are greatly appreciated.



Abstract:

   This document presents network slicing differentiation from the non-

   partition network or from simply partition of connectivity resources.

   It lists 15 standardization gaps related to 6 key requirements for

   network slicing.  It also presents an analysis of existing related

   work and other potential solutions on network slicing.



   This gap analysis document aims to provide a basis for future works

   in network slicing.

Best regards,

Co-authors