Re: [Teas] Two more examples for draft-ietf-teas-ietf-network-slices
"Dongjie (Jimmy)" <jie.dong@huawei.com> Wed, 03 August 2022 08:47 UTC
Return-Path: <jie.dong@huawei.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 CAC8EC14CF1F for <teas@ietfa.amsl.com>; Wed, 3 Aug 2022 01:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYgTea8bzcTh for <teas@ietfa.amsl.com>; Wed, 3 Aug 2022 01:47:22 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84722C157B32 for <teas@ietf.org>; Wed, 3 Aug 2022 01:47:22 -0700 (PDT)
Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LyQNt4jxPz67XhD for <teas@ietf.org>; Wed, 3 Aug 2022 16:43:10 +0800 (CST)
Received: from kwepemi500018.china.huawei.com (7.221.188.213) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 3 Aug 2022 10:47:19 +0200
Received: from kwepemi500017.china.huawei.com (7.221.188.110) by kwepemi500018.china.huawei.com (7.221.188.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 3 Aug 2022 16:47:17 +0800
Received: from kwepemi500017.china.huawei.com ([7.221.188.110]) by kwepemi500017.china.huawei.com ([7.221.188.110]) with mapi id 15.01.2375.024; Wed, 3 Aug 2022 16:47:17 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] Two more examples for draft-ietf-teas-ietf-network-slices
Thread-Index: AdiktPbMrusyWRcoQYGA9pFk30bq1gCXBppg
Date: Wed, 03 Aug 2022 08:47:17 +0000
Message-ID: <7fb2a7cbd4fc40868ae09dc263e2b565@huawei.com>
References: <0c9901d8a4b4$fb618350$f22489f0$@olddog.co.uk>
In-Reply-To: <0c9901d8a4b4$fb618350$f22489f0$@olddog.co.uk>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.66]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/mG5DsXk_DeGXmINhWYSccoRnwW4>
Subject: Re: [Teas] Two more examples for draft-ietf-teas-ietf-network-slices
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
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, 03 Aug 2022 08:47:24 -0000
Hi Adrian, Thanks for proposing text for the hierarchical and multi-domain E2E network slice cases. They look good to me in general, and I agree with adding them as examples to the slice framework draft. Here are a few clarification comments: 1. The example in figure 10 talks about "bridging connectivity", which is a little confusing to me. My reading is that figure gives an example of using hierarchical network slices to provide the connectivity with required SLA/SLO to an upper layer network slice, then I'm not sure whether it needs to be called something special as "Bridge Connectivity". Or maybe I misunderstood something about this case? 2. In the description about the coordination of multiple intra-domain network slices, it is suggested to make some change to the following sentence to align with the network slice definition: Old: The coordination activity involves binding the SDPs, and hence the connectivity constructs, to achieve end-to-end connectivity. Proposed: The coordination activity involves binding the SDPs, and hence the connectivity constructs, to achieve end-to-end connectivity with the required SLA and SLO. Best regards, Jie > -----Original Message----- > From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Sunday, July 31, 2022 4:10 PM > To: teas@ietf.org > Subject: [Teas] Two more examples for draft-ietf-teas-ietf-network-slices > > Hi, > > During the meeting at IETF-114, Lou suggested that we might make some > efforts to include a discussion of hierarchical and concatenated IETF Network > Slices within the framework draft. > > We already have some text that notes that these approaches fall within the > architecture, so probably nothing new needed there. But the Appendix > provides a place to give simple examples of various deployment options > (without getting into the details of realisation). > > So, here is some proposed text. > > Let me know if it causes any of you a problem. > > Cheers, > Adrian > > ==== > > A.5. Hierarchical Composition of Network Slices > > As mentioned in Section 4.3, IETF Network Slices may be arranged > hierarchically. There is nothing special of novel about such an > arrangement, and it models the hierarchical arrangement of services > of virtual networks in many other environments. > > As shown in Figure 9, an Operator's Controller (NSC) that is > requested to provide an IETF Network Slice for a customer may, in > turn, request an IETF Network Slice from another carrier. The > Operator's NSC may manage and control the underlay IETF Network Slice > by modifying the requested connectivity constructs and changing the > SLAs. The customer is entirely unaware of the hierarchy of slices, > and the underlay carrier is entirely unaware of how its slice is > being used. > > This "stacking" of IETF Network Slice constructs is no different to > the way virtual networks may be arranged. > > -------------- > | Network | > | Slice | > | Orchestrator | > -------------- > | IETF Network Slice > | Service Request > | Customer view > ....|................................ > -v---------------- Operator view > |Controller | > | ------------ | > | | IETF | | > | | Network |---|--- > | | Slice | | | > | | Controller | | | > | | (NSC) | | | > | ------------ | | > ------------------ | > | IETF Network Slice > | Service Request > | > .........................|..................... > ----------v------- Carrier view > |Controller | > | ------------ | > | | IETF | | > | | Network | |--> Virtual Network > | | Slice | | > | | Controller | | > | | (NSC) | | > | ------------ | > ....| | Network |............ > | | Configuration | Underlay Network > | v | > | ------------ | > | | Network | | > | | Controller | | > | | (NC) | | > | ------------ | > ------------------ > | Device Configuration > v > > Figure 9: Example Hierarchical Arrangement of IETF Network Slices > > In this case, the network hierarchy may also be provided to bridge > connectivity between networks as shown in Figure 10. Here, the an > IETF Network Slice may be requested of the lower layer network to > provide the desired connectivity constructs to supplement the > connectivity in the higher layer network where this connectivity may > be presented as a virtual link. > > CE1 CE2 > | | > | | > > _|_________________________________________|_ > ( : : ) > ( :.............. ..............: ) > > (_______________:_____________:_______________) > __|_____________|__ > ( : : ) > ( :.............: ) > (___________________) > > Figure 10: Example Hierarchical Arrangement of IETF Network > Slices to Bridge Connectivity > > A.6. Horizontal Composition of Network Slices > > It may be that end-to-end connectivity is achieved using a set of > cooperating networks as described in Section 4.3. For example, there > may be multiple inter-connected networks that provide the required > connectivity as shown in Figure 11. The networks may utilize > different technologies and may be under separate administrative > control. > > CE1 CE2 > | | > SDP1 SDP2 > | | > _|____ ______ ______ ____|_ > ( ) ( ) ( ) ( ) > ( )---( )---( )---( ) > (______) (______) (______) (______) > > Figure 11: Example Customer View of Inter-connected Networks > Provide End-to-End Connectivity > > In this scenario, the customer (represented by CE1 and CE2) may > request an IETF Network Slice service connecting the CEs. The > customer considers the SDPs at the edge (shown as SDP1 and SDP2 in > Figure 11) and might not be aware of how the end-to-end connectivity > is composed. > > However, because the various networks may be of different > technologies and under separate administrative control, the networks > are sliced individually and coordination is necessary to deliver the > desired connectivity. The network to network interfaces (NNIs) are > present as SDPs for the IETF Network Slices in each network so that > each network is individually sliced. In the example in Figure 11, > this is illustrated as network 1 (N/w1) being sliced between SDP1 and > SDPX, N/w2 being sliced between SDPY and SDPU, etc. The coordination > activity involves binding the SDPs, and hence the connectivity > constructs, to achieve end-to-end connectivity. In this way, simple > and complex end-to-end connectivity can be achieved with a variety of > connectivity constructs in the IETF Network Slices of different > networks "stitched" together. > > CE1 > CE2 > | | > SDP1 > SDP2 > | | > _|____ ______ ______ > ____|_ > ( ) SDPX ( ) SDPU ( ) SDPS ( ) > ( N/w1 )------( N/w2 )------( N/w3 )------( N/w4 ) > (______) SDPY (______) SDPV (______) SDPT > (______) > > > Figure 12: Example Delivery of An End-to-End IETF Network Slice > with Inter- connected Networks > > The controller/coordinator relationship is shown in Figure 13. > > -------------- > | Network | > | Slice | > | Orchestrator | > -------------- > | IETF Network Slice > | Service Request > | Customer view > ....|................................ > -v---------------- Coordinator view > |Coordinator | > | | > ------------------ > | |_________________ > | | > | | > ....|....................... ....|..................... > -v-------------- -v-------------- > |Controller1 | Operator1 |Controller2 | Operator2 > | ------------ | | ------------ | > | | IETF | | | | IETF | | > | | Network | | | | Network | | > | | Slice | | | | Slice | | > | | Controller | | | | Controller | | > | | (NSC) | | | | (NSC) | | > | ------------ | | ------------ | > ....| | Network |............ | | Network |............ > | | Config | Underlay1 | | Config | Underlay2 > | v | | v | > | ------------ | | ------------ | > | | Network | | | | Network | | > | | Controller | | | | Controller | | > | | (NC) | | | | (NC) | | > | ------------ | | ------------ | > ---------------- ---------------- > | Device Configuration > v > > Figure 13: Example Relationship of IETF Network Slice Coordination > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas
- [Teas] Two more examples for draft-ietf-teas-ietf… Adrian Farrel
- Re: [Teas] Two more examples for draft-ietf-teas-… mohamed.boucadair
- Re: [Teas] Two more examples for draft-ietf-teas-… Adrian Farrel
- Re: [Teas] Two more examples for draft-ietf-teas-… Dongjie (Jimmy)
- Re: [Teas] Two more examples for draft-ietf-teas-… LUIS MIGUEL CONTRERAS MURILLO
- Re: [Teas] Two more examples for draft-ietf-teas-… Adrian Farrel
- Re: [Teas] Two more examples for draft-ietf-teas-… Adrian Farrel