Re: [Teas] Proposal for text on realising network slices

Uma Chunduri <umac.ietf@gmail.com> Thu, 22 April 2021 04:29 UTC

Return-Path: <umac.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 CF3D33A0BF6 for <teas@ietfa.amsl.com>; Wed, 21 Apr 2021 21:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_BLOCKED=0.001, 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 YW6u24ateBht for <teas@ietfa.amsl.com>; Wed, 21 Apr 2021 21:29:28 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 713723A0BF3 for <teas@ietf.org>; Wed, 21 Apr 2021 21:29:28 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id i4so12287945ybe.2 for <teas@ietf.org>; Wed, 21 Apr 2021 21:29:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dNlzI/lpnc6x3VToSnT//K0FwetRkUOBll1pm7/NHaA=; b=e28o27frsiqYvUGsHDw5mhOUcgU2bYubW5eFvGnQ45Imco9AFiURKDW8AEOIjCNQ+g +8RQyN94/hBs7g8iP+s7sVngvGgbXAxUBCk9DI63kwuIQ24eSX4RwzbPL2apO/2ZkGAv i7jVF9nRehYRVYB7QOJil3yo6FB+HNSNkSx3uXdZlRkKcQ/0uD9843cQc9WZlrwWKiKu 6RZjFXbsW/lo2Ag1XZ0sZhmwsXdwTOyUmLKe6qwrS9ItwGe2eN1F8Qh6brhUK6r+cSR9 9rkhz8o0mHZ1LRsB8lMGYebUSgPi7h6jNVNWI8ZlML0ex/ZRXBO0tUnzn/4MMmH378aR N95g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dNlzI/lpnc6x3VToSnT//K0FwetRkUOBll1pm7/NHaA=; b=nsp4H8bbSreAB51ViyavCYD6P6XIJxsrEFrL85HL49VjHmKJK/dfxxguDjstsfpD6W PAeRlqElDenmaQYcMnbjBpy2Fq2q+S6UpLeBruexOdOQXrbKTYqVo24INrA9GnT60taO nGCSCyXjv3PSJjO2AxRBiLV28JbmO7Uc5dDg+1UN1ePLxA9MHcLUs1Wzay8sJ9y4WH0A 6KcfcAMCbKCbo7jjawfigtq+SN5ETnqpE66W07FlEaLgWeJx+8O3RS/oO+AiQDzwIWRF nLP05gzfEXBdP071kVh7bYw9RROQhH1F8EDF2Z0C66ByQKBJU6d1y8FERXvxnCUTr9RY ik1g==
X-Gm-Message-State: AOAM5314ySXzlLHFNdwz5UOs5+By+n+Ulapome4fTJvgZ5FW2d5DkjK/ kam6oChO1vkTtV9ltXofO4zaVy4GEQI6gyd+NPg=
X-Google-Smtp-Source: ABdhPJymlM2DcCVLNQod3nEgO+sqGgIJCS6IWcEAM7w7YYtNL8FKjRYPBPqnLDRrzhip61UvIRvokF8kvoSiavlC+G4=
X-Received: by 2002:a25:4946:: with SMTP id w67mr1973522yba.141.1619065766501; Wed, 21 Apr 2021 21:29:26 -0700 (PDT)
MIME-Version: 1.0
References: <05a501d736ef$56f046f0$04d0d4d0$@olddog.co.uk>
In-Reply-To: <05a501d736ef$56f046f0$04d0d4d0$@olddog.co.uk>
From: Uma Chunduri <umac.ietf@gmail.com>
Date: Wed, 21 Apr 2021 21:29:15 -0700
Message-ID: <CAF18ct5zQ2G_mLQUxrvmJaoKdi6_yx4vFJ7mDizzG-7f=8U7Hg@mail.gmail.com>
To: adrian@olddog.co.uk
Cc: TEAS WG <teas@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e15dd905c0881f02"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/w5idENIlytozvQTW-V44DF8-Bx0>
Subject: Re: [Teas] Proposal for text on realising network slices
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: Thu, 22 Apr 2021 04:29:33 -0000

Hi Adrian,

FWIW, changes look good to me.
Comments below [Uma]:

Thx!

--
Uma C.

On Wed, Apr 21, 2021 at 1:46 PM Adrian Farrel <adrian@olddog.co.uk> wrote:

