Subject: [Teas] Review of draft-ietf-teas-ietf-network-slices-09

From: Daniele Ceccarelli <[email-masked]>
Date: Fri, 25 Mar 2022 16:12:34 +0000

Hi Adrian, all,

i reviewed the draft once again like if it was an early routing area directorate review...and here are some more comments suggestions, some of which just editorial (picky mode on).
Before going into the details I also have a general comment.

I was hoping that the SFC text was covering services spanning multiple sites, but indeed I guess it shouldn't. This leaves the distributed sites scenario uncovered.
With Cloud RAN it will be very likely to have an IETF network slice being used for a 5G Slice where the RU is at the antenna site, the DU/vDU in a different site and CU/vCU and Core functions yet at different sites. I wonder how the network slice would be built in this scenario, maybe in a sort of "drop and continue" with multiple intermediate SDP ? Maybe the concept of sequential composition applies?
Cloud RAN is just an example and the scenario applies to many other types of applications.
It would be something like.

SDP(antenna site) --------NW------------SDP(site where the DU is deployed)--------NW----------SDP (site there the CU is deployed)-------------NW---------------SDP (core network)

Actually at each site there could be a pair of SDPs, one being the receiving SDP from the previous site and the other being the sending SDP towards the next site. How would the slice be built here? A single e2e slice? Multiple sequentially composed slices?

Other comments:

  *   Section 2 - You might want to add SLE here.
  *   Section 2.1 - It would be great to have a short definition of IETF Network Slice and IETF Network Slice Service here (together with all the others) and then refer to 3.1 and 3.2 for more details. This could be an example "An IETF Network Slice service is specified in terms of a set of SDPs, the associated connectivity constructs and the service objectives that the customer wishes to see fulfilled." And the network slice definition could be (quoting the intro) : "A network connections that, along with connectivity, provides assurance of meeting a specific set of objectives with respect to network resources use.  This connectivity and resource commitment is referred to as a network slice and is expressed in terms of connectivity constructs  and service objectives."
  *   Section 3 - Why definition of IETF network slice (section 3.1) and IETF Network Slice Service (section 3.2) fall into section 3, which describe the objectives of a network slice? Moreover Section 3.1 introduces the definition of IETF Network slice and it starts with "An IETF network slice service..." , mixing network slice and network slices many times in the text. This might be confusing.
  *   Section 3.1 - In the first paragraph I would suggest to add a reference to section 4.1 where SLI, SLO e SLE are defined. We can't wait till page 12 to know who the murder is...
  *   Section 3.2 - Connectivity construct: it is stated that a NS service may be limited to one connectivity construct or may support many. What is the advantage of supporting different constructs in a NS service as opposed to having one NS service per connectivity construct? Usually different connectivity constructs also have different requirements (e.g. a P2P vs P2MP). Combining them reduces the number of NS services in the network but also make its LCM much more complex.
  *   Section 3.2 - P2P Connectivity construct. "there is one sending SDP and one receiving SDP." This implies unidirectionality (which is fine). Could we add a statement saying that bidirectional P2P connectivity is also foreseen and can be achieved via a pair of unidirectional connections? It is said below in the list of various network realizations indeed...
  *   Section 3.2 s/ operating in in/operating in
  *   3.2.1. I'm not sure I fully understand the concept of ancillary SDP. Adding and removing SDPs to a slice should be part of normal LCM. What am I missing?
  *   Section 4.1 - I know it's too late to change this but we already had terms for SLI and SLO in PCE. Aren't SLI = Objective functions and SLO = Metric bounds?
  *   Section 4.1 - The text regarding SLE is a bit confusing, luckily section 4.1.2.1 clarifies it via examples. How about saying something like the SLEs are characteristics of the slice that the customer can't measur himself but that must trust the operator to implement them (e.g. diversity, isolation o geographical restrictions).
  *   Section 4.2 - is the SDP part of the connectivity construct or not? In section 4.2 we have "the IETF Network Slice service is composed of a set of one or more connectivity constructs that describe connectivity between the Service Demarcation Points (SDPs) across the underlay" which would lead to think that the connectivity construct connects the SDPs, while the definition of connectivity construct says "A set of SDPs together with a communication type that defines how traffic flows between the SDPs." Which seems to say that the SDP is part of the connectivity construct.
  *   Section 4.2 bullet 4 - If you remove the text within the brackets (which should be possible) the text doesn't make sense any longer. I would suggest to drop them and have "...according to information like for example the source and destination IP addresses, payload protocol or port numbers, in order to place it onto an IETF Network Slice"
  *   Section 4.3 - wouldn't it be better to call it IETF Network Slice composition?
  *   Section 5.2 - s/who,in turn, use/who,in turn, uses
  *   Section 6.1 - The NRP is build top-down or bottom-up? The test says: "   One or more connectivity constructs from one or more slices are mapped to a set of network resources called a Network Resource Partition (NRP)." The stream followed in the architecture goes bottom-up, starting from the physical network up to the network slice (figure 4). I would expect the NRP to but built from the filter topology, while the text starts from the network slice. Probably it would be more clear to say how the NRP is built from the Filter topology and then how the slice it mapped against it. Also, there is no crisp definition of the NRP (I can't find it drowned in the text).
  *   Still regarding the NRP, the closest thing to a definition is: "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." In what is it different from a filter topology? Is it a further step of filtering?

Cheers,
Daniele

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Fri, 25 Mar 2022 21:56:08 +0100

Hi Adrian, and all

I went as well once again through the entire text. v09 looks very good. Thank you.

I have couple of comments:

Section 2

There are much more abbreviations used in the doc. For example:

SLE
SDP

Section 2.1

"Each SDP must have a unique identifier (e.g., an IP address or MAC address) within a given IETF Network Slice service and may use the same identifier in multiple IETF Network Slice services."

Is some sort of 'node-id + AC-ID' (port-ID, interface-ID, ...) a valid 'unique identifier' in above definition? Many times, neither IP nor MAC is used to define end-point (SDP). Typical example is P2P service (pseudowire) that carries all traffic 'from left to right', without identifying the end-point via IP or MAC.

Section 4.1.1.1

Regarding availability, IMHO, more precise definition would be needed. 3 simple examples:

a) Service A: service not available over single period of 1 second every 10 days
b) Service B: service not available over single period of 10 seconds every 100 days
c) Service C: service not available over single period of 100 seconds every 1000 days

