Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 1 Apr 2022 10:30:06 +0200

Adrian, Med,

Returning to this. I’ve seen many design cases with SPs, where the network is designed physically in very structured manner. Also, I’ve seen some analysis done by couple of SPs, that as the result of this very structured network design, after making internal analysis, they don’t really see the difference between path placement done using IGP metric, and path placement done using delay metric. Hence, even introducing some flex-algos (TE meshes) with different metric optimization is questionable here (as the resulting paths are the same).

To realize services with SLO commitments, these SPs today extensively use admission control at the edge (some times even relatively complex admission control schemes at the edge). But, they don’t use anything specific (TE, Flex-Algo) in the transport, apart from mentioned admission control at the edge (ingress/egress policers/shapers), basic QoS on transit, network capacity planning, and timely capacity upgrades, where needed.

Does this approach could be considered as well as some way of ’network resource partitioning’ mentioned in the draft?

Cheers,
Krzysztof

> On 2022 -Mar-28, at 12:26, Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>> wrote:
> 
> OK,
> 
> If a realization example of network partition is flex-algo + admission control, then I am fine.
> 
> Thanks,
> Krzysztof
> 
> 
>> On 2022 -Mar-28, at 11:36, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Re-,
>>  
>> Manipulating flavors of flex-algos (+ appropriate admission control) is indeed a way to partition a network.
>>  
>> Cheers,
>> Med
>>  
>> De : Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>> 
>> Envoyé : lundi 28 mars 2022 11:31
>> À : BOUCADAIR Mohamed INNOV/NET <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> Cc : [email-masked] <mailto:[email-masked]>
>> Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>>  
>> Hi Med, Adrian,
>>  
>> I still see the partition as realization, thus should be left to the docs/drafts describing the realization, rather than be mandated in framework doc. 
>>  
>> Section 7.2. says:
>>  
>> For example, traffic separation between different IETF Network Slices may be achieved using VPN technologies, such as L3VPN, L2VPN, EVPN, etc. Interference avoidance may be achieved by network capacity planning, allocating dedicated network resources, traffic policing or shaping, prioritizing in using shared network resources, etc. 
>>  
>> ‘Allocating dedicated network resources’, which is my understanding of network partition, is one (and not the only one) of many tools that can be used for realization. 
>>  
>> But, if you are saying, that from, realization perspective for example I can call I partitioned my network by creating two flex-algos, or two sets of TE tunnels (one optimized for latency, another optimized for high capacity links, as an example), then definition of partition is very open, indeed. 
>>  
>> Thanks,
>> Krzysztof
>>  
>> 
>> 
>> On 2022 -Mar-28, at 08:20, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>> Hi Adrian, al,
>>  
>> I think that it is safe to say that partitioning is always needed to realize a slice service. In reference to -10, I even tend to suggest this change: 
>>  
>> ==
>> OLD:
>> An IETF Network Slice is a slice of a network that uses
>>    IETF technology.
>>  
>> NEW:
>> An IETF Network Slice is a partition of a network that is provided using
>>    IETF technologies.
>>  
>> ==
>>  
>> However, that partition does not need to involve only node resources that are partitioned (e.g., some nodes of a partition may exclusively belong to one single slice) or that partition resources are fully isolated. For example, it is completely fine that some form for resource preemption is allowed between slices that belong to the same customer or those engineered for internal use of an operator. I suggest to clarify this in the text by making this change:  
>>  
>> ====
>> OLD:
>>    Network slicing provides the ability to partition a physical network
>>    into multiple isolated logical networks of varying sizes, structures,
>>                  ^^^^^^^^
>>    and functions so that each slice can be dedicated to specific
>>    services or customers.
>>  
>> NEW:
>>    Network slicing provides the ability to partition a physical network
>>    into multiple logical networks of varying sizes, structures,
>>    and functions so that each slice can be dedicated to specific
>>    services or customers. The support of resource preemption between
>>                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>    IETF network slices is deployment specific.  
>>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> =====
>>  
>> Please note that this proposed change is consistent with the definition of “isolation” in the draft:
>>  
>> ==
>>    Isolation:  As described in Section 7 <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-10.txt#section-7>, a customer may request that
>>       its traffic within its IETF Network Slice service is isolated from
>>       the effects of other network services supported by the same
>>       provider. 
>>  
>> ===
>>  
>> and also this text:
>>  
>> ==
>>    An IETF Network Slice could span multiple technologies and multiple
>>    administrative domains.  Depending on the IETF Network Slice
>>    customer's requirements, an IETF Network Slice could be isolated from
>>    other, often concurrent IETF Network Slices in terms of data, control
>>    and management planes.
>>  
>> ==
>>  
>> Thank you.
>>  
>> Cheers,
>> Med
>>  
>> De : Teas <[email-masked] <mailto:[email-masked]>> De la part de Adrian Farrel
>> Envoyé : vendredi 25 mars 2022 22:22
>> À : 'Krzysztof Szarkowicz' <[email-masked] <mailto:[email-masked]>>
>> Cc : [email-masked] <mailto:[email-masked]>
>> Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>>  
>> Hi Krzysztof,
>>  
>> I think you might have something here, but it is confused by a side point.
>>  
>> “might be entire network is single partition” is not a contradiction with “partitioning the network resources.” True, it is at the extreme end of the spectrum, but one is a special case of many.
>>  
>> Now, the BIG question for network slicing is whether the network resources are partitioned at all. If they are counted in any way (including in a central controller) in order to ensure that the traffic can meet the SLOs, then the resources *are* partitioned. It is only if the service delivery is best effort, allowing for congestion and drops, that we can say that the resources are not partitioned.
>>  
>> Or, in another view, if traffic for a particular service is steered onto particular links in order to meet SLOs (for example, latency), then the resources have been partitioned.
>>  
>> So, while I agree that partitioning is strongly tied to realization, I wonder whether it is possible to have a network slice (note “slice”, not “slice service”) without it.
>>  
>> My concern is that we end up with a definition of network slice that is so far removed from realization that it becomes “a slice is what an operator does to their network to deliver a slice service” which, I think, doesn’t tell us what a slice is.
>>  
>> Cheers,
>> Adrian
>>  
>> From: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>> 
>> Sent: 25 March 2022 17:57
>> To: Adrian Farrel <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>
>> Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization
>>  
>> Hi,
>>  
>> I have only one comment, regarding below:
>>  
>>   the "IETF Network
>>   Slice" which is the realization of the service in the provider's 
>>   network achieved by partitioning network resources and by
>>   applying certain tools and techniques within the network (see
>>   Section 3.1).
>>  
>> ‘Achieved by partitioning network resources’ is some specific relation option, which might (or might not) be used in particular realization (depending how the slice is realized, might be entire network is single partition). Hence, it should rather be omitted here, as it should be agnostic to to the actual realization. Thus, I would change it to:
>>  
>>   the "IETF Network
>>   Slice" which is the realization of the service in the provider's 
>>   network achieved by
>>   applying certain tools and techniques within the network (see
>>   Section 3.1).
>>  
>> 
>>  
>> 
>> Regards,
>> Krzysztof
>>  
>> 
>>  
>> 
>> On 2022 -Mar-25, at 12:48, Jalil, Luay <luay.jalil=[email-masked] <mailto:luay.jalil=[email-masked]>> wrote:
>>  
>> +1
>>  
>> Regards,
>> Luay
>>  
>>  
>> On Fri, Mar 25, 2022 at 10:49 AM LUIS MIGUEL CONTRERAS MURILLO <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi all,
>> 
>> Agree, the proposed change is ok.
>> 
>> Best regards
>> 
>> Luis
>> 
>> -----Mensaje original-----
>> De: Teas <[email-masked] <mailto:[email-masked]>> En nombre de Joel M. Halpern
>> Enviado el: viernes, 25 de marzo de 2022 10:30
>> Para: [email-masked] <mailto:[email-masked]>
>> Asunto: Re: [Teas] Slicing Framework Open issue #1 : Service != Realization
>> 
>> Works for me.
>> Yours,
>> Joel
>> 
>> On 3/25/2022 5:17 AM, Adrian Farrel wrote:
>> > Hi,
>> >
>> > First in a series of emails to resolve the open issues mentioned
>> > during the TEAS meeting.
>> >
>> > We have, for the longest time, suffered from a blurring between the
>> > service provided to the customer, and how that service is engineered in the network.
>> > This leads us to talk about VPNs in a way where sometimes a VPN is
>> > what the customer gets and sometimes it is what the operator
>> > engineers. A good example is the term "MPLS VPN" as though the
>> > customer cares whether the VPN is provided using MPLS technology.
>> >
>> > We have, to some extent, clarifies this with recent YANG "Customer
>> > Service Models" that describe the service offered to the customer, but
>> > do not constrain the provider's choice of implementation technology or options.
>> >
>> > As the discussion of IETF Network Slices continues, I have repeatedly
>> > seen some blurring between the topics of the "IETF Network Slice
>> > Service" and the "IETF Network Slice." It seems to me that this mixing
>> > of concepts will continue as future readers pick up the document.
>> >
>> > Although I have tried to use the two terms clearly and distinctly, the
>> > document is missing a clear statement to disambiguate the two.
>> >
>> > Section 3 provides the definitions of the two terms at some length
>> > using subsections. The clarification would get lost if it was placed
>> > at the bottom of the section after the subsections, so I propose to
>> > include some text near the top of section as follows.
>> >
>> > OLD
>> >     IETF Network Slices are created to meet specific requirements,
>> >     typically expressed as bandwidth, latency, latency variation, and
>> >     other desired or required characteristics.  Creation of an IETF
>> >     Network Slice is initiated by a management system or other
>> >     application used to specify network-related conditions for particular
>> >     traffic flows in response to an actual or logical IETF Network Slice
>> >     service request.
>> >
>> >     Once created, these slices can be monitored, modified, deleted, and
>> >     otherwise managed.
>> >
>> >     Applications and components will be able to use these IETF Network
>> >     Slices to move packets between the specified end-points of the
>> >     service in accordance with specified characteristics.
>> > NEW
>> >     IETF Network Slices are created to meet specific requirements,
>> >     typically expressed as bandwidth, latency, latency variation, and
>> >     other desired or required characteristics.  Creation of an IETF
>> >     Network Slice is initiated by a management system or other
>> >     application used to specify network-related conditions for particular
>> >     traffic flows in response to an actual or logical IETF Network Slice
>> >     service request.
>> >
>> >     Once created, these slices can be monitored, modified, deleted, and
>> >     otherwise managed.
>> >
>> >     Applications and components will be able to use these IETF Network
>> >     Slices to move packets between the specified end-points of the
>> >     service in accordance with specified characteristics.
>> >
>> >     A clear distinction should be made between the "IETF Network
>> >     Slice service" which is the function delivered to the customer
>> >     (see Section 3.2) and which is agnostic to the technologies and
>> >     Mechanisms used by the service provider, and the "IETF Network
>> >     Slice" which is the realization of the service in the provider's
>> >     network achieved by partitioning network resources and by
>> >     applying certain tools and techniques within the network (see
>> >     Section 3.1).
>> > END
>> >
>> > Any objections?
>> >
>> > Thanks,
>> > Adrian
>> >
>> > _______________________________________________
>> > Teas mailing list
>> > [email-masked] <mailto:[email-masked]>
>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e=> 
>> 
>> _______________________________________________
>> Teas mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e=> 
>> 
>> ________________________________
>> 
>> 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 confidential and privileged 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
>> [email-masked] <mailto:[email-masked]>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e=>
>> _______________________________________________
>> Teas mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/teas <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.
>>  
>> _________________________________________________________________________________________________________________________
>> 
>> 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: John E Drake <[email-masked]>
Date: Fri, 1 Apr 2022 12:43:27 +0000

