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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 4 May 2021 10:11:16 +0100

Several important points:

1. This is work in progress and you are all allowed to comment on any of the
text. Changes made here are based on text floated on the list and comments
received, but this is NOT confirmed consensus and is still open for
modification.

2. You can see the changes this time around at
https://www.ietf.org/rfcdiff?url1=draft-ietf-teas-ietf-network-slices-01&url
2=draft-ietf-teas-ietf-network-slices-02&difftype=--hwdiff
   a. Eric has retired, but is still following the work
   b. No longer need the Editor's Note in Section 1
   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.
   d. Changes for Isolation text and introduction of "SLE" for
"unquantifiable objectives"
        as proposed on the list, with edits for the comments received
   e. Changes for realisation of network slices as proposed on list, with
edits for the
       comments received.
   f. Various small editorials
   g. Fix ordering of end-matter sections
   h. Remove "Unused Material" Appendix (as it was unused :-)

3. Next work topics (in no particular order)
   a. Definition of a Network Slice Service (based on a discussion started
on the list by John Drake)
   b. Definition of End Points (ditto)
   c. Resolve "duplication" between Figure 1 and Figure 3 as well as
surrounding text
   d. Propose a functional architecture for realising network slices

4. I think that at least 3d will need a meeting. If 3a or 3b gets a
significant level of
    discussion on the list then it should also have a meeting. I will try to
give a week's
    notice for any meeting and pick a time that works for California and
Beijing. But,
    please note that you don't have to come to a meeting to have an opinion
- that is
    what the mailing list is for.

Best,
Adrian

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: 04 May 2021 09:56
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-02.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-02.txt
	Pages           : 32
	Date            : 2021-05-04

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 are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-teas-ietf-network-slices-02
https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-teas-ietf-network-slices-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Teas mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/teas

---

From: Loa Andersson <[email-masked]>
Date: Wed, 5 May 2021 10:48:11 +0200

Adrian, WG,

On customer vs. consumer Adrian says:

>          prefer "consumer". Please discuss if you are not happy.

If the choice is between customer vs. consumer, I prefer customer.

I don't know if it is too late to bring this 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 eatss what i bought at your shop).

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?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 May 2021 10:58:53 +0100

Hi Loa,

>>        use one term). I selected "Customer" because that seemed best, but I 
>>        know some people prefer "consumer". Please discuss if you are not
>>        happy.
>

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.

> 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.

> 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

---

From: <[email-masked]>
Date: Wed, 5 May 2021 10:58:21 +0000

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:[email-masked]] De la part de Adrian Farrel
> Envoyé : mercredi 5 mai 2021 11:59
> À : 'Loa Andersson' <[email-masked]>; [email-masked]
> Objet : Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-
> slices
> 
> Hi Loa,
> 
> > 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
> 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'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.
> 

_________________________________________________________________________________________________________________________

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 May 2021 12:05:46 +0100

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: [email-masked] <[email-masked]> 
Sent: 05 May 2021 11:58
To: [email-masked]; 'Loa Andersson' <[email-masked]>; [email-masked]
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

> Anyone else got anything to say on the topic?

____________________________________________________________________________
_____________________________________________

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.

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Wed, 5 May 2021 11:12:59 +0000

Hi Adrian,

I am fine with the definition of “Customer” provided below. 

Reza

> On May 5, 2021, at 7:06 AM, Adrian Farrel <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Wed, 5 May 2021 11:14:33 +0000

Re-,

Works for me. Thanks. 

I have one comment, though: s/IETF Network Slice/IETF Network Slice Service.

Cheers,
Med

> De : Adrian Farrel [mailto:[email-masked]]
> Envoyé : mercredi 5 mai 2021 13:06
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>; 'Loa
> Andersson' <[email-masked]>; [email-masked]
> Objet : RE: [Teas] Moving forward with draft-ietf-teas-ietf-network-
> slices
> 
> 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
> 
> > Envoyé : mercredi 5 mai 2021 11:59 À : 'Loa Andersson' <[email-masked]>;
> > [email-masked] Objet : Re: [Teas] Moving forward with
> > draft-ietf-teas-ietf-network- slices
> >
> > Hi Loa,
> >
> 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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 May 2021 12:47:52 +0100

Ack

---

From: "Belotti, Sergio (Nokia - IT/Vimercate)" <[email-masked]>
Date: Wed, 5 May 2021 12:17:47 +0000

Hi Adrian,
+1

Thanks
Sergio

> From: Teas <[email-masked]> On Behalf Of Rokui, Reza (Nokia -
> CA/Ottawa)
> Sent: Wednesday, May 5, 2021 1:13 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Loa Andersson
> <[email-masked]>
> Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices
> 
> Hi Adrian,
> 
> ________________________________________________________________
> ______
> > ______ _____________________________________________
> >

---

From: Shunsuke Homma <[email-masked]>
Date: Wed, 5 May 2021 22:23:02 +0900

Hi,

Sorry for cutting in...

I’m not a native English speaker and I’m not sure if my understanding on
the words is correct, but I think “consumer” would be more appropriate,
because I feel that “consumer” implies people rend a slice from a slice
provider with “paying fee”. (On the other hand, in my understanding,
“consumer” means a user of a service and it is independent of whether
he/she pays fee or not.)

As you know, network slice concept generally allows hierarchical structure
(of course, the current IETF network slice definition allows it). For
example, an IETF network slice may be used to provide connectivity (and
some functionalities) to other slices, such as 5G slices, which are under
the same provider, for creating an E2E slice. In such case, can other
slices or a higher orchestrator coordinating these slices be called
“customer”? (In this case, there would not be any payments.)

I’m sorry if my understanding on “customer” is incorrect and it can be
applied to such cases.

Regards,

Shunsuke

---

From: John E Drake <[email-masked]>
Date: Wed, 5 May 2021 13:46:23 +0000

Customer is a standard IETF term

Yours Irrespectively,

John

Juniper Business Use Only