Is the availability for all above services the same, and equal to 99.993%? I could easily imagine some service sustaining 1 sec downtime every 10 days, but not sustaining 10 sec outage (every 100 days)

So, IMHO, availability should be:

a) coupled with the time period, over which the availability is defined/measured
b) specifying maximum allowed single period of downtime

Section 4.1.2.1

I am not sure, why 'Maximal Occupancy Level' cannot be measured by the customer. If the service is for example maximized to 10 IP addresses, it is quite easy for the customer to start traffic towards 11 IP addresses, and verify if all traffic goes through.

Another example is for SLE is:

Link type restrictions: A customer may request that certain link types (for example satellite links, mWave links, ...) are excluded/included when the provider routes traffic for the IETF Network Slice service. 

Whether or not the provider has met this SLE is generally not directly observable by the customer and cannot be measured as a quantifiable metric.

Section 5.3.1

In 5G the 'higher level operation system' is often referred to as SMO (Service Management & Orchestration). Might be SMO could be mentioned as an example?

Section 7:

I am not quite sure, what is the aim, how the customer will express the intend here? Will the architecture document define some 'isolation grades' ('isolation levels', whatever is the good term)? I.e. something like that

'isolation level A' - zero impact from other slices
'isolation level B' - minimal impact from other slices (impact within SLO limits)
'isolation level C' - medium impact from other slices (rare occasions of exceeding SLO limits) 
'isolation level D' - ....

Otherwise, how the customer will express the expectations regarding isolation, without pointing to realization? Also, customer specifies SLO, so why customer should bother about isolation at all? Isn't it internal thing to provider to decide, what sort of isolation techniques to use to ensure requested SLO is achieved?

Thank you,
Krzysztof