Krzysztof,

The usual answer to such a request is to ask you to provide text.

Yours Irrespectively,

John

Juniper Business Use Only
From: Teas <[email-masked]> On Behalf Of Krzysztof Szarkowicz
Sent: Friday, April 1, 2022 4:30 AM
To: <[email-masked]> <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

[External Email. Be cautious of content]

Adrian, Med,

Returning to this. I've seen many design cases with SPs, where the network is designed physically in very structured manner. Also, I've seen some analysis done by couple of SPs, that as the result of this very structured network design, after making internal analysis, they don't really see the difference between path placement done using IGP metric, and path placement done using delay metric. Hence, even introducing some flex-algos (TE meshes) with different metric optimization is questionable here (as the resulting paths are the same).

To realize services with SLO commitments, these SPs today extensively use admission control at the edge (some times even relatively complex admission control schemes at the edge). But, they don't use anything specific (TE, Flex-Algo) in the transport, apart from mentioned admission control at the edge (ingress/egress policers/shapers), basic QoS on transit, network capacity planning, and timely capacity upgrades, where needed.

Does this approach could be considered as well as some way of 'network resource partitioning' mentioned in the draft?

Cheers,
Krzysztof

On 2022 -Mar-28, at 12:26, Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>> wrote:

OK,

Thanks,
Krzysztof

