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, 6 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>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
>