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

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

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.
> 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 <[e-mail]> on behalf of Joel M. Halpern 
> <[e-mail]>
> *Sent:* Wednesday, April 29, 2020 8:22:37 PM
> *To:* Greg Mirsky <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>
> *Subject:* Re: [Teas] Network Slicing design team definitions - 
> 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.
> 
> 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:
>> 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 <[e-mail] 
>> <mailto:[e-mail]>> 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
>>     <[e-mail] <mailto:[e-mail]>> 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
>> 
>> 
>>     On Tue, Apr 28, 2020 at 2:31 AM Dongjie (Jimmy) <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>> 
>>         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
>> 
>>          > -----Original Message-----
>>          > From: Teas [mailto:[e-mail]
>>         <mailto:[e-mail]>] On Behalf Of Joel M. Halpern
>>          > Sent: Tuesday, April 28, 2020 5:33 AM
>>          > To: Greg Mirsky <[e-mail]
>>         <mailto:[e-mail]>>
>>          > Cc: [e-mail] <mailto:[e-mail]>
>>          > 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
>>          > > <[e-mail]
>>         <mailto:[e-mail]>
>>         <mailto:[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]>
>>          > >     <mailto:[e-mail]
>>         <mailto:teas-bounces@ietf..org>>] On Behalf Of Joel M. Halpern
>>          > >      >> Sent: Sunday, April 26, 2020 10:52 AM
>>          > >      >> To: Zhenghaomian <[e-mail]
>>         <mailto:[e-mail]>
>>          > >     <mailto:[e-mail]
>>         <mailto:[e-mail]>>>; [e-mail]
>>         <mailto:[e-mail]>
>>          > <mailto:[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]>
>>          > >     <mailto:[e-mail] <mailto:[e-mail]>>]
>>          > >      >>> 发送时间: 2020年4月26日 10:34
>>          > >      >>> 收件人: Zhenghaomian <[e-mail]
>>         <mailto:[e-mail]>
>>          > >     <mailto:[e-mail]
>>         <mailto:[e-mail]>>>; [e-mail]
>>         <mailto:[e-mail]>
>>          > <mailto:[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]>
>>         <mailto:[e-mail] <mailto:[e-mail]>>
>>          > >      >> 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
>>          > > [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
>>         <mailto:[e-mail]>>
>>          > > 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
>>          > > [e-mail] <mailto:[e-mail]>
>>          > > 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
>>          > [e-mail] <mailto:[e-mail]>
>>          > 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
>>     [e-mail] <mailto:[e-mail]>
>>     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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>