> On 2022 -Mar-25, at 17:12, Daniele Ceccarelli <daniele.ceccarelli=[email-masked]> wrote:
> 
> Hi Adrian, all,
>  
> i reviewed the draft once again like if it was an early routing area directorate review…and here are some more comments suggestions, some of which just editorial (picky mode on).
> I was hoping that the SFC text was covering services spanning multiple sites, but indeed I guess it shouldn’t. This leaves the distributed sites scenario uncovered.
> With Cloud RAN it will be very likely to have an IETF network slice being used for a 5G Slice where the RU is at the antenna site, the DU/vDU in a different site and CU/vCU and Core functions yet at different sites. I wonder how the network slice would be built in this scenario, maybe in a sort of “drop and continue” with multiple intermediate SDP ? Maybe the concept of sequential composition applies?
> Section 2 – You might want to add SLE here.
> Section 2.1 – It would be great to have a short definition of IETF Network Slice and IETF Network Slice Service here (together with all the others) and then refer to 3.1 and 3.2 for more details. This could be an example “An IETF Network Slice service is specified in terms of a set of SDPs, the associated connectivity constructs and the service objectives that the customer wishes to see fulfilled.” And the network slice definition could be (quoting the intro) : “A network connections that, along with connectivity, provides assurance of meeting a specific set of objectives with respect to network resources use.  This connectivity and resource commitment is referred to as a network slice and is expressed in terms of connectivity constructs  and service objectives.”
> Section 3 – Why definition of IETF network slice (section 3.1) and IETF Network Slice Service (section 3.2) fall into section 3, which describe the objectives of a network slice? Moreover Section 3.1 introduces the definition of IETF Network slice and it starts with “An IETF network slice service…” , mixing network slice and network slices many times in the text. This might be confusing.
> Section 3.1 – In the first paragraph I would suggest to add a reference to section 4.1 where SLI, SLO e SLE are defined. We can’t wait till page 12 to know who the murder is…
> Section 3.2 – Connectivity construct: it is stated that a NS service may be limited to one connectivity construct or may support many. What is the advantage of supporting different constructs in a NS service as opposed to having one NS service per connectivity construct? Usually different connectivity constructs also have different requirements (e.g. a P2P vs P2MP). Combining them reduces the number of NS services in the network but also make its LCM much more complex. 
> Section 3.2 – P2P Connectivity construct. “there is one sending SDP and one receiving SDP.” This implies unidirectionality (which is fine). Could we add a statement saying that bidirectional P2P connectivity is also foreseen and can be achieved via a pair of unidirectional connections? It is said below in the list of various network realizations indeed…
> Section 3.2 s/ operating in in/operating in
> 3.2.1. I’m not sure I fully understand the concept of ancillary SDP. Adding and removing SDPs to a slice should be part of normal LCM. What am I missing?
> Section 4.1 – I know it’s too late to change this but we already had terms for SLI and SLO in PCE. Aren’t SLI = Objective functions and SLO = Metric bounds?
> Section 4.1 – The text regarding SLE is a bit confusing, luckily section 4.1.2.1 clarifies it via examples. How about saying something like the SLEs are characteristics of the slice that the customer can’t measur himself but that must trust the operator to implement them (e.g. diversity, isolation o geographical restrictions).
> Section 4.2 – is the SDP part of the connectivity construct or not? In section 4.2 we have “the IETF Network Slice service is composed of a set of one or more connectivity constructs that describe connectivity between the Service Demarcation Points (SDPs) across the underlay” which would lead to think that the connectivity construct connects the SDPs, while the definition of connectivity construct says “A set of SDPs together with a communication type that defines how traffic flows between the SDPs.” Which seems to say that the SDP is part of the connectivity construct.
> Section 4.2 bullet 4 – If you remove the text within the brackets (which should be possible) the text doesn’t make sense any longer. I would suggest to drop them and have “…according to information like for example the source and destination IP addresses, payload protocol or port numbers, in order to place it onto an IETF Network Slice”
> Section 4.3 – wouldn’t it be better to call it IETF Network Slice composition?
> Section 5.2 – s/who,in turn, use/who,in turn, uses
> Section 6.1 – The NRP is build top-down or bottom-up? The test says: “   One or more connectivity constructs from one or more slices are mapped to a set of network resources called a Network Resource Partition (NRP).” The stream followed in the architecture goes bottom-up, starting from the physical network up to the network slice (figure 4). I would expect the NRP to but built from the filter topology, while the text starts from the network slice. Probably it would be more clear to say how the NRP is built from the Filter topology and then how the slice it mapped against it. Also, there is no crisp definition of the NRP (I can’t find it drowned in the text).
> Still regarding the NRP, the closest thing to a definition is: “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.” In what is it different from a filter topology? Is it a further step of filtering?
>  
> Cheers,
> Daniele  
>  
>  
>  
>  
>  
>  
>  
> _______________________________________________
> Teas mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teas <https://www.ietf.org/mailman/listinfo/teas>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Mar 2022 21:21:41 -0000

Hi Daniele,

> I reviewed the draft once again like if it was an early routing area

> directorate review…and here are some more comments suggestions,
> some of which just editorial (picky mode on).

Very many thanks for these comments.

> I was hoping that the SFC text was covering services spanning multiple
> sites, but indeed I guess it shouldn’t. This leaves the distributed sites
> scenario uncovered.

I’m puzzled by your comment. SFC is practically useless if the services are not found at different sites. That is, in essence the whole point of RFC 7665.

> With Cloud RAN it will be very likely to have an IETF network slice

> being used for a 5G Slice where the RU is at the antenna site, the
> DU/vDU in a different site and CU/vCU and Core functions yet at
> different sites. I wonder how the network slice would be built in
> this scenario, maybe in a sort of “drop and continue” with multiple
> intermediate SDP? Maybe the concept of sequential composition
> applies?

> Cloud RAN is just an example and the scenario applies to many

> other types of applications.

I think it might depend a lot on whether the service functions (RU, DU, CU) are at well-known places or whether these is some flexibility of choice.

You could, for example, have a slice with three P2P connectivity constructs as shown in your figure (marked NW).

> SDP(antenna site) ---NW---SDP(site where the DU is deployed)---NW---SDP (site there the CU is deployed)---NW---SDP (core network)

Or you might take an SFC approach if, for example, the DU is a vDU that could be present in several places. Then you would use an ancillary SDP to indicate that *a* vDU must be found, and you would specify the P2P connectivity construct from antenna to vDU, and another from vDU to CU.

> Actually at each site there could be a pair of SDPs, one being the receiving SDP

> from the previous site and the other being the sending SDP towards the next

> site.

Well, you *could* do this. Or you could use a single SDP at each service function.

It might depend on how you realize the SDPs for receive and send.

> How would the slice be built here? A single e2e slice? Multiple

> sequentially composed slices?

Recall that we are not in the business of delivering what 3GPP calls e2e slices. In their scope, we are delivering transport slices.

But whether you decide to have one slice with multiple connectivity constructs, or a set of slices is entirely your choice.

> - Section 2 – You might want to add SLE here.

Surely

> Section 2.1 – It would be great to have a short definition

> of IETF Network Slice and IETF Network Slice Service here

> (together with all the others) and then refer to 3.1 and

> 3.2 for more details. This could be an example 

> “An IETF Network Slice service is specified in terms of a set

> of SDPs, the associated connectivity constructs and the

> service objectives that the customer wishes to see fulfilled.”

> And the network slice definition could be (quoting the intro) : 

