“the [SLA-Exchange] can be used to
Actually, this is not possi=
ble with [SLA-Exchange] given that document says explicitly: “=
The SLA negotiation and assurance is outside the scope=
 of this document."
   The NSRS requirement for reachabilit=
y, direction, bandwidth
   requirements, performance metrics, t=
raffic isolation constraints, and
   flow identification can be built uti=
lizing protocol which can perform
   operations (read, write, notificatio=
n, actions (aka rpcs)) on a yang
   service layer that supports these tr=
affic engineer and resource
   definition at the service layers.&nb=
sp; The network slicing service data
   model can extend existing work in th=
e TEAS and I2RS working group for
   protocol-independent topology models=
.  These models support
   configuration or the dynamic datasto=
res defined in [NMDA] which will
   be abbreviated as NMDA in this secti=
on.  This section provides the
   detail on how the NSRS can be built =
from these models and the
   RESTCONF protocol.=

(3) Table 2:

=B7         =
P=
utting aside what is meant by “NS state m=
onitoring“, is ther=
e any particular reason “Mechanism/protoc=
ols for NS state monitoring;” is listed under NSRS? This is IMHO more=
 an OAM issue. 
=B7         =
Item “8) Mechanis=
ms for on-demand, isolated, elastic and efficient network slice instantiati=
on and resource association” is mysterious. I failed to find where th=
at item is discussed in Section 6.
=B7         =
I’m not sure to u=
nderstand what is meant by “10) Mechanisms for customized network sli=
ces”. 
=B7         =
Items 12 and 13 are not=
 related to NS identification. Further, those are not discussed in the corr=
esponding section. 

Thank you.

Cheers,
Med

De : Netslice=
s [mailto:netslices-bounces@ietf.org]
De la part de qiangli (D)

Envoy=E9 : vendred=
i 2 juin 2017 11:36

=C0 : NetSlices@ietf.org

Objet : [Netslices] draft-qiang-netslices-gap-analysis-00 Uploa=
ded

 =

Dear All,

We have upload "Gap Analysis for Network Slicing" draft =
00 on

https://datatracker.ietf.org/doc/draft-qiang-netslices-gap-analysis/?includ=
e_text=3D1
Your comments and reviews are greatly appreciated.

Abstract:
   This document presents network slicing differentiatio=
n from the non-
   partition network or from simply partition of connect=
ivity resources.
   It lists 15 standardization gaps related to 6 key req=
uirements for
   network slicing.  It also presents an analysis o=
f existing related
   work and other potential solutions on network slicing=
.

   This gap analysis document aims to provide a basis fo=
r future works
   in network slicing.

Best regards,

Co-authors

“the [SLA-Exchange] can be used to
Actually, this is not possi=
ble with [SLA-Exchange] given that document says explicitly: “=
The SLA negotiation and assurance is outside the scope=
 of this document."
   The NSRS requirement for reachabilit=
y, direction, bandwidth
   requirements, performance metrics, t=
raffic isolation constraints, and
   flow identification can be built uti=
lizing protocol which can perform
   operations (read, write, notificatio=
n, actions (aka rpcs)) on a yang
   service layer that supports these tr=
affic engineer and resource
   definition at the service layers.&nb=
sp; The network slicing service data
   model can extend existing work in th=
e TEAS and I2RS working group for
   protocol-independent topology models=
.  These models support
   configuration or the dynamic datasto=
res defined in [NMDA<=
/a>] which will
   be abbreviated as NMDA in this secti=
on.  This section provides the
   detail on how the NSRS can be built =
from these models and the
   RESTCONF pr=
otocol.
(3) Table 2:

=B7         =
P=
utting aside what is meant by “NS state m=
onitoring“, is there any particular reaso=
n “Mechanism/protocols for NS state monitoring;” is list=
ed under NSRS? This is IMHO more an OAM issue. 

[Cr] mo=
nitoring state (i.e. including monitoring of the resource  network fun=
ctions usage) would require explicit probes dynamically configure and set u=
p based on new mechanism. At such monitoring
 state and its configuration is a special and key part of the capability ex=
posure. IMHO such monitoring is a key features which is currently not avail=
able - it is a gap.
&n=
bsp;
=B7         =
Item “8) Mechanis=
ms for on-demand, isolated, elastic and efficient network slice instantiati=
on and resource association” is mysterious. I failed to find where th=
at 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.