On 2022 -Mar-28, at 11:36, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Re-,

Cheers,
Med

De : Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Envoyé : lundi 28 mars 2022 11:31
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Med, Adrian,

Section 7.2. says:

'Allocating dedicated network resources', which is my understanding of network partition, is one (and not the only one) of many tools that can be used for realization.

Thanks,
Krzysztof

On 2022 -Mar-28, at 08:20, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adrian, al,

==
OLD:

NEW:

   IETF technologies.

==

====
OLD:

                 ^^^^^^^^

   services or customers.

NEW:

Please note that this proposed change is consistent with the definition of "isolation" in the draft:

==

   Isolation:  As described in Section 7<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-10.txt*section-7__;Iw!!NEt6yMaO-gk!VYnwrj_-7g5ayraupb1Hjk4RoCo7h8-qvAVpiN-5HNmTNTGoxddiZFQPscuvx0M$>, a customer may request that

      provider.

===

and also this text:

==

   and management planes.

==

Thank you.

Cheers,
Med

De : Teas <[email-masked]<mailto:[email-masked]>> De la part de Adrian Farrel
Envoyé : vendredi 25 mars 2022 22:22
À : 'Krzysztof Szarkowicz' <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Krzysztof,

"might be entire network is single partition" is not a contradiction with "partitioning the network resources." True, it is at the extreme end of the spectrum, but one is a special case of many.

So, while I agree that partitioning is strongly tied to realization, I wonder whether it is possible to have a network slice (note "slice", not "slice service") without it.

My concern is that we end up with a definition of network slice that is so far removed from realization that it becomes "a slice is what an operator does to their network to deliver a slice service" which, I think, doesn't tell us what a slice is.

Cheers,
Adrian

From: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Sent: 25 March 2022 17:57
To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi,

  the "IETF Network

'Achieved by partitioning network resources' is some specific relation option, which might (or might not) be used in particular realization (depending how the slice is realized, might be entire network is single partition). Hence, it should rather be omitted here, as it should be agnostic to to the actual realization. Thus, I would change it to:

  the "IETF Network

Regards,
Krzysztof

On 2022 -Mar-25, at 12:48, Jalil, Luay <luay.jalil=[email-masked]<mailto:luay.jalil=[email-masked]>> wrote:

+1

Regards,
Luay

On Fri, Mar 25, 2022 at 10:49 AM LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Best regards

Luis

-----Mensaje original-----
De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de Joel M. Halpern
Enviado el: viernes, 25 de marzo de 2022 10:30
Para: [email-masked]<mailto:[email-masked]>
Asunto: Re: [Teas] Slicing Framework Open issue #1 : Service != Realization

Works for me.
Yours,
Joel