> “A network connections that, along with connectivity, provides

> assurance of meeting a specific set of objectives with respect

> to network resources use.  This connectivity and resource

> commitment is referred to as a network slice and is expressed

> in terms of connectivity constructs  and service objectives.”

I’m going to push back on this. While it is possible to give high-level descriptions (such as in Section 1) the definitions need to be more full and need more words. That would just mean that the whole of Section 3 was sucked in to Section 2.1. Placing Section 3 where it is (immediately after 2.1) means that it is fairly easy to find, and leaves 2.1 free to give some terms for context. 

> Section 3 – Why definition of IETF network slice (section 3.1) and
> IETF Network Slice Service (section 3.2) fall into section 3, which 
> describe the objectives of a network slice? 

It’s a good point. In fact, despite it’s title, Section 3 does not describe the objectives of a network slice and should be renamed “IETF Network Slice”

> Moreover Section 3.1 introduces the definition of IETF Network

> slice and it starts with “An IETF network slice service…” , mixing

> network slice and network slices many times in the text. This

> might be confusing.

It is a hard problem!

How to describe the network slice without mentioning the network slice service.

Similarly, how to describe the network slice service without mentioning the network slice.

But you have pointed up some overlap between the two sections that needs to be sorted out. So I will try to sort it out.

Indeed, on close inspection, there was quite a lot of text in 3.1 that belonged in 3.2, and some duplication.

> Section 3.1 – In the first paragraph I would suggest to add a reference

> to section 4.1 where SLI, SLO e SLE are defined. We can’t wait till page 

> 12 to know who the murder is… 

OK

> Section 3.2 – Connectivity construct: it is stated that a NS service may be limited

> to one connectivity construct or may support many. What is the advantage of 

> supporting different constructs in a NS service as opposed to having one NS

> service per connectivity construct? Usually different connectivity constructs

> also have different requirements (e.g. a P2P vs P2MP). Combining them reduces

> the number of NS services in the network but also make its LCM much more complex. 

Old discussion successfully re-opened 😊

You are mixing realization with customer interaction.

The customer may wish to specify a set of connectivity constructs that, when bundled, comprise the service they are contracting for. The provider may prefer to change the level of bundling and say “You are buying many services, and we bundle them in one contract.” Neither of these changes how the implementation in the network is achieved *unless* you want it to. Neither of these changes the resulting delivery of service as perceived by customer traffic.

Hence it is an option. 

The only complication I see this introducing is how the constructs are stacked in the YANG model.

> Section 3.2 – P2P Connectivity construct. “there is one sending SDP and 

> one receiving SDP.” This implies unidirectionality (which is fine). Could we

> add a statement saying that bidirectional P2P connectivity is also foreseen

> and can be achieved via a pair of unidirectional connections? It is said

> below in the list of various network realizations indeed…

Right. It is said below where other “service” types are also described. So, no, I don’t think we should call one of them out in the definitions of the three connectivity constructs, because then we would need to call them all out, and if we do that, we end up with some messy text.

As it is, we describe the three constructs and then we note the things that you can do with them.

> Section 3.2 s/ operating in in/operating in

Ack

> 3.2.1. I’m not sure I fully understand the concept of ancillary SDP. 

> Adding and removing SDPs to a slice should be part of normal LCM.

> What am I missing?

An ancillary SDP may be a node within the provider network (i.e., not a customer edge). An example is a node that provides a service function. Another example is a node that acts as a hub. There will be times when the customer wishes to explicitly select one of these.

Alternatively, an ancillary SDP may be a service function at an unknown point in the provider’s network. In this case, the function may be a placeholder that has its addressed resolved as part of the realization of the slice service.

The word “supplemented” does not necessarily imply a change in real time. It simply means that the set has things added to it.

> Section 4.1 – I know it’s too late to change this but we already had terms for

> SLI and SLO in PCE. Aren’t SLI = Objective functions and SLO = Metric bounds? 

No, not really. They are similar, but not the same. I’m not sure it would help anyone to reuse terminology, but then have to explain the differences.

> Section 4.1 – The text regarding SLE is a bit confusing, luckily section 4.1.2.1 clarifies

> it via examples. How about saying something like the SLEs are characteristics of the

> slice that the customer can’t measure himself but that must trust the operator to

> implement them (e.g. diversity, isolation o geographical restrictions).

With the exception of the examples, I think the first paragraph says exactly this.

I will add in the parenthetical text.

> Section 4.2 – is the SDP part of the connectivity construct or not? In

> section 4.2 we have “the IETF Network Slice service is composed of a
> set of one or more connectivity constructs that describe connectivity

> between the Service Demarcation Points (SDPs) across the underlay”
> which would lead to think that the connectivity construct connects
> the SDPs, while the definition of connectivity construct says “A set
> of SDPs together with a communication type that defines how traffic
> flows between the SDPs.” Which seems to say that the SDP is part of
> the connectivity construct. 

Do you own a hose pipe? Maybe for watering your garden or washing your dog/car/child.

Are the ends of the hose part of the hose? Does that change the fact that the hose connects the two ends?

> Section 4.2 bullet 4 – If you remove the text within the brackets
> (which should be possible) the text doesn’t make sense any longer.
> I would suggest to drop them and have “…according to information

