Re: [Teas-ns-dt] Appendix text on isolation

["Dongjie (Jimmy)" <[e-mail]>]

Hi Kiran,

On the conference call yesterday, I also raised a comment about confidence level, according to the discussion on the meeting, it seems availability as defined in this draft and confidence level have similar meaning, thus we may use availability (or availability level?) through the document.

As for isolation, based on Jari’s text, I suggested to describe it from requirement and realization’s perspective separately, and also consider the different dimensions of isolation.

From requirement’s perspective, isolation can mean: 1) traffic separation and 2) interference avoidance. The second is related to providing committed SLOs (avoiding the impacts from misbehaving customers or users).

Accordingly, from realization’s perspective, 1) traffic separation can be provided by VPNs, and 2) interference avoidance can be provided by the mechanisms listed in Jari’s text: capacity planning, priority, policing, shaping, selecting dedicated resource.

Based on yesterday’s conference call, it is agreed that some text on isolation will be kept in this draft, while it was not discussed in which section to put that text. As this document will not going into details about realization, my personal understanding is maybe a subsection in section 4 would be appropriate.

And please see some comments to your suggested text inline:

From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of Kiran Makhijani
Sent: Tuesday, June 16, 2020 10:29 AM
To: Jari Arkko <[e-mail]>om>; [e-mail]
Subject: Re: [Teas-ns-dt] Appendix text on isolation

Hi Jari,
Thank you! This is better.
Somehow the text on confidence level and isolation are getting mixed up. This doesn’t seem right. I am wondering if we can remove the last paragraph or rephrase as shown below.
I am also wondering if we should add brief text on isolation (maybe in realization section)?

Transport slices are perceived as if the services provisioned by a
customer were running on a dedicated network. To achieve this a set of
SLOs are described. The committed SLOs for a given customer should be
maintained during the service life-time even in the face of potential
disruptions.  Such disruptions include sudden traffic volume changes,
equipment failures in the service provider network, misbehaving
customers or users (e.g., by injecting more traffic than initially
declared), or attacks.

The service provider needs to ensure that their network can provide
the requested services at the level and confidence level agreed upon
with the customers. In general, there are many ways to do this, both
technical and business-oriented. Some of the main technical approaches
to respecting guarantees are about network planning, managing
capacity, priority mechanisms, policing or shaping customer traffic,
selecting dedicated resources, and so on.

One term that has commonly been also used in this context is
"isolation". This is discussed further in the framework draft
[I-D.nsdt-teas-ns-framework] and has also been a topic in
[I-D.ietf-teas-enhanced-vpn].

The term “isolation” implies in part traffic separation
(a common feature in VPNs) and in part the selection
of dedicated resources. Dedicated resources can help
assure that, for instance, traffic in other slices does not affect a
this slice. However, it should also be noted that this is one
particular realization of a requirement for guarantees, and other
mechanisms may also be used, such as priority mechanisms or
policing amount of traffic entering a link from different sources.

It should  also be noted that neither
dedicated resources or the other mechanisms can
provide a 100% guarantee against problems. Equipment failures,
for instance, can prevent the resources from being used. When
very high level of confidence is needed that a guarantee can be
maintained, additional techniques such as redundancy are needed.

[KM]
Service providers may also need to ensure that their network can provide
the requested service  with a certain level of confidence that were agreed upon with the customers.
There are many ways to do this, both technical and business-oriented.
Technical means to improve confidence level may include isolation as described above. Additionally,
to maintain protection against resource and equipment failures techniques such as redundancy are needed.

[Jie] Is it needed to have business-oriented mentioned in this draft? Perhaps you mean the level of guarantee/confidence needs to be expressed in business-oriented approach to the customer?


Best regards,
Jie


Thanks
Kiran

From: Jari Arkko <[e-mail]<mailto:[e-mail]>>
Sent: Monday, June 15, 2020 5:47 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Kiran Makhijani <[e-mail]<mailto:[e-mail]>>
Subject: Appendix text on isolation

I had promised some suggestions on how to change the text on isolation.
This is not a proposal about where the text is, but is an attempt to discuss
an important term and provide an accurate description of characteristics
associated with it.

OLD:
Transport slices are perceived as if the services provisioned by a
customer were running on a dedicated network. To achieve this a set of
SLOs are described. The committed SLOs for a given customer should be
maintained along the service life-time even when other customers'
networks could misbehave (e.g., by injecting more traffic than
initially declared). In some cases, a customer could explicitly ask
effective isolation in the sense of strict dedication of some
resources because of the nature of the service (e.g., mission critical
emergency services). Two situations can motivate the introduction of
isolation as proposed:

* SLO commitments: Providing such kind of guarantees in a shared
  network infrastructure to exploit statistical multiplexing gains is
  not always achievable, despite the mechanisms availble in some cases
  to enforce such guarantees: traffic shaping mechanisms, hierarchical
  queuing, traffic engineering, over-dimensioning of the network
  capacity, etc.

* Dedicated resource reservation: Reasons for such situations are not
  solely related to performance, but others such as security, service
  continuity, service specialization, etc. The resource reservation
  and dedication does not imply that the same specific and concrete
  resources are devoted for a customer, but that the same kind of
  resources are maintained for that customer along the service
  lifetime.

In this way, customers can request isolation as an additional
attribute for the transport slice. Depending on the specific level of
isolation requested, the implementation could take different forms,
such as diversity on transport network routes (topological isolation),
allocation of certain transport capabilities (data plane isolation),
etc. The actual implementation of isolation is out of the scope of
this document.

NEW:

Transport slices are perceived as if the services provisioned by a
customer were running on a dedicated network. To achieve this a set of
SLOs are described. The committed SLOs for a given customer should be
maintained during the service life-time even in the face of potential
disruptions.  Such disruptions include sudden traffic volume changes,
equipment failures in the service provider network, misbehaving
customers or users (e.g., by injecting more traffic than initially
declared), or attacks.

The service provider needs to ensure that their network can provide
the requested services at the level and confidence level agreed upon
with the customers. In general, there are many ways to do this, both
technical and business-oriented. Some of the main technical approaches
to respecting guarantees are about network planning, managing
capacity, priority mechanisms, policing or shaping customer traffic,
selecting dedicated resources, and so on.

One term that has commonly been also used in this context is
"isolation". This is discussed further in the framework draft
[I-D.nsdt-teas-ns-framework] and has also been a topic in
[I-D.ietf-teas-enhanced-vpn].

The term “isolation” implies in part traffic separation
(a common feature in VPNs) and in part the selection
of dedicated resources. Dedicated resources can help
assure that, for instance, traffic in other slices does not affect a
this slice. However, it should also be noted that this is one
particular realization of a requirement for guarantees, and other
mechanisms may also be used, such as priority mechanisms or
policing amount of traffic entering a link from different sources.

It should  also be noted that neither
dedicated resources or the other mechanisms can
provide a 100% guarantee against problems. Equipment failures,
for instance, can prevent the resources from being used. When
very high level of confidence is needed that a guarantee can be
maintained, additional techniques such as redundancy are needed.