On 3/25/2022 5:17 AM, Adrian Farrel wrote:
> [email-masked]<mailto:[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e=

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e=

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
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_teas&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=k0DrrBeS0St-D1jEwNQ_u1ZyHQXQly5fgCsWF0VTh7o&m=ZgpFwbYBRDMbGaCALx4Ex8KrMyZD-gVEhsHKWD9592QJ8dwgs8zvLN3YyhpE0lAq&s=PT9yEot5W1FaYvK-vS_Gc8_apuR_Azv2CkH7JBiNeUw&e=
_______________________________________________
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!VYnwrj_-7g5ayraupb1Hjk4RoCo7h8-qvAVpiN-5HNmTNTGoxddiZFQPijBXflw$>

Thank you.

Thank you.

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 1 Apr 2022 09:18:24 -0400

Hi Med. al,

I am good with your suggestions to add partition for realization of IETF
network slice.

Adrian

I am good with the rest of your verbiage.

Thanks

Gyan
On Mon, Mar 28, 2022 at 2:20 AM <[email-masked]> wrote:

> Hi Adrian, al,
>
>
>
> I think that it is safe to say that partitioning is always needed to
> realize a slice service. In reference to -10, I even tend to suggest this
> change:
>
>
>
> ==
>
> OLD:
>
> However, that partition does not need to involve only node resources that
> are partitioned (e.g., some nodes of a partition may exclusively belong to
> one single slice) or that partition resources are fully isolated. For
> example, it is completely fine that some form for resource preemption is
> allowed between slices that belong to the same customer or those engineered
> for internal use of an operator. I suggest to clarify this in the text by
> making this change:
>
>
>
> ====
>
> OLD:
>
> *De :* Teas <[email-masked]> *De la part de* Adrian Farrel
> *Envoyé :* vendredi 25 mars 2022 22:22
> *À :* 'Krzysztof Szarkowicz' <[email-masked]>
> *Cc :* [email-masked]
> *Objet :* Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service !=
> Realization
>
>
>
> Hi Krzysztof,
>
>
>
> “might be entire network is single partition” is not a contradiction with
> “partitioning the network resources.” True, it is at the extreme end of the
> spectrum, but one is a special case of many.
>
>
>
> Now, the BIG question for network slicing is whether the network resources
> are partitioned at all. If they are counted in any way (including in a
> central controller) in order to ensure that the traffic can meet the SLOs,
> then the resources **are** partitioned. It is only if the service
> delivery is best effort, allowing for congestion and drops, that we can say
> that the resources are not partitioned.
>
>
>
> Or, in another view, if traffic for a particular service is steered onto
> particular links in order to meet SLOs (for example, latency), then the
> resources have been partitioned.
>
>
>
> So, while I agree that partitioning is strongly tied to realization, I
> wonder whether it is possible to have a network slice (note “slice”, not
> “slice service”) without it.
>
>
>
> My concern is that we end up with a definition of network slice that is so
> far removed from realization that it becomes “a slice is what an operator
> does to their network to deliver a slice service” which, I think, doesn’t
> tell us what a slice is.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Krzysztof Szarkowicz <[email-masked]>
> *Sent:* 25 March 2022 17:57
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service
> != Realization
>
>
>
> Hi,
>
>
>
> ‘Achieved by partitioning network resources’ is some specific relation
> option, which might (or might not) be used in particular realization
> (depending how the slice is realized, might be entire network is single
> partition). Hence, it should rather be omitted here, as it should be
> agnostic to to the actual realization. Thus, I would change it to:
>
>
>
>   the "IETF Network
> On 2022 -Mar-25, at 12:48, Jalil, Luay <
> luay.jalil=[email-masked]> wrote:
>
>
>
> +1
>
>
>
> Regards,
>
> *Luay*
>
>
>
>
>
> On Fri, Mar 25, 2022 at 10:49 AM LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]> wrote:
>
> Hi all,
>
> De: Teas <[email-masked]> En nombre de Joel M. Halpern
> Para: [email-masked]
> > [email-masked]
> [email-masked]
> 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 confidential and
> privileged 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]
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: <[email-masked]>
Date: Fri, 1 Apr 2022 13:20:50 +0000

Krzysztof,

Admission control + use of limited set of core QoS classes (PDBs) + much more access QoS classes + map access QoS classes to core classes + no multi-topology/customized path selection is also an example network partitioning. I even expect this to be the privileged approach when legacy forwarding mechanisms should be used to fulfil slicing objectives.

Cheers,
Med

De : Krzysztof Szarkowicz <[email-masked]>
Envoyé : vendredi 1 avril 2022 10:30
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
Cc : [email-masked]
Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Re-,

Cheers,
Med

Hi Med, Adrian,

Section 7.2. says:

Thanks,
Krzysztof

Hi Adrian, al,

==
OLD:

NEW:

   IETF technologies.

==

====
OLD:

                 ^^^^^^^^

   services or customers.

NEW:

==

   Isolation:  As described in Section 7<https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-10.txt#section-7>, a customer may request that

      provider.

===

and also this text:

==

   and management planes.

==

Thank you.

Cheers,
Med

Hi Krzysztof,

Cheers,
Adrian

Hi,

  the "IETF Network

  the "IETF Network

Regards,
Krzysztof

+1

Regards,
Luay

Best regards

Luis

-----Mensaje original-----
De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de Joel M. Halpern
Enviado el: viernes, 25 de marzo de 2022 10:30
Para: [email-masked]<mailto:[email-masked]>
Asunto: Re: [Teas] Slicing Framework Open issue #1 : Service != Realization

Works for me.
Yours,
Joel

Thank you.

Thank you.

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 1 Apr 2022 15:25:38 +0200

Med,

We are on the same page here. I see this as well as predominant approach, in fact.

Cheers,
Krzysztof

> On 2022 -Apr-01, at 15:20, <[email-masked]> <[email-masked]> wrote:
> 
> Krzysztof,
>

---

From: <[email-masked]>
Date: Fri, 1 Apr 2022 13:44:15 +0000

Re-,

Indeed.

FWIW, some of this is captured in RFC7297 with a focus on legacy mechanisms:

