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

From: Jari Arkko <[email-masked]>
Date: Mon, 15 Jun 2020 12:47:25 +0000

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.

---

From: Kiran Makhijani <[email-masked]>
Date: Tue, 16 Jun 2020 02:29:12 +0000

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)?

[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.

Thanks
Kiran

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

OLD:

NEW:

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 16 Jun 2020 06:50:09 +0000

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:[email-masked]] On Behalf Of Kiran Makhijani
Sent: Tuesday, June 16, 2020 10:29 AM
To: Jari Arkko <[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] Appendix text on isolation

Hi Jari,

[KM]

[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 <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 15, 2020 5:47 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>
Subject: Appendix text on isolation

OLD:

NEW:

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Jun 2020 07:25:30 +0000

Hi Kiran,

Thanks for this. Yesterday on the call there were also comments as Jie said, e.g., on confidence level. I have an action item to produce a revised proposal. I can now take your suggestions into that as well. Stay tuned.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Jun 2020 08:26:20 +0000

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.

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 16 Jun 2020 08:34:48 +0000

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

De: Teas-ns-dt <[email-masked]> En nombre de Jari Arkko
Enviado el: martes, 16 de junio de 2020 10:26
Para: [email-masked]
CC: Kiran Makhijani <[email-masked]>
Asunto: Re: [Teas-ns-dt] Appendix text on isolation

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: "Luis M. Contreras" <[email-masked]>
Date: Tue, 16 Jun 2020 10:37:16 +0200

(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.

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=
[email-masked]>) escribió:

> Here’s a suggested 2nd revision of the suggested text, based on
> yesterday’s comments on the call and Kiran’s email.
>
>
>
>
>
> --
> Teas-ns-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas-ns-dt
>

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Jun 2020 08:43:15 +0000

> 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 dec…

I’d be fine with that.

Jari

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 16 Jun 2020 10:15:18 +0000

Hi Jari,

Thanks for considering most of my comments in this revision.

And as mentioned yesterday and in my previous email, I’d like to suggest whether the description about isolation could be rephrased a bit, so as to better clarify the requirement and realization of isolation in different dimensions.

The term “isolation” can refer to multiple dimensions of requirements. A customer may ask for traffic separation or interference avoidance, or both. Accordingly, from realization’s perspective, traffic separation can be provided by VPNs, and interference avoidance can be provided by mechanisms such as capacity planning, priority mechanisms, policing or shaping, selecting dedicated resources, and so on.

Hope this helps.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Jari Arkko
Sent: Tuesday, June 16, 2020 4:26 PM
To: [email-masked]
Cc: Kiran Makhijani <[email-masked]>
Subject: Re: [Teas-ns-dt] Appendix text on isolation

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 17 Jun 2020 01:30:13 +0000

Hi Jie, and all,
One argument against using isolation as an SLO is that it is an implementation specific detail that customer should not have to (always) concern with. So I am not comfortable with the use of ‘multi-dimensional’.
One way to separate realization and customer requirement may be we can use business objective/case. May be we can add, one sentence  at the end of the original paragraph. What do you think?

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. Business objectives may require a customer
to ask for explicit traffic separation or interference avoidance mechanisms.

-Kiran

From: Dongjie (Jimmy) <[email-masked]>
Sent: Tuesday, June 16, 2020 3:15 AM
To: Jari Arkko <jari.arkko=[email-masked]>; [email-masked]
Cc: Kiran Makhijani <[email-masked]>
Subject: RE: Appendix text on isolation

Hi Jari,

Hope this helps.

Best regards,
Jie

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 17 Jun 2020 02:26:03 +0000

Hi Kiran and all,

Your concern is part of the reason that I suggest to describe the requirement and realization of isolation separately. Firstly, multi-dimension can help to clarify the different requirements related to isolation, such as traffic separation and interference avoidance, in my understanding both of which can be raised by a customer as requirement, and they do not reflect implementation details. Then the implementation-specific mechanisms could be briefly described to match each dimension of the requirement.

The sentence you added in the end of the paragraph looks good, while maybe it could be better if such requirement description be moved to the beginning of the paragraph. Please check the modified text below:

A consumer of transport slice may ask for isolation from other transport slices.
The term “isolation” can refer to multiple dimensions of requirements,
such as traffic separation, or interference avoidance, or both. Accordingly, from
realization’s perspective, traffic separation can be provided by VPN technologies,
and interference avoidance may be provided by mechanisms such as capacity
planning, policing or shaping, priority mechanisms, selecting dedicated resources, and so on.

Please let me know your thoughts. Thanks.

Best regards,
Jie

From: Kiran Makhijani [mailto:[email-masked]]
Sent: Wednesday, June 17, 2020 9:30 AM
To: Dongjie (Jimmy) <[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>; [email-masked]
Subject: RE: Appendix text on isolation

Hi Jie, and all,

-Kiran

From: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 16, 2020 3:15 AM
To: Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>
Subject: RE: Appendix text on isolation

Hi Jari,

Hope this helps.

Best regards,
Jie

---

From: Kiran Makhijani <[email-masked]>
Date: Wed, 17 Jun 2020 03:04:41 +0000

I am trying to say that customer should not have to ask for isolation but some abstraction of it. It may explicitly  ask for specific requirements but not isolation.

It’s ok to go with your suggestion if its just me. Some text is repeated from 2nd para. So that still needs some work.

Regards,
Kiran
________________________________
From: Dongjie (Jimmy) <[email-masked]>
Sent: Tuesday, June 16, 2020 7:26:03 PM
To: Kiran Makhijani <[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: Appendix text on isolation

Hi Kiran and all,

Best regards,

Jie

Hi Jie, and all,

-Kiran

Hi Jari,

Hope this helps.

Best regards,

Jie

redundancy are needed.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 17 Jun 2020 10:16:34 +0000

Hi Kiran,

I understand your point, while since isolation is specified as a requirement of network slicing in other SDOs (e.g. GSMA, 3GPP), some customers may also ask for isolation in end-to-end network slice or transport slice. My opinion is it may be helpful to interpret and clarify isolation as more specific requirements in IETF and transport slice context (such as traffic separation, interference avoidance, etc.)

Another option is to describe the specific requirement and the corresponding realization directly: "A consumer of transport slice may ask for traffic separation or interference avoidance from other transport slices. The term "isolation" implies traffic separation, or interference avoidance, or both. Accordingly, from realization's perspective, ..."

Best regards,
Jie

From: Kiran Makhijani [mailto:[email-masked]]
Sent: Wednesday, June 17, 2020 11:05 AM
To: Dongjie (Jimmy) <[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>; [email-masked]
Subject: Re: Appendix text on isolation

It's ok to go with your suggestion if its just me. Some text is repeated from 2nd para. So that still needs some work.

Regards,
Kiran
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Hi Kiran and all,

The term "isolation" can refer to multiple dimensions of requirements,

realization's perspective, traffic separation can be provided by VPN technologies,

Best regards,

Jie

From: Kiran Makhijani [mailto:[email-masked]]
Sent: Wednesday, June 17, 2020 9:30 AM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Appendix text on isolation

Hi Jie, and all,

One argument against using isolation as an SLO is that it is an implementation specific detail that customer should not have to (always) concern with. So I am not comfortable with the use of 'multi-dimensional'.

The term "isolation" implies in part traffic separation (a common

-Kiran

Hi Jari,

And as mentioned yesterday and in my previous email, I'd like to suggest whether the description about isolation could be rephrased a bit, so as to better clarify the requirement and realization of isolation in different dimensions.

The term "isolation" can refer to multiple dimensions of requirements. A customer may ask for traffic separation or interference avoidance, or both. Accordingly, from realization's perspective, traffic separation can be provided by VPNs, and interference avoidance can be provided by mechanisms such as capacity planning, priority mechanisms, policing or shaping, selecting dedicated resources, and so on.

Hope this helps.

Best regards,

Jie

Here's a suggested 2nd revision of the suggested text, based on yesterday's comments on the call and Kiran's email.

The term "isolation" implies in part traffic separation (a common

redundancy are needed.

---

From: Kiran Makhijani <[email-masked]>
Date: Mon, 22 Jun 2020 20:00:15 +0000

Hi Jie, and all,
Please review the final text, considering all the comments received so far.

--begin--
A.1.  On isolation requirements in a transport slice

   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, prioritizing, policing or
   shaping customer traffic, selecting dedicated resources, and so on.

   One term that has commonly been used in this context is "isolation"
   and is also discussed in the [I-D.ietf-teas-enhanced-vpn].

   A customer of transport slice may ask for traffic separation,
   selection of dedicated resources, or interference avoidance from
   other traffic.  The term "isolation" can refer to any or all of them.
   For instance, dedicated resources can help assure that traffic in
   other slices does not affect a given slice.  Simillarly, traffic
   separation can be provided by VPN technologies, and interference
   avoidance may be provided by mechanisms such as technical approaches
   mentioned in previous paragraph.  Moreover, these are some of the
   examples of particular realization of requirement for guarantees;
   other mechanisms may also be used.

   It should also be noted that neither above mentioned nor the other
   mechanisms can provide a 100% guarantee against outage problems.  To
   maintain protection against resource and equipment failures
   techniques such as redundancy are also needed.
--end--
Thanks
Kiran

From: Dongjie (Jimmy) <[email-masked]>
Sent: Wednesday, June 17, 2020 3:17 AM
To: Kiran Makhijani <[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>; [email-masked]
Subject: RE: Appendix text on isolation

Hi Kiran,

Best regards,
Jie

Regards,
Kiran

Hi Kiran and all,

Best regards,

Jie

Hi Jie, and all,

-Kiran

Hi Jari,

Hope this helps.

Best regards,

Jie

redundancy are needed.

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 22 Jun 2020 20:44:49 +0000

Hi Kiran,

Thanks for taking care of this. Let me insist in a small but important part. It is respect to the last paragraph, where it is mentioned that any mechanisms can provide 100% of guarantee. My point is that being true, this is applicable not only for the isolation concept but for any other consideration, e.g. meeting whatever SLO such as bandwidth. Then, in my view, leaving that reference in this annex could make apparent that such statement is only related to isolation when in reality it is related to whatever characteristic of the transport slice.

So I would suggest to remove it.

Best regards

Luis

De: Teas-ns-dt <[email-masked]> En nombre de Kiran Makhijani
Enviado el: lunes, 22 de junio de 2020 22:00
Para: [email-masked]
CC: Dongjie (Jimmy) <[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>
Asunto: Re: [Teas-ns-dt] Appendix text on isolation

Hi Jie, and all,

--begin--

From: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 17, 2020 3:17 AM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Appendix text on isolation

Hi Kiran,

Best regards,
Jie

Regards,
Kiran

Hi Kiran and all,

Best regards,

Jie

Hi Jie, and all,

-Kiran

Hi Jari,

Hope this helps.

Best regards,

Jie

redundancy are needed.

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o

---

From: Kiran Makhijani <[email-masked]>
Date: Mon, 22 Jun 2020 20:47:12 +0000

Ack. I was tentative too.

Regards
Kiran

________________________________
From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Sent: Monday, June 22, 2020 1:44:49 PM
To: Kiran Makhijani <[email-masked]>; [email-masked] <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>
Subject: RE: Appendix text on isolation

Hi Kiran,

Best regards

Luis

Hi Jie, and all,

--begin--

--end--

Thanks

Kiran

Hi Kiran,

Another option is to describe the specific requirement and the corresponding realization directly: “A consumer of transport slice may ask for traffic separation or interference avoidance from other transport slices. The term “isolation” implies traffic separation, or interference avoidance, or both. Accordingly, from realization’s perspective, …”

Best regards,

Jie

Regards,

Kiran

Hi Kiran and all,

Best regards,

Jie

Hi Jie, and all,

-Kiran

Hi Jari,

Hope this helps.

Best regards,

Jie

redundancy are needed.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 23 Jun 2020 01:48:44 +0000

Hi Kiran,

Thanks for incorporate the comments together into the text. It looks good to me.

I agree that the statement in last paragraph applies to all the characteristics of a transport slice, thus it is better to remove it from this section. Thanks.

Best regards,
Jie

From: Kiran Makhijani [mailto:[email-masked]]
Sent: Tuesday, June 23, 2020 4:47 AM
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]
Cc: Dongjie (Jimmy) <[email-masked]>; Jari Arkko <jari.arkko=[email-masked]>
Subject: Re: Appendix text on isolation

Regards
Kiran

________________________________
From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>
Sent: Monday, June 22, 2020 1:44:49 PM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Cc: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>
Subject: RE: Appendix text on isolation

Hi Kiran,

Best regards

Luis

De: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> En nombre de Kiran Makhijani
Enviado el: lunes, 22 de junio de 2020 22:00
Para: [email-masked]<mailto:[email-masked]>
CC: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>
Asunto: Re: [Teas-ns-dt] Appendix text on isolation

Hi Jie, and all,

--begin--

--end--

Thanks

Kiran

Hi Kiran,

Best regards,

Jie

Regards,

Kiran

Hi Kiran and all,

Best regards,

Jie

Hi Jie, and all,

-Kiran

Hi Jari,

Hope this helps.

Best regards,

Jie

redundancy are needed.

---

From: Xufeng Liu <[email-masked]>
Date: Wed, 24 Jun 2020 20:20:07 -0400

Hi Kiran,

Jary's proposal describes the "isolation" as two parts:

<quote>
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.
</quote>
Your text has added another part: "interference avoidance".

However, I am not sure "interference avoidance" can be classified as the
3rd part. It is rather a fundamental characteristic achieved by both parts
above. Therefore, I'd prefer the previous two-parts description in this
context. If "interference avoidance" is described, the topic could be a
separate section.

Since this is a definition document, should we provide clearly defined
terms for these two parts of the "isolation": "traffic isolation" and
"resource isolation", so that we would have a terminology reference for
later accurate usage.

Thanks,
- Xufeng

On Mon, Jun 22, 2020 at 9:48 PM Dongjie (Jimmy) <[email-masked]> wrote:

> I agree that the statement in last paragraph applies to all the
> characteristics of a transport slice, thus it is better to remove it from
> this section. Thanks.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Kiran Makhijani [mailto:[email-masked]]
> *Sent:* Tuesday, June 23, 2020 4:47 AM
> *To:* LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]>; [email-masked]
> *Cc:* Dongjie (Jimmy) <[email-masked]>; Jari Arkko <jari..arkko=
> [email-masked]>
> *Subject:* Re: Appendix text on isolation
>
>
>
> ------------------------------
>
> *From:* LUIS MIGUEL CONTRERAS MURILLO <
> [email-masked]>
> *Sent:* Monday, June 22, 2020 1:44:49 PM
> *To:* Kiran Makhijani <[email-masked]>; [email-masked] <
> [email-masked]>
> *Cc:* Dongjie (Jimmy) <[email-masked]>; Jari Arkko <
> jari.arkko=[email-masked]>
> *Subject:* RE: Appendix text on isolation
>
>
>
> Hi Kiran,
>
>
>
> Thanks for taking care of this. Let me insist in a small but important
> part. It is respect to the last paragraph, where it is mentioned that any
> mechanisms can provide 100% of guarantee. My point is that being true, this
> is applicable not only for the isolation concept but for any other
> consideration, e.g. meeting whatever SLO such as bandwidth. Then, in my
> view, leaving that reference in this annex could make apparent that such
> statement is only related to isolation when in reality it is related to
> whatever characteristic of the transport slice.
>
>
>
> *De:* Teas-ns-dt <[email-masked]> *En nombre de *Kiran
> Makhijani
> *Enviado el:* lunes, 22 de junio de 2020 22:00
> *Para:* [email-masked]
> *CC:* Dongjie (Jimmy) <[email-masked]>; Jari Arkko <
> jari.arkko=[email-masked]>
> *Asunto:* Re: [Teas-ns-dt] Appendix text on isolation
>
>
>
> Hi Jie, and all,
>
> *From:* Dongjie (Jimmy) <jie.dong@huawei..com <[email-masked]>>
> *Sent:* Wednesday, June 17, 2020 3:17 AM
> *To:* Kiran Makhijani <[email-masked]>; Jari Arkko <
> jari.arkko=[email-masked]>; [email-masked]
> *Subject:* RE: Appendix text on isolation
>
>
>
> Hi Kiran,
>
>
>
> I understand your point, while since isolation is specified as a
> requirement of network slicing in other SDOs (e.g. GSMA, 3GPP), some
> customers may also ask for isolation in end-to-end network slice or
> transport slice. My opinion is it may be helpful to interpret and clarify
> isolation as more specific requirements in IETF and transport slice context
> (such as traffic separation, interference avoidance, etc.)
>
>
>
> Another option is to describe the specific requirement and the
> corresponding realization directly: “A consumer of transport slice may ask
> for traffic separation or interference avoidance from other transport
> slices. The term “isolation” implies traffic separation, or interference
> avoidance, or both. Accordingly, from realization’s perspective, …”
>
>
>
> Best regards,
>
> Jie
>
>
>
>
>
> *From:* Kiran Makhijani [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, June 17, 2020 11:05 AM
> *To:* Dongjie (Jimmy) <[email-masked]>; Jari Arkko <
> jari.arkko=[email-masked]>; [email-masked]
> *Subject:* Re: Appendix text on isolation
>
>
>
> I am trying to say that customer should not have to ask for isolation but
> some abstraction of it. It may explicitly  ask for specific requirements
> but not isolation.
>
>
>
> It’s ok to go with your suggestion if its just me. Some text is repeated
> from 2nd para. So that still needs some work.
>
>
>
> Regards,
>
> Kiran
> ------------------------------
>
> *From:* Dongjie (Jimmy) <[email-masked]>
> *Sent:* Tuesday, June 16, 2020 7:26:03 PM
> *To:* Kiran Makhijani <[email-masked]>; Jari Arkko <
> jari.arkko=[email-masked]>; [email-masked] <
> [email-masked]>
> *Subject:* RE: Appendix text on isolation
>
>
>
> Hi Kiran and all,
>
>
>
> Your concern is part of the reason that I suggest to describe the
> requirement and realization of isolation separately. Firstly,
> multi-dimension can help to clarify the different requirements related to
> isolation, such as traffic separation and interference avoidance, in my
> understanding both of which can be raised by a customer as requirement, and
> they do not reflect implementation details. Then the
> implementation-specific mechanisms could be briefly described to match each
> dimension of the requirement.
>
>
>
> The sentence you added in the end of the paragraph looks good, while maybe
> it could be better if such requirement description be moved to the
> beginning of the paragraph. Please check the modified text below:
>
>
>
> *From:* Kiran Makhijani [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, June 17, 2020 9:30 AM
> *To:* Dongjie (Jimmy) <[email-masked]>; Jari Arkko <
> jari.arkko=[email-masked]>; [email-masked]
> *Subject:* RE: Appendix text on isolation
>
>
>
> Hi Jie, and all,
>
> One argument against using isolation as an SLO is that it is an
> implementation specific detail that customer should not have to (always)
> concern with. So I am not comfortable with the use of ‘multi-dimensional’.
>
> One way to separate realization and customer requirement may be we can use
> business objective/case. May be we can add, one sentence  at the end of the
> original paragraph. What do you think?
>
>
>
> *From:* Dongjie (Jimmy) <[email-masked]>
> *Sent:* Tuesday, June 16, 2020 3:15 AM
> *To:* Jari Arkko <jari.arkko=[email-masked]>;
> [email-masked]
> *Cc:* Kiran Makhijani <[email-masked]>
> *Subject:* RE: Appendix text on isolation
>
>
>
> Hi Jari,
>
>
>
> And as mentioned yesterday and in my previous email, I’d like to suggest
> whether the description about isolation could be rephrased a bit, so as to
> better clarify the requirement and realization of isolation in different
> dimensions.
>
>
>
> The term “isolation” can refer to multiple dimensions of requirements. A
> customer may ask for traffic separation or interference avoidance, or both.
> Accordingly, from realization’s perspective, traffic separation can be
> provided by VPNs, and interference avoidance can be provided by mechanisms
> such as capacity planning, priority mechanisms, policing or shaping,
> *From:* Teas-ns-dt [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Jari Arkko
> *Sent:* Tuesday, June 16, 2020 4:26 PM
> *To:* [email-masked]
> *Cc:* Kiran Makhijani <[email-masked]>
> *Subject:* Re: [Teas-ns-dt] Appendix text on isolation
>
>
>
> ------------------------------
>
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario,
> puede contener información privilegiada o confidencial y es para uso
> exclusivo de la persona o entidad de destino. Si no es usted. el
> destinatario indicado, queda notificado de que la lectura, utilización,
> divulgación y/o copia sin autorización puede estar prohibida en virtud de
> la legislación vigente. Si ha recibido este mensaje por error, le rogamos
> que nos lo comunique inmediatamente por esta misma vía y proceda a su
> destrucción.
>
> The information contained in this transmission is privileged and
> confidential information intended only for the use of the individual or
> entity named above. If the reader of this message is not the intended
> recipient, you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have received
> this transmission in error, do not read it. Please immediately reply to the
> sender that you have received this communication in error and then delete
> it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário,
> pode conter informação privilegiada ou confidencial e é para uso exclusivo
> da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário
> indicado, fica notificado de que a leitura, utilização, divulgação e/ou
> cópia sem autorização pode estar proibida em virtude da legislação vigente.
> Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique
> imediatamente por esta mesma via e proceda a sua destruição
> --
> Teas-ns-dt mailing list
> [email-masked]

---

From: Kiran Makhijani <[email-masked]>
Date: Sun, 28 Jun 2020 18:23:19 +0000

Hi Xufeng,
The differences are subtle, but quite clear in my mind. traffic separation is segmentation end to end, explained as VPN, without any specificity of preferential treatment. The interference is described in terms of traffic treatment capacity management, shaping scheduling. I prefer to keep it as is.
-Kiran

From: Xufeng Liu <[email-masked]>
Sent: Wednesday, June 24, 2020 5:20 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Kiran Makhijani <[email-masked]>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]; Jari Arkko <jari.arkko=[email-masked]>
Subject: Re: [Teas-ns-dt] Appendix text on isolation

Hi Kiran,

<quote>
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.
</quote>
Your text has added another part: "interference avoidance".

However, I am not sure "interference avoidance" can be classified as the 3rd part. It is rather a fundamental characteristic achieved by both parts above. Therefore, I'd prefer the previous two-parts description in this context. If "interference avoidance" is described, the topic could be a separate section.

Since this is a definition document, should we provide clearly defined terms for these two parts of the "isolation": "traffic isolation" and "resource isolation", so that we would have a terminology reference for later accurate usage.

Thanks,
- Xufeng

On Mon, Jun 22, 2020 at 9:48 PM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Kiran,

Best regards,
Jie

From: Kiran Makhijani [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, June 23, 2020 4:47 AM
To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari..arkko=[email-masked]<mailto:[email-masked]>>
Subject: Re: Appendix text on isolation

Regards
Kiran

Hi Kiran,

Best regards

Luis

Hi Jie, and all,

--begin--

--end--

Thanks

Kiran

From: Dongjie (Jimmy) <jie.dong@huawei..com<mailto:[email-masked]>>
Sent: Wednesday, June 17, 2020 3:17 AM
To: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: Appendix text on isolation

Hi Kiran,

Best regards,

Jie

Regards,

Kiran

Hi Kiran and all,

Best regards,

Jie

Hi Jie, and all,

-Kiran

Hi Jari,

Hope this helps.

Best regards,

Jie

redundancy are needed.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7C247c8d9f2075464adb7008d8189d8b34%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637286412232172353&sdata=iWlIvUQ1XZE3q09r8VjCdiB5WjG7CMvi1RfgOUBZAfc%3D&reserved=0>

---

From: Eric Gray <[email-masked]>
Date: Mon, 29 Jun 2020 12:53:08 +0000

Kiran/Xufeng,

              This part of the text in the appendix was discussed during the meeting last Thursday.

              The point that some (at least one person) felt that the specific text related to “interference” was redundant relative to other examples of isolation  forms was made and dismissed.

              Hence this discussion should have already been closed.

--
Eric

From: Teas-ns-dt <[email-masked]> On Behalf Of Kiran Makhijani
Sent: Sunday, June 28, 2020 2:23 PM
To: Xufeng Liu <[email-masked]>; Dongjie (Jimmy) <[email-masked]>
Cc: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>; [email-masked]; Jari Arkko <jari.arkko=[email-masked]>
Subject: Re: [Teas-ns-dt] Appendix text on isolation

Hi Xufeng,

From: Xufeng Liu <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, June 24, 2020 5:20 PM
To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>
Cc: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>; LUIS MIGUEL CONTRERAS MURILLO <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Jari Arkko <jari.arkko=[email-masked]<mailto:jari.arkko=[email-masked]>>
Subject: Re: [Teas-ns-dt] Appendix text on isolation

Hi Kiran,

<quote>

Thanks,
- Xufeng

Best regards,
Jie

Regards
Kiran

Hi Kiran,

Best regards

Luis

Hi Jie, and all,

--begin--

--end--

Thanks

Kiran

Hi Kiran,

Best regards,

Jie

Regards,

Kiran

Hi Kiran and all,

Best regards,

Jie

Hi Jie, and all,

-Kiran

Hi Jari,

Hope this helps.

Best regards,

Jie

redundancy are needed.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
--
Teas-ns-dt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://protect2.fireeye.com/v1/url?k=8e01d940-d0a11b05-8e0199db-86b568293eb5-2c2979c49ce1b173&q=1&e=68b928cf-ef44-4936-bfcb-69da7b58a825&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas-ns-dt%26data%3D02%257C01%257Ckiranm%2540futurewei.com%257C247c8d9f2075464adb7008d8189d8b34%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637286412232172353%26sdata%3DiWlIvUQ1XZE3q09r8VjCdiB5WjG7CMvi1RfgOUBZAfc%253D%26reserved%3D0>