=B7         =
I’m not sure to u=
nderstand what is meant by “10) Mechanisms for customized network sli=
ces”. 
=B7         =
Items 12 and 13 are not=
 related to NS identification. Further, those are not discussed in the corr=
esponding section. 

[Cr]=
 Item 12, NS identification is essential for determining/discovering the co=
rresponding network slice for coming flows, OAM operations, etc. ; Item 13,=
 the E2E repository for NS includes the
 mechanisms for name of NS translations when needed.  The relevant dis=
cussion will be enhanced in next version.

Thank you.

Cheers,
Med

De : Netslice=
s [mailto:netslices-bounces@i=
etf.org]
De la part de qiangli (D)

Envoy=E9 : vendredi 2 juin 2017 11:36

=C0 : NetSlices@ietf.org<=
/a>

Objet : [Netslices] draft-qiang-netslices-gap-analysis-00 Uploa=
ded

Dear All,<=
/p>

We have upload "Gap Ana=
lysis for Network Slicing" draft 00 on

https://datatracker.ietf.org/doc/draft-qiang-netslices-gap-analysis/?includ=
e_text=3D1
Your comments and reviews ar=
e greatly appreciated.

Abstract:<=
/p>
   This document p=
resents network slicing differentiation from the non-
   partition netwo=
rk or from simply partition of connectivity resources.
   It lists 15 sta=
ndardization gaps related to 6 key requirements for
   network slicing=
.  It also presents an analysis of existing related<=
/p>
   work and other =
potential solutions on network slicing.

   This gap analys=
is document aims to provide a basis for future works
   in network slic=
ing.

Best regards,=

Co-authors

“the [SLA-Exchange] can be used to
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."
   The NSRS requirement =
for reachability, direction, bandwidth
   requirements, perform=
ance metrics, traffic isolation constraints, and
   flow identification c=
an be built utilizing protocol which can perform
   operations (read, wri=
te, notification, actions (aka rpcs)) on a yang
   service layer that su=
pports these traffic engineer and resource
   definition at the ser=
vice layers.  The network slicing service data
   model can extend exis=
ting work in the TEAS and I2RS working group for
   protocol-independent =
topology models.  These models support
   configuration or the =
dynamic datastores defined in [NMDA] which wil=
l
   be abbreviated as NMD=
A in this section.  This section provides the
   detail on how the NSR=
S can be built from these models and the
   RESTCONF protocol.
(3) Table 2:

=B7 =
;        =
Putting aside what is meant=
 by “NS state monitoring“, is there any particular reason “Mechanism/protocols for NS state monitoring;” is listed under NS=
RS? This is IMHO more an OAM issue. 

=B7 =
;        =
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 discu=
ssed 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. 

=B7 =
;        =
I’m not sure to understand what i=
s meant by “10) Mechanisms for customized network slices”. 
[Med] What about this =
one?

=B7 =
;        =
Items 12 and 13 are not related to NS i=
dentification. Further, those are not discussed in the corresponding sectio=
n. 

In those cases, the goal of the
BOF is to demonstrate that the community has agreement that:

      - there is a problem that needs solving, and the IETF is the right
        group to attempt solving it.

      - there is a critical mass of participants willing to work on the
        problem (e.g., write drafts, review drafts, etc.).

      - the scope of the problem is well defined and understood, that
        is, people generally understand what the WG will work on (and
        what it won't) and what its actual deliverables will be.

      - there is agreement that the specific deliverables (i.e.,
        proposed documents) are the right set.

      - it is believed that the WG has a reasonable probability of
        having success (i.e., in completing the deliverables in its
        charter in a timely fashion).
In those cases, the goal of =
the
BOF is to demonstrate that the =
community has agreement that:

      - there =
is a problem that needs solving, and the IETF is the =
right
      &nb=
sp; group to attempt solving it.

      - there =
is a critical mass of participants willing to work on =
the
      &nb=
sp; problem (e.g., write drafts, review drafts, =
etc.).

      - the =
scope of the problem is well defined and understood, =
that
      &nb=
sp; is, people generally understand what the WG will work on =
(and
      &nb=
sp; what it won't) and what its actual deliverables will =
be.

      - there =
is agreement that the specific deliverables =
(i.e.,
    =
    proposed documents) are the right =
set.

      - it is =
believed that the WG has a reasonable probability =
of
      &nb=
sp; having success (i.e., in completing the deliverables in =
its
      &nb=
sp; charter in a timely fashion).