Re: [Teas] New revision: draft-ietf-teas-ietf-network-slices-03.txt

["Ogaki, Kenichi" <[e-mail]>]

Hi Adrian and All,

As we touched on "[Teas] New Version Notification for draft-wd-teas-ietf-network-slice-nbi-yang-03.txt" thread, we believe a feasibility check functionality is required as one of IETF network slice operations, although PCE is described as one of mechanisms in "5.2.  Expressing Connectivity Intents". It's almost same as VN compute in actn-vn-yang. 

The feasibility check and reservation capabilities are required to avoid complicated rollback operation in instantiating/modifying an e2e(end-to-end) slice instance. Based on that, GSMA NGVT requested ETSI ZSM and NFV to add those steps in their specification, and they added in ZSM003 6.2.2.2, 6.3.2.2 and NFV IFA013 7.3.3. Although TEAS WG received the related liaison before, but the requirement is unclear.
https://www.ietf.org/proceedings/108/slides/slides-108-teas-administrivia-wg-status-02.pdf
Title: LS from GSMA NEST for mapping with slices of different domains via Cross-domain OAM coordination

We believe the exposure of those capabilities on IETF network slice would be beneficial for the consumers. The original requirement coming from 3GPP, TS 28.531 5.1.6, 5.1.21, is to secure multiple slice subnet instantiations forming an e2e slice without any failure and rollback operation as possible. Where a slice instance, e2e slice, is stitched/composed of multiple slice instances, which 3GPP calls as slice subnet, when an NSC of a slice subnet domain successfully instantiates the instance, but the other NSC of the different slice subnet domain may fail to instantiate the instance. At that time, all the slice subnet instances in multiple domains may have to be deleted. Also, the series of instantiation/deletion operations across multiple domains lets our customers wait long time for the result ending up failure.

The set of feasibility check and reservation is coming from ETSI ZSM discussion. If multiple consumers of an NSC exist and request multiple feasibility checks independent in a short period. The former feasibility check result may not be assured. So, the NSC once succeeds the feasibility check, then subsequently just reserves the resource without the instantiation.

All the best,
Kenichi



-----Original Message-----
From: Teas <[e-mail]> On Behalf Of [e-mail]
Sent: Wednesday, May 26, 2021 6:58 PM
To: [e-mail]; [e-mail]
Subject: Re: [Teas] New revision: draft-ietf-teas-ietf-network-slices-03.txt

Hi Adrian, 

Thank you for this updated version. 

Please find below two comments about Sections 3 and 4, fwiw. 

(1) It seems there is an internal inconsistency as we say in 3.1:

   An IETF Network Slice is a logical network topology connecting a
   number of endpoints using a set of shared or dedicated network
   resources that are used to satisfy specific Service Level Objectives
   (SLOs).

while we have in 4.1:
   An IETF Network Slice service is defined in terms of quantifiable
   characteristics known as Service Level Objectives (SLOs) and
   unquantifiable characteristics known as Service Level Expectations
   (SLEs).  SLOs are expressed in terms Service Level Indicators (SLIs),
   and together with the SLEs form the contractual agreement between
   service customer and service provider known as a Service Level
   Agreement (SLA).

I think this can be easily solved by removing the SLO/SLE taxonomy. 

Things would be much simpler if we just focus on service requirements without making an assumption how such requirement is expressed and whether it is quantified/quantitative/qualitative/measurable/etc. Whether/how a specific service requirement is covered by service assurance/fulfillment can be part of the slice service definition itself. 

Also, some of the items that are tagged as SLEs are questionable. I'm thinking about the encryption, for example. This can be verified at the provided-facing interfaces or at SF (if such resources are part of the slices). 

We are adding extra complexity for the modelling part as service requirements will need to be classified based as SLO or SLEs. If that classification won't drive the modelling, that's a reason to remove it. 

An "expectation" may not be easily assessed using current techniques (and thus be tagged as SLE), but this does not prevent that innovative means would be defined in the future (which means that it is an SLO, not an SLE anymore). For example, proof of transit mechanisms can be used to assess the nodes that were crossed and may fed any non-via constraint in the SLE/SLO. However, PoT have some implications on the underlay nodes.  More optimized means would be proposed in the future. 
 
What is really important for the customer to assess that the delivered slice service is aligned with the requested slice service. A specific "SLO" may be honored, but the overall delivered slice service isn't. 

(2) It seems that some clean-up is in needed in 4.1.1:

==
   SLOs define a set of network attributes and characteristics that
   describe an IETF Network Slice.  SLOs do not describe how the IETF
   Network Slices are implemented or realized in the underlying network
   layers.  Instead, they are defined in terms of dimensions of
   operation (time, capacity, etc.), availability, and other attributes.
   An IETF Network Slice can have one or more SLOs associated with it.
   The SLOs are combined in an SLA.  
==

vs. 

==
   SLOs define a set of measurable network attributes and
   characteristics that describe an IETF Network Slice service.  SLOs do
   not describe how the IETF network slices are implemented or realized
   in the underlying network layers.  Instead, they are defined in terms
   of dimensions of operation (time, capacity, etc.), availability, and
   other attributes.  An IETF Network Slice service can have one or more
   SLOs associated with it.  The SLOs are combined with Service Level
   Expectations in an SLA.
==

Cheers,
Med

> -----Message d'origine-----
> De : Teas [mailto:[e-mail]] De la part de Adrian Farrel 
> Envoyé : dimanche 23 mai 2021 23:25 À : [e-mail] Objet : [Teas] 
> New revision: draft-ietf-teas-ietf-network-slices-
> 03.txt
> 
> Hi WG,
> 
> This is a housekeeping revision.
> 
> - Picked up some editorial comments from Kenichi and Xiaobing.
> 
> - Moved the definition of 'customer' up to section 2.1 as requested by
>   several people
> 
> - Added a definition of 'provider' to section 2.1 per Oscar
> 
> - Fix (i.e., remove) use of "Network Slice User"
> 
> Cheers,
> Adrian
> 
> -----Original Message-----
> From: Teas <[e-mail]> On Behalf Of internet- 
> [e-mail]
> Sent: 23 May 2021 22:03
> To: [e-mail]
> Cc: [e-mail]
> Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-
> 03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Traffic Engineering Architecture and 
> Signaling WG of the IETF.
> 
>         Title           : Framework for IETF Network Slices
>         Authors         : Adrian Farrel
>                           Eric Gray
>                           John Drake
>                           Reza Rokui
>                           Shunsuke Homma
>                           Kiran Makhijani
>                           Luis M. Contreras
>                           Jeff Tantsura
> 	Filename        : draft-ietf-teas-ietf-network-slices-03.txt
> 	Pages           : 32
> 	Date            : 2021-05-23
> 
> Abstract:
>    This document describes network slicing in the context of networks
>    built from IETF technologies.  It defines the term "IETF Network
>    Slice" and establishes the general principles of network slicing in
>    the IETF context.
> 
>    The document discusses the general framework for requesting and
>    operating IETF Network Slices, the characteristics of an IETF 
> Network
>    Slice, the necessary system components and interfaces, and how
>    abstract requests can be mapped to more specific technologies.
> The
>    document also discusses related considerations with monitoring and
>    security.
> 
>    This document also provides definitions of related terms to enable
>    consistent usage in other IETF documents that describe or use 
> aspects
>    of IETF Network Slices.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-teas-ietf-network-slices/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-
> slices-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-
> slices-03
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas

_________________________________________________________________________________________________________________________

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.

_______________________________________________
Teas mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/teas