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, 3 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