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

mohamed.boucadair@orange.com Thu, 29 October 2020 09:38 UTC

Return-Path: <mohamed.boucadair@orange.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 2CD203A03F1; Thu, 29 Oct 2020 02:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=orange.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 oLEY0qKTA2nK; Thu, 29 Oct 2020 02:38:36 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2E63A0BE4; Thu, 29 Oct 2020 02:38:36 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4CML3Z6Q4Zz8t52; Thu, 29 Oct 2020 10:38:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1603964314; bh=+5Q4o2nXOm/ijy+UwgEufZ73DzF/jhLG6V1oaE8tSKM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=w/qHl+DHItI3Kwcr7vcxXnqfnUoKYoXzELIOQ1FU2mSvPhvxFrvxjodg0tGInRYCQ kpw5UQ7n8PIp+zrDsqFD26l2ZEZ5c5xs1l3L1MWVE/JEhtPO78UHKotd7ODvZVGnDP /neVlNsIT5YXuIjUrA/9rlz+H5qQ8hFQdcg8RxhWcD3+DW9Y9RRJje4SjAOfjw+pG4 gvgGOtbGYvXzlBfCA9FuBl2rfMOF2KiH0N8DMaGw3mT+bAODWiUUkxLOWKbYfgBW3L yBAq2yBLCnCU3jSUkjm0MAjPkS31/bhVyQOVAsqfwaXZGbDKIusQvsOV8r1l01aBIM OOvlZE2WRbV4g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.98]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 4CML3Z516Xz1xp5; Thu, 29 Oct 2020 10:38:34 +0100 (CET)
From: <mohamed.boucadair@orange.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Kiran Makhijani' <kiranm@futurewei.com>, "teas-ns-dt@ietf.org" <teas-ns-dt@ietf.org>, "'TEAS WG'" <teas@ietf.org>
Thread-Topic: [Teas-ns-dt] New Version Notification for draft-nsdt-teas-ietf-network-slice-definition-00.txt
Thread-Index: AQHgC41I55FYvxoDOgxM9N1MOiaQcQJLYPYuAzYPg90BdsE+0wJTz3ogAj3HmwCpPhxkAIABKkkw
Date: Thu, 29 Oct 2020 09:38:33 +0000
Message-ID: <25938_1603964314_5F9A8D9A_25938_25_1_787AE7BB302AE849A7480A190F8B933031568FE8@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <160334637666.17176.15293064565481905957@ietfa.amsl.com> <BYAPR13MB2437223D535F2ACC294A8FEAD91D0@BYAPR13MB2437.namprd13.prod.outlook.com> <4718_1603366886_5F916FE6_4718_480_1_787AE7BB302AE849A7480A190F8B933031564F1F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR13MB24378C3EFA84B04EBE80D41DD91A0@BYAPR13MB2437.namprd13.prod.outlook.com> <27534_1603704442_5F96967A_27534_444_1_787AE7BB302AE849A7480A190F8B93303156688B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <BYAPR13MB24375163CE6ACE3FD9FE8B3AD9170@BYAPR13MB2437.namprd13.prod.outlook.com> <062d01d6ad46$3e868e90$bb93abb0$@olddog.co.uk>
In-Reply-To: <062d01d6ad46$3e868e90$bb93abb0$@olddog.co.uk>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/uTNxF65Mmupp66BI8gM0PjI47Yg>
Subject: Re: [Teas] [Teas-ns-dt] New Version Notification for draft-nsdt-teas-ietf-network-slice-definition-00.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, 29 Oct 2020 09:38:39 -0000

Hi Adrian, 

You got it well. Especially, 

> Maybe we have two concepts:
> - IETF network slicing
> - IETF connectivity network slicing

Kiran, I fully agree with you that "Terminology document should be very clear". This is why I do think that explicitly pointing to the concept we are looking at will help us progress.

Thanks. 

Cheers,
Med