> From: Teas <[email-masked]> On Behalf Of Adrian Farrel
> Sent: Wednesday, May 5, 2021 5:59 AM
> To: 'Loa Andersson' <[email-masked]>; [email-masked]
> [External Email. Be cautious of content]
> 
> 
> Hi Loa,
> 
> > indication that that that a customer is a person (a person that walks
> > inte to your
> 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'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.
> 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-
> gk!SK7Qcl0ydZ1sAg7KdxLhZRtYc8GrgEj15xn3VPtMhJmMrBf_WoYQQNiYEgurmG
> E$

---

From: John E Drake <[email-masked]>
Date: Wed, 5 May 2021 13:49:41 +0000

Hi,

Comment inline

Yours Irrespectively,

John

> Sent: Wednesday, May 5, 2021 7:06 AM
> To: [email-masked]; 'Loa Andersson' <[email-masked]>;
> [email-masked]
> network operator, an individual working at such an entity, a private individual
> contracting for a service, or an application or software component."

[JD]  Gilding the lily 

> > the customer? The contract is with the school, negotiated by the cook,
> > signed by the bursar.
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!W_DnXhZ2tbxnRkBApq_DRzmQ0Ly6IR0J0-
> FHQYZ3xvHJ9jsYVvotI
> > 86LGMNRzE4$
> 
> 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.
> 
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.
> Et6yMaO-gk!W_DnXhZ2tbxnRkBApq_DRzmQ0Ly6IR0J0-
> FHQYZ3xvHJ9jsYVvotI86LGMNRzE4$

---

From: <[email-masked]>
Date: Thu, 6 May 2021 10:09:25 +0800 (CST)

Hi Adrian,

Thanks for your hard work for the slice architecture.

I have a little comments,  as we know, there are slice scenarios that have nothing to do with VPN, for example, multiple slices in backbone can be used for connections between metros. So it is strange to put a usecase (VPN+) of slice be as a scheme for slice architecture, as section 6.3 described.

Regards,

PSF

原始邮件

发件人：AdrianFarrel
收件人：[email-masked];
日 期 ：2021年05月04日 17:11
主 题 ：[Teas] Moving forward with draft-ietf-teas-ietf-network-slices

 

 
Best,
Adrian
 
-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: 04 May 2021 09:56
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-02.txt

 
Abstract:

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 6 May 2021 03:52:39 +0000

Hi Adrian,

My feeling is in this context "customer" is better than "consumer". When talking about the customers of network services, there is also another term: tenant. Sometimes customer and tenant may be considered interchangeable, while as you said customer can be generic covering either an individual, an entity, or a physical or logical component.

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Wednesday, May 5, 2021 7:06 PM
> ____________

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 6 May 2021 00:03:00 -0700

Personally I prefer consumer, for similar reasons, however if there’s wg consensus to use customer, I’m ok with it, at the end it is the meaning of the word, not the word itself.

Regards,
Jeff

> On May 5, 2021, at 06:23, Shunsuke Homma <[email-masked]> wrote:
> 
> 
> Hi,
> 
> Sorry for cutting in...
> 
> I’m not a native English speaker and I’m not sure if my understanding on the words is correct, but I think “consumer” would be more appropriate, because I feel that “consumer” implies people rend a slice from a slice provider with “paying fee”. (On the other hand, in my understanding, “consumer” means a user of a service and it is independent of whether he/she pays fee or not.)
> 
> As you know, network slice concept generally allows hierarchical structure (of course, the current IETF network slice definition allows it). For example, an IETF network slice may be used to provide connectivity (and some functionalities) to other slices, such as 5G slices, which are under the same provider, for creating an E2E slice. In such case, can other slices or a higher orchestrator coordinating these slices be called “customer”? (In this case, there would not be any payments.)
> 
> I’m sorry if my understanding on “customer” is incorrect and it can be applied to such cases.
> 
> Regards,
> 
> Shunsuke 
> 
> 2021年5月5日(水) 21:18 Belotti, Sergio (Nokia - IT/Vimercate) <[email-masked]>:
>> Hi Adrian,
>> +1
>> 
>> Thanks
>> Sergio
>>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 6 May 2021 09:31:19 +0200

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

--

---

From: Oscar González de Dios <[email-masked]>
Date: Thu, 6 May 2021 11:53:13 +0000

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 <[email-masked]> En nombre de Loa Andersson
Enviado el: jueves, 6 de mayo de 2021 9:31
Para: [email-masked]; [email-masked]; [email-masked]
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 "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:
> ______________________________________________________________________

--

________________________________

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

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 6 May 2021 14:25:46 +0000 (UTC)

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 <[email-masked]> wrote:  
 
 Hi Adrian,

        Best Regards,

                Oscar

-----Mensaje original-----
De: Teas <[email-masked]> En nombre de Loa Andersson
Enviado el: jueves, 6 de mayo de 2021 9:31
Para: [email-masked]; [email-masked]; [email-masked]
Asunto: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Adrian,

That is acceptable.

Your wholesale example:

I rest my case.

/Loa

--

---

From: John E Drake <[email-masked]>
Date: Thu, 6 May 2021 15:48:00 +0000

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.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Igor Bryskin
Sent: Thursday, May 6, 2021 10:26 AM
To: Loa Andersson <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Oscar González de Dios <[email-masked]>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Hi Adrian,

Thanks,
Igor

On Thursday, May 6, 2021, 07:53:32 AM EDT, Oscar González de Dios <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian,

        Best Regards,

                Oscar

-----Mensaje original-----
De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de Loa Andersson
Enviado el: jueves, 6 de mayo de 2021 9:31
Para: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Asunto: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Adrian,

That is acceptable.

Your wholesale example:

I rest my case.

/Loa

On 05/05/2021 13:05, Adrian Farrel wrote:
> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
> Sent: 05 May 2021 11:58
> To: [email-masked]<mailto:[email-masked]>; 'Loa Andersson' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>> De : Teas [mailto:[email-masked]<mailto:[email-masked]>] De la part de Adrian Farrel
>> Envoyé : mercredi 5 mai 2021 11:59 À : 'Loa Andersson' <[email-masked]<mailto:[email-masked]>>;
>> [email-masked]<mailto:[email-masked]> Objet : Re: [Teas] Moving forward with
>> [email-masked]<mailto:[email-masked]>
>> 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$>
>
> [email-masked]<mailto:[email-masked]>
> 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: [email-masked]<mailto:[email-masked]>
Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>
Bronze Dragon Consulting            phone: +46 739 81 21 64

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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$>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 6 May 2021 16:38:37 +0000 (UTC)

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=[email-masked]> wrote:  
 
 #yiv6988404160 #yiv6988404160 -- _filtered {} _filtered {} _filtered {} _filtered {}#yiv6988404160 #yiv6988404160 p.yiv6988404160MsoNormal, #yiv6988404160 li.yiv6988404160MsoNormal, #yiv6988404160 div.yiv6988404160MsoNormal {margin:0in;font-size:11.0pt;font-family:sans-serif;}#yiv6988404160 a:link, #yiv6988404160 span.yiv6988404160MsoHyperlink {color:blue;text-decoration:underline;}#yiv6988404160 span.yiv6988404160EmailStyle18 {font-family:sans-serif;color:windowtext;}#yiv6988404160 p.yiv6988404160msipfooter30b3d538, #yiv6988404160 li.yiv6988404160msipfooter30b3d538, #yiv6988404160 div.yiv6988404160msipfooter30b3d538 {margin-right:0in;margin-left:0in;font-size:11.0pt;font-family:sans-serif;}#yiv6988404160 .yiv6988404160MsoChpDefault {font-size:10.0pt;} _filtered {}#yiv6988404160 div.yiv6988404160WordSection1 {}#yiv6988404160 
Igor,

 
Yours Irrespectively,

John

 

 
Hi Adrian,

 

Thanks,
 
Igor

 

Hi Adrian,

        Best Regards,

                Oscar

-----Mensaje original-----
De: Teas <[email-masked]> En nombre de Loa Andersson
Enviado el: jueves, 6 de mayo de 2021 9:31
Para: [email-masked]; [email-masked]; [email-masked]
Asunto: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Adrian,

That is acceptable.

Your wholesale example:

I rest my case.

/Loa

On 05/05/2021 13:05, Adrian Farrel wrote:
> To: [email-masked]; 'Loa Andersson' <[email-masked]>;[email-masked]

--

---

From: John E Drake <[email-masked]>
Date: Thu, 6 May 2021 16:56:05 +0000

Hi,

Comments inline.  In general, much like VPNs, the customer doesn't have visibility into the provider's network.

Yours Irrespectively,

John

Juniper Business Use Only
From: Igor Bryskin <i_bryskin=[email-masked]>
Sent: Thursday, May 6, 2021 12:39 PM
To: Igor Bryskin <[email-masked]>; Loa Andersson <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Oscar González de Dios <[email-masked]>; John E Drake <[email-masked]>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Thanks John,

[JD]  I have no idea.  One of the reasons why we haven't yet included SFCs is that we have no idea what are the requirements for it.

[JD]  This is already handled with Service Level Expectations (SLEs), which have been added to the framework draft.

Igor

On Thursday, May 6, 2021, 11:48:22 AM EDT, John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>> 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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-bess-nsh-bgp-control-plane-18__;!!NEt6yMaO-gk!UiAW41P7JKVUF0vjIvj-fdWXz4tdgy1TQsJvFgOakNad0SkwwCcGftg70olRfow$>.

Yours Irrespectively,

John

From: Teas <[email-masked]<mailto:[email-masked]>> On Behalf Of Igor Bryskin
Sent: Thursday, May 6, 2021 10:26 AM
To: Loa Andersson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Oscar González de Dios <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Hi Adrian,

Thanks,

Igor

Hi Adrian,

        Best Regards,

                Oscar

-----Mensaje original-----
De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de Loa Andersson
Enviado el: jueves, 6 de mayo de 2021 9:31
Para: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Asunto: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Adrian,

That is acceptable.

Your wholesale example:

I rest my case.

/Loa

--

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!UiAW41P7JKVUF0vjIvj-fdWXz4tdgy1TQsJvFgOakNad0SkwwCcGftg7Jv_wONI$>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 6 May 2021 13:28:15 -0400

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)?
> 
> On Thursday, May 6, 2021, 11:48:22 AM EDT, John E Drake 
> <jdrake=[email-masked]> 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
> 
> *From:* Teas <[email-masked]> *On Behalf Of * Igor Bryskin
> *Sent:* Thursday, May 6, 2021 10:26 AM
> *To:* Loa Andersson <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]; Oscar González de Dios 
> <[email-masked]>
> *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.
> 
> On Thursday, May 6, 2021, 07:53:32 AM EDT, Oscar González de Dios 
> <[email-masked] 
> <mailto:[email-masked]>> 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
> 
> 
> De: Teas <[email-masked] <mailto:[email-masked]>> En 
> nombre de Loa Andersson
> Para: [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>
>> From: [email-masked] <mailto:[email-masked]> 
> <[email-masked] <mailto:[email-masked]>>
>> Sent: 05 May 2021 11:58
>> To: [email-masked] <mailto:[email-masked]>; 'Loa Andersson' 
> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>> De : Teas [mailto:[email-masked] <mailto:[email-masked]>] De la part de 
> Adrian Farrel
>>> Envoyé : mercredi 5 mai 2021 11:59 À : 'Loa Andersson' <[email-masked] <mailto:[email-masked]>>;
>>> [email-masked] <mailto:[email-masked]> Objet : Re: [Teas] Moving forward with
>>> [email-masked] <mailto:[email-masked]>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!X_3my20D0a0-O-3AGBF9WTsXoLaXi_9rJT8003XW0WCdkSUuAV5G3D-29TXGHao$>
>>
>> [email-masked] <mailto:[email-masked]>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!X_3my20D0a0-O-3AGBF9WTsXoLaXi_9rJT8003XW0WCdkSUuAV5G3D-29TXGHao$>
>>
> 
> --
> 
> Loa Andersson                        email: [email-masked] <mailto:[email-masked]>
> Senior MPLS Expert [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> <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
> 
> 
> [email-masked] <mailto:[email-masked]>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas__;!!NEt6yMaO-gk!X_3my20D0a0-O-3AGBF9WTsXoLaXi_9rJT8003XW0WCdkSUuAV5G3D-29TXGHao$>
> 
> [email-masked] <mailto:[email-masked]>
> <https://www.ietf.org/mailman/listinfo/teas>
>

---

From: <[email-masked]>
Date: Fri, 7 May 2021 10:40:01 +0800 (CST)

hi Adrian,

Some typo or comments for your consideration,

Page 10, the first line: be determined [by] the customer...

Page 12, in 4.2:  the 'multipoint-to-point' is duplicate.      

                The IETF NSE[s] are conceptual points of connection ...

Page 12,  it says,

'An NSE should be identified by a unique ID in the context of an  IETF Network Slice customer.'

'A combination of NSE unique ID and NSE attributes defines an NSE in the context of the IETF Network Slice Controller (NSC).'

The unique ID of NSE is in the context (or name space) of IETF Network Slice customer. The context/name space of IETF Network slice customer may be different from the context of IETF network slice controller, considering, for example, difference customers could use different the same unique ID in their own customer contexts. It may need to consider the difference between the customer context and NSC context in order to keep the ID unique.

Page 20, 'IEFT' typo

Page 20,  'are mapped to the underlay IETF Network Slice Endpoints   (NEPs)'.    The abbreviation could be NSEs while not NEPs.

Page 24, security consideration, ' as some aspects of security may be expressed in SLOs.'    

    According to 4.1.2.1, security is expressed in SLE, and here, the SLOs could be SLEs.

Regards,

Xiaobing NIU

原始邮件

发件人：AdrianFarrel
收件人：[email-masked];
日 期 ：2021年05月04日 17:11

 

 
Best,
Adrian
 
-----Original Message-----
From: Teas <[email-masked]> On Behalf Of [email-masked]
Sent: 04 May 2021 09:56
To: [email-masked]
Cc: [email-masked]
Subject: [Teas] I-D Action: draft-ietf-teas-ietf-network-slices-02.txt

 
Abstract:

---

From: Shunsuke Homma <[email-masked]>
Date: Fri, 7 May 2021 11:53:08 +0900

Hi,

Firstly, I also follow the WG consensus, and I’m ok to use “customer” if WG
prefers it.

I assume there are mainly two types of use cases on (IETF) network slices:
1. Providing slices to externals(customers) as a network service
2. Operating some internal network resources with the same slice system
with case1

As far as I read other comments on the terms, most of people seem to
focuses on use cases where IETF network slices are provided as a type of
network services (i.g., case1), and I’d like to confirm if case2 is also in
our scope and “customer” can cover both cases. (I personally want to avoid
using different terms depending on assumed use cases).

Btw, I agree with that slice management would be important, and we’ll need
to clarify what “customers” and “providers” can do on slice managements. In
my memory, the NS-DT’s study was started with an assumption that resources
should be abstracted from several reasons, such as usability, scalability,
security, etc. In this assumption, in my understanding, who controls
network resources will be always slice provider (i.e., the owner of NSC).
In other words, customers never manage resources structuring a slice
directly, and a customer will send a service request to a slice
provider/NSC when he/she wants to create/change/delete a slice. (I think
this is fit to operation models considered in other SDOs such as TMF.)

What can be done via service request will depend on design of slice
service, and the current definition part provides just minimal sets of
selectable parameters as SLOs. More details are provided in NBI drafts.

Regards,

Shunsuke

2021年5月6日(木) 20:53 Oscar González de Dios <
[email-masked]>:

> 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.
>
> 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.
>
> 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 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.
>
> similar, the risk is that we talk about "customer" (even if we change it),
> and "slice" (even though if is really "IETF Slice)",
>
> 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.
>
> 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

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 7 May 2021 14:10:54 +0000 (UTC)

Hi Joel,
     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.IB>> But is not possible that in  the chain:AccessPoint 1 -> SF1->SF2->...-> AccessPoint2 the client cares about SF1->SF2 delay more than  about AccessPoint1 to AccessPoint2 delay ?
      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.
IB>> What if I want to stay away, say, from a particular DC? Would it be easier and more flexible to express such exclusions/inclusions in terms of an abstract topology nodes representing countries, DCs, internal networks, etc.?

Igor

    On Thursday, May 6, 2021, 11:14:07 PM EDT, Shunsuke Homma <[email-masked]> wrote:  
 
 Hi,
Firstly, I also follow the WG consensus, and I’m ok to use “customer” if WG prefers it.
I assume there are mainly two types of use cases on (IETF) network slices:1. Providing slices to externals(customers) as a network service 2. Operating some internal network resources with the same slice system with case1
As far as I read other comments on the terms, most of people seem to focuses on use cases where IETF network slices are provided as a type of network services (i.g., case1), and I’d like to confirm if case2 is also in our scope and “customer” can cover both cases. (I personally want to avoid using different terms depending on assumed use cases).

Btw, I agree with that slice management would be important, and we’ll need to clarify what “customers” and “providers” can do on slice managements. In my memory, the NS-DT’s study was started with an assumption that resources should be abstracted from several reasons, such as usability, scalability, security, etc. In this assumption, in my understanding, who controls network resources will be always slice provider (i.e., the owner of NSC). In other words, customers never manage resources structuring a slice directly, and a customer will send a service request to a slice provider/NSC when he/she wants to create/change/delete a slice. (I think this is fit to operation models considered in other SDOs such as TMF.) 

What can be done via service request will depend on design of slice service, and the current definition part provides just minimal sets of selectable parameters as SLOs. More details are provided in NBI drafts.

Regards,

Shunsuke 

2021年5月6日(木) 20:53 Oscar González de Dios <[email-masked]>:

Hi Adrian,

        Best Regards,

                Oscar

-----Mensaje original-----
De: Teas <[email-masked]> En nombre de Loa Andersson
Enviado el: jueves, 6 de mayo de 2021 9:31
Para: [email-masked]; [email-masked]; [email-masked]
Asunto: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Adrian,

That is acceptable.

Your wholesale example:

I rest my case.

/Loa

--

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 7 May 2021 10:30:47 -0400

I will let others comment on the best way to express constraints at the 
ietf network slice service level.  I do expect that there is an abstract 
topological representation at that level.

With regard to expressing a delay constraint between service function 
instances, my reaction is a combination of two opposites.  First, I ahve 
trouble, given the nature of service functions, seeing why that would be 
needed.  If there is a dialog (outside of the service function chain 
itseslf) among the instances, then something much more complex is going on.

If we really need to represent it, we can presumably do so in the 
abstract service topology.

Yours,
Joel

On 5/7/2021 10:10 AM, Igor Bryskin wrote:
> requirements.
> IB>> But is not possible that in  the chain:
> AccessPoint 1 -> SF1->SF2->...-> AccessPoint2
>   the client cares about SF1->SF2 delay more than  about AccessPoint1 to 
> AccessPoint2 delay ?
> 
> IB>> What if I want to stay away, say, from a particular DC? Would it be 
> easier and more flexible to express such exclusions/inclusions in terms 
> of an abstract topology nodes representing countries, DCs, internal 
> networks, etc.?
> 
> Igor
> 
> 
> network services (i.g., case1), and I’d like to confirm if case2 is also 
> in our scope and “customer” can cover both cases. (I personally want to 
> avoid using different terms depending on assumed use cases).
> 
> 
> Btw, I agree with that slice management would be important, and we’ll 
> need to clarify what “customers” and “providers” can do on slice 
> managements. In my memory, the NS-DT’s study was started with an 
> assumption that resources should be abstracted from several reasons, 
> such as usability, scalability, security, etc. In this assumption, in my 
> understanding, who controls network resources will be always slice 
> provider (i.e., the owner of NSC). In other words, customers never 
> manage resources structuring a slice directly, and a customer will send 
> a service request to a slice provider/NSC when he/she wants to 
> create/change/delete a slice. (I think this is fit to operation models 
> considered in other SDOs such as TMF.)
> 
> 
> 2021年5月6日(木) 20:53 Oscar González de Dios 
> <mailto:[email-masked]>>:
> 
>     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
> 
> 
>     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:
> 
>     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
>     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.
> 
>     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
> 
> 
>      > From: [email-masked]
>     <mailto:[email-masked]> <[email-masked]
>     <mailto:[email-masked]>>
>      > Sent: 05 May 2021 11:58
>      > To: [email-masked] <mailto:[email-masked]>; 'Loa
>     Andersson' <[email-masked] <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>      >> De : Teas [mailto:[email-masked]
>     <mailto:[email-masked]>] De la part de Adrian Farrel
>     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.
> 
>     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.
> 
>     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

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 7 May 2021 16:35:07 +0000 (UTC)

Thanks Joel,
I was hoping you'd say something like that, because this is what  I was kind of getting at :) In TEAS we are working on SF-aware abstract topology model that IMHO can help.
draft-ietf-teas-sf-aware-topo-model-07 - SF Aware TE Topology YANG Model

Regards,Igor
    On Friday, May 7, 2021, 10:31:08 AM EDT, Joel M. Halpern <[email-masked]> wrote:  

Yours,
Joel

On 5/7/2021 10:10 AM, Igor Bryskin 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: [email-masked]
>      > Sent: 05 May 2021 11:58
>      > To: [email-masked] <mailto:[email-masked]>; 'Loa
>      > 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:[email-masked]
>      >> Envoyé : mercredi 5 mai 2021 11:59 À : 'Loa Andersson'
>    <[email-masked] <mailto:[email-masked]>>;
>      >> [email-masked] <mailto:[email-masked]> 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
>      >> [email-masked] <mailto:[email-masked]>
>      >> 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
>      > [email-masked] <mailto:[email-masked]>
>      > https://www.ietf.org/mailman/listinfo/teas
>      >

---

From: Joel Halpern Direct <[email-masked]>
Date: Fri, 7 May 2021 12:54:00 -0400

the expectation currently is that the IETF Network Slice Service will 
use something along the lines of the service models (L2SM and L3SM).  It 
seems reasonable to enhance those with something about service 
functions, quite possibly along the lines you are already working on.

Yours,
Joel

On 5/7/2021 12:35 PM, Igor Bryskin wrote:
> Thanks Joel,
> 
> I was hoping you'd say something like that, because this is what  I was 
> kind of getting at :) In TEAS we are working on SF-aware abstract 
> topology model that IMHO can help.
> 
> <https://datatracker.ietf.org/doc/draft-ietf-teas-sf-aware-topo-model/>
> 
> 
> 
> Regards,
> Igor
> 
>  > On Thursday, May 6, 2021, 11:14:07 PM EDT, Shunsuke Homma
>  > <[email-masked] 
> <mailto:[email-masked]>> wrote:
>  >
>  >
>  > Hi,
>  >
> <mailto:[email-masked]>
>  > <mailto:[email-masked] 
> <mailto:[email-masked]>>>:
>  >
>  >    Hi Adrian,
>  >
>  >    De: Teas <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>> En
>  >    nombre de Loa Andersson
>  >    Para: [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>;
>  > [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>;
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked]>
>  >    <mailto:[email-masked] 
> <mailto:[email-masked]>> <[email-masked] 
> <mailto:[email-masked]>
>  >    <mailto:[email-masked] 
> <mailto:[email-masked]>>>
>  >      > To: [email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>; 'Loa
>  >    Andersson' <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>; [email-masked] <mailto:[email-masked]>
>  >    <mailto:[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked]>
>  >    <mailto:[email-masked] <mailto:[email-masked]>>] De 
> la part de Adrian Farrel
>  >    <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>;
>  >      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>> Objet : Re: [Teas] Moving
>  >    forward with
>  >      >> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
>  >    <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>
>  >      >
>  >      >
>  >      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
>  >    <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>
>  >      >
>  >
>  >    --
>  >
> <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
>  >    <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>
>  >
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
>  >    <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>
>  >
>  > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>
> 
> <https://www.ietf.org/mailman/listinfo/teas >
>  > <https://www.ietf.org/mailman/listinfo/teas 
> <https://www.ietf.org/mailman/listinfo/teas>>
>  >

---

From: Tarek Saad <[email-masked]>
Date: Fri, 7 May 2021 17:45:43 +0000

Hi John/all,

>> Comments inline.  In general, much like VPNs, the customer doesn’t have visibility into the provider’s network.
[TS]: a customer may want to have a say in defining a policy on top of the route that a NS connection can take. In absence of a common language to express such (inclusion/exclusion) policy/intent, does it suffice to express this in terms of geographies (GPS locations, countries, cities, roads), srlgs (srlgs may not have global meaning), diversity needs (from other connections), etc.? Alternatively, does it help if the NBI request expresses such inclusions/exclusions policy using/referencing a “customer-centric” topology that a provider may have furnished earlier to the customer, and which the provider can readily map to their network?

Regards,
Tarek

On 5/6/21, 12:56 PM, "Teas" <[email-masked]> wrote:

Hi,

Comments inline.  In general, much like VPNs, the customer doesn’t have visibility into the provider’s network.

Yours Irrespectively,

John

Thanks John,

[JD]  I have no idea.  One of the reasons why we haven’t yet included SFCs is that we have no idea what are the requirements for it.

Igor

Igor,

Yours Irrespectively,

John

Hi Adrian,

Thanks,

Igor

Hi Adrian,

        Best Regards,

                Oscar

-----Mensaje original-----
De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de Loa Andersson
Enviado el: jueves, 6 de mayo de 2021 9:31
Para: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Asunto: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Adrian,

That is acceptable.

Your wholesale example:

I rest my case.

/Loa

--

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 7 May 2021 12:55:16 -0700

Hi,
I agree with Loa, moving the definition of how the term "customer" is
interpreted in the document to the Terms and Abbreviations section seems
very reasonable. Perhaps the section can include two sub-sections -
Abbreviations/Acronyms and Terms/Terminology. I've noticed that there is
the forward reference in the section:
   The above terminology is defined in greater details in the remainder
   of this document.
It could be those other definitions of terms used in the specific context
in the document be collected in the new sub-section.

Regards,
Greg

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 7 May 2021 21:54:59 -0400

I agree with Loa and am not crazy about either customer or consumer as
either refers to a “human” endpoint and not a system endpoint made of
hardware or software like the term “CE”.

+1 for Customer over Consumer as a customer is human endpoint that has paid
for service SLA where  a consumer is  broader term like subscriber
describing for example all broadband subscriber community.

-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Mon, 10 May 2021 01:58:36 +0000

Hi Adrian and All,

>I agree with Loa, moving the definition of how the term "customer" is interpreted in the document to the Terms and Abbreviations section seems very reasonable.
+1
I don't stick to "customer", but a discussion how about rephrasing "provider" with "producer" may also rise when I choose non-ietf-standard "consumer" term,

Related to this, should we rephrase " IETF Network Slice user" if there is any intention to leave?
5.2.  Expressing Connectivity Intents
The NSC northbound interface (NBI) can be used to communicate between IETF Network Slice users (or customers) and the NSC.
An IETF Network Slice user may be a network operator who, in turn, provides the IETF Network Slice to another IETF Network Slice user or customer.

>the expectation currently is that the IETF Network Slice Service will use something along the lines of the service models (L2SM and L3SM).  It seems reasonable to enhance those with something about service functions, quite possibly along the lines you are already working on.
>
> [TS] (snip) Alternatively, does it help if the NBI request expresses such inclusions/exclusions policy using/referencing a  customer-centric  topology that a provider may have furnished earlier to the customer, and which the provider can readily map to their

FYI, L3SM tried to let the customer define such policy against PE site in sec. 6.6.
I know this is non-exhaustive for IETF Network Slice.

Editorials:
- I'm not sure if recent RFCs should refer SNMP as an NBI in the sense of https://www.ietf.org/about/groups/iesg/statements/writable-mib-module/ .
5.2.  Expressing Connectivity Intents
o  SNMP ([RFC3417], [RFC3412] and [RFC3414] uses binary encoding (ASN.1).
o  For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to model configuration and other data for NETCONF, RESTCONF, and GNMI - among others; ProtoBufs can be used to model gRPC and GNMI data; Structure of Management Information (SMI) [RFC2578] may be used to define Management Information Base (MIB) modules for SNMP, using an adapted subset of OSI's Abstract Syntax Notation One (ASN.1, 1988).

- multipoint-to-point twice
.2.  IETF Network Slice Endpoints
As noted in Section 3.1, an IETF Network Slice describes connectivity between multiple endpoints across the underlying network.  These connectivity types are: point-to-point, point-to-multipoint, multipoint-to-point, multipoint-to-point, or multipoint-to-multipoint.

All the best,
Kenichi

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Gyan Mishra
Sent: Saturday, May 8, 2021 10:55 AM
To: Greg Mirsky <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; Med Boucadair <[email-masked]>; TEAS WG <[email-masked]>; Loa Andersson <[email-masked]>
Subject: Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

I agree with Loa and am not crazy about either customer or consumer as either refers to a “human” endpoint and not a system endpoint made of hardware or software like the term “CE”.  

+1 for Customer over Consumer as a customer is human endpoint that has paid for service SLA where  a consumer is  broader term like subscriber describing for example all broadband subscriber community.

On Fri, May 7, 2021 at 3:55 PM Greg Mirsky <[email-masked] <mailto:[email-masked]> > wrote:

	Hi,
	I agree with Loa, moving the definition of how the term "customer" is interpreted in the document to the Terms and Abbreviations section seems very reasonable. Perhaps the section can include two sub-sections - Abbreviations/Acronyms and Terms/Terminology. I've noticed that there is the forward reference in the section:
	   The above terminology is defined in greater details in the remainder
	   of this document.
	
	It could be those other definitions of terms used in the specific context in the document be collected in the new sub-section.

	Regards,
	Greg

	On Thu, May 6, 2021 at 12:32 AM Loa Andersson <[email-masked] <mailto:[email-masked]> > wrote:

		Adrian,
		
		That is acceptable.

		Your wholesale example:

		

		I rest my case.
		
		/Loa

		On 05/05/2021 13:05, Adrian Farrel wrote:
		> From: [email-masked] <mailto:[email-masked]>  <[email-masked] <mailto:[email-masked]> >
		> Sent: 05 May 2021 11:58
		> To: [email-masked] <mailto:[email-masked]> ; 'Loa Andersson' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
		>> De : Teas [mailto:[email-masked] <mailto:[email-masked]> ] De la part de Adrian Farrel
		>> À : 'Loa Andersson' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
		
		-- 

-- 

Gyan Mishra

Network Solutions Architect 

Email [email-masked] <mailto:[email-masked]> 

M 301 502-1347

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 11 May 2021 15:58:48 -0400

On Sun, May 9, 2021 at 10:09 PM Ogaki, Kenichi <[email-masked]> wrote:

> very reasonable.
> I don't stick to "customer", but a discussion how about rephrasing
> "provider" with "producer" may also rise when I choose non-ietf-standard
> "consumer" term,
>
> The NSC northbound interface (NBI) can be used to communicate between IETF
> Network Slice users (or customers) and the NSC.
> An IETF Network Slice user may be a network operator who, in turn,
> provides the IETF Network Slice to another IETF Network Slice user or
> customer.
>

During the discussions on TE Topology Model, there was a similar discussion
on such terminology. At that time, the pair "client/provider" was picked
over "consumer" and "customer". The term "client" has my vote here too.

> >the expectation currently is that the IETF Network Slice Service will use
> something along the lines of the service models (L2SM and L3SM).  It seems
> reasonable to enhance those with something about service functions, quite
> possibly along the lines you are already working on.
> >
> > [TS] (snip) Alternatively, does it help if the NBI request expresses
> such inclusions/exclusions policy using/referencing a  customer-centric
> topology that a provider may have furnished earlier to the customer, and
> which the provider can readily map to their
>
> - I'm not sure if recent RFCs should refer SNMP as an NBI in the sense of
> https://www.ietf.org/about/groups/iesg/statements/writable-mib-module/ .
> o  For data modeling, YANG ([RFC6020] and [RFC7950]) may be used to model
> configuration and other data for NETCONF, RESTCONF, and GNMI - among
> others; ProtoBufs can be used to model gRPC and GNMI data; Structure of
> Management Information (SMI) [RFC2578] may be used to define Management
> Information Base (MIB) modules for SNMP, using an adapted subset of OSI's
> Abstract Syntax Notation One (ASN.1, 1988).
>
> As noted in Section 3.1, an IETF Network Slice describes connectivity
> between multiple endpoints across the underlying network.  These
> connectivity types are: point-to-point, point-to-multipoint,
> multipoint-to-point, multipoint-to-point, or multipoint-to-multipoint.
>
>
> All the best,
> Kenichi
>
> Cc: Adrian Farrel <[email-masked]>; Med Boucadair <
> [email-masked]>; TEAS WG <[email-masked]>; Loa Andersson <
> [email-masked]>
> +1 for Customer over Consumer as a customer is human endpoint that has
> paid for service SLA where  a consumer is  broader term like subscriber
>         I agree with Loa, moving the definition of how the term "customer"
> is interpreted in the document to the Terms and Abbreviations section seems
>         It could be those other definitions of terms used in the specific
> context in the document be collected in the new sub-section.
>
>         Regards,
>         Greg
>
>
>                 > From: [email-masked] <mailto:
> [email-masked]>  <[email-masked] <mailto:
> [email-masked]> >
>                 > Sent: 05 May 2021 11:58
>                 > To: [email-masked] <mailto:[email-masked]> ;
> 'Loa Andersson' <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:
> [email-masked]>
>                 >> De : Teas [mailto:[email-masked] <mailto:
> [email-masked]> ] De la part de Adrian Farrel
>                 >>>>    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.
>                 >>>
>                 >>> shop) and consumer is also a person /that eats what I
> bought at
>                 >> your shop).
>                 >>
>                 >>> IETF specifies "systems", including what goes into SW
> and HW, but
>                 >> we
> <mailto:[email-masked]>
>                 Senior MPLS Expert
> [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 18 May 2021 15:30:08 +0000

Hi Shunsuke,

“As far as I read other comments on the terms, most of people seem to focuses on use cases where IETF network slices are provided as a type of network services (i.g., case1), and I’d like to confirm if case2 is also in our scope and “customer” can cover both cases. (I personally want to avoid using different terms depending on assumed use cases).”

I agree with you that both should be in scope. I don’t see slicing different compared to other network services. The “customer” can be used for both internal and external cases.

Cheers,
Med

De : Shunsuke Homma [mailto:[email-masked]]
Envoyé : vendredi 7 mai 2021 04:53
À : Oscar González de Dios <[email-masked]>
Cc : Loa Andersson <[email-masked]>; [email-masked]; BOUCADAIR Mohamed TGI/OLN <[email-masked]>; [email-masked]
Objet : Re: [Teas] Moving forward with draft-ietf-teas-ietf-network-slices

Hi,

I assume there are mainly two types of use cases on (IETF) network slices:
1. Providing slices to externals(customers) as a network service
2. Operating some internal network resources with the same slice system with case1

Regards,

Shunsuke

---

From: Shunsuke Homma <[email-masked]>
Date: Sat, 22 May 2021 00:05:13 +0900

Thanks, Med. I got that "customer" can be used for both cases, and I'm ok
to use it.

Regards,

Shunsuke

On Wed, May 19, 2021 at 12:30 AM <[email-masked]> wrote:

> Hi Shunsuke,
>
>
>
> “As far as I read other comments on the terms, most of people seem to
> using different terms depending on assumed use cases).”
>
>
>
> I agree with you that both should be in scope. I don’t see slicing
> different compared to other network services. The “customer” can be used
> for both internal and external cases.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Shunsuke Homma [mailto:[email-masked]]
> *Envoyé :* vendredi 7 mai 2021 04:53
> *À :* Oscar González de Dios <[email-masked]>
> *Cc :* Loa Andersson <[email-masked]>; [email-masked]; BOUCADAIR Mohamed
> TGI/OLN <[email-masked]>; [email-masked]
> *Objet :* Re: [Teas] Moving forward with

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 May 2021 16:39:11 +0100

Hi Xufeng,

+1

> During the discussions on TE Topology Model, there was a similar discussion on

> such terminology. At that time, the pair "client/provider" was picked over 

> "consumer" and "customer". The term "client" has my vote here too.

I’m not sure we’re voting, but I have registered your preference.

If we get convincing reasons or an obvious consensus, we can change the words used. That, at least, will be an easy edit, and can be made at pretty much any time.

Cheers,

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 May 2021 17:09:12 +0100

Hi Kenichi,

I'm cleaning up the comments to produce a new revision.

>I agree with Loa, moving the definition of how the term "customer" is interpreted in
> the document to the Terms and Abbreviations section seems very reasonable.
> +1

OK. I'm doing this.

> I don't stick to "customer", but a discussion how about rephrasing "provider" with
> "producer" may also rise when I choose non-ietf-standard "consumer" term

Two things:
- Yes, the discussion of alternatives to "provider" is also still open
- I am keeping a list of people who feel "strongly" about customer/consumer/client
  At the moment I don't feel able to draw any conclusions. I don't think this will 
  change the text on the definition, and we can change the name later if we can
  reach agreement.

> Related to this, should we rephrase " IETF Network Slice user" if there is any

Good catch.

> possibly along the lines you are already working on.

Yes. I hope to bring some text on "slice as a service" for discussion SOON.

> [TS] (snip) Alternatively, does it help if the NBI request expresses such 
> inclusions/exclusions policy using/referencing a  customer-centric 
> topology that a provider may have furnished earlier to the customer,
> and which the provider can readily map to their
>

Thanks for the pointer to L3SM.

>   https://www.ietf.org/about/groups/iesg/statements/writable-mib-module/ .

I agree with you. I'll remove SNMP from the list in 5.2 unless someone shouts (see separate email).

> As noted in Section 3.1, an IETF Network Slice describes connectivity between multiple
> endpoints across the underlying network.  These connectivity types are: point-to-point,
> point-to-multipoint,  multipoint-to-point, multipoint-to-point, or multipoint-to-multipoint.

Thanks.

Cheers,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 May 2021 18:20:11 +0100

Hi Xiaobing,

> Some typo or comments for your consideration,

Many thanks. In line…

> 1. Page 10, the first line: be determined [by] the customer...

Ack

> 2. Page 12, in 4.2:  the 'multipoint-to-point' is duplicate.      

Yes, to both.

> 3. Page 12,  it says,
> 'A combination of NSE unique ID and NSE attributes defines an NSE in the
>  context of the IETF Network Slice Controller (NSC).'
>
> The unique ID of NSE is in the context (or name space) of IETF Network Slice
> customer. The context/name space of IETF Network slice customer may be
> different from the context of IETF network slice controller, considering, for
> example, difference customers could use different the same unique ID in
> their own customer contexts. It may need to consider the difference between
> the customer context and NSC context in order to keep the ID unique.

Right. I think the NSC is going to be aware of the customer ID/name, so that in the provider's context the NSE is identified by {customer,  NSE ID}.

I'm pretty sure the point here is that the NSE identifiers form a set across all of the slices that a single customer has and the NSE IDs are, therefore, unique within the customer scope not within the scope of a slice.

I don't see a typo to change here.

> 4. Page 20, 'IEFT' typo

Yes

> 5. Page 20,  'are mapped to the underlay IETF Network Slice Endpoints
>   (NEPs)'.    The abbreviation could be NSEs while not NEPs.

Oops 😊
Actually, this should be "EP" as in the diagram. A little additional tidying of the text is needed.

> 6. Page 24, security consideration, 'as some aspects of security may be expressed
>   in SLOs.'    

Oh, well found!

Best,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 23 May 2021 18:50:12 +0100

Hi Shaofu,

> I have a little comments,  as we know, there are slice scenarios that have
> nothing to do with VPN, for example, multiple slices in backbone can be
> used for connections between metros. So it is strange to put a usecase
> (VPN+) of slice be as a scheme for slice architecture, as section 6.3 described.

I think there are several things to say on this subject.

The first is that you're right that the use cases for network slicing go far beyond providing VPNs. But I would note that "connectivity services" are very similar to VPNs: they are expressed in terms of a connectivity matrix between a number of endpoints. Actually, you'll notice that this is comparable to a network slice.

I think the next thing to notice is that section 6.3 is not a use case. The whole of section 6 is about ways to realise (i.e., build) network slices, not a discussion of how to use slices.

In fact, ACTN and VPN+ are both TEAS working group architectural solutions (although VPN+ isn't an RFC as yet). That's why they're included in this section.

Best,
Adrian