Re: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology

"Luis M. Contreras" <contreras.ietf@gmail.com> Fri, 01 October 2021 10:58 UTC

Return-Path: <contreras.ietf@gmail.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 66A993A097D for <teas@ietfa.amsl.com>; Fri, 1 Oct 2021 03:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eSBgWxhICjY4 for <teas@ietfa.amsl.com>; Fri, 1 Oct 2021 03:58:13 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338983A097E for <teas@ietf.org>; Fri, 1 Oct 2021 03:58:12 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id r1so8462133qta.12 for <teas@ietf.org>; Fri, 01 Oct 2021 03:58:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FUgD911IIoSve6eSW4PqpN6R/5gSrZkO5Vl8f/Xi2pY=; b=Ot+bh5TtnpIVZhKzuv6nl8PUFusbGS53ylpNHf7+zkc/Kg/Em+cNVqPVD3+KatDdQv lFP3QXmDjwCVYt9zuZS/vh1r7Lt8SriGjcHW2CnrjrzK7iaFQDdIntWnj27iAjGCJUOI 1+0gmTMEjk6nGorf4aIlMVwSgMB954M2rwE9ugODCFzZ7njyY3d98W6fo3Vevx3rdHW2 Z1G2qQ50+iDlRxKvXOY5uO5N74uJY/7dX7IV5qzIK+iREYEHQnk0sNI1QqHPijt1JtWY kxXY36oclMk0ddnoTJlCJhUykmrGUo9AI/XeEkSa7jiBUrLiQ7zrA9PtRdEmw3dYsDsP C3eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FUgD911IIoSve6eSW4PqpN6R/5gSrZkO5Vl8f/Xi2pY=; b=204HoEUe6+bKvsLCXvRFG92tJTVc7TRJQeHI74OEU7CE/Xx/pGohZirfumRKqzDfXd MPAmnhi47bizf8xPDxILZA8d408kHSK0nVmw+rTjaH9VIZN1E4oVMxgUVnA/63HMBUqy U9JD26xBTtr0x9WOM11Jvf4xuiQvVyfA9V6QzAW6Iry+HajAlEneiGdYBYOtVFm1Ko9s 8//jeF2yBxiwxuaENwmlW0EZOVcg+unQGiHISI9O3NYOHbPiwIO3v7lZqb82MYT8hjaY 2hGsmCZu6RLa696wY1PS8tMSzrtU30AkqwB030/hQuARvLUIM2o0XDK67CsDSee3t6q4 8hGw==
X-Gm-Message-State: AOAM533g21aUWpqw1gCQZimjM1rybbmx4+2IlkfWnrhqMiiCm5sQBmt1 RL25Q6DzMbLCJLPOEbLqjkGyd0y1QPL9r2wwIb8=
X-Google-Smtp-Source: ABdhPJxiYVGg2wEYvQjRsaJx+LyJR67dr3usHhWRk9cCOIlerbHVd4xDWyeAtGL0ACSn/AoxfPhZGbVrgMqIp/cA75E=
X-Received: by 2002:ac8:7259:: with SMTP id l25mr12373707qtp.49.1633085891707; Fri, 01 Oct 2021 03:58:11 -0700 (PDT)
MIME-Version: 1.0
References: <054b01d7b3cc$d5731bb0$80595310$@olddog.co.uk>
In-Reply-To: <054b01d7b3cc$d5731bb0$80595310$@olddog.co.uk>
From: "Luis M. Contreras" <contreras.ietf@gmail.com>
Date: Fri, 01 Oct 2021 12:58:00 +0200
Message-ID: <CAE4dcxkd5ixz3zWO19172MZU9iFcHWb6yAQfK86+CJ4TeDwY4A@mail.gmail.com>
To: adrian@olddog.co.uk
Cc: TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000076880305cd4870fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/lYxI0rGREGnzZaZmC3JQ2gXEvU8>
Subject: Re: [Teas] Network slicing framework : Issue #6: Realisation Architecture and Terminology
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: Fri, 01 Oct 2021 10:58:19 -0000

Hi Adrian,

revisiting your proposed figure, and considering current Figure 2 in the
draft (the one showing the NSC between the high level orchestration system
and the Networc Controllers), I think it would be convenient to include the
network controller(s) here interfacing with the NSC in the boundary you
marl as Physical Network. The Network controller will be the one
controlling (i.e., in direct touch) with the physical network, and
providing a view (filtered or not) of the Physical network to the NSC.

Showing it in this way I think keeps consistency with Fig 2 in the document
and also avoids confusion. This does not prevent the fact the NSC could be
integrated with Network Controller in some cases.