==
   These requirements include: reachability scope (e.g., limited scope,
   Internet-wide), direction, bandwidth requirements, QoS parameters
   (e.g., one-way delay [RFC2679], loss [RFC2680], or one-way delay
   variation [RFC3393]), protection, and high-availability guidelines
   (e.g., restoration in less than 50 ms, 100 ms, or 1 second).

   These requirements are then translated into IP/MPLS-related technical
   clauses (e.g., need for recovery means, definition of the class of
   service, need for control-plane protection, etc.).  In a later stage,
   these various clauses will be addressed by the activation of adequate
   network features and technology-specific actions (e.g., Multiprotocol
   Label Switching Traffic Engineering (MPLS-TE, [RFC3346]), Resource
   Reservation Protocol (RSVP, [RFC2205]), Open Shortest Path First
   (OSPF), Intermediate System to Intermediate System (IS-IS), etc.), by
   means of CPP-derived configuration information.

   …

   The CPP template aims to capture connectivity needs and to represent
   and value these requirements in a standardized manner.  Service- and
   Customer-specific IP provisioning rules may lead to a dramatic
   increase of the number of IP transfer classes that need to be
   (pre-)engineered in the network.  Instantiating each CPP into a
   distinct class of service should therefore be avoided for the sake of
   performance and scalability.

   Therefore, application-agnostic IP provisioning practices should be
   recommended, since the requirements captured in the CPP can be used
   to identify which network class of service is to be used to meet
   those requirements/guarantees.  From that standpoint, the CPP concept
   is meant to design a limited number of generic classes so that
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   individual CPP documents, by capturing the connectivity requirements
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   of services, applications, and Customers, can be easily mapped to
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   these classes.
   ^^^^^^^^^^^^
==

Cheers,
Med

De : Krzysztof Szarkowicz <[email-masked]>
Envoyé : vendredi 1 avril 2022 15:26
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]; [email-masked]
Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Med,

Cheers,
Krzysztof

On 2022 -Apr-01, at 15:20, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 1 Apr 2022 15:38:27 +0000

Hi Krzysztof,

Please see some comments inline:

From: Teas [mailto:[email-masked]] On Behalf Of Krzysztof Szarkowicz
Sent: Friday, April 1, 2022 4:30 PM
To: <[email-masked]> <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Adrian, Med,

[Jie] Agree that with some network structure and topology, the path computed based on different constraints may still be the same. This shows that only based on path placement it is hard to provide services with different performance.

[Jie] These are the tools used “today” for the services “today”. For sure they can meet those service requirement, but I hope we agreed that it is not good enough for all the upcoming services in 5G and other aspects.

[Jie] Maybe this could be rephrased as: can the existing VPN services also be called network slices services?  The answer could be “yes” considering the similarity between VPN services and network slice services, and the generality of the IETF network slice framework, while it is more important to identify the new functionalities required and work on them in IETF.

Best regards,
Jie

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Re-,

Cheers,
Med

Hi Med, Adrian,

Section 7.2. says:

Thanks,
Krzysztof

Hi Adrian, al,

==
OLD:

NEW:

   IETF technologies.

==

====
OLD:

                 ^^^^^^^^

   services or customers.

NEW:

==

      provider.

===

and also this text:

==

   and management planes.

==

Thank you.

Cheers,
Med

Hi Krzysztof,

Cheers,
Adrian

Hi,

  the "IETF Network

  the "IETF Network

Regards,
Krzysztof

+1

Regards,
Luay

Best regards

Luis

-----Mensaje original-----
De: Teas <[email-masked]<mailto:[email-masked]>> En nombre de Joel M. Halpern
Enviado el: viernes, 25 de marzo de 2022 10:30
Para: [email-masked]<mailto:[email-masked]>
Asunto: Re: [Teas] Slicing Framework Open issue #1 : Service != Realization

Works for me.
Yours,
Joel

Thank you.

Thank you.

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 1 Apr 2022 13:25:55 -0700

Hi Adrain,
thank you for the suggested clarification of our dictionary. Have you
considered using "IETF Network Slice instance" as the realization of the
service?

Regards,
Greg

On Fri, Mar 25, 2022 at 2:17 AM Adrian Farrel <[email-masked]> wrote:

> Hi,
>
> First in a series of emails to resolve the open issues mentioned during the
> TEAS meeting.
>
> We have, for the longest time, suffered from a blurring between the service
> provided to the customer, and how that service is engineered in the
> network.
> This leads us to talk about VPNs in a way where sometimes a VPN is what the
> customer gets and sometimes it is what the operator engineers. A good
> example is the term "MPLS VPN" as though the customer cares whether the VPN
> is provided using MPLS technology.
>
> We have, to some extent, clarifies this with recent YANG "Customer Service
> Models" that describe the service offered to the customer, but do not
> constrain the provider's choice of implementation technology or options.
>
> As the discussion of IETF Network Slices continues, I have repeatedly seen
> some blurring between the topics of the "IETF Network Slice Service" and
> the
> "IETF Network Slice." It seems to me that this mixing of concepts will
> continue as future readers pick up the document.
>
> Section 3 provides the definitions of the two terms at some length using
> subsections. The clarification would get lost if it was placed at the
> bottom
> of the section after the subsections, so I propose to include some text
> near
> the top of section as follows.
>
> OLD

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 12 Apr 2022 16:07:50 +0200

John, Adrian, Med

In that case, I would propose following text update. The reason is, from the current text, I cannot extract the the examples provided by Med and Adrian could be and well considered as an NSP realization.

