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

(sorry, resending through gmail to avoid any confidential notice be default
in my main email account)

Hi Jari, all,

Apologies since I couldn’t attend the meeting yesterday. One further
comment on your proposed text.

You refer there to the fact that isolation is further discussed in the
framework document, but this is not the case by now (at least this is my
understanding), so either we introduce some discussion on the framework
document or we need to remove the reference by now.

Additionally, with respect to:

“It should also be noted that neither dedicated resources or the other

mechanisms can provide a 100% guarantee against problems.”

I think the same comment can apply to whatever SLOs such as throughput,
latency, jitter,… so, do we need to link it to isolation or it is actually
a generic aspect for the slice? If so, I would decouple it from isolation,
linking to the broader case of slice (--perception of a dedicated network
with specific SLOs).

Best regards

Luis

El mar., 16 jun. 2020 a las 10:26, Jari Arkko (<jari.arkko=
40ericsson.com@dmarc.ietf.org>) escribió:

> Here’s a suggested 2nd revision of the suggested text, based on
> yesterday’s comments on the call and Kiran’s email.
>
>
>
>
>
> Transport slices are perceived as if slice was provisioned for the
>
> customer as a dedicated network with specific SLOs. These committed
>
> SLOs for a given customer should be maintained during the life-time of
>
> the slice even in the face of potential disruptions.  Such disruptions
>
> include sudden traffic volume changes either from the customer itself
>
> or others, equipment failures in the service provider network, and
>
> various misbehaviors or attacks.
>
>
>
> The service provider needs to ensure that their network can provide
>
> the requested slices with the availability agreed with its
>
> customers. Some of the main technical approaches to
>
> ensuring 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 given 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.  To maintain
>
> protection against resource and equipment failures techniques such as
>
> redundancy are needed.
> --
> Teas-ns-dt mailing list
> Teas-ns-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>

-- 
___________________________________________
Luis M. Contreras
contreras.ietf@gmail.com
luismiguel.contrerasmurillo@telefonica.com
Global CTIO unit / Telefonica