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

[John E Drake <[e-mail]>]

This is exactly correct.  How an SP chooses to meet an SLO is their business.

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Teas <[e-mail]> On Behalf Of Joel M. Halpern
> Sent: Tuesday, April 28, 2020 11:52 PM
> To: Zhenghaomian <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Teas] Network Slicing design team definitions - isolation and
> resolution
> 
> [External Email. Be cautious of content]
> 
> 
> On the topic of isolation, I would suggest that you
> 1) remove the current text related to isolation
> 2) figure out what it is that is observable and well-defined
> 3) figure out a name for that, and propose the name and definition
> 
> I presume that this addition will require discussion among the design team, since
> it would be a significant change to the document.  Or it could be proposed in a
> separate document for now.
> 
> Separately, I suggest a similar approach to the current resolution text, as it does
> not make sense as written.
> 
> Yours,
> Joel
> 
> On 4/28/2020 11:36 PM, Zhenghaomian wrote:
> > Hi, All,
> >
> > Agree on we have multiple kinds of isolations, and we may need to
> > differentiate them. It reminds me in some previous discussions we may
> > separate the isolation from the user side and from the network side.
> >
> > Isolation at the user side: just indicate the demand about a
> > comprehensive performance from the user. For example, when requesting
> > a transport slice, request some isolation if the user is sensitive to
> > latency (or something similar); or, don’t request any isolation if the
> > user is not sensitive to such parameters.
> >
> > Isolation at the network side: how to technically guarantee the
> > isolation (in VPN, etc.), which is already existing as cited in Jie’s
> > email.
> >
> > Basically I think we need the ‘isolation at the user side’, but this
> > isolation is different with what is indicated in ‘Isolation at the
> > network side’. We may need better definition on ‘isolation as a part
> > of SLO’, instead of simply removing it.
> >
> > Best wishes,
> >
> > Haomian
> >
> > *发件人:*Teas [mailto:[e-mail]] *代表 *Igor Bryskin
> > *发送时间:*2020年4月29日1:52
> > *收件人:*Dongjie (Jimmy) <[e-mail]>; Greg Mirsky
> > <[e-mail]>
> > *抄送:*Joel M. Halpern <[e-mail]>; [e-mail]
> > *主题:*Re: [Teas] Network Slicing design team definitions - isolation
> > and resolution
> >
> > 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:teas-
> bounces@ietf..org>] 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:jmh.direct@joelhalpern..com>
> >     <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:teas-
> [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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$
> >     > >
> >     > >     _______________________________________________
> >     > >     Teas mailing list
> >     > >     [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> >     <mailto:[e-mail]>>
> >     > >
> https://urldefense.com/v3/__https://www.ietf..org/mailman/listinfo/teas__;!!
> NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGW8R9S1s$
> >
> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!
> NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$ >
> >     > >
> >     > >
> >     > > _______________________________________________
> >     > > Teas mailing list
> >     > > [e-mail] <mailto:[e-mail]>
> >     > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$
> >     > >
> >     >
> >     > _______________________________________________
> >     > Teas mailing list
> >     > [e-mail] <mailto:[e-mail]>
> >     >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-
> m9b0CoNPmTInchmF-5E564
> > tOGGuu5Hro$
> >
> > _______________________________________________
> > Teas mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-
> m9b0CoNPmTInchmF-5E564
> > tOGGuu5Hro$
> >
> 
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$