> like for example the source and destination IP addresses, payload

> protocol or port numbers, in order to place it onto an IETF Network Slice”

Erm, I think it does make sense without the brackets. You would have

   4.  Finally, the SDP may be within the PE.  In this mode, the PE

       classifies the traffic coming from the AC according to

       information in order to place it onto an IETF Network Slice.

> Section 4.3 – wouldn’t it be better to call it IETF Network Slice composition? 

On the basis that “composition” is used more than “decomposition”, yes.

> Section 5.2 – s/who,in turn, use/who,in turn, uses

Ack

> Section 6.1 – The NRP is build top-down or bottom-up? The text says:

> “One or more connectivity constructs from one or more slices are

> mapped to a set of network resources called a Network Resource

> Partition (NRP).” 

> The stream followed in the architecture goes bottom-up, starting 

> from the physical network up to the network slice (figure 4).

The figure shows no ordering.

The text describes the steps, but then says…

   The steps described here can be applied in a variety of orders

   according to implementation and deployment preferences.

> I would expect the NRP to be built from the filter topology, while

> the text starts from the network slice.

I don’t think it does. It says that the slice is mapped to the NRP, but that does not imply that the NRP has not already been created from the filter topology.

Indeed, the last paragraph on p29 says “An NRP may be chosen…” which implies that it already exists.

> Probably it would be more clear to say how the NRP is built from the

> Filter topology and then how the slice it mapped against it.

You see, this is why I was hesitant about putting any of this stuff in the framework!

The job of the framework is not to tell you how to operate your network or how to implement your management system.

I think you are trying too hard to see the NRP as something very special as…

> Also, there is no crisp definition of the NRP (I can’t find it drowned

> in the text).

…it is hard to create something when you can’t see what it is 😊

But we have (as you note below)…

   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.

While that may not be crisp, I don’t think it is hidden or buried. Indeed, it is waving not drowning.

> Still regarding the NRP, the closest thing to a definition is: “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.” In what is it different

> from a filter topology? Is it a further step of filtering?

What does “filtering” mean?

As noted on page 29 it is the process of selecting nodes and links according to their capabilities. It produces topologies of nodes and links that achieve a certain common grade (such as is done when producing colored topologies). It is an optional step (as noted in the text) that may make the process of selecting resources into an NRP considerably easier.

Thanks for all the good discussions.

Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 25 Mar 2022 21:47:32 -0000

Hi again,

Thanks for this.

> SDP

Ack. In -10

> "Each SDP must have a unique identifier (e.g., an IP address
> or MAC address) within a given IETF Network Slice service and
> may use the same identifier in multiple IETF Network Slice services."

> Is some sort of 'node-id + AC-ID' (port-ID, interface-ID, ...) a 
> valid 'unique identifier' in above definition? Many times, 
> neither IP nor MAC is used to define end-point (SDP). 
> Typical example is P2P service (pseudowire) that carries
> all traffic 'from left to right', without identifying the
> end-point via IP or MAC.

Yes, “a unique identifier” includes *any* identifier that is unique.

It’s a solution engineering decision which things to use to form the identifier.

> Regarding availability, IMHO, more precise definition would be 

> needed. 3 simple examples:

> Is the availability for all above services the same, and equal to 99.993%? I could

> easily imagine some service sustaining 1 sec downtime every 10 days, but not
> sustaining 10 sec outage (every 100 days)

I would hate to impugn the customer service of my ISP, but this is exactly how they measure and report it.

Of course, different customers have more leverage in negotiating their SLAs.

> a) coupled with the time period, over which the availability is

>    defined/measured

> b) specifying maximum allowed single period of downtime

Folded this in for -10.

> I am not sure, why 'Maximal Occupancy Level' cannot be measured

> by the customer. If the service is for example maximized to 10 IP

> addresses, it is quite easy for the customer to start traffic towards

> 11 IP addresses, and verify if all traffic goes through.

Hence “may not be able to fully”.

I agree that some of this stuff sits on the line between SLO and SLE. I don’t want this document to arbitrate that distinction. If there are elements of a thing that are possibly not measurable, it is an SLE.

> Link type restrictions: A customer may request that certain link

> types (for example satellite links, mWave links, ...) are
> excluded/included when the provider routes traffic for the IETF

> Network Slice service. 

> Whether or not the provider has met this SLE is generally not
> directly observable by the customer and cannot be measured
> as a quantifiable metric.

Indeed.

It’s not our objective here to list all SLOs and SLEs.

This one was briefly discussed before and it quickly led on to “vendor types”.

We found that even mentioning “geographic restrictions” got some people very, very nervous. Mentioning “vendor types” obviously worries people even more.

In practice, of course, it is highly likely that both “link type” and “vendor type” will be SLEs in a number of contracts.

Do we need to include them in this document?

> In 5G the 'higher level operation system' is often referred to as

> SMO (Service Management & Orchestration). Might be SMO

> could be mentioned as an example?

Do you have a reference for that I could use?

> I am not quite sure, what is the aim, how the customer will

> express the intend here? Will the architecture document define

> some 'isolation grades' ('isolation levels', whatever is the good

> term)? I.e. something like that

