Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 06 May 2021 17:28 UTC
Return-Path: <jmh@joelhalpern.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 48DEF3A29FD for <teas@ietfa.amsl.com>; Thu, 6 May 2021 10:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
X-Spam-Status: No, score=-2.121 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 iEU80UJmgruP for <teas@ietfa.amsl.com>; Thu, 6 May 2021 10:28:17 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7586F3A29FC for <teas@ietf.org>; Thu, 6 May 2021 10:28:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4FbgXJ6ypPz1nsn6; Thu, 6 May 2021 10:28:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1620322096; bh=84+OgYKQvAtdKsisH4asE4Fp768FbAtz1eLzTIe+pPQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=bBjwyNc4laqoRVotSXCmhr3neG2HKXBxbcgTZaC7pcHYRAlpYMfntfvPIfNsiR/HG jv1wd2lq9gT3Wr19Aou9Kt7zn3TLeALc8MLcx2D03nmxqDSLOjmCzrfJJodsvVVPia w3gUS63YO4i/TCpoGB6zynEy1KbYKMrbTVjPE4rQ=
X-Quarantine-ID: <5DaSr7JIJlJ9>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4FbgXJ2m3jz1nsYJ; Thu, 6 May 2021 10:28:16 -0700 (PDT)
To: Igor Bryskin <i_bryskin=40yahoo.com@dmarc.ietf.org>, "teas@ietf.org" <teas@ietf.org>
References: <037401d740c5$70a9cc30$51fd6490$@olddog.co.uk> <3ea262cf-e4c0-5ec0-9736-aedaf6d5d4d8@pi.nu> <009401d74195$41fd70a0$c5f851e0$@olddog.co.uk> <9933_1620212302_60927A4E_9933_344_1_787AE7BB302AE849A7480A190F8B933035376DFA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <00a001d7419e$99e5a040$cdb0e0c0$@olddog.co.uk> <03cf404d-59a7-0ec5-e18f-0a98bf638c0f@pi.nu> <PAXPR06MB7872B2DEF299B15988966A9DFD589@PAXPR06MB7872.eurprd06.prod.outlook.com> <914297092.1179550.1620311146249@mail.yahoo.com> <BY3PR05MB80815F1DD23D443E17009E5DC7589@BY3PR05MB8081.namprd05.prod.outlook.com> <919542370.1252604.1620319117290@mail.yahoo.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <f8cf25fc-1436-055f-a4c0-a36a95e42c7b@joelhalpern.com>
Date: Thu, 06 May 2021 13:28:15 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <919542370.1252604.1620319117290@mail.yahoo.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/gtMTwu_2OJkqekhxAGAuxpOHPZc>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
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, 06 May 2021 17:28:22 -0000
As far as I can tell, the client should not be trying to control the details of which instance is used to fill the service function requirements. i Constraints like "stay out of a certain country", or "stay within a given country" would be expressed in terms of the properties the slice is to meet (service level expectations). Not by controlling particular aspects of the service. Yours, Joel On 5/6/2021 12:38 PM, Igor Bryskin wrote: > Thanks John, > > But wouldn't the client want to constrain the connectivity for a given > link in the specified SFC, say, to be more stringent than end-to-end > (perhaps by a separate set of SLOs)? > > Also, could the client have a say on location of SFs? For example, can > it instruct to avoid a country or DC? > > Igor > > On Thursday, May 6, 2021, 11:48:22 AM EDT, John E Drake > <jdrake=40juniper.net@dmarc.ietf.org> wrote: > > > Igor, > > Given the IETF Network Slice Service definition that Eric and I > proposed, I think we could add an SFC definition to the SLO definition > for each sender to a given connectivity construct. It would indicate > that a packet from that sender to each receiver would pass through the > specified SFC before being received. This is consistent with what is > described in: > https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-18 > <https://datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-18>. > > Yours Irrespectively, > > John > > Juniper Business Use Only > > *From:* Teas <teas-bounces@ietf.org> *On Behalf Of * Igor Bryskin > *Sent:* Thursday, May 6, 2021 10:26 AM > *To:* Loa Andersson <loa@pi.nu>; adrian@olddog.co.uk; > mohamed.boucadair@orange.com; teas@ietf.org; Oscar González de Dios > <oscar.gonzalezdedios@telefonica.com> > *Subject:* Re: [Teas] Moving forward with > draft-ietf-teas-ietf-network-slices > > *[External Email. Be cautious of content]* > > Hi Adrian, > > I probably missed the discussion, but how do we reconcile two IETF > stories - network slicing and SFCs? Surely, at some point a network > slice client will ask the provider not just only to deliver its traffic > from A to B with delay no worse than D, but also to do something else > with the data (e.g. DPI). On the other hand, when we talk about SFCs we > cannot assume I think any longer the context of a physical (not sliced) > network. I do not suppose we can simply mandate the SF placement at > network slice end points or somewhere outside network slices - this > approach would probably not scale well. > > So, the question is how SFs relate to network slices, in particular, to > their SLAs, SLOs and topologies? > > Thanks, > > Igor > > On Thursday, May 6, 2021, 07:53:32 AM EDT, Oscar González de Dios > <oscar.gonzalezdedios@telefonica.com > <mailto:oscar.gonzalezdedios@telefonica.com>> wrote: > > Hi Adrian, > > I think what is really relevant is to have a clear definition > on the chosen term to avoid misunderstandings. Unfortunately today > customer/consumer/client are used also in other contexts that might > bring extra implications. > > Said that, I am fine with the term customer. There are still > a couple of places in the document where the term "service customer" is > used. Please change those to "IETF Network Slice customer" to be coherent. > > One argument in favor of the term customer is that the "IETF > Network slice customer" makes use of the slice to fulfill its needs (can > be carry the traffic from a to b with a set of SLOs) and manage the > granted slice (that is, it can rearrange the resources it is allowed > to). The term consumer misses the management part, which is a key > differentiator of a slice. > > In the definition of customer, Can we just say: " A customer > may manage the granted IETF Network Slice. > > Also, I'd like to clarify between the management of the IETF > Network slice that the customer can do and the management the provider > can do. The customer can "play" within the allocated resources, but may > have some limitations. One question, the ability to manage the slice, is > part of an SLO? Or should be defined separately with a different term? > It would be interesting to have the possibility to indicate what the > slice customer can manage and what not... > > I support moving earlier in the document the definition of the > IETF Network Slice Customer and, also, add a definition for the IETF > Network Slice Provider (although only "provider" is used thought the text). > > Best Regards, > > Oscar > > > -----Mensaje original----- > De: Teas <teas-bounces@ietf.org <mailto:teas-bounces@ietf.org>> En > nombre de Loa Andersson > Enviado el: jueves, 6 de mayo de 2021 9:31 > Para: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; > mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>; > teas@ietf.org <mailto:teas@ietf.org> > Asunto: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices > > Adrian, > > That is acceptable. > > As you said it is late in the document, and really not in a definitions > section. I don't know if we can we place something in Section "2. Terms > and Abbreviations", but there seems to be only abbreviations. > > Your wholesale example: > > I think you forget about wholesale. What do you call the school that > buys food at the shop to provide to the children? Do you call the school > the customer, or do you refer to the cook who buys the food as the > customer? The contract is with the school, negotiated by the cook, > signed by the bursar. > > I think "the school! is the customer, which is OK in this context. The > cook and the school kids could be viewed as consumers", one removed from > the system. > > It strikes me that "Customer System" and "IETF Slice" are somewhat > similar, the risk is that we talk about "customer" (even if we change > it), and "slice" (even though if is really "IETF Slice)", > > Having said that, though it is not my task to call consensus, I think we > have a enough support to use "customer". > > I rest my case. > > /Loa > > > On 05/05/2021 13:05, Adrian Farrel wrote: >> We currently have (in section 5.1, which may be a bit late in the >> document) >> >> Customer: A customer is the requester of an IETF Network Slice. >> Customers may request monitoring of SLOs. A customer may manage >> the IETF Network Slice service directly by interfacing with the >> IETF NSC or indirectly through an orchestrator. >> >> We could add "A customer may be an entity such as an enterprise >> network or a network operator, an individual working at such an >> entity, a private individual contracting for a service, or an >> application or software component." >> >> Cheers, >> Adrian >> >> -----Original Message----- >> From: mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com> > <mohamed.boucadair@orange.com <mailto:mohamed.boucadair@orange.com>> >> Sent: 05 May 2021 11:58 >> To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk>; 'Loa Andersson' > <loa@pi.nu <mailto:loa@pi.nu>>; teas@ietf.org <mailto:teas@ietf.org> >> Subject: RE: [Teas] Moving forward with >> draft-ietf-teas-ietf-network-slices >> >> Hi all, >> >>> Anyone else got anything to say on the topic? >> >> I would simply use "customer" and make sure the definition is generic >> enough to denote a role/entity. >> >> Thanks. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : Teas [mailto:teas-bounces@ietf.org <mailto:teas-bounces@ietf.org>] De la part de > Adrian Farrel >>> Envoyé : mercredi 5 mai 2021 11:59 À : 'Loa Andersson' <loa@pi.nu <mailto:loa@pi.nu>>; >>> teas@ietf.org <mailto:teas@ietf.org> Objet : Re: [Teas] Moving forward with >>> draft-ietf-teas-ietf-network- slices >>> >>> Hi Loa, >>> >>>> On customer vs. consumer Adrian says: >>>> >>>>> c. "Consumer" vs "customer". I have made this consistent (we >>> only need to >>>>> use one term). I selected "Customer" because that seemed >>> best, but I >>>>> know some people prefer "consumer". Please discuss if you >>> are not >>>>> happy. >>>> >>>> If the choice is between customer vs. consumer, I prefer customer. >>> >>> OK. So I made an improvement, but... >>> >>>> I don't know if it is too late to bring this up. >>> >>> It's never too late to bring things up. >>> >>>> But I really don't like either, normal language has a strong >>>> indication that that that a customer is a person (a person that >>> walks >>>> inte to your >>>> shop) and consumer is also a person /that eats what I bought at >>> your shop). >>> >>> I think you forget about wholesale. What do you call the school that >>> buys food at the shop to provide to the children? Do you call the >>> school the customer, or do you refer to the cook who buys the food as >>> the customer? The contract is with the school, negotiated by the >>> cook, signed by the bursar. >>> >>>> IETF specifies "systems", including what goes into SW and HW, but >>> we >>>> don't specify normative rules for human behavior. >>>> >>>> I don't know if we can talk about Customer System? >>> >>> I'm afraid of this getting heavy for the reader. There are 73 >>> instances of "customer" in the document, and "customer system" may >>> become tiresome to read. >>> >>> Anyone else got anything to say on the topic? >>> >>> Cheers, >>> Adrian >>> >>> _______________________________________________ >>> Teas mailing list >>> Teas@ietf.org <mailto:Teas@ietf.org> >>> https://www.ietf.org/mailman/listinfo/teas > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!X_3my20D0a0-O-3AGBF9WTsXoLaXi_9rJT8003XW0WCdkSUuAV5G3D-29TXGHao$> >> >> ______________________________________________________________________ >> ______ _____________________________________________ >> >> 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 <mailto:Teas@ietf.org> >> https://www.ietf.org/mailman/listinfo/teas > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!X_3my20D0a0-O-3AGBF9WTsXoLaXi_9rJT8003XW0WCdkSUuAV5G3D-29TXGHao$> >> > > -- > > Loa Andersson email: loa@pi.nu <mailto:loa@pi.nu> > Senior MPLS Expert loa.pi.nu@gmail.com <mailto:loa.pi.nu@gmail.com> > Bronze Dragon Consulting phone: +46 739 81 21 64 > > _______________________________________________ > Teas mailing list > Teas@ietf.org <mailto:Teas@ietf.org> > https://www.ietf.org/mailman/listinfo/teas > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!X_3my20D0a0-O-3AGBF9WTsXoLaXi_9rJT8003XW0WCdkSUuAV5G3D-29TXGHao$> > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener información privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilización, > divulgación y/o copia sin autorización puede estar prohibida en virtud > de la legislación vigente. Si ha recibido este mensaje por error, le > rogamos que nos lo comunique inmediatamente por esta misma vía y proceda > a su destrucción. > > The information contained in this transmission is privileged and > confidential information intended only for the use of the individual or > entity named above. If the reader of this message is not the intended > recipient, you are hereby notified that any dissemination, distribution > or copying of this communication is strictly prohibited. If you have > received this transmission in error, do not read it. Please immediately > reply to the sender that you have received this communication in error > and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinatário, pode conter informação privilegiada ou confidencial e é > para uso exclusivo da pessoa ou entidade de destino. Se não é vossa > senhoria o destinatário indicado, fica notificado de que a leitura, > utilização, divulgação e/ou cópia sem autorização pode estar proibida em > virtude da legislação vigente. Se recebeu esta mensagem por erro, > rogamos-lhe que nos o comunique imediatamente por esta mesma via e > proceda a sua destruição > > > _______________________________________________ > Teas mailing list > Teas@ietf.org <mailto:Teas@ietf.org> > https://www.ietf.org/mailman/listinfo/teas > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!X_3my20D0a0-O-3AGBF9WTsXoLaXi_9rJT8003XW0WCdkSUuAV5G3D-29TXGHao$> > > _______________________________________________ > Teas mailing list > Teas@ietf.org <mailto:Teas@ietf.org> > https://www.ietf.org/mailman/listinfo/teas > <https://www.ietf.org/mailman/listinfo/teas> > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas >
- [Teas] Moving forward with draft-ietf-teas-ietf-n… Adrian Farrel
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Loa Andersson
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Adrian Farrel
- Re: [Teas] Moving forward with draft-ietf-teas-ie… mohamed.boucadair
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Adrian Farrel
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Rokui, Reza (Nokia - CA/Ottawa)
- Re: [Teas] Moving forward with draft-ietf-teas-ie… mohamed.boucadair
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Adrian Farrel
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Shunsuke Homma
- Re: [Teas] Moving forward with draft-ietf-teas-ie… John E Drake
- Re: [Teas] Moving forward with draft-ietf-teas-ie… John E Drake
- Re: [Teas] Moving forward with draft-ietf-teas-ie… peng.shaofu
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Dongjie (Jimmy)
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Jeff Tantsura
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Loa Andersson
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Oscar González de Dios
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Igor Bryskin
- Re: [Teas] Moving forward with draft-ietf-teas-ie… John E Drake
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Igor Bryskin
- Re: [Teas] Moving forward with draft-ietf-teas-ie… John E Drake
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Joel M. Halpern
- Re: [Teas] Moving forward with draft-ietf-teas-ie… niu.xiaobing
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Shunsuke Homma
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Igor Bryskin
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Joel M. Halpern
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Igor Bryskin
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Joel Halpern Direct
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Tarek Saad
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Greg Mirsky
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Gyan Mishra
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Ogaki, Kenichi
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Xufeng Liu
- Re: [Teas] Moving forward with draft-ietf-teas-ie… mohamed.boucadair
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Shunsuke Homma
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Adrian Farrel
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Adrian Farrel
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Adrian Farrel
- Re: [Teas] Moving forward with draft-ietf-teas-ie… Adrian Farrel