Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution

From: Zhenghaomian <[email-masked]>
Date: Sun, 26 Apr 2020 02:44:04 +0000

Not sure if I understand your question correctly. 
Well, it's reasonable for people to request hard isolation because 'I don't want my data to be transported together with other people's data'. 
For delivery this can be achieved by separating physical devices/connections, which are visible to users. For example dedicated boxes and fibers will guarantee the user's data is not mixed with others...

Best wishes,
Haomian

-----邮件原件-----
发件人: Joel M. Halpern [mailto:[email-masked]] 
发送时间: 2020年4月26日 10:34
收件人: Zhenghaomian <[email-masked]>; [email-masked]
主题: Re: [Teas] Network Slicing design team definitions - isolation and resolution

(trimmed)
What is the user perceivable effect that the user is asking for when you say "if the user requests isolation"?

Yours,
Joel

On 4/25/2020 10:31 PM, Zhenghaomian wrote:
> Hi, Kiran, Joel,
...
> BTW, regarding the isolation, I don't see the necessity to argue whether it should be in SLO or not. The isolation itself, can either be requested by the user of the transport slice (then from NBI of TSC) to express the demand of reliability, or be offered by the provider of the transport slice (then from the SBI of TSC) to achieve the SLO requested from the user. In other words, if the user requests certain level of isolation in an SLO, such isolation should be provided; if the user does not request certain level of isolation (no isolation request in SLO), then there may be some isolation provided to satisfy the user's request.
> 
> Best wishes,
> Haomian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 25 Apr 2020 22:51:49 -0400

Actually, I am not at all sure that the erquest you describe is 
reasonable.  The data is going to go through devices with other people's 
data.  It's the Internet.   Even if you give them an entire wavelength, 
it is going through the same fiber as other people's data.
If the customer wants an entirely separate phsical infrastructure, then 
you do not need any of the orchestration taht has been discussed. 
Because in order to do that you ahve to physically wire up separate 
devices, separate cables, etc.  That can not be orchestrated.  It can 
not use data center technology.  (Sure, you can give a customer 
dedicated servers.  That is something I understand.  We do know that 
active compute can get across boundaries.  But we are discussing shared 
networking infrastructure, not the asigned compute platforms.)

And from the opposite perspective, data does not look at other data. (In 
contrast to compute, where we know it can look, and modify across 
boundaries.)  So going through the same cable with other people's data 
is an irrelevant constraint.  Even security folks do not ask for 
avoiding that.  What is the problem the customer wants to solve.

More importantly, it is not something the customer has any way to 
verify.  There is no test a customer can run that will verify this.
Making unverifiable promises is rarely a useful thing to do.

Yours,
Joel

PS: Note that I understand that operators get asked for odd things mby 
customers.  But if we are going to define standards to support it, we 
need to understand the actual need.

---

From: Zhenghaomian <[email-masked]>
Date: Sun, 26 Apr 2020 06:27:09 +0000

Inline...

Best wishes,
Haomian

-----邮件原件-----
发件人: Joel M. Halpern [mailto:[email-masked]] 
发送时间: 2020年4月26日 10:52
收件人: Zhenghaomian <[email-masked]>; [email-masked]
主题: Re: [Teas] Network Slicing design team definitions - isolation and resolution

Actually, I am not at all sure that the erquest you describe is reasonable.  The data is going to go through devices with other people's 
data.  It's the Internet.   Even if you give them an entire wavelength, 
it is going through the same fiber as other people's data.
If the customer wants an entirely separate phsical infrastructure, then you do not need any of the orchestration taht has been discussed. 
Because in order to do that you ahve to physically wire up separate devices, separate cables, etc.  That can not be orchestrated.  It can not use data center technology.  (Sure, you can give a customer dedicated servers.  That is something I understand.  We do know that active compute can get across boundaries.  But we are discussing shared networking infrastructure, not the asigned compute platforms.)
[Haomian] An example: some people travel by taxi, some others travel by bus. They are both 'on the road with each other', but they service level should be differentiated and the user should be able to select between taxi and bus. I think the network is in similar circumstance. 

And from the opposite perspective, data does not look at other data. (In contrast to compute, where we know it can look, and modify across
boundaries.)  So going through the same cable with other people's data is an irrelevant constraint.  Even security folks do not ask for avoiding that.  What is the problem the customer wants to solve.
[Haomian] Agree on 'data does not look at other data'. The isolation should not be checked by data. 

More importantly, it is not something the customer has any way to verify.  There is no test a customer can run that will verify this.
Making unverifiable promises is rarely a useful thing to do.
[Haomian] I agree this is more important, and also agree on the statement 'Making unverifiable promises is rarely a useful thing to do '. I am not sure if you are claiming 'the isolation is not verifiable' or 'the customer is lack of capability to verify isolation'. For the former, when the congestion is analyzed, engineers may know where the data is stuck, such as 'there are many different slices queuing at this router/link', which helps understanding the slice is not isolated. For the latter, I had a feeling that the customer may be lack of capability to verify not only isolation, but other more fundamental parameters like redundancy and security mentioned in section 4.1 of the draft. 

Yours,
Joel

PS: Note that I understand that operators get asked for odd things mby customers.  But if we are going to define standards to support it, we need to understand the actual need.
[Haomian] Yes, that is exactly why I was writing and requesting for the explanation on explicit understanding SLO, then we will know what is the user 'should ask' and what is not. Unfortunately our current discussion is losing focus... maybe I suggest we come back once we are clear on SLO.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sun, 26 Apr 2020 15:08:29 +0000

Hi Joel, 

Please see some replies inline:

> -----Original Message-----
> From: Teas [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Sunday, April 26, 2020 10:52 AM
> To: Zhenghaomian <[email-masked]>; [email-masked]
> Subject: Re: [Teas] Network Slicing design team definitions - isolation and
> resolution
> 
> Actually, I am not at all sure that the erquest you describe is reasonable.  The
> data is going to go through devices with other people's

You are right that typically the data will share the network infrastructure with other data, while usually network slicing is not in internet. 

And your second point is related to the degree of isolation. Different fibers can also be possible it is required by a customer. 

> If the customer wants an entirely separate phsical infrastructure, then you do
> not need any of the orchestration taht has been discussed.
> Because in order to do that you ahve to physically wire up separate devices,
> separate cables, etc.  That can not be orchestrated.  It can not use data center
> technology.  (Sure, you can give a customer dedicated servers.  That is
> something I understand.  We do know that active compute can get across
> boundaries.  But we are discussing shared networking infrastructure, not the
> asigned compute platforms.)

Different customers of an operator can ask for different levels of isolation. These can be met with the same network infrastructure, using different approaches for network resource partitioning. It is similar to the server side, where there are different approaches for virtualization, with different levels of isolation.

> boundaries.)  So going through the same cable with other people's data is an
> irrelevant constraint.  Even security folks do not ask for avoiding that.  What is
> the problem the customer wants to solve.

The impact between data of different customers is that data of one customer may have to wait for the processing of the data of another customer, which result in its SLA being violated.

> 
> More importantly, it is not something the customer has any way to verify.
> There is no test a customer can run that will verify this.

Totally agree that tools for verification is important. As mentioned in Haomian's mail, isolation can be verified with suitable tools which can be used to collect the information at the necessary places with a suitable interval. And it is important that customers can be provided with such tools to monitor the performance and be informed of SLA violation.

Best regards,
Jie