> 'isolation level B' - minimal impact from other slices (impact 

> within SLO limits)

> 'isolation level C' - medium impact from other slices (rare

> occasions of exceeding SLO limits) 

> Otherwise, how the customer will express the expectations
> regarding isolation, without pointing to realization? Also, 

> customer specifies SLO, so why customer should bother about

> isolation at all? Isn't it internal thing to provider to decide, what

> sort of isolation techniques to use to ensure requested SLO is

> achieved?

Somewhat re-opening an old discussion.

1.	How the isolation SLE is expressed is an interesting discussion, but fortunately not one for this document.
2.	You mentioned, above, an SLE for link types. But surely the customer only cares that their SLOs are met, not which types of link are used? If the SLOs are well-enough spec’d then the operator can choose any links so long as the SLOs are met.
3.	With isolation, the customer may want more than “meet my SLOs.” They might want, “and don’t let me notice the impact of other services even if my SLOs are still being met.”
4.	An example to think about is how a financial institution may contract to have their traffic carried by a service provider. They might put in place very stringent SLOs (and penalties) that force the provider to use isolation. Or they might insist on isolation.
5.	Another example to think about is government organisations that not only demand SLOs, but demand that their traffic is isolated from the traffic of the common people.

Cheers,

Adrian

---

From: <[email-masked]>
Date: Mon, 28 Mar 2022 07:36:03 +0000

Hi Daniele, All,

(focusing on the SFC part)

The current SFC text does not make an assumption about where the functions will be provided (same or distinct sites). The exact location will be decides as per the following step in Section 6.6 of the framework:

==
   *  Execute an SF placement algorithm to decide where to locate the
      ancillary SDPs in order to fulfil the service objectives.
===

Cheers,
Med

De : Teas <[email-masked]> De la part de Adrian Farrel
Envoyé : vendredi 25 mars 2022 22:22
À : 'Daniele Ceccarelli' <daniele.ceccarelli=[email-masked]>; 'TEAS WG' <[email-masked]>
Objet : Re: [Teas] Review of draft-ietf-teas-ietf-network-slices-09

Hi Daniele,

_________________________________________________________________________________________________________________________

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: Krzysztof Szarkowicz <[email-masked]>
Date: Mon, 28 Mar 2022 10:41:32 +0200

Hi Adrian,

Thanks for updating -10 with some of my comments.

Please see as well inline.

Thanks,
Krzysztof

> On 2022 -Mar-25, at 22:47, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi again,
>  
> Thanks for this.
>  

[Krzysztof] Ack

> Do we need to include them in this document?

[Krzysztof] Ack. These are just some examples, so don’t need to be included in the doc.

> Do you have a reference for that I could use?

[Krzysztof] https://orandownloadsweb.azurewebsites.net/specifications <https://orandownloadsweb.azurewebsites.net/specifications>, -> O-RAN.WG1.Slicing-Architecture-v06.00. SMO is responsible for overall slice management in RAN, including requests towards transport domain to create transport slices between RAN components.

> How the isolation SLE is expressed is an interesting discussion, but fortunately not one for this document.
> You mentioned, above, an SLE for link types. But surely the customer only cares that their SLOs are met, not which types of link are used? If the SLOs are well-enough spec’d then the operator can choose any links so long as the SLOs are met.
> With isolation, the customer may want more than “meet my SLOs.” They might want, “and don’t let me notice the impact of other services even if my SLOs are still being met.”

[Krzysztof] If the SLOs are meet, then customer didn’t noticed impact of other services, IMHO. Otherwise, how the customer notices the impact?
> An example to think about is how a financial institution may contract to have their traffic carried by a service provider. They might put in place very stringent SLOs (and penalties) that force the provider to use isolation. Or they might insist on isolation.
> Another example to think about is government organisations that not only demand SLOs, but demand that their traffic is isolated from the traffic of the common people.

[Krzysztof] OK, so more detailed definition of ‘isolation SLE’ is out of scope for this doc. It would be interesting to see the discussion, how this SLE can be expressed by the customer, without pointing to realization (i.e., without saying ‘use dedicated links for my slice’, or ‘use dedicated lambdas in DWDM for my slice’, or ‘use dedicated queues for my slice’, ‘use dedicated VPN for my slice’, etc.). Or, it is just binary (‘isolated’, ’not isolated) SLE, living the decision to the operator, what does it mean ’isolated’ from the realization perspective (operator might say, if the SLOs are meet, it means the service is ‘isolated’, regardless what is the realization).

---

From: Daniele Ceccarelli <[email-masked]>
Date: Mon, 28 Mar 2022 13:40:03 +0000

Hi Adrian,

Please see inline (snipping agreed parts to try to help readability).
I’ll reply later to Med’s email on SFC so that people only interested in that part can follow that thread only.

Cheers
Daniele

From: Adrian Farrel <[email-masked]>
Sent: den 25 mars 2022 22:22
To: Daniele Ceccarelli <[email-masked]>; 'TEAS WG' <[email-masked]>
Subject: RE: [Teas] Review of draft-ietf-teas-ietf-network-slices-09

Hi Daniele,

But whether you decide to have one slice with multiple connectivity constructs, or a set of slices is entirely your choice.
[DC] See separate reply to Med.

> Other comments:
[DC] [snip]

