Re: [Teas] Two more examples for draft-ietf-teas-ietf-network-slices

Adrian Farrel <adrian@olddog.co.uk> Tue, 02 August 2022 18:07 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 19CE5C14F747 for <teas@ietfa.amsl.com>; Tue, 2 Aug 2022 11:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=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 cLWeQFPN_6hG for <teas@ietfa.amsl.com>; Tue, 2 Aug 2022 11:07:11 -0700 (PDT)
Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (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 6F79AC14F73F for <teas@ietf.org>; Tue, 2 Aug 2022 11:07:10 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.7/8.14.7) with ESMTP id 272I77rW027306; Tue, 2 Aug 2022 19:07:07 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B7A9C4604B; Tue, 2 Aug 2022 19:07:07 +0100 (BST)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A22DC4604A; Tue, 2 Aug 2022 19:07:07 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS; Tue, 2 Aug 2022 19:07:07 +0100 (BST)
Received: from LAPTOPK7AS653V ([84.93.40.1]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.7/8.14.7) with ESMTP id 272I76eq011749 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Aug 2022 19:07:07 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <mohamed.boucadair@orange.com>
Cc: <teas@ietf.org>
References: <0c9901d8a4b4$fb618350$f22489f0$@olddog.co.uk> <25988_1659356908_62E7C6EC_25988_60_1_0d0de4c015134d3b8587e3b8cf643682@orange.com>
In-Reply-To: <25988_1659356908_62E7C6EC_25988_60_1_0d0de4c015134d3b8587e3b8cf643682@orange.com>
Date: Tue, 2 Aug 2022 19:07:04 +0100
Organization: Old Dog Consulting
Message-ID: <0e1101d8a69a$ad037910$070a6b30$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKpKGR1oh0vQ3g1zzSk0neAWepetwILGXS3q+qC0AA=
Content-Language: en-gb
X-Originating-IP: 84.93.40.1
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-27054.001
X-TM-AS-Result: No--30.196-10.0-31-10
X-imss-scan-details: No--30.196-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-9.0.1002-27054.001
X-TMASE-Result: 10--30.196200-10.000000
X-TMASE-MatchedRID: jFqw+1pFnMzmicbHRUsaV3FPUrVDm6jtdmWMDQajOiIc5SGKNk1CG2tC BJGDrKJF0Kk6pZDnq7vi3A9Zt5S/qh6bq3k85nyUxDiakrJ+Spkcsx3IH4sq3H0EjOOM/PN6y7d +7uYYRNnZT+dS3P6tLweVnWO5aBtg52/pxZx2tzSVUcz8XpiS9JGAt645FF0SpeDMqsfje3g7LL LiKSvVklfpfcKqwNX38WQ5kRYELR8c9OUMTLzFSxTs4T19wprxMzbF1gbxlQY03/elgXTzI4c4C x6gjMqoFpv4ALYwnewmEDFX9cEEF6f0QmPqa4keGXGu0jdPFGSzPnlWSjg1A+chHA04zz3zTgAJ HNh+lo89e6CkFI5L+1ktjcD7FD7SDOKPBsSbejIK3Ma88LL+bjvH5O5/sxwMTAf96YMvlmeYpuG 7kpoKRyG0s0Pu7sp43PtN8qoaBA9yRuzYw1m0v+MobH1h01zi9v33UW8WNYBCbDVw9++PqYTnpc /gBVJz8NTq8ffAbf6dwnIEQTviipV3eQoqkpPnA9lly13c/gGoxfDhgVWbCJm3OIVSf4P5nULNg N42j5NJiAQ22LY+4X+Kx4IA1XTXEh3KMeNpo8GeuwQMMC+SOrMtDtVV8y/HgQSJO2SN76dVcXP3 eMLfFyqq0O5S3DJ8m37VUJbd34XsZfRzVSVqXGzvIi8LanAapwfsNixA/+QArX9f73pQzq2Cl6Q JGTmN2K712dfVcKTJpy3BSWjWU35VZDvqjp4MYeSLiGsUzvk+w3qPVHVLMbic4Ma14CgQ8hJf6I ANrt0AMDcd9CDKBWkN/HZiNjh512uw2WNOlX2eAiCmPx4NwGNn8XPiALIb817pqrse5+PEwwc9f F2NzgtuKBGekqUpIG4YlbCDECtruV6hT84yE/IxdJB3PGL0
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/QlgyHr7YS_rOwWvNaWRqYDbBUzA>
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: Tue, 02 Aug 2022 18:07:13 -0000

Hi Med,

I think that the Appendix in the draft is trying to give some examples and
not address every possible scenario.

I think your reference to 5160 is interesting because of the requirement for
agreements between the network domains. But there is also a problem of
selecting adjacent domains - call it domain slice routing. I suspect that
that problem needs a good deal of thought and is way out of scope for the
framework. Whether the solution is reachability routing (like BGP) or
hierarchical routing (like PCE) needs discussion. Maybe this is something
that Jie would like to factor into his work on end-to-end slice composition.

Cheers,
Adrian

-----Original Message-----
From: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com> 
Sent: 01 August 2022 13:28
To: adrian@olddog.co.uk; teas@ietf.org
Subject: RE: [Teas] Two more examples for
draft-ietf-teas-ietf-network-slices

Hi Adrian,

Thanks.

The centralized approach used in A.6 (particularly in Figure 13) is one way
to stitch slices. That approach is suitable when the underlying domains
belong to the same administrative entity or when the "coordinator" can
assure the overall slice (e.g., identify intermediate root causes, react to
localized deterioration signals, etc.). In cases where distinct entities are
involved, the bilateral mode would be more convenient because it offers a
clear responsibility scope for each involved domain and also offers means to
intermediate domains to react to upstream failures/deterioration symptoms in
order to satisfy the slice objectives (e.g., make use of multihoming). The
bilateral mode is similar to what is depicted in
https://datatracker.ietf.org/doc/html/rfc5160#section-4.1. 

In a bilateral mode, the slice services that will lead to the stitched
slices would be between these service attachment points: 
* SDP1-SDP2 (ctrl of nw1)
* SDPX-SDP2 (ctrl of nw2)
* SDPU-SDP2 (ctrl of nw3)
* SDPS-SDP2 (ctrl of nw4)

The flow of the service requests would be as follows: 
             
(ctrl of nw1)==>(ctrl of nw2)==>(ctrl of nw3)==>(ctrl of nw4)
  | Device        | Device        | Device        | Device
  | Config        | Config        | Config        | Config
  v               v               v               v

Cheers,
Med

> -----Message d'origine-----
> De : Teas <teas-bounces@ietf.org> De la part de Adrian Farrel
> Envoyé : dimanche 31 juillet 2022 10:10
> À : teas@ietf.org
> Objet : [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

____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.