Re: [Teas-ns-dt] New Version Notification for draft-nsdt-teas-ietf-network-slice-definition-00.txt

[[e-mail]]

Hi Kiran,

> Let ask naïve questions on (1) Can you explain what's misleading?

Sure.

Changing the name without adjusting the scope is what is misleading. The actual description is more about connectivity which is exactly what you had in previous versions of the draft but the use of "network slice" suggests this is not exclusively restricted to connectivity but can include "something else". There is a disconnect if you will between the scope as described in the draft and the current name. This discussion is meant to hopefully clarify this.

> and " **specific** to slicing vs generic ones."?  How do you see

The question is whether the required attributes to characterize the connectivity part of a slice can be used beyond slicing or there are attributes that are "tied" to slicing. We need to call out these exclusive attributes, if any. This is important from a modelling standpoint.

> CPP/7297 relates to IETF network slices?

This depends on the answer to the previous question, but from the current draft, the connectivity component of an "IETF Network Slice" can be expressed as a CPP. 

Cheers,
Med

> -----Message d'origine-----
> De : Kiran Makhijani [mailto:[e-mail]]
> Envoyé : vendredi 23 octobre 2020 19:47
> À : BOUCADAIR Mohamed TGI/OLN <[e-mail]>; teas-
> [e-mail]; TEAS WG <[e-mail]>
> Objet : RE: New Version Notification for draft-nsdt-teas-ietf-
> network-slice-definition-00.txt
> 
> Hi Med,
> Many thanks for reviewing the updated text.
> 
> Let ask naïve questions on (1) Can you explain what's misleading?
> and " **specific** to slicing vs generic ones."?  How do you see
> CPP/7297 relates to IETF network slices?
> 
> On (2) and (3): Terminology document is motivated to establish
> minimal common understanding independently - upon which further work
> can progress, as well as previous efforts can relate to.
> 
> With that in mind, there are 2 ways to tie down RFC7297 -  we have
> applicability section in framework and appropriate text on how CPP
> applies can go there. Another option is to establish CPP
> relationship briefly with SLOs in section  4.1.1 to slices with a
> reference to 7297. In both cases we need your help to provide the
> right text.
> 
> But that's secondary. Lets first cover (1).
> -Kiran
> 
> 
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Thursday, October 22, 2020 4:41 AM
> > To: Kiran Makhijani <[e-mail]>; [e-mail];
> TEAS
> > WG <[e-mail]>
> > Subject: RE: New Version Notification for
> > draft-nsdt-teas-ietf-network-slice-
> > definition-00.txt
> >
> > Hi Kiran, all,
> >
> > Thank you for sharing this updated version.
> >
> > (1)
> >
> > It seems that the scope is still connectivity:
> >
> >    An IETF Network Slice is a well-defined structure of
> connectivity
> >    requirements and associated network behaviors.  IETF Network
> Slices
> >    are defined such that they are independent of the underlying
> >    infrastructure connectivity and technologies used.  This is to
> allow
> >    an IETF Network Slice consumer to describe their network
> connectivity
> >    and relevant objectives in a common format, independent of the
> >    underlying technologies used.
> >
> > Which is fine by me but the use of "network slice" is misleading.
> >
> > (2)
> >
> > I already made this comment during the call for adoption, but I
> don't
> > see it addressed in this version: It would be really cool if we
> can
> > identify attributes that are **specific** to slicing vs generic
> ones.
> > I'm particularly referring to the CPP defined in RFC7297:
> >
> > ====
> >    3.  Connectivity Provisioning Profile (CPP)
> >      3.1.  Customer Nodes Map
> >      3.2.  Scope
> >      3.3.  QoS Guarantees
> >      3.4.  Availability
> >      3.5.  Capacity
> >      3.6.  Conformance Traffic
> >      3.7.  Overall Traffic Guarantees
> >      3.8.  Traffic Isolation
> >      3.9.  Flow Identification
> >      3.10. Routing and Forwarding
> >      3.11. Activation Means
> >      3.12. Invocation Means
> >      3.13. Notifications
> > ====
> >
> > (3)
> >
> > Both clarifications are important to be worked out for the
> following reasons:
> > * If the "IETF Network slice" is more than connectivity, then its
> > connectivity component does not need to signal explicitly this is
> > about a "slice" because its presence in the "IETF Network slice"
> is sufficient to infer that.
> >
> > * If there are no connectivity-related attributes that are
> specific to
> > slicing, then we need to factorize and use a generic modelling for
> the
> > connectivity component. For example, an ABNF inspired from RFC7297
> would look like:
> >
> >    <NETWORK_SLICE> ::=
> >                  <Some_Non_Connectivity_Component> ...
> >                  <Connectivity Provisioning Component> ...
> >    <Connectivity Provisioning Component> ::=
> >                               <CONNECTIVITY_PROVISIONING_PROFILE>
> ...
> >    <CONNECTIVITY_PROVISIONING_PROFILE> ::=
> >                               <Customer Nodes Map>
> >                               <Scope>
> >                               <QoS Guarantees>
> >                               <Availability>
> >                               <Capacity>
> >                               <Traffic Isolation>
> >                               <Conformance Traffic>
> >                               <Flow Identification>
> >                               <Overall Traffic Guarantees>
> >                               <Routing and Forwarding>
> >                               <Activation Means>
> >                               <Invocation Means>
> >                               <Notifications>
> >                               <Optional Information Element> ...
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Teas [mailto:[e-mail]] De la part de Kiran
> > > Makhijani Envoyé : jeudi 22 octobre 2020 08:12 À :
> > > [e-mail]; TEAS WG <[e-mail]> Objet : [Teas] FW:
> New
> > > Version Notification for
> > > draft-nsdt-teas- ietf-network-slice-definition-00.txt
> > >
> > > Hello Teas and teas-ns-dt,
> > > FYI: Please find new version of  IETF network slices (previously
> > > called transport slices) definition document.
> > >
> > > This is still a work in progress document but several comments
> and
> > > feedback received till now have been addressed. We want to share
> > > updates so far and look forward to further comments and
> discussion.
> > >
> > > Thanks
> > > -Authors
> > >
> >


_________________________________________________________________________________________________________________________

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 messages that have been modified, changed or falsified.
Thank you.