> -----Message d'origine-----
> De : Adrian Farrel [mailto:adrian@olddog.co.uk]
> Envoyé : mercredi 28 octobre 2020 17:20
> À : 'Kiran Makhijani' <kiranm@futurewei.com>om>; BOUCADAIR Mohamed
> TGI/OLN <mohamed.boucadair@orange.com>om>; teas-ns-dt@ietf.org; 'TEAS
> WG' <teas@ietf.org>
> Objet : RE: [Teas-ns-dt] New Version Notification for draft-nsdt-
> teas-ietf-network-slice-definition-00.txt
> 
> I hope this debate is not dancing on the head of a pin, but it does
> seem to be quite fundamental to what we are trying to achieve.
> 
> On the one hand, a network contains many "resources" such as
> storage, compute, virtual functions, and access to content. If the
> process of slicing is to 'share out' the network resources by
> building "virtual networks," then those virtual networks surely need
> to include all the sorts of things that a physical network includes.
> 
> On the other hand, the primary need is clearly connectivity. Without
> connectivity we have nothing.
> 
> Maybe we have two concepts:
> - IETF network slicing
> - IETF connectivity network slicing
> 
> The second of these is a subset of the first.
> The second is what Kiran is seeking to discuss in this draft (I
> think, reading her emails and having talked with her).
> The first is, I think, what Med is talking about.
> 
> Notwithstanding, all of this, Kiran's approach is the right one for
> this draft at the moment. That is, fix the most inflammatory issues
> first; pick up a pile of nits along the way; reduce the text to only
> that which is necessary (work in progress); and then come up with
> something we can debate a bit more clearly.
> 
> Cheers,
> Adrian
> 
> -----Original Message-----
> From: Teas-ns-dt <teas-ns-dt-bounces@ietf.org> On Behalf Of Kiran
> Makhijani
> Sent: 28 October 2020 15:33
> To: mohamed.boucadair@orange.com; teas-ns-dt@ietf.org; TEAS WG
> <teas@ietf.org>
> Subject: Re: [Teas-ns-dt] New Version Notification for draft-nsdt-
> teas-ietf-network-slice-definition-00.txt
> 
> Hi Med,
> Well! while working on this major revision authors did not feel that
> primary scope need to be adjusted. Although a lot of re-write has
> happened.
> Deflating the tension with naming and addressing major comments
> were the first steps.
> 
> Our proposed definition has 2 parts, first one is connectivity
> (because we concern with network specific characteristics) and
> second is meeting service specific requirements, which allows
> consumer to specify its application/service needs. One could extend
> those objectives if they can be well-described through NBI and are
> feasible in the realized network.
> 
> I still do not know what is that "something else" you are alluding
> to?
> Terminology document should be very clear so it will be good to know
> what other things you have in mind that have been overlooked.
> 
> You are also asking whether required attributes to characterize an
> IETF network slice can be used beyond slicing. Without clearly
> knowing what you want, I see them being usable in the context of
> end-to-end slice (last section before security) which is broader
> than the IETF network slice.
> 
> Thanks
> Kiran
> 
> 
> > -----Original Message-----
> > From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com>
> > Sent: Monday, October 26, 2020 2:27 AM
> > To: Kiran Makhijani <kiranm@futurewei.com>om>; teas-ns-dt@ietf.org;
> TEAS
> > WG <teas@ietf.org>
> > Subject: RE: New Version Notification for
> draft-nsdt-teas-ietf-network-slice-
> > definition-00.txt
> >
> > 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:kiranm@futurewei.com] Envoyé :
> vendredi
> > > 23 octobre 2020 19:47 À : BOUCADAIR Mohamed TGI/OLN
> > > <mohamed.boucadair@orange.com>om>; teas- ns-dt@ietf.org; TEAS WG
> > > <teas@ietf.org> 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: mohamed.boucadair@orange.com
> > <mohamed.boucadair@orange.com>
> > > > Sent: Thursday, October 22, 2020 4:41 AM
> > > > To: Kiran Makhijani <kiranm@futurewei.com>om>; teas-ns-
> dt@ietf.org;
> > > TEAS
> > > > WG <teas@ietf.org>
> > > > 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:teas-bounces@ietf.org] De la part de Kiran
> > > > > Makhijani Envoyé : jeudi 22 octobre 2020 08:12 À :
> > > > > teas-ns-dt@ietf.org; TEAS WG <teas@ietf.org> 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.
> 
> --
> Teas-ns-dt mailing list
> Teas-ns-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/teas-ns-dt


_________________________________________________________________________________________________________________________

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.