Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

["Joel M. Halpern" <[e-mail]>]

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=[e-mail]> 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 <[e-mail]> *On Behalf Of * Igor Bryskin
> *Sent:* Thursday, May 6, 2021 10:26 AM
> *To:* Loa Andersson <[e-mail]>; [e-mail]; 
> [e-mail]; [e-mail]; Oscar González de Dios 
> <[e-mail]>
> *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 
> <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> En 
> nombre de Loa Andersson
> Enviado el: jueves, 6 de mayo de 2021 9:31
> Para: [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>; 
> [e-mail] <mailto:[e-mail]>
> 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: [e-mail] <mailto:[e-mail]> 
> <[e-mail] <mailto:[e-mail]>>
>> Sent: 05 May 2021 11:58
>> To: [e-mail] <mailto:[e-mail]>; 'Loa Andersson' 
> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> 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:[e-mail] <mailto:[e-mail]>] De la part de 
> Adrian Farrel
>>> Envoyé : mercredi 5 mai 2021 11:59 À : 'Loa Andersson' <[e-mail] <mailto:[e-mail]>>;
>>> [e-mail] <mailto:[e-mail]> 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
>>> [e-mail] <mailto:[e-mail]>
>>> 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
>> [e-mail] <mailto:[e-mail]>
>> 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: [e-mail] <mailto:[e-mail]>
> Senior MPLS Expert [e-mail] <mailto:[e-mail]>
> Bronze Dragon Consulting            phone: [phone]
> 
> _______________________________________________
> Teas mailing list
> [e-mail] <mailto:[e-mail]>
> 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
> [e-mail] <mailto:[e-mail]>
> 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
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>