I’m going to push back on this. While it is possible to give high-level descriptions (such as in Section 1) the definitions need to be more full and need more words. That would just mean that the whole of Section 3 was sucked in to Section 2.1. Placing Section 3 where it is (immediately after 2.1) means that it is fairly easy to find, and leaves 2.1 free to give some terms for context.
[DC] v10 addresses all of my issues, the new arrangement of the paragraphs as:
3. IETF Network Slice
3.1 Definition and Scope of IETF NS
3.2 IETF network slice service

Plus the text added helps a lot understanding what is what. Issue cleared.

[DC] [snip]

Hence it is an option.

The only complication I see this introducing is how the constructs are stacked in the YANG model.
[DC] OK. Maybe it could be helpful to say it explicitly, what about:

OLD
Note that a service
   provider may decide how many connectivity constructs per IETF Network
   Slice service it wishes to support such that an IETF Network Slice
   service may be limited to one connectivity construct or may support
   many.
NEW

Note that different connectivity constructs can be specified in the service request but the service

   provider may decide how many connectivity constructs per IETF Network

   Slice service it wishes to support such that an IETF Network Slice

   service may be limited to one connectivity construct or may support

   many.

[DC] [snip]

The word “supplemented” does not necessarily imply a change in real time. It simply means that the set has things added to it.
[DC] why didn’t you explain like this in the text? Now it’s clear, before it wasn’t 😃

[DC] [snip]

Do you own a hose pipe? Maybe for watering your garden or washing your dog/car/child.
Are the ends of the hose part of the hose? Does that change the fact that the hose connects the two ends?
[DC] I’ll try to wash my daughter with a hose pipe…but I’m not sure she’ll be super happy about that…
The fact that the ends are part of the pipe doesn’t change the fact that water is delivered but changes the definition of pipe.
I’m not sure we can say that LERs can be considered part of the LSP as long as traffic flows…

[DC] According to which information? Does it really make sense? Luckily I can claim English is not my mother language

[DC] [snip]

   The steps described here can be applied in a variety of orders
   according to implementation and deployment preferences.
[DC] this is right. I can create an LSP and then a L3VPN on top of it or create a L3VPN and then put it on top of an LSP.

I think you are trying too hard to see the NRP as something very special as…
[DC] you’re right. Non something in particular but to something that already exist. We need examples here. If we don’t we’ll keep on having readers believing that and NRP is e.g. a LxVPN and readers believing that it is e.g. a TE tunnel. Both could be right o wrong. Not saying what it can be is potentially more harmful than helpful.

[DC] thanks to you
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 28 Mar 2022 21:52:09 +0100

Thanks Krysztof,

[snip]

[Krzysztof] https://orandownloadsweb.azurewebsites.net/specifications, -> O-RAN.WG1.Slicing-Architecture-v06.00. SMO is responsible for overall slice management in RAN, including requests towards transport domain to create transport slices between RAN components.

OK. I’ll go and read that. 

Suppose I have a regular order with my baker to deliver three bread rolls to my house every morning.

Every day, my baker (who is a nice lady) delivers four bread rolls.

One day, however, I have a new neighbour and I notice that I only receive three rolls in the morning.

Then my neighbour goes on vacation and cancels their order and I notice that I start receiving four rolls again.

My SLO is being met all through this, but I have noticed an impact because of my neighbour.

There may be a learning moment for the service provider to never over-deliver on an SLO.

3.	 

Yes, that will be interesting to observe. What you have described in your “id est” is known as “hard slicing” (although, since the customer doesn’t know about the underlay technology, they are likely to say ‘use dedicated resources’). I believe that there is a spectrum (hard to soft) and it may be this spectrum that is expressed.

You may find the discussion in section 3.2 of draft-ietf-teas-enhanced-vpn to be enlightening.

Cheers,

Adrian

---

From: Krzysztof Szarkowicz <[email-masked]>
Date: Thu, 31 Mar 2022 18:34:36 +0200

Hi Adrian,

Please see inline.

Cheers,
Krzysztof

> On 2022 -Mar-28, at 22:52, Adrian Farrel <[email-masked]> wrote:
> 
> Thanks Krysztof,
>  
> [snip]
>  
>> > Section 5.3.1
>> > 

[Krzysztof] Not sure, how it applies to the slice service. Assume, I ordered (paying $) the slice service with CIR/PIR=1Gbps/2Gbps. Based on my observations, I always stay with 1Gbps/2Gbps limits, so my requested SLO is fulfilled. Even if the SP has available capacity to serve my slice service e.g. with 3Gbps, there is no incentive from SP to do it, as likely there is next level of the service (priced at $$ level, instead of $), where I can achieve 3Gbps. So, instead of giving 3Gbps for free, the SP goal would be to let me pay $$ to get 3Gbps.

> You may find the discussion in section 3.2 of draft-ietf-teas-enhanced-vpn to be enlightening.