> customers.  But if we are going to define standards to support it, we need to
> understand the actual need.
> 
> > Well, it's reasonable for people to request hard isolation because 'I don't want
> my data to be transported together with other people's data'.
> > For delivery this can be achieved by separating physical devices/connections,
> which are visible to users. For example dedicated boxes and fibers will guarantee
> the user's data is not mixed with others...
> >
> > Best wishes,
> > Haomian
> >
> > -----邮件原件-----
> >> BTW, regarding the isolation, I don't see the necessity to argue whether it
> should be in SLO or not. The isolation itself, can either be requested by the user
> of the transport slice (then from NBI of TSC) to express the demand of reliability,
> or be offered by the provider of the transport slice (then from the SBI of TSC) to
> achieve the SLO requested from the user. In other words, if the user requests
> certain level of isolation in an SLO, such isolation should be provided; if the user
> does not request certain level of isolation (no isolation request in SLO), then
> there may be some isolation provided to satisfy the user's request.
> >>
> >> Best wishes,
> >> Haomian
> 
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas

---

From: Joel Halpern Direct <[email-masked]>
Date: Sun, 26 Apr 2020 11:57:18 -0400

Trimmed, in line.
Joel

...
> Totally agree that tools for verification is important. As mentioned in Haomian's mail, isolation can be verified with suitable tools which can be used to collect the information at the necessary p…

As far as I can tell, the observable that you describe is latency 
variation (or maybe loss).  Fine, describe the SLO in terms of latency 
variation  (or loss).  Given that there are always imperfections in the 
system, the customer may think that the issue is isolation.  But what he 
can observe, and as far as I can tell what he cares about, is delay 
variation, loss, or other factors that affect his traffic.

To use a different example, I have learned from the advocates to hate 
bufferbloat.  But even their tests measure delay, delay variation, etc. 
They then infer the presence of large buffers.  But in fact, if the 
large buffers are present but never used, we would all be happy.  So the 
SLO on this would be in terms of latency, latency variation, loss, etc. 
Not bufferbloat.`

Yours,
Joel

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 27 Apr 2020 14:22:50 -0700

Dear Joel,
thank you for bringing the matter of "isolation" to the discussion. I
agree, that it is not practical to expect physical isolation in modern
networks. In my view, a transport slice that requires isolation is as a
transport connection that expects to receive data only from the specific
domain and not from any other domain. In other words, I view isolation as
the absence of mis-connectivity (in transport network interpretation which
differentiates between path continuity check and connectivity
verification). If my interpretation is acceptable, then isolation can be
monitored using connectivity verification OAM mechanism(s).
I much appreciate your thoughts, opinion on the proposed interpretation of
isolation on transport slice.

Regards,
Greg

On Sun, Apr 26, 2020 at 8:57 AM Joel Halpern Direct <
[email-masked]> wrote:

> verify.
> > Totally agree that tools for verification is important. As mentioned in
> Haomian's mail, isolation can be verified with suitable tools which can be
> used to collect the information at the necessary places with a suitable
> interval. And it is important that customers can be provided with such
> tools to monitor the performance and be informed of SLA violation.
>
> >>> What is the user perceivable effect that the user is asking for when
> you say "if
> >> the user requests isolation"?
> >>>
> >>> Yours,
> >>> Joel
> >>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 27 Apr 2020 17:32:50 -0400

Greg, that definition seems to be a specific subset of VPN.
As far as I can tell, the slice definition does include what endpoints 
the slice participants can talk to.  Presumably, with some way to say 
"the Internet".
So Whether the slice supports communication with the Internet or not is 
definitely an observable property.  I would tend not to call it 
isolation.  Separately, the definition you propose is unrelated to the 
definition in the document,
Which is why I suggest, for now, removing all discussion of isolation 
from the document.

Yours,
Joel

On 4/27/2020 5:22 PM, Greg Mirsky wrote:
> domain and not from any other domain. In other words, I view isolation 
> as the absence of mis-connectivity (in transport network 
> interpretation which differentiates between path continuity check and 
> connectivity verification). If my interpretation is acceptable, then 
> isolation can be monitored using connectivity verification OAM mechanism(s).
> I much appreciate your thoughts, opinion on the proposed interpretation 
> of isolation on transport slice.
> 
> Regards,
> Greg
> 
> On Sun, Apr 26, 2020 at 8:57 AM Joel Halpern Direct 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Trimmed, in line.
>     Joel
> 
>      >> From: Teas [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Joel M. Halpern
>      >> To: Zhenghaomian <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     ....
>      > Totally agree that tools for verification is important. As
>     mentioned in Haomian's mail, isolation can be verified with suitable
>     tools which can be used to collect the information at the necessary
>     places with a suitable interval. And it is important that customers
>     can be provided with such tools to monitor the performance and be
>     informed of SLA violation.
> 
>     bufferbloat.  But even their tests measure delay, delay variation,
>     etc..
>      >>> 发件人: Joel M. Halpern [mailto:[email-masked]
>     <mailto:[email-masked]>]
>      >>> 发送时间: 2020年4月26日 10:34
>      >>> 收件人: Zhenghaomian <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>      >>> 主题: Re: [Teas] Network Slicing design team definitions -
>     isolation and
>      >>> resolution
>      >>>
>      >>> (trimmed)
>      >>> What is the user perceivable effect that the user is asking for
>     when you say "if
>      >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 28 Apr 2020 09:30:59 +0000

Hi Joel and Greg,

As I mentioned during the virtual meeting, isolation was described as a requirement in several PPVPN requirement and framework RFCs. In summary, isolation is firstly required to avoid unwanted exposure of both data traffic and routing information, then it is also mentioned that isolation is needed to avoid the effects of traffic congestion happened in other VPNs in the network. 

Just quote some of them: 

RFC 3809: Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)

4.4.  Data isolation

   The PPVPN MUST support forwarding plane isolation.  The network MUST
   never deliver user data across VPN boundaries unless the two VPNs
   participate in an intranet or extranet.

   Furthermore, if the provider network receives signaling or routing
   information from one VPN, it MUST NOT reveal that information to
   another VPN unless the two VPNs participate in an intranet or
   extranet.

RFC 4031: Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)

4.1.  Isolated Exchange of Data and Routing Information

   A mechanism must be provided for isolating the distribution of
   reachability information to only those sites associated with a VPN.
   ...
   Note that isolation of forwarded data or exchange of reachability
   information to only those sites that are part of a VPN may be viewed
   as a form of security - for example, [Y.1311.1], [MPLSSEC].

5.8.  Isolation

   These features include traffic and routing information exchange
   isolation, similar to that obtained in VPNs based on Layer 1 and
   Layer 2 (e.g., private lines, FR, or ATM) [MPLSSEC].

6.8.  Isolation of Traffic and Routing
   ...
   From a high-level SP perspective, a PE-based L3VPN MUST isolate the
   exchange of traffic and routing information to only those sites that
   are authenticated and authorized members of a VPN.

   In a CE-based VPN, the tunnels that connect the sites effectively
   meet this isolation requirement if both traffic and routing
   information flow over the tunnels.

   An L3VPN solution SHOULD provide a means to meet L3VPN QoS SLA
   requirements that isolates VPN traffic from the effects of traffic
   offered by non-VPN customers.  Also, L3VPN solutions SHOULD provide a
   means to isolate the effects that traffic congestion produced by
   sites as part of one VPN can have on another VPN.

RFC 4110: A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)

1.2 Overview of Virtual Private Networks

   In PE-based layer 3 VPNs, the PE devices may
   route the VPN traffic based on the customer addresses found in the IP
   headers; this implies that the PE devices need to maintain a level of
   isolation between the packets from different customer networks.
   ...
   Tunneling is also important for other reasons, such as providing
   isolation between different customer networks, allowing a wide range
   of protocols to be carried over an SP network, etc.  Different QoS
   and security characteristics may be associated with different
   tunnels.

4. 3 VPN Tunneling

   Another capability optionally provided by tunneling is that of
   isolation between different VPN traffic flows.  The QoS and security
   requirements for these traffic flows may differ, and can be met by
   using different tunnels with the appropriate characteristics.  This
   allows a provider to offer different service characteristics for
   traffic in different VPNs, or to subsets of traffic flows within a
   single VPN.

Hope this helps. 

Best regards,
Jie

> Sent: Tuesday, April 28, 2020 5:33 AM
> To: Greg Mirsky <[email-masked]>
> Cc: [email-masked]
> As far as I can tell, the slice definition does include what endpoints the slice
> participants can talk to.  Presumably, with some way to say "the Internet".
> definitely an observable property.  I would tend not to call it isolation.
> Separately, the definition you propose is unrelated to the definition in the
> document, Which is why I suggest, for now, removing all discussion of
> isolation from the document.
> 
> Yours,
> Joel
> 
> > networks. In my view, a transport slice that requires isolation is as
> > a transport connection that expects to receive data only from the
> > specific domain and not from any other domain. In other words, I view
> > isolation as the absence of mis-connectivity (in transport network
> > I much appreciate your thoughts, opinion on the proposed
> > interpretation of isolation on transport slice.
> >
> > Regards,
> > Greg
> >

---

From: Joel Halpern Direct <[email-masked]>
Date: Tue, 28 Apr 2020 09:39:59 -0400

Those are indeed uses of the word isolation.
In none of those cases is isolation a parameter to the VPN or a 
variable.   it is part of teh definition of a VPN.

More importantly, those definitions describe something very different 
from what the network slicing definitions draft describesas isolation. 
Providing yet more evidence that we should remove the description from 
that draft.

Yours,
Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 28 Apr 2020 16:07:49 +0000

Hi Joel, 

In those referenced text, isolation is described as one requirement of VPN from both customers and operators' point of view. And as discussed in previous mails, isolation is also considered as one important requirement for slicing, thus it would be weird to me if isolation is not mentioned in this document. That said, the text in this draft could be improved, and suggestions are welcome.

As you pointed out, the meaning of isolation in the VPN context could be different from the isolation in network slicing. While please note that besides isolation of reachability, RFC 4031 also mentions additional requirement on isolation: 

"An L3VPN solution SHOULD provide a means to meet L3VPN QoS SLA requirements that isolates VPN traffic from the effects of traffic offered by non-VPN customers. Also, L3VPN solutions SHOULD provide a means to isolate the effects that traffic congestion produced by sites as part of one VPN can have on another VPN."

How to describe this as a parameter is something needs further discussion. 

Best regards,
Jie

> From: Joel Halpern Direct [mailto:[email-masked]]
> Sent: Tuesday, April 28, 2020 9:40 PM
> To: Dongjie (Jimmy) <[email-masked]>
> Cc: [email-masked]
> More importantly, those definitions describe something very different from
> what the network slicing definitions draft describesas isolation.
> Providing yet more evidence that we should remove the description from that
> draft.
> 
> Yours,
> Joel
> 
> > As I mentioned during the virtual meeting, isolation was described as a
> requirement in several PPVPN requirement and framework RFCs. In summary,
> isolation is firstly required to avoid unwanted exposure of both data traffic and
> routing information, then it is also mentioned that isolation is needed to avoid
> the effects of traffic congestion happened in other VPNs in the network.
> >
> > Just quote some of them:
> >
> >> Subject: Re: [Teas] Network Slicing design team definitions -
> >> isolation and resolution
> >>
> >> As far as I can tell, the slice definition does include what
> >> endpoints the slice participants can talk to.  Presumably, with some way to
> say "the Internet".
> >> So Whether the slice supports communication with the Internet or not
> >> is definitely an observable property.  I would tend not to call it isolation.
> >> Separately, the definition you propose is unrelated to the definition
> >> in the document, Which is why I suggest, for now, removing all
> >> discussion of isolation from the document.
> >>
> >> Yours,
> >> Joel
> >>
> >>> thank you for bringing the matter of "isolation" to the discussion.
> >>> I agree, that it is not practical to expect physical isolation in
> >>> modern networks. In my view, a transport slice that requires
> >>> isolation is as a transport connection that expects to receive data
> >>> only from the specific domain and not from any other domain. In
> >>> other words, I view isolation as the absence of mis-connectivity (in
> >>> transport network interpretation which differentiates between path
> >>> continuity check and connectivity verification). If my
> >>> interpretation is acceptable, then isolation can be monitored using
> >>> connectivity verification OAM
> >> mechanism(s).
> >>>      variation  (or loss).  Given that there are always
> >>> imperfections in
> >> the

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Apr 2020 09:17:37 -0700

Hi Joel,
thank you for your expedient response. I agree that the current document
uses the term isolation is a rather overloaded way. One way may be to look
for other terms to differentiate between, for example, underlay resource
access and utilization.

Regards,
Greg

> Greg, that definition seems to be a specific subset of VPN.
GIM>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 28 Apr 2020 09:29:55 -0700

Hi Jie,
thank you for listing the existing cases of isolation term use in IETF
RFCs. My understanding of these quotes is that most of them refer to data
flow isolation/separation. And that is what Connectivity Verification OAM
is intended to monitor. At the same time, as Joel has pointed out, the term
isolation is being used in the draft-nsdt-teas-transport-slice-definition
in a different manner, particularly in Section 4.1.1. In that section,
several levels (hard and soft) of the isolation are discussed whereas
isolation of data flows, in my understanding, is always "hard". As I've
mentioned earlier, we might look for different terms when referring to
use/access to underlay resources vs. data flows interaction.

Regards,
Greg

On Tue, Apr 28, 2020 at 2:31 AM Dongjie (Jimmy) <[email-masked]> wrote:

> isolation is firstly required to avoid unwanted exposure of both data
> traffic and routing information, then it is also mentioned that isolation
> is needed to avoid the effects of traffic congestion happened in other VPNs
> in the network.
>
> Just quote some of them:
>
> the slice
> isolation.
> > >     large buffers are present but never used, we would all be happy.
> So
> > >     the

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 28 Apr 2020 17:51:41 +0000 (UTC)

Hi Greg,

Flow isolation and network isolation are different things. For example, you do not expect receiving data in one network broadcasted over properly isolated another network. Likewise, you do not expect congestion in one network caused by an activity in another (isolated) network. Om the other hand, flows in the same network may influence on each other.

Igor 

    On Tuesday, April 28, 2020, 12:30:38 PM EDT, Greg Mirsky <[email-masked]> wrote:  
 
 Hi Jie,thank you for listing the existing cases of isolation term use in IETF RFCs. My understanding of these quotes is that most of them refer to data flow isolation/separation. And that is what Connectivity Verification OAM is intended to monitor. At the same time, as Joel has pointed out, the term isolation is being used in the draft-nsdt-teas-transport-slice-definition in a different manner, particularly in Section 4.1.1. In that section, several levels (hard and soft) of the isolation are discussed whereas isolation of data flows, in my understanding, is always "hard". As I've mentioned earlier, we might look for different terms when referring to use/access to underlay resources vs. data flows interaction.
Regards,Greg

Hi Joel and Greg,

Just quote some of them: 

4.4.  Data isolation

5.8.  Isolation

   isolation between the packets from different customer networks..

4. 3 VPN Tunneling

Hope this helps. 

Best regards,
Jie

> >      > Hi Joel,
> >      >
> >      > Please see some replies inline:
> >      >
> >      >> -----Original Message-----
> >      >> From: Teas [mailto:[email-masked]
> >      >> Sent: Sunday, April 26, 2020 10:52 AM
> >      >> To: Zhenghaomian <[email-masked]
> >      >> Subject: Re: [Teas] Network Slicing design team definitions -
> >     isolation and
> >      >> resolution
> >      >>
> >     ....
> >      >> More importantly, it is not something the customer has any way
> >     to verify.
> >      >> There is no test a customer can run that will verify this.
> >      >> Making unverifiable promises is rarely a useful thing to do.
> >      >
> >      > Totally agree that tools for verification is important. As
> >      >
> >      > Best regards,
> >      > Jie
> >      >
> >      >>
> >      >> Yours,
> >      >> Joel
> >      >>
> >      >> PS: Note that I understand that operators get asked for odd
> >     things mby
> >      >> customers.  But if we are going to define standards to support
> >     it, we need to
> >      >> understand the actual need.
> >      >>
> >      >> On 4/25/2020 10:44 PM, Zhenghaomian wrote:
> >      >>> Not sure if I understand your question correctly.
> >      >>> Well, it's reasonable for people to request hard isolation
> >     because 'I don't want
> >      >> my data to be transported together with other people's data'.
> >      >>> For delivery this can be achieved by separating physical
> >     devices/connections,
> >      >> which are visible to users. For example dedicated boxes and
> >     fibers will guarantee
> >      >> the user's data is not mixed with others...
> >      >>>
> >      >>> Best wishes,
> >      >>> Haomian
> >      >>>
> >      >>> -----邮件原件-----
> >      >>> 发件人: Joel M. Halpern [mailto:[email-masked]
> >      >>> 发送时间: 2020年4月26日 10:34
> >      >>> 收件人: Zhenghaomian <[email-masked]
> >      >>> 主题: Re: [Teas] Network Slicing design team definitions -
> >     isolation and
> >      >>> resolution
> >      >>>
> >      >>> (trimmed)
> >      >>> What is the user perceivable effect that the user is asking for
> >     when you say "if
> >      >> the user requests isolation"?
> >      >>>
> >      >>> Yours,
> >      >>> Joel
> >      >>>
> >      >>> On 4/25/2020 10:31 PM, Zhenghaomian wrote:
> >      >>>> Hi, Kiran, Joel,
> >      >>>>
> >      >>> ...
> >      >>>> BTW, regarding the isolation, I don't see the necessity to
> >     argue whether it
> >      >> should be in SLO or not. The isolation itself, can either be
> >     requested by the user
> >      >> of the transport slice (then from NBI of TSC) to express the
> >     demand of reliability,
> >      >> or be offered by the provider of the transport slice (then from
> >     the SBI of TSC) to
> >      >> achieve the SLO requested from the user. In other words, if the
> >     user requests
> >      >> certain level of isolation in an SLO, such isolation should be
> >     provided; if the user
> >      >> does not request certain level of isolation (no isolation
> >     request in SLO), then
> >      >> there may be some isolation provided to satisfy the user's
> request.
> >      >>>>
> >      >>>> Best wishes,
> >      >>>> Haomian
> >      >>
> >      >> _______________________________________________
> >      >> Teas mailing list
> >      >> [email-masked] <mailto:[email-masked]>
> >      >> https://www.ietf.org/mailman/listinfo/teas
> >

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 29 Apr 2020 14:51:35 +0000

Hi Greg,

Thanks for your comment.

Maybe you missed my summary of the text quoted from existing PPVPN RFCs:

“In summary, isolation is firstly required to avoid unwanted exposure of both data traffic and routing information, then it is also mentioned that isolation is needed to avoid the effects of traffic congestion happened in other VPNs in the network.”

This shows that isolation is not just about connectivity, but is also related to the impact on performance.  The hard isolation is about whether the performance of one service could be impacted by another service in the network.

As for the terms, in my understanding isolation means “no interaction”. As it has been used in existing RFCs to describe the similar requirements, maybe an easier approach is to add some descriptive word in front of isolation to make it more accurate, rather than looking for a new term with the same meaning.

Best regards,
Jie

From: Greg Mirsky [mailto:[email-masked]]
Sent: Wednesday, April 29, 2020 12:30 AM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Joel M. Halpern <[email-masked]>; [email-masked]
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution

Hi Jie,
thank you for listing the existing cases of isolation term use in IETF RFCs. My understanding of these quotes is that most of them refer to data flow isolation/separation. And that is what Connectivity Verification OAM is intended to monitor. At the same time, as Joel has pointed out, the term isolation is being used in the draft-nsdt-teas-transport-slice-definition in a different manner, particularly in Section 4.1.1. In that section, several levels (hard and soft) of the isolation are discussed whereas isolation of data flows, in my understanding, is always "hard". As I've mentioned earlier, we might look for different terms when referring to use/access to underlay resources vs. data flows interaction.

Regards,
Greg

On Tue, Apr 28, 2020 at 2:31 AM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Joel and Greg,

Just quote some of them:

4.4.  Data isolation

5.8.  Isolation

4. 3 VPN Tunneling

Hope this helps.

Best regards,
Jie

> From: Teas [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Joel M. Halpern
> To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> > <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
> wrote:
> >
> >     Trimmed, in line.
> >     Joel
> >
> >      >> From: Teas [mailto:[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>] On Behalf Of Joel M. Halpern
> >      >> To: Zhenghaomian <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >>> 发件人: Joel M. Halpern [mailto:[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>]
> >      >>> 发送时间: 2020年4月26日 10:34
> >      >>> 收件人: Zhenghaomian <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 29 Apr 2020 17:01:14 -0700

Hi Jie,
thank you for highlighting your conclusion of how isolation is
interpreted in PPVPN documents.
While looking for how isolation can be verified, measured, or monitored, I
think that the absence of mis-connection error is one of the externally
verifiable demonstrations of the isolation between VPNs. Others include
throughput and available bandwidth (performance metrics like packet loss
ratio and packet delay variation also may be useful as indicators).
I agree that we need to clarify the context of using the term isolation.
And that will likely help in defining hard and soft isolation (the latter
probably does not guarantee the absence of performance impact from other
networks whereas the former includes such guarantee). But both types of
isolation, in my view, assume the guarantee of the absence of
mis-connection errors.

Regards,
Greg

On Wed, Apr 29, 2020 at 7:51 AM Dongjie (Jimmy) <[email-masked]> wrote:

> “In summary, isolation is firstly required to avoid unwanted exposure of
> both data traffic and routing information, then it is also mentioned that
> isolation is needed to avoid the effects of traffic congestion happened in
> other VPNs in the network.”
>
>
>
> This shows that isolation is not just about connectivity, but is also
> related to the impact on performance.  The hard isolation is about whether
> the performance of one service could be impacted by another service in the
> network.
>
>
>
> As for the terms, in my understanding isolation means “no interaction”. As
> it has been used in existing RFCs to describe the similar requirements,
> maybe an easier approach is to add some descriptive word in front of
> isolation to make it more accurate, rather than looking for a new term with
> the same meaning.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Wednesday, April 29, 2020 12:30 AM
> *To:* Dongjie (Jimmy) <[email-masked]>
> *Cc:* Joel M. Halpern <[email-masked]>; [email-masked]
> *Subject:* Re: [Teas] Network Slicing design team definitions - isolation
> and resolution
>
>
>
> Hi Jie,
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 29 Apr 2020 20:13:52 -0700

Hi Igor,
I agree with you but with some clarification. If we, as in the draft,
introduce the notion of "hard isolation" and "soft isolation", then, in my
opinion, we acknowledge that in some cases isolation is not guaranteed.
Hence, everything that you've said is the case for hard isolation. But for
soft isolation, I think, a network might be affected by another network.
What is your opinion on hard vs. soft isolation?

Regards,
Greg

On Tue, Apr 28, 2020 at 10:52 AM Igor Bryskin <[email-masked]> wrote:

> Hi Greg,
>
> Flow isolation and network isolation are different things. For example,
> you do not expect receiving data in one network broadcasted over properly
> isolated another network. Likewise, you do not expect congestion in one
> network caused by an activity in another (isolated) network. Om the other
> hand, flows in the same network may influence on each other.
>
> Igor
>
>
> > >     <mailto:[email-masked] <teas-bounces@ietf..org>>] On
> Behalf Of Joel M. Halpern

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 29 Apr 2020 23:22:37 -0400

I have never seen a good or useful distinction between hard and soft 
isolation.  The one described in the draft (based on causes of failure) 
is not effective.

Everything has a confidence / reliability / variability.  some are 
better than 5 9s.  And some are one 9.  Niether is hard.  And neither is 
soft.

Yours,
Joel

On 4/29/2020 11:13 PM, Greg Mirsky wrote:
> introduce the notion of "hard isolation" and "soft isolation", then, in 
> my opinion, we acknowledge that in some cases isolation is not 
> guaranteed. Hence, everything that you've said is the case for hard 
> isolation. But for soft isolation, I think, a network might be affected 
> by another network.
> On Tue, Apr 28, 2020 at 10:52 AM Igor Bryskin <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Hi Greg,
> 
>     Flow isolation and network isolation are different things. For
>     example, you do not expect receiving data in one network broadcasted
>     over properly isolated another network. Likewise, you do not expect
>     congestion in one network caused by an activity in another
>     (isolated) network. Om the other hand, flows in the same network may
>     influence on each other.
> 
>     Igor
> 
> 
>     On Tuesday, April 28, 2020, 12:30:38 PM EDT, Greg Mirsky
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>     Hi Jie,
>     thank you for listing the existing cases of isolation term use in
>     IETF RFCs. My understanding of these quotes is that most of them
>     refer to data flow isolation/separation. And that is what
>     Connectivity Verification OAM is intended to monitor. At the same
>     time, as Joel has pointed out, the term isolation is being used in
>     the draft-nsdt-teas-transport-slice-definition in a different
>     manner, particularly in Section 4.1.1. In that section, several
>     levels (hard and soft) of the isolation are discussed whereas
>     isolation of data flows, in my understanding, is always "hard". As
>     I've mentioned earlier, we might look for different terms when
>     referring to use/access to underlay resources vs. data flows
>     interaction.
> 
>     Regards,
>     Greg
> 
> 
>         As I mentioned during the virtual meeting, isolation was
>         described as a requirement in several PPVPN requirement and
>         framework RFCs. In summary, isolation is firstly required to
>         avoid unwanted exposure of both data traffic and routing
>         information, then it is also mentioned that isolation is needed
>         to avoid the effects of traffic congestion happened in other
>         VPNs in the network.
> 
>         Just quote some of them:
> 
>          > Cc: [email-masked] <mailto:[email-masked]>
>         endpoints the slice
>          > > <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>          > wrote:
>          > >
>          > >     Trimmed, in line.
>          > >     Joel
>          > >
>         <mailto:[email-masked]>
>          > >     <mailto:[email-masked]
>         <mailto:teas-bounces@ietf..org>>] On Behalf Of Joel M. Halpern
>         <mailto:[email-masked]>
>          > >     <mailto:[email-masked]
>         <mailto:[email-masked]>>>; [email-masked]
>         <mailto:[email-masked]>
>          > <mailto:[email-masked] <mailto:[email-masked]>>
>          > >     system, the customer may think that the issue is
>         isolation.  But
>          > >     what he
>          > >     large buffers are present but never used, we would all
>         be happy.  So
>          > >     the
>          > >      >>> 发件人: Joel M. Halpern
>         [mailto:[email-masked] <mailto:[email-masked]>
>          > >     <mailto:[email-masked] <mailto:[email-masked]>>]
>         <mailto:[email-masked]>
>          > >     <mailto:[email-masked]
>         <mailto:[email-masked]>>>; [email-masked]
>         <mailto:[email-masked]>
>          > <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>          > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>

---

From: Kiran Makhijani <[email-masked]>
Date: Thu, 30 Apr 2020 04:47:04 +0000

A lot of this should be seen in the context of why would we do slices? The way I see it - it is about supporting diverse set of services with their own set of SLOs. A few of those services really need complete separation and no interference, while others will have some wiggle room ( tolerance to some amount of interference). I am ok with what we call it - but both should be possible.
Seems to me most of the discussion we have had are in the generic sense and not considering the  slicing aspect.
-Kiran

Regards
Kiran

________________________________
From: Teas <[email-masked]> on behalf of Joel M. Halpern <[email-masked]>
Sent: Wednesday, April 29, 2020 8:22:37 PM
To: Greg Mirsky <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution

Yours,
Joel

On 4/29/2020 11:13 PM, Greg Mirsky wrote:
>          > >      >> More importantly, it is not something the customer
>         has any way
>          > >     to verify.
>          > >      >> PS: Note that I understand that operators get asked
>         for odd
>          > >     things mby
>          > >      >> customers.  But if we are going to define standards
>         to support
>          > >     it, we need to
>          > >      >>> Well, it's reasonable for people to request hard
>         isolation
>          > >     because 'I don't want
>          > >      >>> For delivery this can be achieved by separating
>         physical
>          > >     devices/connections,
>          > >      >> which are visible to users. For example dedicated
>         boxes and
>          > >     fibers will guarantee
>          > >      >>> 发件人: Joel M. Halpern
>          > >      >>>> BTW, regarding the isolation, I don't see the
>         necessity to
>          > >     argue whether it
>          > >      >> should be in SLO or not. The isolation itself, can
>         either be
>          > >     requested by the user
>          > >      >> of the transport slice (then from NBI of TSC) to
>         express the
>          > >     demand of reliability,
>          > >      >> or be offered by the provider of the transport
>         slice (then from
>          > >     the SBI of TSC) to
>          > >      >> achieve the SLO requested from the user. In other
>         words, if the
>          > >     user requests
>          > >      >> certain level of isolation in an SLO, such
>         isolation should be
>          > >     provided; if the user
>          > >      >> does not request certain level of isolation (no
>         isolation
>          > >     request in SLO), then
>          > >      >> there may be some isolation provided to satisfy the
>         user's
>          > request.
>          > >      >>>>
>          > >      >>>> Best wishes,
>          > >      >>>> Haomian
>          > >      >>
>          > >      >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022686963&amp;sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee%2Bw2e8XK5zZ0%3D&amp;reserved=0
>          > >
>          > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0
>          > >
>          > >
>          > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0
>          > >
>          >
>          > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0
>
>     https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0
>

_______________________________________________
Teas mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 30 Apr 2020 08:43:11 +0000

Hi Kiran,

I agree with Joel on the fact that we don’t need this distinction.
I don’t think the customer of the slice needs a complete separation, what is needed is a given performance.
If for some reasons there is the need to something totally dedicated with no interference, where there are the good old leased lines, right?

Cheers,
Daniele

From: Teas <[email-masked]> On Behalf Of Kiran Makhijani
Sent: den 30 april 2020 06:47
To: Joel M. Halpern <[email-masked]>; Greg Mirsky <[email-masked]>
Cc: [email-masked]
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution

Regards
Kiran

________________________________
From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Joel M. Halpern <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, April 29, 2020 8:22:37 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution

Yours,
Joel

<mailto:[email-masked]%20%0b>> <mailto:[email-masked]>> wrote:
>     On Tue, Apr 28, 2020 at 2:31 AM Dongjie (Jimmy) <[email-masked]
<mailto:[email-masked]%0b>>     <mailto:[email-masked]>> wrote:
>          > To: Greg Mirsky <[email-masked]
<mailto:[email-masked]%0b>>         <mailto:[email-masked]>>
>          > Cc: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
<mailto:[email-masked]%0b>>         <mailto:[email-masked]>
>         <mailto:[email-masked]
<mailto:[email-masked]%0b>>         <mailto:[email-masked]>>>
>          > >      >> To: Zhenghaomian <[email-masked]
<mailto:[email-masked]%0b>>         <mailto:[email-masked]>
>          > >     <mailto:[email-masked]
<mailto:[email-masked]%0b>>         <mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
>          > >      >>> Not sure if I understand your question correctly..
<mailto:[email-masked]%0b>>         <mailto:[email-masked]>
>          > >     <mailto:[email-masked]
<mailto:[email-masked]%0b>>         <mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]>
>          > >      >> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>          > >      >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022686963&amp;sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee%2Bw2e8XK5zZ0%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=863b9a86-dab23545-863bda1d-0cc47ad93d36-b3362418dc02d3f6&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022686963%26amp%3Bsdata%3DhF6Uo1VE2OQyRm1EsWlbtO3whH1phaee%252Bw2e8XK5zZ0%253D%26amp%3Breserved%3D0>
>          > >
>          > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> <mailto:[email-masked]
<mailto:[email-masked]%0b>>         <mailto:[email-masked]>>
>          > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=5a325ab1-06bbf572-5a321a2a-0cc47ad93d36-947af5a2ee92c483&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>
>          > >
>          > >
>          > > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>          > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=2a48ccd9-76c1631a-2a488c42-0cc47ad93d36-b6d9c9f1274be9cf&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>
>          > >
>          >
>          > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>          > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=39a40fbd-652da07e-39a44f26-0cc47ad93d36-03a7d986e4f736a1&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>
>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>     https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=7b928849-271b278a-7b92c8d2-0cc47ad93d36-695f10ee0b5d178a&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>
>

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=2b5032e0-77d99d23-2b50727b-0cc47ad93d36-4a8555bbe875224c&q=1&e=de9c3dd0-284d-4520-b57a-42c1d74c97c8&u=https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fteas%26amp%3Bdata%3D02%257C01%257Ckiranm%2540futurewei.com%257C248a23140e1a44a2aff008d7ecb5d308%257C0fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637238138022696959%26amp%3Bsdata%3Ddyr8KnHm1N1A193%252FHsl0S9I3LczD5cvx60HfJVnNcDc%253D%26amp%3Breserved%3D0>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 Apr 2020 09:47:57 -0400

I think we all agree that we need to support a range of services.

We need to know the parameters of those services.  If "complete 
separation" is an observable rather than a philosophical concept, then 
define what it means in terms of observables.  Heck, we have claimed 
conceptually that VPNs already provide "separation", but we do not make 
that a parameter of the VPN.

Similarly, if "interference" is an observable, define it.  Remembering 
that from the perspective of the customer of the slice, the customer 
cares about effects on his traffic, not on causes.

This is described as a definitions document.  Not a conceptual 
discussion document.

Yours,
Joel

On 4/30/2020 12:47 AM, Kiran Makhijani wrote:
> A lot of this should be seen in the context of why would we do slices? 
> The way I see it - it is about supporting diverse set of services with 
> their own set of SLOs. A few of those services really need complete 
> separation and no interference, while others will have some wiggle room 
> ( tolerance to some amount of interference). I am ok with what we call 
> it - but both should be possible.
> ------------------------------------------------------------------------
> *From:* Teas <[email-masked]> on behalf of Joel M. Halpern 
> <[email-masked]>
> *Sent:* Wednesday, April 29, 2020 8:22:37 PM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* Re: [Teas] Network Slicing design team definitions - 
> isolation and resolution
>>     <mailto:[email-masked]>> wrote:
>> 
>>         Hi Joel and Greg,
>> 
>>          > -----Original Message-----
>>          > From: Teas [mailto:[email-masked]
>>          > Sent: Tuesday, April 28, 2020 5:33 AM
>>          > To: Greg Mirsky <[email-masked]
>>         <mailto:[email-masked]>>
>>          > Cc: [email-masked] <mailto:[email-masked]>
>>          > Subject: Re: [Teas] Network Slicing design team definitions -
>>         isolation and
>>          > resolution
>>          >
>>          > Greg, that definition seems to be a specific subset of VPN.
>>          > As far as I can tell, the slice definition does include what
>>         endpoints the slice
>>          > participants can talk to.  Presumably, with some way to say
>>         "the Internet".
>>          > So Whether the slice supports communication with the Internet
>>         or not is
>>          > definitely an observable property.  I would tend not to call
>>         it isolation.
>>          > Separately, the definition you propose is unrelated to the
>>         definition in the
>>          > document, Which is why I suggest, for now, removing all
>>         discussion of
>>          > isolation from the document.
>>          >
>>          > Yours,
>>          > Joel
>>          >
>>          > On 4/27/2020 5:22 PM, Greg Mirsky wrote:
>>          > > Dear Joel,
>>          > > thank you for bringing the matter of "isolation" to the
>>         discussion. I
>>          > > agree, that it is not practical to expect physical
>>         isolation in modern
>>          > > networks. In my view, a transport slice that requires
>>         isolation is as
>>          > > a transport connection that expects to receive data only
>>         from the
>>          > > specific domain and not from any other domain. In other
>>         words, I view
>>          > > isolation as the absence of mis-connectivity (in transport
>>         network
>>          > > interpretation which differentiates between path continuity
>>         check and
>>          > > connectivity verification). If my interpretation is
>>         acceptable, then
>>          > > isolation can be monitored using connectivity verification OAM
>>          > mechanism(s).
>>          > > I much appreciate your thoughts, opinion on the proposed
>>          > > interpretation of isolation on transport slice.
>>          > >
>>          > > Regards,
>>          > > Greg
>>          > >
>>          > > On Sun, Apr 26, 2020 at 8:57 AM Joel Halpern Direct
>>          > > <[email-masked]
>>          > wrote:
>>          > >
>>          > >     Trimmed, in line.
>>          > >     Joel
>>          > >
>>          > >     On 4/26/2020 11:08 AM, Dongjie (Jimmy) wrote:
>>          > >      > Hi Joel,
>>          > >      >
>>          > >      > Please see some replies inline:
>>          > >      >
>>          > >      >> -----Original Message-----
>>          > >      >> From: Teas [mailto:[email-masked]
>>          > >     <mailto:[email-masked]
>>          > >      >> Sent: Sunday, April 26, 2020 10:52 AM
>>          > >      >> To: Zhenghaomian <[email-masked]
>>          > >     <mailto:[email-masked]
>>          > <mailto:[email-masked] <mailto:[email-masked]>>
>>          > >      >> Subject: Re: [Teas] Network Slicing design team
>>         definitions -
>>          > >     isolation and
>>          > >      >> resolution
>>          > >      >>
>>          > >     ....
>>          > >      >> More importantly, it is not something the customer
>>         has any way
>>          > >     to verify.
>>          > >      >> There is no test a customer can run that will
>>         verify this.
>>          > >      >> Making unverifiable promises is rarely a useful
>>         thing to do.
>>          > >      >
>>          > >      > Totally agree that tools for verification is
>>         important. As
>>          > >     mentioned in Haomian's mail, isolation can be verified
>>         with suitable
>>          > >     tools which can be used to collect the information at
>>         the necessary
>>          > >     places with a suitable interval. And it is important
>>         that customers
>>          > >     can be provided with such tools to monitor the
>>         performance and be
>>          > >     informed of SLA violation.
>>          > >
>>          > >     As far as I can tell, the observable that you describe
>>         is latency
>>          > >     variation (or maybe loss).  Fine, describe the SLO in
>>         terms of latency
>>          > >     variation  (or loss).  Given that there are always
>>         imperfections in
>>          > the
>>          > >     system, the customer may think that the issue is
>>         isolation.  But
>>          > >     what he
>>          > >     can observe, and as far as I can tell what he cares
>>         about, is delay
>>          > >     variation, loss, or other factors that affect his traffic.
>>          > >
>>          > >     To use a different example, I have learned from the
>>         advocates to hate
>>          > >     bufferbloat.  But even their tests measure delay, delay
>>         variation,
>>          > >     etc..
>>          > >     They then infer the presence of large buffers.  But in
>>         fact, if the
>>          > >     large buffers are present but never used, we would all
>>         be happy.  So
>>          > >     the
>>          > >     SLO on this would be in terms of latency, latency
>>         variation, loss, etc.
>>          > >     Not bufferbloat.`
>>          > >
>>          > >     Yours,
>>          > >     Joel
>>          > >
>>          > >      >
>>          > >      > Best regards,
>>          > >      > Jie
>>          > >      >
>>          > >      >>
>>          > >      >> Yours,
>>          > >      >> Joel
>>          > >      >>
>>          > >      >> PS: Note that I understand that operators get asked
>>         for odd
>>          > >     things mby
>>          > >      >> customers.  But if we are going to define standards
>>         to support
>>          > >     it, we need to
>>          > >      >> understand the actual need.
>>          > >      >>
>>          > >      >> On 4/25/2020 10:44 PM, Zhenghaomian wrote:
>>          > >      >>> Not sure if I understand your question correctly..
>>          > >      >>> Well, it's reasonable for people to request hard
>>         isolation
>>          > >     because 'I don't want
>>          > >      >> my data to be transported together with other
>>         people's data'.
>>          > >      >>> For delivery this can be achieved by separating
>>         physical
>>          > >     devices/connections,
>>          > >      >> which are visible to users. For example dedicated
>>         boxes and
>>          > >     fibers will guarantee
>>          > >      >> the user's data is not mixed with others...
>>          > >      >>>
>>          > >      >>> Best wishes,
>>          > >      >>> Haomian
>>          > >      >>>
>>          > >      >>> -----邮件原件-----
>>          > >      >>> 发件人: Joel M. Halpern
>>          > >     <mailto:[email-masked] <mailto:[email-masked]>>]
>>          > >      >>> 发送时间: 2020年4月26日 10:34
>>          > >      >>> 收件人: Zhenghaomian <[email-masked]
>>          > >     <mailto:[email-masked]
>>          > <mailto:[email-masked] <mailto:[email-masked]>>
>>          > >      >>> 主题: Re: [Teas] Network Slicing design team
>>         definitions -
>>          > >     isolation and
>>          > >      >>> resolution
>>          > >      >>>
>>          > >      >>> (trimmed)
>>          > >      >>> What is the user perceivable effect that the user
>>         is asking for
>>          > >     when you say "if
>>          > >      >> the user requests isolation"?
>>          > >      >>>
>>          > >      >>> Yours,
>>          > >      >>> Joel
>>          > >      >>>
>>          > >      >>> On 4/25/2020 10:31 PM, Zhenghaomian wrote:
>>          > >      >>>> Hi, Kiran, Joel,
>>          > >      >>>>
>>          > >      >>> ...
>>          > >      >>>> BTW, regarding the isolation, I don't see the
>>         necessity to
>>          > >     argue whether it
>>          > >      >> should be in SLO or not. The isolation itself, can
>>         either be
>>          > >     requested by the user
>>          > >      >> of the transport slice (then from NBI of TSC) to
>>         express the
>>          > >     demand of reliability,
>>          > >      >> or be offered by the provider of the transport
>>         slice (then from
>>          > >     the SBI of TSC) to
>>          > >      >> achieve the SLO requested from the user. In other
>>         words, if the
>>          > >     user requests
>>          > >      >> certain level of isolation in an SLO, such
>>         isolation should be
>>          > >     provided; if the user
>>          > >      >> does not request certain level of isolation (no
>>         isolation
>>          > >     request in SLO), then
>>          > >      >> there may be some isolation provided to satisfy the
>>         user's
>>          > request.
>>          > >      >>>>
>>          > >      >>>> Best wishes,
>>          > >      >>>> Haomian
>>          > >      >>
>>          > >      >> _______________________________________________
>>          > >      >> Teas mailing list
>>          > >      >> [email-masked] <mailto:[email-masked]>
>>          > >      >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022686963&amp;sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee%2Bw2e8XK5zZ0%3D&amp;reserved=0
>>          > >
>>          > >     _______________________________________________
>>          > >     Teas mailing list
>>          > > [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>>         <mailto:[email-masked]>>
>>          > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0
>>          > >
>>          > >
>>          > > _______________________________________________
>>          > > Teas mailing list
>>          > > [email-masked] <mailto:[email-masked]>
>>          > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0
>>          > >
>>          >
>>          > _______________________________________________
>>          > Teas mailing list
>>          > [email-masked] <mailto:[email-masked]>
>>          > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&amp;data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&amp;sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&amp;reserved=0
>>

---

From: John E Drake <[email-masked]>
Date: Thu, 30 Apr 2020 14:11:10 +0000

Hi,

As someone pointed out, even 'hard isolation' does not use completely dedicated resources;  i.e., it shares software, hardware, wavelengths, fibers, power, etc.  I think that what people have in mind when they talk about 'hard isolation' is something like a TDM circuit.  If this is the case, then it should be possible to describe it in terms of an SLO/SLA because there have been SLOs/SLAs for TDM circuits since the dawn of time.

Yours Irrespectively,

John

Juniper Business Use Only

> From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
> Sent: Thursday, April 30, 2020 9:48 AM
> To: Kiran Makhijani <[email-masked]>
> Cc: [email-masked]
> [External Email. Be cautious of content]
>
>
> We need to know the parameters of those services.  If "complete separation" is
> an observable rather than a philosophical concept, then define what it means in
> terms of observables.  Heck, we have claimed conceptually that VPNs already
> provide "separation", but we do not make that a parameter of the VPN.
>
> Similarly, if "interference" is an observable, define it.  Remembering that from
> the perspective of the customer of the slice, the customer cares about effects
> on his traffic, not on causes.
>
> This is described as a definitions document.  Not a conceptual discussion
> document.
>
> Yours,
> Joel
>
> > separation and no interference, while others will have some wiggle
> > room ( tolerance to some amount of interference). I am ok with what we
> > call it - but both should be possible.
> > Seems to me most of the discussion we have had are in the generic
> > sense and not considering the  slicing aspect.
> > -Kiran
> >
> > Regards
> > Kiran
> >
> > isolation and resolution I have never seen a good or useful
> > distinction between hard and soft isolation.  The one described in the
> > draft (based on causes of failure) is not effective.
> >
> > better than 5 9s.  And some are one 9.  Niether is hard.  And neither
> > is soft.
> >
> > Yours,
> > Joel
> >
> >> introduce the notion of "hard isolation" and "soft isolation", then,
> >> in my opinion, we acknowledge that in some cases isolation is not
> >> isolation. But for soft isolation, I think, a network might be
> >> affected by another network.
> >>         RFC 3809: Generic Requirements for Provider Provisioned
> >>Virtual
> >>         Private Networks (PPVPN)
> >>
> >>         4.4.  Data isolation
> >>
> >>             never deliver user data across VPN boundaries unless the
> >>two
> >>         VPNs
> >>             Furthermore, if the provider network receives signaling
> >>or
> >>         routing
> >>         RFC 4031: Service Requirements for Layer 3 Provider
> >>Provisioned
> >>         Virtual Private Networks (PPVPNs)
> >>
> >>             reachability information to only those sites associated
> >>with
> >>         a VPN.
> >>             ...
> >>             information to only those sites that are part of a VPN
> >>may
> >>         be viewed
> >>             requirements that isolates VPN traffic from the effects
> >>of
> >>         traffic
> >>             offered by non-VPN customers.  Also, L3VPN solutions
> >>SHOULD
> >>         provide a
> >>         RFC 4110: A Framework for Layer 3 Provider-Provisioned
> >>Virtual
> >>         Private Networks (PPVPNs)
> >>
> >>             route the VPN traffic based on the customer addresses
> >>found
> >>         in the IP
> >>             headers; this implies that the PE devices need to
> >>maintain a
> >>         level of
> >>             isolation between different VPN traffic flows.  The QoS
> >>and
> >>         security
> >>             requirements for these traffic flows may differ, and can
> >>be
> >>         met by
> >>          > participants can talk to.  Presumably, with some way to
> >>say
> >>         "the Internet".
> >>          > So Whether the slice supports communication with the
> >>Internet
> >>         or not is
> >>          > definitely an observable property.  I would tend not to
> >>call
> >>         it isolation.
> >>          > > isolation as the absence of mis-connectivity (in
> >>transport
> >>         network
> >>          > > interpretation which differentiates between path
> >>continuity
> >>         check and
> >>          > > isolation can be monitored using connectivity
> >>verification OAM
> >>          > mechanism(s).
> https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook.com/
> ?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas&amp;data=02
> *7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ecb5d308*7
> C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637238138022686963&am
> p;sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee*2Bw2e8XK5zZ0*3D&amp;re
> served=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-
> iOcrp4s1zN_XiiFeC3u8lY63P9B6s9o0GYqZsXjvd9O8a4$
> >>          > >
> >>https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook
> >>.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas&amp;
> d
> >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec
> b5d30
> >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695
> 9&amp;
> >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;reserv
> ed=0_
> >>_;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF
> >>eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$
> >>          > >
> >>          > >
> >>https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook
> >>.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas&amp;
> d
> >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec
> b5d30
> >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695
> 9&amp;
> >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;reserv
> ed=0_
> >>_;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF
> >>eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$
> >>          > >
> >>          >
> >>https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook
> >>.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas&amp;
> d
> >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec
> b5d30
> >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695
> 9&amp;
> >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;reserv
> ed=0_
> >>_;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF
> >>eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$
> >>
> >>https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook
> >>.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas&amp;
> d
> >>ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ec
> b5d30
> >>8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C63723813802269695
> 9&amp;
> >>sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;reserv
> ed=0_
> >>_;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF
> >>eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$
> >>
> >
> > https://urldefense.com/v3/__https://nam11.safelinks.protection.outlook
> >
> .com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas&amp;d
> >
> ata=02*7C01*7Ckiranm*40futurewei.com*7C248a23140e1a44a2aff008d7ecb5
> d30
> >
> 8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637238138022696959&
> amp;
> >
> sdata=dyr8KnHm1N1A193*2FHsl0S9I3LczD5cvx60HfJVnNcDc*3D&amp;reserved
> =0_
> > _;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-iOcrp4s1zN_XiiF
> > eC3u8lY63P9B6s9o0GYqZsXjgUN8ytU$
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!SA_HL9cyyH-DrEoq-
> iOcrp4s1zN_XiiFeC3u8lY63P9B6s9o0GYqZ
> > sXjcmeGkV4$
> >
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!SA_HL9cyyH-DrEoq-
> iOcrp4s1zN_XiiFeC3u8lY63P9B6s9o0GYqZsXjcmeGkV4$

Juniper Business Use Only

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 30 Apr 2020 14:36:16 +0000 (UTC)

Hi Joel,

I am not disagreeing with you, but, please, consider this:

If I see packets in my network/slice that I am not supposed to be seeing, this may not affect the observables like delay, availability, etc., but would still be not a good thing, because it would be surely a safe assumption (or at least concern) that my own packets are showing up in other people's networks/slices. Taking your example with buses and taxis. If I buy a bus ticket, it is probable that the bus will be (completely or almost) empty, and I will get the satisfactory degree of isolation, but this is not in any way guaranteed, therefore, I am willing to pay more and get the cab. Your argument, as I understand, is that in this case the isolation is observable - for example, I may disallow the cab driver to take another passenger despite the passenger is heading to the same destination and there is room in the cab. I am curious, could detected unknown traffic be  some proof of non-isolation?  What am I missing here?

Regards,
Igor

    On Thursday, April 30, 2020, 9:48:27 AM EDT, Joel M. Halpern <[email-masked]> wrote:  

Yours,
Joel

On 4/30/2020 12:47 AM, Kiran Makhijani wrote:
>>          > >      >> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022686963&sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee%2Bw2e8XK5zZ0%3D&reserved=0
>>          > >
>>          > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0
>>          > >
>>          > >
>>          > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0
>>          > >
>>          >
>>          > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0
>> 
>>    https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0
>> 
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022696959&sdata=dyr8KnHm1N1A193%2FHsl0S9I3LczD5cvx60HfJVnNcDc%3D&reserved=0
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 30 Apr 2020 11:03:23 -0400

I expect )assuming it is carefully phrased) that I could live with a 
requirement that one receives only ones own traffic.  That is, after 
all, what we expect of existing VPNs.  It does not have anything to do 
with isloation as currently described in the document.

That is one of the few SLOs that I could imagine (and even expect) to be 
associated with being delivered 100% of the time.

My only real concern with it is that I do not see any point in wasting 
parameter exchange on it.  Unless one wants to describe Internet 
connectivity as a slice (not sure why one would want to.)  In which 
case, yes, it is a simple parameter.

Yours,
Joel

On 4/30/2020 10:36 AM, Igor Bryskin wrote:
> If I see packets in my network/slice that I am not supposed to be 
> seeing, this may not affect the observables like delay, availability, 
> etc., but would still be not a good thing, because it would be surely a 
> safe assumption (or at least concern) that my own packets are showing up 
> in other people's networks/slices. Taking your example with buses and 
> taxis. If I buy a bus ticket, it is probable that the bus will be 
> (completely or almost) empty, and I will get the satisfactory degree of 
> isolation, but this is not in any way guaranteed, therefore, I am 
> willing to pay more and get the cab. Your argument, as I understand, is 
> that in this case the isolation is observable - for example, I may 
> disallow the cab driver to take another passenger despite the passenger 
> is heading to the same destination and there is room in the cab. I am 
> curious, could detected unknown traffic be  some proof of 
> non-isolation?  What am I missing here?
> 
> Regards,
> Igor
> 
> 
> 
>  > *From:* Teas <[email-masked] <mailto:[email-masked]>> 
> on behalf of Joel M. Halpern
>  > <[email-masked] <mailto:[email-masked]>>
>  > *To:* Greg Mirsky <[email-masked] <mailto:[email-masked]>>
>  > *Cc:* [email-masked] <mailto:[email-masked]> <[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked]>
>  >> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>  >>
>  >>     Hi Greg,
>  >>
>  >>     <[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>  >>
>  >>
>  >>     Hi Jie,
>  >>     On Tue, Apr 28, 2020 at 2:31 AM Dongjie (Jimmy) 
> <[email-masked] <mailto:[email-masked]>
>  >>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>  >>
>  >>         Hi Joel and Greg,
>  >>
> <mailto:[email-masked]>>] On Behalf Of Joel M. Halpern
> <mailto:[email-masked]>
>  >>         <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked]>>
> <mailto:[email-masked]>>>>
>  >>          > wrote:
>  >>          > >
>  >>          > >     Trimmed, in line.
>  >>          > >     Joel
>  >>          > >
>  >>         <mailto:[email-masked] <mailto:[email-masked]>>
>  >>         <mailto:teas-bounces@ietf..org 
> <mailto:teas-bounces@ietf..org>>>] On Behalf Of Joel M. Halpern
> <mailto:[email-masked]>>
> <mailto:[email-masked]>>>>; [email-masked] <mailto:[email-masked]>
>  >>          > <mailto:[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked] <mailto:[email-masked]>>
>  >>          > >     <mailto:[email-masked] 
> <mailto:[email-masked]> <mailto:[email-masked] 
> <mailto:[email-masked]>>>]
> <mailto:[email-masked]>>
> <mailto:[email-masked]>>>>; [email-masked] <mailto:[email-masked]>
>  >>          > <mailto:[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>
>  >>         <mailto:[email-masked] <mailto:[email-masked]> 
> <mailto:[email-masked] <mailto:[email-masked]>>>
>  >>          > >      >> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas&data=02%7C01%7Ckiranm%40futurewei.com%7C248a23140e1a44a2aff008d7ecb5d308%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637238138022686963&sdata=hF6Uo1VE2OQyRm1EsWlbtO3whH1phaee%2Bw2e8XK5zZ0%3D&reserved=0
>  >>          > >
> <mailto:[email-masked] <mailto:[email-masked]>> <mailto:[email-masked] 
> <mailto:[email-masked]>
>  >>         <mailto:[email-masked] <mailto:[email-masked]>>>
>  >>          > >