===== Current Text ============
An NRP is simply a collection of resources identified in the underlay network.  Thus, the NRP is a scoped view of a topology and may be considered as a topology in its own right.  The process of determining the NRP may be made easier if the underlay network topology is first filtered into a Filter Topology in order to be aware of the subset of network resources that are suitable for specific NRPs, but this is optional.
====== End of current text ==========

===== New Text ============
It is out of scope for this document to describe the details, how an NSP can be realized. However, at a high-level, an NRP is simply a collection of resources identified in the underlay network. Some (none exhaustive) examples of an NSP realization are:

a) collection of paths optimized based on certain criteria. For example low latency paths for NSP-A, and high capacity paths for NSP-B.

b) admission control - possibly with large number of QoS classes - at the transport access, coupled with limited set of transport core QoS classes (PDBs), and N:M mapping between access and core classes.

c) combination of above

d) more complex realization schemes, with combinations of advanced QoS at both the access and transport core, possibly coupled with Filter Topology and different path optimizations methods.
====== End of new text ==========

Best regards,
Krzysztof Szarkowicz

> On 2022 -Apr-01, at 14:43, John E Drake <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Krzysztof,
>  

> On 2022 -Apr-01, at 15:44, [email-masked] <mailto:[email-masked]> wrote:
> 
> Re-,
>  
> Indeed.
>  
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked] <mailto:[email-masked]>>
> Cc : [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> On 2022 -Apr-01, at 15:20, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Krzysztof,
>

---

From: John E Drake <[email-masked]>
Date: Tue, 12 Apr 2022 14:53:54 +0000

Krzsyztof,

This is fine with me.  I think you meant NRP rather than NSP in the proposed text?

Yours Irrespectively,

John

Juniper Business Use Only
From: Krzysztof Szarkowicz <[email-masked]>
Sent: Tuesday, April 12, 2022 10:08 AM
To: [email-masked]; John E Drake <[email-masked]>; <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

On 2022 -Apr-01, at 14:43, John E Drake <[email-masked]<mailto:[email-masked]>> wrote:

Krzysztof,

Yours Irrespectively,

John

On 2022 -Apr-01, at 15:44, [email-masked]<mailto:[email-masked]> wrote:

Re-,

Indeed.

==

   ...

Cheers,
Med

De : Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Envoyé : vendredi 1 avril 2022 15:26
À : BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Tue, 12 Apr 2022 16:54:32 +0200

Sorry.

Typo, indeed.

It should be NRP.

> On 2022 -Apr-12, at 16:53, John E Drake <[email-masked]> wrote:
> 
> Krzsyztof,
>  
> To: [email-masked] <mailto:[email-masked]>; John E Drake <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 13 Apr 2022 06:52:41 +0000

Hi Krzysztof,

One concern is the text you proposed is the level of detail which the framework document was trying to avoid.

And as for the examples you provided, I’m not sure if all of them can be called NRP. For example:

Low latency paths and high capacity paths may be obtained by using different metric types in Flex-Algo or other path computation, while as mentioned in a previous mail, depends on the network structure and topology, the path computed based on different metric types or constraints may still be the same or contain a set of shared links. Then it is not clear how the performance of services mapped to different NRPs with shared paths or links can be guaranteed. IMO some kind of resource reservation or management is needed for different NRPs.

Best regards,
Jie

From: Teas [mailto:[email-masked]] On Behalf Of Krzysztof Szarkowicz
Sent: Tuesday, April 12, 2022 10:08 PM
To: [email-masked]; John E Drake <[email-masked]>; <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

Re-,

Indeed.

==

   …

Cheers,
Med

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.

---

From: John E Drake <[email-masked]>
Date: Wed, 13 Apr 2022 13:44:14 +0000

Hi,

Upon re-reading Krzysztof's email, I think we should keep the existing text and supplement it with Krzysztof's text, but striking the second sentence.  Comments inline below.

Yours Irrespectively,

John

Juniper Business Use Only
From: Dongjie (Jimmy) <[email-masked]>
Sent: Wednesday, April 13, 2022 2:53 AM
To: Krzysztof Szarkowicz <[email-masked]>; [email-masked]; John E Drake <[email-masked]>; <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Krzysztof,

And as for the examples you provided, I'm not sure if all of them can be called NRP. For example:

Low latency paths and high capacity paths may be obtained by using different metric types in Flex-Algo or other path computation, while as mentioned in a previous mail, depends on the network structure and topology, the path computed based on different metric types or constraints may still be the same or contain a set of shared links.

[JD]  What you are describing is how the NRP specified in a), above, might be instantiated.  I think a) is consistent with the existing text

Then it is not clear how the performance of services mapped to different NRPs with shared paths or links can be guaranteed. IMO some kind of resource reservation or management is needed for different NRPs.

[JD]  This is an issue for the service provider

Best regards,
Jie

To: [email-masked]<mailto:[email-masked]>; John E Drake <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

Re-,

Indeed.

==

   ...

Cheers,
Med

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 14 Apr 2022 07:05:05 +0000

Hi John,

Thanks for the discussion on this point. Please see further inline with [Jie]:

From: John E Drake [mailto:[email-masked]]
Sent: Wednesday, April 13, 2022 9:44 PM
To: Dongjie (Jimmy) <[email-masked]>; Krzysztof Szarkowicz <[email-masked]>; [email-masked]; <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi,

Yours Irrespectively,

John

Juniper Business Use Only
From: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 13, 2022 2:53 AM
To: Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; John E Drake <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Krzysztof,

[Jie] My point was that the mechanism in a) may not be a good example for NRP instantiation. As it is only path computation and does not describe how the resources are managed or reserved for different NRPs.

