Re: [Teas-ns-dt] Suggested new text for the isolation part and related characteristics

[Kiran Makhijani <[e-mail]>]

I have incorporated the suggestions along with a few editorial changes. It also has newer text for my own clarity – the discussions we had on two kinds of isolation. It makes this section a bit lengthy – but improvements at a later time will be made.
Thanks
Kiran

From: Jari Arkko <[e-mail]>
Date: Monday, March 9, 2020 at 6:42 AM
To: Kiran Makhijani <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Suggested new text for the isolation part and related characteristics

I’d like to suggest the following text as a change c to current definitions document discussion on isolation. This text casts isolation as a characteristic that can be requested, along with resource redundancy and other characteristics. It is a requirement level issue rather than a specific way to implement isolation.



4.1.  Service Level Objectives on Transport Slice

   A transport slice is defined ...

   A non-exhaustive list of characteristics types for transport slice is
   described below:

   o  Guaranteed Bandwidth: assurance of minimum or range of the
      bandwidth requirement.  Requested unidirectionally.

   o ...

   o  Packet loss rate: To specify permissible packet loss rate between
      two endpoints.  For critical networks, this number may be very
      close to zero.  See [RFC7680].
      Bandwidth guarantees come in two variants:

   o The above characteristics can be specified as hard limits and not
      affected by other traffic or as soft. In a soft limit, a
      violation of the limit may occur in rare cases due to resource
      interference.  In such cases, the limit will be maintained by
      the controller within a certain tolerance level of that
      objective.

      Note that specifying a hard limit will not prevent failures --
      such as losing a node -- from affecting the transport slice. Protection
      against such issues is possible, but needs to be specified separately
      (see item "resource redundancy" below).

      Note also that the hard and soft limits do not say anything
      about the specific implementation of how these limits are
      achieve. Different implementations might use different
      techniques, from avoiding oversubsription to dedicating
      particular links or their virtual fractions to particular
      transport slices.

   o ...

   o  etc.

   The framework may further specify ...

4.1.1.  Isolation

   Providing a hard limit for the characteristics of a transport slice
   means that the behavior and performance of other transport slices
   should not impact that slice, even if they run over the same underlying
   infrastructure or use logically shared network resources.

   Since the transport slices are logically partitioned over the
   shared resources, a certain degree of isolation is expected even
   when no hard limit has been specified.  When the shared resource
   pools begin to become saturated, SLO violations can happen,
   however, impacting the performance or operation of service
   associated with the transport slice.

   The degree of isolation can be derived from availability
   characteristics requested, such as whether a hard or soft limit was
   requested. Requesting a hard limit may commit more resources
   than would be required for a softer limit.

   When realizing a transport slice, the network controller should be
   responsible for allocating and providing resources according to the specified
   characteristics.

   SLO violations can occur for two reasons and corresponding statements
   apply

   o  Shared resource interference: i.e. multiple transport slices
      simultaneously share the same resource, and one of them consume
      the resource in surplus.  If the SLO guarantees are strictly
      required, then the network controller can be informed about the
      requirement using hard limit. Note that the terms hard and soft
      limit are requirement oriented and different from what is specified
      in, for instance,  [I-D.ietf-teas-enhanced-vpn]).

   o  Resource failure or fault occurs, such as a link or node failure.

       Where it is important to defend against these, the relevant
       characteristics on resoure redundancy (and perhaps some
       other characteristics on restoration speed and other factors) need to be specified.