> All,
>
> I promised a revision of the text around realizing network slicing.
> This is based on my earlier suggestion (on the list) about reducing the
> ACTN section, and the thread with Daniele about referencing the various
> possible solution technologies.
>
> Here is a suggestion for:
> - removing a little text from sections 3 and 5
> - making a small change to 5.2
> - replacing sections 5.5 and 6 with a new section 6
>
> Comments are encouraged.
>
> I will leave a respectful period of time and then post an update. Once
> updated, this text in the draft can still be discussed and modified.
>
> Best,
> Adrian
>
> ===
>
> 3.
>
> OLD
>    As an example of requirements that might apply to IETF Network
>    Slices, see [I-D.ietf-teas-enhanced-vpn] (in particular, section 3).
> NEW
> END
>
> ---
>
> 5.
>
> OLD
>    Section 3 of [I-D.ietf-teas-enhanced-vpn] provides an example
>    architecture that might apply in using the technology described in
>    this document.
> NEW
> END
>
> ---
>
> 5.2
> OLD
>    Layered virtual connections are comprehensively discussed in IETF
>    documents and are widely supported.  See, for instance, GMPLS-based
>    networks ([RFC5212] and [RFC4397]), or ACTN ([RFC8453] and
>    [RFC8454]).  The principles and mechanisms associated with layered
>    networking are applicable to IETF Network Slices.
> NEW
>    Layered virtual connections are comprehensively discussed in IETF
>    documents and are widely supported.  See, for instance, GMPLS-based
>    networks [RFC5212] and [RFC4397], or Abstraction and Control of TE
>    Networks (ACTN) [RFC8453] and [RFC8454].  The principles and
>    mechanisms associated with layered networking are applicable to IETF
>    Network Slices.
> END
>
> ---
>
> OLD
> 5.5.  Realizing IETF Network Slice
>
>    Realization of IETF Network Slices is out of scope of this document.
>    It is a mapping of the definition of the IETF Network Slice to the
>    underlying infrastructure and is necessarily technology-specific and
>    achieved by the NSC over the SBI.
>
>    The realization can be achieved in a form of either physical or
>    logical connectivity through VPNs (see, for example,
>    [I-D.ietf-teas-enhanced-vpn], a variety of tunneling technologies
>    such as Segment Routing, MPLS, etc.  Accordingly, endpoints may be
>    realized as physical or logical service or network functions.
>
> 5.5.1.  Underlying Technology
>
>    There are a number of different technologies that can be used,
>    including physical connections, MPLS, TSN, Flex-E, etc.
>
>    See Section 5 of [I-D.ietf-teas-enhanced-vpn] for instance, for
>    example underlying technologies.
>
>    Also, as outlined in "applicability of ACTN to IETF Network Slices"
>    below, ACTN ([RFC8453]) offers a framework that is used elsewhere in
>    IETF specifications to create virtual network (VN) services similar
>    to IETF Network Slices.
>
>    A IETF Network Slice can be realized in a network, using specific
>    underlying technology or technologies.  The creation of a new IETF
>    Network Slice will be initiated with following three steps:
>
>    o  Step 1: A higher level system requests connections with specific
>       characteristics via NBI.
>
>    o  Step 2: This request will be processed by an IETF NSC which
>       specifies a mapping between northbound request to any IETF
>       Services, Tunnels, and paths models.
>
>    o  Step 3: A series of requests for creation of services, tunnels and
>       paths will be sent to the network to realize the trasport slice.
>
>    It is very clear that regardless of how IETF Network Slice is
>    realized in the network (i.e., using tunnels of type RSVP or SR), the
>    definition of IETF Network Slice does not change at all but rather
>    its realization.
>
> 6.  Applicability of ACTN to IETF Network Slices
>
>    Abstraction and Control of TE Networks (ACTN - [RFC8453]) is an
>    example of similar IETF work.  ACTN defines three controllers to
>    support virtual network (VN) services -
>
>    o  Customer Network Controller (CNC),
>
>    o  Multi-Domain Service Coordinator (MDSC) and
>
>    o  Provisioning Network Controller (PNC).
>
>    A CNC is responsible for communicating a customer's VN requirements.
>
>    A MDSC is responsible for multi-domain coordination, virtualization
>    (or abstraction), customer mapping/translation and virtual service
>    coordination to realize the VN requirement.  Its key role is to
>    detach the network/service requirements from the underlying
>    technology.
>
>    A PNC oversees the configuration, monitoring and collection of the
>    network topology.  The PNC is a underlay technology specific
>    controller.
>
>    While the ACTN framework is a generic VN framework that is used for
>    various VN service beyond the IETF Network Slice, it is still a
>    suitable basis to understand how the various controllers interact to
>    realize a IETF Network Slice.
>
>    One possible mapping between the IETF Network Slice, and ACTN,
>    definitions is as shown in Figure 4.
>
>                    IETF Network Slice                |   ACTN analogous
>                  Terminology / Concepts                  Terminology
>                                                      |    and Concepts
>           +--------------------------------------+
>           |Consumer higher level operation system|   |    +-----+
>           | (e.g E2E network slice orchestrator) | =====> | CNC |
>           +--------------------------------------+   |    +-----+
>                             ^                                ^
>                             | NSC NBI                |       | CMI
>                             v                                v
>           +-------------------------------------+    |    +------+
>           | IETF Network Slice Controller (NSC) |  =====> | MDSC |
>           +-------------------------------------+    |    +------+
>                             ^                                ^
>                             | NSC SBI                |       | MPI
>                             v                                v
>           +-------------------------------------+    |    +-----+
>           |        Network Controller(s)        |  =====> | PNC |
>           +-------------------------------------+    |    +-----+
>
>
>           Figure 4: Mapping between IETF Network Slices and ACTN
>
>    The NSC NBI conveys the generic IETF Network Slice requirements.
>    These may then be realized using an SBI within the NSC.
>
>    As per [RFC8453] and [I-D.ietf-teas-actn-yang], the CNC-MDSC
>    Interface (CMI) is used to convey the virtual network service
>    requirements along with the service models and the MDSC-PNC Interface
>    (MPI) is used to realize the service along network configuration
>    models.  [I-D.ietf-teas-te-service-mapping-yang] further describe how
>    the VPN services can be mapped to the underlying TE resources.
>
>    The Network Controller is depicted as a single block, analogous to a
>    Provisioning Network Controller (PNC - in this example).  In the ACTN
>    framework, however, it is also possible that the NC function is
>    decomposed into MDSC and PNC - that is, the NC may comprise hierarchy
>    as needed to handle the multiple domains and various underlay
>    technologies, whereas a PNC in ACTN is intended to be specific to at
>    most a single underlay technology and (likely) to individual devices
>    (or functional components).
>
>    Note that the details of potential implementations of everything that
>    is below the NSC in Section 6 are out of scope in this document -
>    hence the specifics of the relationship between NC and PNC, and the
>    possibility that the MDSC and PNC may be combined are at most
>    academically interesting in this context.  Another way to view this
>    is that, in the same way that ACTN might combine MDSC and PNC, the
>    NSC might also directly include NC functionality.
>
>    [RFC8453] also describes TE Network Slicing in the context of ACTN as
>    a collection of resources that is used to establish a logically
>    dedicated virtual network over one or more TE networks.  In case of
>    TE enabled underlying network, ACTN VN can be used as a base to
>    realize the IETF Network Slicing by coordination among multiple peer
>    domains as well as underlay technology domains.
>
>    Section 6 shows only one possible mapping as each ACTN component (or
>    interface) in the figure may be a composed differently in other
>    mappings, and the exact role of both components and subcomponents
>    will not be always an exact analogy between the concepts used in this
>    document and those defined in ACTN.
>
>    This is - in part - shown in a previous paragraph in this section
>    where it is pointed out that the NC may actually subsume some aspects
>    of both the MDSC and PNC.
>
>    Similarly, in part depending on how "customer" is interpreted, CNC
>    might merge some aspects of the higher level system and the NSC.  As
>    in the NC/PNC case, this way of comparing ACTN to this work is not
>    useful as the NSC and NSC NBI are the focus on this document.
> NEW
> 6.  Realizing IETF Network Slice
>

>    Realization of IETF Network Slices is out of scope of this document.
>    It is a mapping of the definition of the IETF Network Slice to the
>    underlying infrastructure and is necessarily technology-specific and
>    achieved by the NSC over the SBI.
>
>    The realization can be achieved in a form of either physical or
>    logical connectivity using VPNs, virtual networks (VNs), or a variety
>    of tunneling technologies such as Segment Routing, MPLS, etc.
>    Accordingly, endpoints (NSEs) may be realized as physical or logical
>    service or network functions.
>
> 6.1.  Underlying Technology
>
>    There are a number of different technologies that can be used in the
>    underlay, including physical connections, MPLS, time-sensitive
>    networking (TSN), Flex-E, etc.
>
>    An IETF Network Slice can be realized in a network, using specific
>    underlying technology or technologies.  The creation of a new IETF
>    Network Slice will be initiated with following three steps:
>
>    o  Step 1: A higher level system requests connections with specific
>       characteristics via the NBI.
>
>    o  Step 2: This request will be processed by an IETF NSC which
>       specifies a mapping between northbound request to any IETF
>       Services, Tunnels, and paths models.
>
>    o  Step 3: A series of requests for creation of services, tunnels and
>       paths will be sent to the network to realize the transport slice.
>
>    It is very clear that, regardless of how IETF Network Slice is
>    realized in the network (i.e., using tunnels of different types), the
>    definition of the IETF Network Slice does not change at all.  The
>    only difference is how the slice is realized.  The following sections
>    briefly introduce some existing approaches that can be applied to
>    realize IETF Network Slices.
>


> 6.2.  Applicability of ACTN to IETF Network Slices
>

[Uma]: I found Figure 4 in the original text  very useful and I presume
that would be
            covered in [I-D.king-teas-applicability-actn-slicing].

>
>    Abstraction and Control of TE Networks (ACTN - [RFC8453]) is a
>    management architecture and toolkit used to create virtual networks
>    (VNs) on top of a traffic engineering (TE) underlay network.  The VNs
>    can be presented to customers for them to operate as private
>    networks.
>
>    In many ways, the function of ACTN is similar to IETF network
>    slicing.  Customer requests for connectivity-based overlay services
>    are mapped to dedicated or shared resources in the underlay network
>    in a way that meets customer guarantees for service level objectives
>    and for separation from other customers' traffic.  [RFC8453] the
>    function of ACTN as collecting resources to establish a logically
>    dedicated virtual network over one or more TE networks.  Thus, in the
>    case of a TE-enabled underlying network, the ACTN VN can be used as a
>    basis to realize an IETF network slicing.
>
>    While the ACTN framework is a generic VN framework that can be used
>    for VN services beyond the IETF network slice, it also a suitable
>    basis for delivering and realizing IETF network slices.
>
>    Further discussion of the applicability of ACTN to IETF network
>    slices including a discussion of the relevant YANG models can be
>    found in [I-D.king-teas-applicability-actn-slicing].
>

[Uma]: It would be great if this section reflects what is necessary and
sufficient technologies for realizing the IETF network slicing.
The not-so-nice outcome would be to have someone, who is not fully active
in IETF mailing lists,  in an illusion that these are
*the* technologies to realize on what is laid out w.r.t
underlay capabilities/requirements.
We can go on here, but I would leave it there. Thank you!

>
> 6.3.  Applicability of Enhanced VPNs to IETF Network Slices
>
>    An enhanced VPN (VPN+) is designed to support the needs of new
>    applications, particularly applications that are associated with 5G
>    services, by utilizing an approach that is based on existing VPN an
>    d Traffic Engineering (TE) technologies and adds characteristics that
>    specific services require over and above traditional VPNs.
>
>    An enhanced VPN can be used to provide enhanced connectivity services
>    between customer sites (a concept similar to an IETF Network Slice)
>    and can be used to create the infrastructure to underpin network
>    slicing.
>
>    It is envisaged that enhanced VPNs will be delivered using a
>    combination of existing, modified, and new networking technologies.
>
>    [I-D.ietf-teas-enhanced-vpn] describes the framework for Enhanced
>    Virtual Private Network (VPN+) services.
>
> 6.4.  Network Slicing and Slice Aggregates in IP/MPLS Networks
>
>    Network slicing provides the ability to partition a physical network
>    into multiple isolated logical networks of varying sizes, structures,
>    and functions so that each slice can be dedicated to specific
>    services or customers.
>
>    The Differentiated Service (Diffserv) model allows for carrying
>    multiple services on top of a single physical network by relying on
>    compliant nodes to apply specific forwarding treatments on to packets
>    that carry the respective Diffserv code point.  This approach is
>    developed in [I-D.bestbar-teas-ns-packet] to realize network slicing
>    in IP/MPLS networks.  This solution is agnostic to the path control
>    technology used in the network slicing domain and allows service
>    differentiation of traffic within a given network slice.
> END
>
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas
>