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

Kiran M <kiran.ietf@gmail.com> Thu, 22 July 2021 14:47 UTC

Return-Path: <kiran.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A19F3A48FE for <teas@ietfa.amsl.com>; Thu, 22 Jul 2021 07:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVhCi0YdDfu9 for <teas@ietfa.amsl.com>; Thu, 22 Jul 2021 07:47:34 -0700 (PDT)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6443A48EF for <teas@ietf.org>; Thu, 22 Jul 2021 07:47:34 -0700 (PDT)
Received: by mail-pl1-x631.google.com with SMTP id b12so4672306plh.10 for <teas@ietf.org>; Thu, 22 Jul 2021 07:47:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version:content-transfer-encoding; bh=0vQS05dLNv6g0wMxt7mfDkJjUTXAPPn/izVkIngGz0M=; b=o24KOWpyLCcRthu4Gj5k/Y4dsejl6rw/WJEP9L0P3UoV9kaZ6//HqfCfTmmbke3r95 SurjIYrLxlIYQFg4KKb5IOUvfIaaiSyyIA0xNw1cYpQPV48fDXRfODfutvR8UAyWsets GAVey3YWjr0dHTbj48+O5k54MPCr/DI7Pueb5IVf2lMWKNezuPkO8V2E8gy5OggjGHhh TgCJlg6i4wLri3a1VGWc16AZl7sL7aB1QfTrulx/4pfk6Fol15RK0LQBJi1F8HNco6ye 7xtJd3f/WyG2z3upKECReg1PfRssYnIMEQR7G7TFeHLVv1HySehfs3wcc8yzpCCVqEtC 95zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version :content-transfer-encoding; bh=0vQS05dLNv6g0wMxt7mfDkJjUTXAPPn/izVkIngGz0M=; b=Qogj0YXbNbRCuc053fuII4d7cyIM5dovaDNZOPYqAN8H9TABG7of27aLDIFAFAX/F4 W7jTJszZYQIBOSsck3RIUFf7nuIeaTKGrwnHq0FmIUXZG55N/j8fTWdxC9ERlTp6anE9 r469FuNG+LCfnXPRPDxEaDp+0gPccP/yqwnhrJ6jb6xfw7hDjYDQz4Kskop2/5GTO15B +br8TfuxADpsFWt+c6oqf5e5JbxAihzmxMTlnWmBVZkAadwOz2IHY6Fg3PrzW5ytlSiH Lu9bnjQqT/cvW93dN4XJThYDhpX9vtNGajNm58TR3tfcm/bUaVEmPiJ6VMLN5jZicvhH SaCA==
X-Gm-Message-State: AOAM533rK6iddu3JdwqdxM1fCJLwH0VL43y8gz40GTbac8IbSDBNgoQj ulgi2FczpF9bfXjp6AxTnVM=
X-Google-Smtp-Source: ABdhPJwtS8n2p4KcFNb7QluqRVGypH7P5SjGwSe7tJUSIfhQdqu5sLMFjVcOhN0oZhHxWQSKNmaBTg==
X-Received: by 2002:a63:3d1:: with SMTP id 200mr374759pgd.26.1626965253872; Thu, 22 Jul 2021 07:47:33 -0700 (PDT)
Received: from [192.168.1.4] (c-73-202-182-183.hsd1.ca.comcast.net. [73.202.182.183]) by smtp.gmail.com with ESMTPSA id e16sm20105174pja.14.2021.07.22.07.47.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jul 2021 07:47:33 -0700 (PDT)
From: "Kiran M" <kiran.ietf@gmail.com>
To: mohamed.boucadair@orange.com, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Date: Thu, 22 Jul 2021 14:47:32 +0000
Message-Id: <em5b403581-4d56-4fc0-acc1-2a97dc33efdd@tromso.local>
In-Reply-To: <16404_1622023054_60AE1B8E_16404_76_7_787AE7BB302AE849A7480A190F8B93303538F308@opexcaubma2.corporate.adroot.infra.ftgroup>
References: <009201d7501a$233de670$69b9b350$@olddog.co.uk> <16404_1622023054_60AE1B8E_16404_76_7_787AE7BB302AE849A7480A190F8B93303538F308@opexcaubma2.corporate.adroot.infra.ftgroup>
Reply-To: "Kiran M" <kiran.ietf@gmail.com>
User-Agent: eM_Client/8.2.1478.0
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/V5_k4i6G0m--CDj0_8BPTESGmWg>
Subject: Re: [Teas] New revision: draft-ietf-teas-ietf-network-slices-03.txt
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Jul 2021 14:47:48 -0000

Hi Med,
On SLO/SLE: in my opinion, for the sake of completeness in the document, 
the text adds value to acknowledge cases where it will not be possible 
to verify service guarantees by matching requested to measured values.
However, it should not imply that NBI models are required to have 
SLE/SLO indicators and I totally agreed with your comments on 
draft-wd-teas-ietf-network-slice-nbi-yang-03. In fact, I am wondering if 
verification of service (called monitoring in NBI)should be part of NBI 
model or separate.

-Kiran

On 5/26/2021 2:57:34 AM, mohamed.boucadair@orange.com wrote:

>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:teas-bounces@ietf.org] De la part de Adrian Farrel
>>  Envoyé : dimanche 23 mai 2021 23:25
>>  À : teas@ietf.org
>>  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 <teas-bounces@ietf.org> On Behalf Of internet-
>>drafts@ietf.org
>>  Sent: 23 May 2021 22:03
>>  To: i-d-announce@ietf.org
>>  Cc: teas@ietf.org
>>  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
>>Teas@ietf.org
>>https://www.ietf.org/mailman/listinfo/teas
>>
>>  _______________________________________________
>>  Teas mailing list
>>Teas@ietf.org
>>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
>Teas@ietf.org
>https://www.ietf.org/mailman/listinfo/teas