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

From: Zhenghaomian <[email-masked]>
Date: Wed, 29 Apr 2020 03:36:33 +0000

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:[email-masked]] 代表 Igor Bryskin
发送时间: 2020年4月29日 1:52
收件人: Dongjie (Jimmy) <[email-masked]>; Greg Mirsky <[email-masked]>
抄送: Joel M. Halpern <[email-masked]>; [email-masked]
主题: 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 <[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

On Tue, Apr 28, 2020 at 2:31 AM Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> 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:[email-masked]<mailto:teas-bounces@ietf..org>] On Behalf Of Joel M. Halpern
> 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]<mailto:jmh.direct@joelhalpern..com> <mailto:[email-masked]<mailto:[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]>
> >     <mailto:[email-masked]<mailto:teas-bounces@ietf..org>>] On Behalf Of Joel M. Halpern
> >      >> Sent: Sunday, April 26, 2020 10:52 AM
> >      >> To: Zhenghaomian <[email-masked]<mailto:[email-masked]>
> >     <mailto:[email-masked]<mailto:[email-masked]>>>; [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]>
> >     <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]>>
> >      >>> 主题: 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]> <mailto:[email-masked]<mailto:[email-masked]>>
> >      >> https://www.ietf.org/mailman/listinfo/teas
> >
> >     _______________________________________________
> >     Teas mailing list
> >     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> >     https://www.ietf..org/mailman/listinfo/teas<https://www.ietf.org/mailman/listinfo/teas>
> >
> >
> > _______________________________________________
> > Teas mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/teas
> >
>
> _______________________________________________
> Teas mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/teas
_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 28 Apr 2020 23:51:57 -0400

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:[email-masked]] *代表 *Igor Bryskin
> *发送时间:*2020年4月29日1:52
> *收件人:*Dongjie (Jimmy) <[email-masked]>; Greg Mirsky 
> <[email-masked]>
> *抄送:*Joel M. Halpern <[email-masked]>; [email-masked]
> *主题:*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 
> <[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:
> 
>     > From: Teas [mailto:[email-masked] <mailto:teas-bounces@ietf..org>] On Behalf Of
>     Joel M. Halpern
>     > To: Greg Mirsky <[email-masked] <mailto:[email-masked]>>
>     > Cc: [email-masked] <mailto:[email-masked]>
>     > > <[email-masked] <mailto:jmh.direct@joelhalpern..com>
>     <mailto:[email-masked] <mailto:[email-masked]>>>
>     > wrote:
>     > >
>     > >     Trimmed, in line.
>     > >     Joel
>     > >
>     > >      > Hi Joel,
>     > >      >
>     > >      > Please see some replies inline:
>     > >      >
>     > >      >> -----Original Message-----
>     > >      >> From: Teas [mailto:[email-masked] <mailto:[email-masked]>
>     > >     <mailto:[email-masked] <mailto:teas-bounces@ietf..org>>] On Behalf Of
>     Joel M. Halpern
>     > >      >> Sent: Sunday, April 26, 2020 10:52 AM
>     > >      >> To: Zhenghaomian <[email-masked] <mailto:[email-masked]>
>     > >     <mailto:[email-masked] <mailto:[email-masked]>>>;
>     [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
>     > >      >
>     > >      > 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]>
>     > >     <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]>>
>     > >      >>> 主题: 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]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     > >      >> https://www.ietf.org/mailman/listinfo/teas
>     > >
>     > >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     > >     https://www.ietf..org/mailman/listinfo/teas
>     <https://www.ietf.org/mailman/listinfo/teas>
>     > >
>     > >
>     > > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: John E Drake <[email-masked]>
Date: Wed, 29 Apr 2020 13:57:45 +0000

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

Yours Irrespectively,

John

Juniper Business Use Only

> From: Teas <[email-masked]> On Behalf Of Joel M. Halpern
> Sent: Tuesday, April 28, 2020 11:52 PM
> To: Zhenghaomian <[email-masked]>
> Cc: [email-masked]
> [External Email. Be cautious of content]
> 
> 
> 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
> 
> > comprehensive performance from the user. For example, when requesting
> > a transport slice, request some isolation if the user is sensitive to
> > network side’. We may need better definition on ‘isolation as a part
> > of SLO’, instead of simply removing it.
> >
> > Best wishes,
> >
> > Haomian
> >
> > 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
> > pointed out, the term isolation is being used in the
> > draft-nsdt-teas-transport-slice-definition in a different manner,
> > 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
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$
> >     > >
> 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$ >
> >     > >
> >     > >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$
> >     > >
> >     >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-
> m9b0CoNPmTInchmF-5E564
> > tOGGuu5Hro$
> >
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas
> > __;!!NEt6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-
> m9b0CoNPmTInchmF-5E564
> > tOGGuu5Hro$
> >
> 
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas__;!!N
> Et6yMaO-gk!RCLTSUdiC4YDLf34fu9GfHdhmwhODl-m9b0CoNPmTInchmF-
> 5E564tOGGuu5Hro$

---

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

Hi Joel, 

Based on the recent mail discussion, my understanding is most people agree that isolation is one requirement which needs to be documented in this document. Based on the discussion, the text may need to be further revised, hope both design team and mail list discussion could be helpful to make it clearer. 

Best regards,
Jie

> From: Teas [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Wednesday, April 29, 2020 11:52 AM
> 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.
> 
> >     > From: Teas [mailto:[email-masked]
> <mailto:teas-bounces@ietf..org>] On Behalf Of
> >     Joel M. Halpern
> >     > >     <mailto:[email-masked]
> <mailto:teas-bounces@ietf..org>>] On Behalf Of
> >     Joel M. Halpern

---

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

Jie, please leave drawing conclusions about what "most people believe" 
to the WG chairs.  While not many people have spoken up, I do not think 
it is fair to conclude that we know what "most people believe".

As far as I can tell, there i snot even agreement on the list about what 
"isolation" means, as I have seen different defenses with very different 
explanations.  Most of which do not match the discussion in the draft.

Yours,
Joel

---

From: David Sinicrope <[email-masked]>
Date: Wed, 29 Apr 2020 13:13:51 -0400

I’ve been following this thread although haven’t commented mostly because I agree with Joel on all points and he has articulated them far better than I could have.

WG Chairs, Please exclude me from Jie’s “most people”.

Dave

> On Apr 29, 2020, at 10:29 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Jie, please leave drawing conclusions about what "most people believe" to the WG chairs.  While not many people have spoken up, I do not think it is fair to conclude that we know what "most people believe".
> 
> As far as I can tell, there i snot even agreement on the list about what "isolation" means, as I have seen different defenses with very different explanations.  Most of which do not match the discussion in the draft.
> 
> Yours,
> Joel
> 
>>> <mailto:[email-masked]>
>>>>     > >      >>> 发送时间: 2020年4月26日10:34
>>> <mailto:[email-masked]