[Teas] Two more examples for draft-ietf-teas-ietf-network-slices
Adrian Farrel <adrian@olddog.co.uk> Sun, 31 July 2022 08:10 UTC
Return-Path: <adrian@olddog.co.uk>
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 C04B6C15C50D for <teas@ietfa.amsl.com>; Sun, 31 Jul 2022 01:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.928
X-Spam-Level:
X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 sF_sBV9cOG-2 for <teas@ietfa.amsl.com>; Sun, 31 Jul 2022 01:10:28 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 2D13BC16ECDF for <teas@ietf.org>; Sun, 31 Jul 2022 01:10:25 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 26V8AM50029729 for <teas@ietf.org>; Sun, 31 Jul 2022 09:10:22 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A3E6C4604E for <teas@ietf.org>; Sun, 31 Jul 2022 09:10:22 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 983474604B for <teas@ietf.org>; Sun, 31 Jul 2022 09:10:22 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS for <teas@ietf.org>; Sun, 31 Jul 2022 09:10:22 +0100 (BST)
Received: from LAPTOPK7AS653V ([88.128.88.120]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 26V8ALWw030613 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <teas@ietf.org>; Sun, 31 Jul 2022 09:10:22 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: teas@ietf.org
Date: Sun, 31 Jul 2022 09:10:21 +0100
Organization: Old Dog Consulting
Message-ID: <0c9901d8a4b4$fb618350$f22489f0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdiktPbMrusyWRcoQYGA9pFk30bq1g==
Content-Language: en-gb
X-Originating-IP: 88.128.88.120
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-9.0.0.1002-27048.006
X-TM-AS-Result: No--7.808-10.0-31-10
X-imss-scan-details: No--7.808-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27048.006
X-TMASE-Result: 10--7.808400-10.000000
X-TMASE-MatchedRID: cPu9AiD5JXwZnuop9luYIDjNGpWCIvfTNUSduuqYHDvIgofMgahPrXqT KrT4kCRpc3LebuSG3T7Rr6pL4diplaML3v3DWTsM3nHtGkYl/Vo98wLbdeI5WFc/CedjlcvkuWe Brf0F8lSpLnDsE79B8cuHgW1QxPEaRpsoDCmkF1KHZXNSWjgdU3hejHrzFWVAoRBIy5J0l8Dv5t G5qQwjQACbBLiecFi5Z4CRvgkL6MqCuMXj+VaDNfZvT2zYoYOwEDnDEqNPduoRBtVagi8jbYpbw G9fIuITTQ5QroDJ1I9XJ6DuDcfpaCWUkRhX1GFJOYqUl58EXDO6NdkJrh18mgDVt9UpyMklbjQ2 nmm3r6ggeznBnsNrAUnNNccK+FvHs/ej5mUo2GoOOK9P8WgPzXUF9R5TWOMEmyiLZetSf8nJ4y0 wP1A6ANjQedTOgaIMoe5zfF+josbdB/CxWTRRu/558CedkGIvqcoAhihTwvjeXNwsACEp4QhcFe Jqeu7af9FPEYrVtrgCf6ioBWiB6nCbh6li8RUS
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/FTvdju_t2_G4ZZnQLiE2fnfHL54>
Subject: [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: Sun, 31 Jul 2022 08:10:30 -0000
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] 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