[Krzysztof] Yes, I know the enhanced-vpn draft. Saying that, I still don’t see how the customer will formulate the isolation requirements to SP, without pointing to realization. I.e., do we expect to define ‘hard’, ‘mid-hard’, ‘mid-soft’ or ’soft’ (or whatever.) isolation grades (draft says: “A customer may request different degrees of isolation ranging from soft isolation to hard isolation.", and define exactly what these grades mean (without pointing to realization)?

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 31 Mar 2022 12:43:20 -0400

I hope I misread the below.  Top posting what I understood.

There seems to be a discussion about an impact on SLO due to sometimes 
getting more service than I asked for.  My understanding of SLOs is
a) the provider would be perfectly within their rights to police the 
customer to within the bandwidth commitment.)
b) If you want to restrict the service from giving you better service, 
you include that in the SLO.  For example, one can have both a delay 
bounn and a delay variation bound.
So I do not see what problem is being discussed.

then there is a digression into hard and soft slicing.  To the degree 
that is still in the VPN+ drafts, I consider that a problem for that 
draft.  the service is defined in terms of the observables and 
specifiables.  Hard slicing is neither.  It does not even rise to the 
level of an SLE, as it is not a well-defined expectation.  We should 
simply stay away from it.

Yours,
Joel

On 3/31/2022 12:34 PM, Krzysztof Szarkowicz wrote:
> Hi Adrian,
> 
> Please see inline.
> 
> Cheers,
> Krzysztof
> 
> 
>> On 2022 -Mar-28, at 22:52, Adrian Farrel <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Thanks Krysztof,
>> [snip]
>>> > Section 5.3.1
>>> >
>> [Krzysztof] https://orandownloadsweb.azurewebsites.net/specifications 
>> <https://orandownloadsweb.azurewebsites.net/specifications>, 
>> -> O-RAN.WG1.Slicing-Architecture-v06.00. SMO is responsible for 
>> overall slice management in RAN, including requests towards transport 
>> domain to create transport slices between RAN components.
>>
>>>  1. How the isolation SLE is expressed is an interesting discussion,
>>>     but fortunately not one for this document.
>>>  2. You mentioned, above, an SLE for link types. But surely the
>>>     customer only cares that their SLOs are met, not which types of
>>>     link are used? If the SLOs are well-enough spec’d then the
>>>     operator can choose any links so long as the SLOs are met.
>>>  3. With isolation, the customer may want more than “meet my SLOs.”
>>>     They might want, “and don’t let me notice the impact of other
>>>     services even if my SLOs are still being met.”
>> [Krzysztof] If the SLOs are meet, then customer didn’t noticed impact 
>> of other services, IMHO. Otherwise, how the customer notices the impact?
>> Then my neighbour goes on vacation and cancels their order and I 
>> notice that I start receiving four rolls again.
> [Krzysztof] Not sure, how it applies to the slice service. Assume, I 
> ordered (paying $) the slice service with CIR/PIR=1Gbps/2Gbps. Based on 
> my observations, I always stay with 1Gbps/2Gbps limits, so my requested 
> SLO is fulfilled. Even if the SP has available capacity to serve my 
> slice service e.g. with 3Gbps, there is no incentive from SP to do it, 
> as likely there is next level of the service (priced at $$ level, 
> instead of $), where I can achieve 3Gbps. So, instead of giving 3Gbps 
> for free, the SP goal would be to let me pay $$ to get 3Gbps.
> 
>>>  4. An example to think about is how a financial institution may
>>>     contract to have their traffic carried by a service provider.
>>>     They might put in place very stringent SLOs (and penalties) that
>>>     force the provider to use isolation. Or they might insist on
>>>     isolation.
>>>  5. Another example to think about is government organisations that
>>>     not only demand SLOs, but demand that their traffic is isolated
>>>     from the traffic of the common people.
>> [Krzysztof] OK, so more detailed definition of ‘isolation SLE’ is out 
>> of scope for this doc. It would be interesting to see the discussion, 
>> how this SLE can be expressed by the customer, without pointing to 
>> realization (i.e., without saying ‘use dedicated links for my slice’, 
>> or ‘use dedicated lambdas in DWDM for my slice’, or ‘use dedicated 
>> queues for my slice’, ‘use dedicated VPN for my slice’, etc.). Or, it 
>> is just binary (‘isolated’, ’not isolated) SLE, living the decision to 
>> the operator, what does it mean ’isolated’ from the realization 
>> perspective (operator might say, if the SLOs are meet, it means the 
>> service is ‘isolated’, regardless what is the realization).
>>
>> Yes, that will be interesting to observe. What you have described in 
>> your “id est” is known as “hard slicing” (although, since the customer 
>> doesn’t know about the underlay technology, they are likely to say 
>> ‘use dedicated resources’). I believe that there is a spectrum (hard 
>> to soft) and it may be this spectrum that is expressed.
>> You may find the discussion in section 3.2 of 
>> draft-ietf-teas-enhanced-vpn to be enlightening.
> 
> [Krzysztof] Yes, I know the enhanced-vpn draft. Saying that, I still 
> don’t see how the customer will formulate the isolation requirements to 
> SP, without pointing to realization. I.e., do we expect to define 
> ‘hard’, ‘mid-hard’, ‘mid-soft’ or ’soft’ (or whatever.) isolation grades 
> (draft says: “A customer may request different degrees of isolation 
> ranging from soft isolation to hard isolation.", and define exactly what 
> these grades mean (without pointing to realization)?
> 
>> Cheers,
>> Adrian
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas