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

["Joel M. Halpern" <[e-mail]>]

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 
> <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
>     <mailto:[e-mail]>] On Behalf Of Joel M. Halpern
>      >> Sent: Sunday, April 26, 2020 10:52 AM
>      >> To: Zhenghaomian <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>      >> 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:[e-mail]
>     <mailto:[e-mail]>]
>      >>> 发送时间: 2020年4月26日 10:34
>      >>> 收件人: Zhenghaomian <[e-mail]
>     <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>      >>> 主题: 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
>      >> [e-mail] <mailto:[e-mail]>
>      >> https://www.ietf.org/mailman/listinfo/teas
> 
>     _______________________________________________
>     Teas mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/teas
> 
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>