[Jie] Indeed service provider needs the mechanisms which can create NRPs to meet the performance requirement of different services, even if the paths or links are shared with other services.

Best regards,
Jie

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

Re-,

Indeed.

==

   ...

Cheers,
Med

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.

---

From: <[email-masked]>
Date: Thu, 14 Apr 2022 11:26:39 +0000

Hi Krzysztof, all,

Looks good to me. Thanks.

Cheers,
Med

De : Krzysztof Szarkowicz <[email-masked]>
Envoyé : mardi 12 avril 2022 16:08
À : [email-masked]; John E Drake <[email-masked]>; BOUCADAIR Mohamed INNOV/NET <[email-masked]>
Cc : [email-masked]
Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Thu, 14 Apr 2022 14:59:31 +0200

Hi Jie,

I agree, NRP is a realization, and a such, my initial comments (few weeks ago) was that it should not be mentioned at all in the framework document, but should be left to the documents describing the realization.

If, however, NRP is mandated by the framework document for realization, the wording for NRP in the framework document should be wide enough, to allow different realization options (described in different realization documents). For example, realization option mentioned by Med:

* admission control with advanced QoS (large number of edge QoS classes) at the transport edge
* basic QoS (limited number of transport core QoS classes) in transport core
* mapping between large number of transport edge QoS classes to limited number transport core QoS classes
* capacity planning

has no good match with current wording about NRP in the framework document, IMHO.

Please see as well inline.

Thanks,
Krzysztof