Furthermore, it could be better to rename "Controller view" to "NSC view"
or either "provider view" in the upper part of the figure.

Best regards

Luis

El lun, 27 sept 2021 a las 20:24, Adrian Farrel (<adrian@olddog.co.uk>)
escribió:

> Hi,
>
>
>
> There was surprisingly little shouting about this proposal in my slides
> today. This may meant that more time is needed to digest it, or it may be
> that everyone has been doing their homework and we have something
> approaching agreement.
>
>
>
> First the picture (with a light touch to the choice of terms), and then
> some discussion of terms.
>
>
>
>
>
>                        --      --      --
>
>                       |CE|    |CE|    |CE|
>
>                        --      --      --
>
>                      AC :    AC :    AC
> :
>
>                      ----------------------        -------
>
>                     ( |PE|....|PE|....|PE| )      ( IETF  )
>
>                    (   --:     --     :--   )    ( Network )
>
>                    (     :............:     )    (  Slice
> )
>
>                     (  IETF Network Slice  )      (       )  Customer
>
>                      ----------------------        -------     View
>
>                   ........................\........./..................
>
>                                            \       /        Controller
>
>           >>>>>>>>>>>>>>>  Grouping/Mapping v     v            View
>
>          ^             -----------------------------------------
>
>          ^            ( |PE|.......|PE|........|PE|.......|PE|  )
>
>     ------------     (   --:        --         :--         --    )
>
>    |            |    (     :...................:                 )
>
>    | Controller |     (        Network Resource Partition       )
>
>    |   (NSC)    |      -----------------------------------------
>
>    |            |                             |
>
>    |            |>>>>>  Resource Partitioning |
>
>     ------------        of Available Topology |
>
>      v   v                                    v
>
>      v   v            -----------------------------      --------
>
>      v   v           (|PE|..-..|PE|... ..|PE|..|PE|)    (        )
>
>      v   v          ( :--  |P|  --   :-:  --   :--  )  (  Filter  )
>
>      v   v          ( :.-   -:.......|P|       :-   )  ( Topology )
>
>      v   v          (  |P|...........:-:.......|P|  )   (        )
>
>      v   v           (  -    Filter Topology       )     --------
>
>      v   v            -----------------------------       A
>
>      v    >>>>>>>>>>>>  Topology Filter A                /
>
>      v            .......................\............../..............
>
>      v                                    \            /  Physical Network
>
>      v            ------------------------------------------------
>
>      v           ( |PE|.....-.....|PE|.......    |PE|.......|PE|  )
>
>      v          (   --     |P|     --       :-...:--     -..:--    )
>
>       >>>>>>>>>(    :       -:..............|P|.........|P|
> )
>
>                (    -.......................:-:..-       -          )
>
>                 (  |P|..........................|P|......:         )
>
>                  (  -                            -                )
>
>                   ------------------------------------------------
>
>
>
> And now the names for the pieces.
>
>
>
> I think that “IETF Network Slice” is uncontentious.
>
> I think that “Physical Network” is clear, although I would note that this
> could actually be a virtual network.
>
>
>
> There was some debate about what a “Filter Topology” is. This undoubtedly
> needs some words and thought. My working text for this is:
>
>      The Physical Network may be filtered into a number of Filter
>
>      Topologies.  Filter actions may include selection of specific nodes
>
>      and links according to their capabilities and are based on network-
>
>      wide policies.  The resulting topologies can be used to host IETF
>
>      Network Slices and provide a useful way for the network operator to
>
>      know that all of the resources they are using to plan a network
>
>      slice meet specific SLOs.  This could be an offline planning
>
>      activity or could be performed dynamically as new demands arise.
>
>      The use of Filter Topologies is entirely optional in the architecture
>
>      and  IETF Network Slices could be hosted directly on the Physical
>
>      Network.
>
>
>
> The remaining term is for the collection of resources that are used to
> support the IETF Network Slice or grouping of IETF Network Slices. We
> appear to be down to a choice between “Network Resource Group” and “Network
> Resource Partition”.
>
>
>
> I do not personally have a strong feeling on this. I think that
> “partition” is a slightly better word because it implies no sharing between
> sets of resources, and it may better cover statistical use of resources
> (e.g., you have 10% of the total bandwidth, not exactly that 10% of the
> bandwidth). But “group” is a perfectly fine word.
>
>
>
> Opinions please.
>
>
>
> Adrian
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>


-- 
___________________________________________
Luis M. Contreras
contreras.ietf@gmail.com
luismiguel.contrerasmurillo@telefonica.com
Global CTIO unit / Telefonica