[Teas-ns-dt] Appendix text on isolation

[Jari Arkko <[e-mail]>]

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.