> On 2022 -Apr-14, at 09:05, Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi John,
>  
> From: John E Drake [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>>; Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> Upon re-reading Krzysztof’s email, I think we should keep the existing text and supplement it with Krzysztof’s text, but striking the second sentence.  Comments inline below.
>  
> Yours Irrespectively,
>  
> John
>  
>  
> From: Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>> 
> To: Krzysztof Szarkowicz <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; John E Drake <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>

[Krzysztof] This is the question of realization, not the question of the framework. Some realization might use some advanced resource reservation/management for each link in the network, to squeeze out the link to last possible bit, some other realization might just use advanced reservation techniques on some links only (for example transport edge links), while using more loosely techniques on other links (e.g. transport core links). Some other realization might over provision certain links, instead of using advanced reservation mechanisms on these links. And, there could be dozens of different realization options, optimized for specific underlying technology. The framework document should not dictate any realization option, IMHO. It should be left to the realization documents.

>  
> Best regards,
> Jie
>  
>  
> From: Teas [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Krzysztof Szarkowicz

---

From: John E Drake <[email-masked]>
Date: Thu, 14 Apr 2022 13:11:46 +0000

Jie,

My first reaction to a) was the same as yours, put then I re-read the existing text and sets of paths are consistent with it.

Yours Irrespectively,

John

Juniper Business Use Only
From: Dongjie (Jimmy) <[email-masked]>
Sent: Thursday, April 14, 2022 3:05 AM
To: John E Drake <[email-masked]>; Krzysztof Szarkowicz <[email-masked]>; [email-masked]; <[email-masked]> <[email-masked]>
Cc: [email-masked]
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi John,

To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>

Hi,

Yours Irrespectively,

John

Hi Krzysztof,

Best regards,
Jie

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

Re-,

Indeed.

==

   ...

Cheers,
Med

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 15 Apr 2022 05:00:57 +0000

Hi Krzysztof,

Yes NRP is a concept introduced for the realization of IETF network slice, and it is the result of long time WG discussion about the terminology for the underlay network construct which is used to support the IETF network slice services. My personal understanding is that the NRP concept and definition belongs to the framework document, while the technologies used to instantiate NRP are out of its scope. For sure there can be multiple ways to build an NRP, as long as they comply to the NRP definition in the framework.

I understand your concern is whether the framework mandates only one or two mechanisms to build NRP, I don’t think this is what the current framework indicates. Thus to me the examples about detailed realization mechanisms are not quite necessary for the framework document and may contradict with its role as a high-level framework.

On the other hand, discussion about the possible mechanisms to build NRPs can continue in the WG.

To me an NRP is usually realized with the combination of a set of data plane and control plane technologies. Constrained path computation or Flex-Algo can only be seen as a component rather than a complete solution. As you mentioned, one or multiple technologies such as admission control/advanced or basic QoS/capacity planning/resource reservation either on the edge nodes or the transit nodes would be needed, and the mechanisms can have specific applicability to different network applications.

Best regards,
Jie

From: Krzysztof Szarkowicz [mailto:[email-masked]]
Sent: Thursday, April 14, 2022 9:00 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: John E Drake <[email-masked]>; [email-masked]; <[email-masked]> <[email-masked]>; [email-masked]
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Jie,

Thanks,
Krzysztof

On 2022 -Apr-14, at 09:05, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi John,

Hi,

Yours Irrespectively,

John

Hi Krzysztof,

Best regards,
Jie

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

Re-,

Indeed.

==

   …

Cheers,
Med

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.

---

From: <[email-masked]>
Date: Fri, 15 Apr 2022 06:59:23 +0000

Hi Jie, all,

I fully agree that the current document does not put any constraint on how NRP is designed/tweaked/realized. However, what I’m hearing from Krzysztof is that it is helpful to have some examples to illustrate the various abstract notions in the draft. That’s consistent with other parts of the draft where samples are provided.

Thank you.

Cheers,
Med

De : Dongjie (Jimmy) <[email-masked]>
Envoyé : vendredi 15 avril 2022 07:01
À : Krzysztof Szarkowicz <[email-masked]>
Cc : John E Drake <[email-masked]>; [email-masked]; BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
Objet : RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Krzysztof,

Best regards,
Jie

From: Krzysztof Szarkowicz [mailto:[email-masked]]
Sent: Thursday, April 14, 2022 9:00 PM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: John E Drake <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Jie,

Thanks,
Krzysztof

Hi John,

Hi,

Yours Irrespectively,

John

Hi Krzysztof,

Best regards,
Jie

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

Re-,

Indeed.

==

   …

Cheers,
Med

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 15 Apr 2022 09:01:21 +0200

Hi Jie,

Thank you for fast response.

I fully agree with you, that the realization is the combination of various techniques, and in particular realization, there could be more focus on some technique ‘A’, while in some other realization there could be some more focus on technique ‘B’. And, the framework should be open for different realizations.

I have re-read section 6.1, I am still confused with the first paragraph on page 30, which says:

   An NRP is simply a collection of resources identified in the underlay
   network.  Thus, the NRP is a scoped view of a topology and may be
   considered as a topology in its own right.  The process of
   determining the NRP may be made easier if the underlay network
   topology is first filtered into a Filter Topology in order to be
   aware of the subset of network resources that are suitable for
   specific NRPs, but this is optional.

It is very tight coupling between NRP and the topology. IMHO, is some realizations this tight coupling might be true, I’m some realizations it might not be true. This paragraph is most distracting for me.

Best regards,
Krzysztof

> On 2022 -Apr-15, at 07:00, Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Krzysztof,
>  
> From: Krzysztof Szarkowicz [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>>
> Cc: John E Drake <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: <[email-masked]>
Date: Fri, 15 Apr 2022 07:15:24 +0000

Re-,

The first sentence is really what is important in the para you quoted. The second sentence is OK (e.g., a PDB can be seen as a scoped view). The last sentence is about examples. These examples should be linked with this text:

   The
   use of Filter Topologies is entirely optional in the architecture,
   and IETF Network Slices could be hosted directly on the underlay
   network.

Cheers,
Med

De : Krzysztof Szarkowicz <[email-masked]>
Envoyé : vendredi 15 avril 2022 09:01
À : Dongjie (Jimmy) <[email-masked]>
Cc : John E Drake <[email-masked]>; [email-masked]; BOUCADAIR Mohamed INNOV/NET <[email-masked]>; [email-masked]
Objet : Re: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Jie,

Best regards,
Krzysztof

On 2022 -Apr-15, at 07:00, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Krzysztof,

Best regards,
Jie

Hi Jie,

Thanks,
Krzysztof

Hi John,

Hi,

Yours Irrespectively,

John

Hi Krzysztof,

Best regards,
Jie

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

Re-,

Indeed.

==

   …

Cheers,
Med

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 18 Apr 2022 08:12:47 +0000

Hi Med,

I think we are aligned in the understanding of the NRP description in the framework document: there is no constraint on the realization technologies, as long as the requirements are met.

Whether it is helpful to add examples to the draft can be discussed on the list and decided based on the consensus.

And I agree with you that illustrating the abstract notions would be enough for this document, the details will be specified in NRP realization specific drafts.

Best regards,
Jie

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 15, 2022 2:59 PM
To: Dongjie (Jimmy) <[email-masked]>; Krzysztof Szarkowicz <[email-masked]>
Cc: John E Drake <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Jie, all,

Thank you.

Cheers,
Med

De : Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Envoyé : vendredi 15 avril 2022 07:01
À : Krzysztof Szarkowicz <[email-masked]<mailto:[email-masked]>>
Cc : John E Drake <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; BOUCADAIR Mohamed INNOV/NET <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Objet : RE: [Teas] [E] Re: Slicing Framework Open issue #1 : Service != Realization

Hi Krzysztof,

Best regards,
Jie

Hi Jie,

Thanks,
Krzysztof

Hi John,

Hi,

Yours Irrespectively,

John

Hi Krzysztof,

Best regards,
Jie

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

Re-,

Indeed.

==

   …

Cheers,
Med

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.

Thank you.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 18 Apr 2022 10:18:04 +0000

Hi Krzysztof,

Thanks for your reply. Please see some further inline with [Jie]:

Sent: Friday, April 15, 2022 3:01 PM

Hi Jie,

[Jie] Agree the framework should be open to different realizations, and this is my understanding about the NRP description in the framework draft.

[Jie] My understanding about the topology here is that it is a generic term used to represent the set of network nodes and links that belong to the NRP, it does not constrain any mechanism to build or select the topology.

But I agree the text could be improved. My suggestion is something like:

      An NRP is simply a collection of resource identified in the underlay network. The set of nodes and links belonging to the NRP provide the scoped view of a topology, and the NRP may be considered as a topology in its own right.

The rest text about filter topology (or call it sub-topology) is considered optional and I’m fine to either remove it or keep it.

Best regards,
Jie

Best regards,
Krzysztof

Hi Krzysztof,

Best regards,
Jie

Hi Jie,

Thanks,
Krzysztof

Hi John,

Hi,

Yours Irrespectively,

John

Hi Krzysztof,

Best regards,
Jie

John, Adrian, Med

c) combination of above

Best regards,
Krzysztof Szarkowicz

Krzysztof,

Yours Irrespectively,

John

Re-,

Indeed.

==

   …

Cheers,
Med

Med,

Cheers,
Krzysztof

Krzysztof,

Cheers,
Med

Adrian, Med,

Cheers,
Krzysztof

OK,

Thanks,
Krzysztof

Thank you.