Re: [Teas] Network Slicing design team definitions - isolation and resolution
"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 29 April 2020 03:52 UTC
Return-Path: <jmh@joelhalpern.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C751D3A0E0C for <teas@ietfa.amsl.com>; Tue, 28 Apr 2020 20:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmJpAvYTsIAe for <teas@ietfa.amsl.com>; Tue, 28 Apr 2020 20:51:59 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8EC3A0E0B for <teas@ietf.org>; Tue, 28 Apr 2020 20:51:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 49Bl275DLcz6GDxT; Tue, 28 Apr 2020 20:51:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1588132319; bh=WcMVBXMV8ZpheW+91zl8k0xPXGVJxRyEowgHgQvU3kM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Sizj2P+dmx3ca2QdgHiDtjNL/01P2ZGtH2ilLo4wHkDjidF1trtx+9sAND+3mIh0Z 6UbP6GZgpLMr+UDDegZGkwaFIimCXqPX1Tn3L+1NeOwoevAvJjWX1Pf26IhhRI/pam 584w+0zXhVcVGIbpjkdSIOWlrrCcVtbCZ1kSut/A=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 49Bl264jjJz6GDc6; Tue, 28 Apr 2020 20:51:58 -0700 (PDT)
To: Zhenghaomian <zhenghaomian@huawei.com>
Cc: "teas@ietf.org" <teas@ietf.org>
References: <E0C26CAA2504C84093A49B2CAC3261A43F8369C3@dggeml531-mbs.china.huawei.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <7faa674d-36cb-9b11-1db6-72839b252dac@joelhalpern.com>
Date: Tue, 28 Apr 2020 23:51:57 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A43F8369C3@dggeml531-mbs.china.huawei.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/72SxNDNTQyYa3L7bkK0ixJerCHs>
Subject: Re: [Teas] Network Slicing design team definitions - isolation and resolution
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2020 03:52:03 -0000
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:teas-bounces@ietf.org] *代表 *Igor Bryskin > *发送时间:*2020年4月29日1:52 > *收件人:*Dongjie (Jimmy) <jie.dong@huawei.com>; Greg Mirsky > <gregimirsky@gmail.com> > *抄送:*Joel M. Halpern <jmh@joelhalpern.com>; teas@ietf.org > *主题:*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 > <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> 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) <jie.dong@huawei.com > <mailto:jie.dong@huawei.com>> 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:teas-bounces@ietf.org <mailto:teas-bounces@ietf..org>] On Behalf Of > Joel M. Halpern > > Sent: Tuesday, April 28, 2020 5:33 AM > > To: Greg Mirsky <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> > > Cc: teas@ietf.org <mailto:teas@ietf.org> > > 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 > > > <jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern..com> > <mailto:jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>>> > > 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:teas-bounces@ietf.org <mailto:teas-bounces@ietf.org> > > > <mailto:teas-bounces@ietf.org <mailto:teas-bounces@ietf..org>>] On Behalf Of > Joel M. Halpern > > > >> Sent: Sunday, April 26, 2020 10:52 AM > > > >> To: Zhenghaomian <zhenghaomian@huawei.com <mailto:zhenghaomian@huawei.com> > > > <mailto:zhenghaomian@huawei.com <mailto:zhenghaomian@huawei.com>>>; > teas@ietf.org <mailto:teas@ietf.org> > > <mailto:teas@ietf.org <mailto:teas@ietf.org>> > > > >> 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:jmh@joelhalpern.com > <mailto:jmh@joelhalpern.com> > > > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>] > > > >>> 发送时间: 2020年4月26日10:34 > > > >>> 收件人: Zhenghaomian <zhenghaomian@huawei.com > <mailto:zhenghaomian@huawei.com> > > > <mailto:zhenghaomian@huawei.com <mailto:zhenghaomian@huawei.com>>>; > teas@ietf.org <mailto:teas@ietf.org> > > <mailto:teas@ietf.org <mailto:teas@ietf.org>> > > > >>> 主题: 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 > > > >> Teas@ietf.org <mailto:Teas@ietf.org> <mailto:Teas@ietf.org > <mailto:Teas@ietf.org>> > > > >> https://www.ietf.org/mailman/listinfo/teas > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org <mailto:Teas@ietf.org> <mailto:Teas@ietf.org > <mailto:Teas@ietf.org>> > > > https://www.ietf..org/mailman/listinfo/teas > <https://www.ietf.org/mailman/listinfo/teas> > > > > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org <mailto:Teas@ietf.org> > > > https://www.ietf.org/mailman/listinfo/teas > > > > > > > _______________________________________________ > > Teas mailing list > > Teas@ietf.org <mailto:Teas@ietf.org> > > https://www.ietf.org/mailman/listinfo/teas > > _______________________________________________ > Teas mailing list > Teas@ietf.org <mailto:Teas@ietf.org> > https://www.ietf.org/mailman/listinfo/teas >
- [Teas] Network Slicing design team definitions - … Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Kiran Makhijani
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- [Teas] 答复: Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Luis M. Contreras
- Re: [Teas] Network Slicing design team definition… Luis M. Contreras
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… Joel Halpern Direct
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] Network Slicing design team definition… Kiran Makhijani
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… Joel Halpern Direct
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Igor Bryskin
- Re: [Teas] Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… John E Drake
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Dongjie (Jimmy)
- Re: [Teas] Network Slicing design team definition… David Sinicrope
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Zhenghaomian
- Re: [Teas] Network Slicing design team definition… Greg Mirsky
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… Kiran Makhijani
- Re: [Teas] Network Slicing design team definition… Daniele Ceccarelli
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern
- Re: [Teas] Network Slicing design team definition… John E Drake
- Re: [Teas] Network Slicing design team definition… Igor Bryskin
- Re: [Teas] Network Slicing design team definition… Jari Arkko
- Re: [Teas] Network Slicing design team definition… Joel M. Halpern