[Teas] Network Slicing meeting at IETF 97

Stewart Bryant <stewart.bryant@gmail.com> Tue, 22 November 2016 14:01 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 688F01299F6 for <teas@ietfa.amsl.com>; Tue, 22 Nov 2016 06:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id oRpConzkntmO for <teas@ietfa.amsl.com>; Tue, 22 Nov 2016 06:00:56 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 A4DDA1299F0 for <teas@ietf.org>; Tue, 22 Nov 2016 06:00:55 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id a197so26781980wmd.0 for <teas@ietf.org>; Tue, 22 Nov 2016 06:00:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=DZ2u1DJrT/GhOLeRQEz0D52g2z6htrsmuOMDadUykPk=; b=heXf35FWlHqcB9W15HRwL6SWuZbsl2oVzottohT2oFkKwAiOufpL/mPeCEaQp3YUXg 81dQ7PPaHJF8j39o5NT5nnph+Oae0C7wsSwgMmh3tlrv6E5ritR3ZifajcD+pG4UCEtZ LUwqEciVO7jWLrNI28VLgU/E8akfBTzRgVyS8pA56yRBJ1OtDeMFsHShCgZIhxCj/Gx5 MWBPAv/z+LuKop0VxqhN1ESkl5+Og2iFyLNnqUvIAeilhD92n0ts2iQGyAYMfplytxis 8iwk0+JKq/hQdTPY/zv1fJR3Ey1UHYYuJ5u/+cCEh6WWB2EQ6gnB2MuqsKR96tCfPJEQ 2usw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=DZ2u1DJrT/GhOLeRQEz0D52g2z6htrsmuOMDadUykPk=; b=ljIqegolFbMDzATzMZ5MkfjCEZ+t6Xg/tBqH7lM3+qP0d+rVJXyetCCScNsl8IfQHX SJ2tihJSxvUCNHdILJvgBxrnE0bucQYOr46FVUQOZyExGnII/u0KVc4lGtdVacbViBpQ FCnEqyLFRzoH6qu/N65X3GnsZyKMlcEs//P8vD8I7Xfed3BXOVjP9LmjgWgQk+Bl5jZ+ wHXckgCjsg1Olli/QhP7u+yMnYfX59jEyCi/tBl3Tn2btfHAMV7ZGnsOXWic6fhSSpr3 ZPNLTrg162MLu+ExmrSnTtsoTJxQt1w3yJICrHZP2rVScKZEXmzhiWi8go2UQYzros1z 8wPw==
X-Gm-Message-State: AKaTC03NRi6NBWY6Jfei4p2J9rCVElBsJQovQ6a2AH4eXwPvI7xQTv3WZ9/J3dD1j85cLw==
X-Received: by with SMTP id n81mr2505560wmg.120.1479823253633; Tue, 22 Nov 2016 06:00:53 -0800 (PST)
Received: from [] (host213-123-124-182.in-addr.btopenworld.com. []) by smtp.gmail.com with ESMTPSA id ab10sm30968935wjc.45.2016. for <teas@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 06:00:53 -0800 (PST)
References: <CAA=duU1FEC2n6PQL6VTG2=5-1NFzj24u-MAPyYb4SgVF5U8iAA@mail.gmail.com>
To: teas@ietf.org
From: Stewart Bryant <stewart.bryant@gmail.com>
X-Forwarded-Message-Id: <CAA=duU1FEC2n6PQL6VTG2=5-1NFzj24u-MAPyYb4SgVF5U8iAA@mail.gmail.com>
Message-ID: <99babdf7-b3bb-bc6b-4331-1f3ce0e38932@gmail.com>
Date: Tue, 22 Nov 2016 14:00:51 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <CAA=duU1FEC2n6PQL6VTG2=5-1NFzj24u-MAPyYb4SgVF5U8iAA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------CB4153AC340F99980449FBFA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/lDT3Izdmco7KAufVMj99Q1bPhuk>
Subject: [Teas] Network Slicing meeting at IETF 97
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
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, 22 Nov 2016 14:01:01 -0000

I sent the following to the attendees of the Network Slicing Side 
Meeting at IETF97.

It has been proposed that discussion continue on the TEAS list.


On Tue, Nov 22, 2016 at 6:15 AM, Stewart Bryant 
<stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com>> wrote:

    Thanks to everyone that participated and thanks to those that took notes
    of the meeting.

    Jie and I have merged the notes, which are included below. Corrections

    I have put the slides on dropbox rather than attach them to the email.
    The slides can be found here:






    If anyone has trouble with the links, please let me know and I will make
    some other arrangement for depositing the files.

    To avoid span traps, I am sending this to a few people at a time, so
    please do not reply to this email and expect the
    message to go to the entire set of attendees. The last discussion I had
    with the Routing ADs suggested that we
    continue the discussion on the IETF TEAS list. I am not sure that this
    is necessarily the best long term home, but let's
    start there and if we generate to much noise outside their scope, I am
    sure we will be asked to move and provided
    with a new home.

    Best Regards

    Stewart & jie


    Network Slicing Side Meeting

    Nov 14, 2016, 19:00-21:00, Studio 3

    67 People signed the attendance sheet.

    0.    General Admin

    Jie Dong introduced the purpose of the meeting.
    Services have unique requirements, end-2-end slicing is required
    for 5G. Among definitions we need to establish common definition.
    Purpose is to have a common view of what network slicing is in IETF.

    List request has been sent to Deborah (Routing Area AD).

    1. Network slicing problem statement    Stewart Bryant



    What is to be done in IETF, what existing and new work?

    Existing definition
    -    NGMN
    -    3GPP
    -    ITU-T (FG IMT-2020)
    -    IETF?

    Requirements of Network Slicing
    -    Isolation/separation
    -    Customization of topology
    -    Flexibility of topology
    -    Guaranteed QoS
    -    Management consideration

    What should be definition of network slicing in IETF ?
    What is needed beyond connectivity?

    What is the scope of network slicing in IETF?

    How much can existing/on-going tech meet the reqt?


    Comment 1. IETF is protocol-oriented, how would slicing change
    the semantics of existing protocols?

    Stewart: We typically have a set of tools designed for
    best-effort fabrics and adding BW, these are not scalable and we
    need some additional scheduling.

    Comment 2. We typically build separate networks for banking and
    other low latency apps, this is not economical. Isolation and
    security are weak points.

    Comment 3. What are the performance and isolation requirements?
    Does this mean statistical sharing is out of scope? Fixed
    fraction of b/w seems to be a must.

    Stewart: There will be a spectrum of requirements, different QoS
    for different application, we may need some packet scheduling.
    Do we need isolation using mechanisms like IEEE (time sensitive
    networking ? TSN) or detnet. If its bit-level, we will go back
    to TDM.

    Andrew: isolation and security is the biggest challenge,
    figure out how to provide banking applications in economic manner,
    such as a slice. Packet scheduling at buffer and line speed
    level is not enough we need to adapt to packet changes at micro-level
    (it was quietly mentioned, we are not thinking at bit-level but
    focus at packet level).

    Comment 4. Look at 5G applications for machine critical, interface
    b/w down to radio is key, we may adapt BW based on radio capacity,
    Internet does not do this today, we need to figure this out.

    Stewart: It may be a packet level.  factoring into a lower layer is
    an issue

    Comment 5. Can we define slicing??

    Stewart: We can also agree on an existing definition, which would
    be useful.

    Comment 6. Generalised packet networks are not suitable for hard
    packet tunnels.

    Comment 7. Dave Allen (Ericsson):  slicing definition leave it open
    disjoint resource like wavelength is considered in other forum as
    the only way to achieve isolation. e.g. WDM-PON, wavelengths allocated
    per slice. (Young Lee added that WSON controller is already doing this).
    What does packet have to do if isolation cannot be guaranteed?

    2. Autonomic slice networking    Alex Galis


    Generation 1 - Resource partition of network resource is one definition.
    Generation 2 - Network function and services are another definition of
                    network slicing.
    Generation 3 - Grouping of partitioning of 5G slicing
    Generation 4 - Management and control and advertisement has to be added
                    to the Network slicing definition

    ANIMA - unified network slicing definition in the context of autonomic

    - The service instance component
    - A network slice instance component
    - Resource component
    - Slice capability exposure component

    Suggested 15 work items and issues


    Comment 1. Dino: asked difference between horizontal and vertical
    slicing. Vertical slicing, can an application be a member of
    multiple slices? Will Extranet be required? For horizontal
    slicing, would it be stitching or something else? These would be
    for customers ill shared services and isolation for specific VPN

    Alex: Yes, level of abstraction and level of isolation need to be
    considered, and separate control may also be needed.

    Stewart: We may see both models

    Comment 2. This complicates the solution space.

    Alex: This is not an intent to recreate a VPN technology.

    Comment 3. Feels like IETF is lagging in industry work, upper
    service layer which drives network resources. OpenSource is already
    ahead/doing some of this, slicing is mainly multi-tenant, this is
    not rocket science or new. They are trying to map existing
    technology like
    VXLAN and mapping it into YANG. Is there a new architecture and
    protocol required? what is the role of IETF? API ? application
    level TOSCA; policy; YANG; already in place in industry. Question
    is where is the gap? Map to protocol of new or existing protocols.

    Stewart: Those are the questions we are asking at the start of the

    Comment 4.  Slicing is a service definition, where is the gap?
    Categorise them and see if we need new protocols, or adapt existing.

    Alec: Yes, at least 15 problems, these are not supported by existing

    Comment 5. We have a slicing architecture (as part of a H2020 project),
    and service orchestrator, we then define flows which are application
    specific: IoT, video, etc.

    Comment 6. Ravi: IMT-2020 challenge was that service context could
    be only identified by flow tuple in cp, dp and mgmt. Also slicing is
    interesting for ICN as it allows new architectures and new properites
    per slice basis.

    3. Architecture for delivering multicast mobility services using
    network slicing Truong-Xuan Do



    Multicast functionality is different for say broadcast, mobility etc
    cases, so there is a need to function decomposition and function


    Comment 1. You are aware of DMM working group, DMM FTC draft defines
    a model that covers this. I think the group does not have a good
    definition of "slice", domain is similar with 5G slice. I think it's
    not clear what a slice is.

    Stewart: This is why we are here; do we need to define "slice"?

    4. ACTN and network slicing - Daniele Ceccarelli



    Describe end to end L2VPN/L3VPN is not enough, so there are 3
    different level of controls (CNC, PNC and MDSC for customer, physical,
    multi-domain network controls). Access points, per domain tunnels and
    inter-domain links. Customer is able to provide constraints during
    network provisioning.


    Comment 1. Parviz: ACTN is a great piece of work, we have integrated
                based on this framework. We shipped and integrate into ONOS.
                ACTN is used for integrated packet optical SDN based
                It is generalized for L0-L3 layers and need to be perhaps
                extended for L1,L2 and NS. ACTN seems to have a good
                point for network resource slicing and Detnet may be
                implementing a protocol solution for time-sensitive

    Comment 2. Do you slice at the lower/physical lower and provide a
    slice to
                the customer? So they can modify network resource, based on
                their specific slice? Customer may just want the
    resource, not
                a solution, they want to manage it by themselves.

    Daniele:  Yes, they can manage their own resource.

    Young Lee: VNF connectivity is included in the solution.

    Alex: Maybe methods for slicing exist, the management methods for
           specific applications and network functions are missing.

    Comment 3. ACTN has multiple topology descriptions (physical, virtual
                and customer), can it support end to end slicing with

    YoungLee:  ACTN also support NFV-constraints as part of abstraction and

    Comment 4. Looking at ACTN it seems it can abstract multiple physical
                domains and give us a logical view of TE/transport.

    Daniele: ACTN introduces virtual networking, between MDSC and CNC,
              PNC, its technology/vendor specific.

    Comment 5: Why ACTN for network slicing? Does it support hierarchy?

    YoungLee: Yes. It does via MDSC-MDSC recursion.

    Comment 6. ACTN is for multi-domain. How about for a single domain?

    YoungLee: Yes, multi-domain solution includes single-domain, which is

    Comment 7. For 5G transport, IETF has a role to play. Front-haul,
                and cross haul need transport network abstraction which is
                for 5G network. Orchestration federation takes each
                to give end-to-end solution.

    Georgios: Asked how does it do QoS besides partitioning of n/w

    Ans: Whatever TC can do is supported

    Pedro: There are 2 aspects of slices - an act of creating it, and second
            customizing and managing it in isolation is second part of the

    Comment: Service abstraction layer is missing and Information models.

    Seil: is there a gap to be discussed.

    Natasha from GSMA: not duplicate the work of other SDOs, if work needs
    to evolve they will let IETF specific group know.

    Wim from Nokia: slicing includes all - management, applications, radio
    etc beyond transport.

    Chris Seal: we need a stable platform first that doesnt exist.

    Loa: non WG BOF can be done, it is way too early to exclude from IETF

    Dave Allend: so many people are working on it. Problem space need to be
    deconstructed, work needs to be done in totality of it.

    Jonas: can we invite 3GPP for next meeting?

    5. Open Discussion 60 mins

    Stewart posed several questions

    1. Does the IETF need to work on slicing?   Yes

    2. Does existing technologies solve the full set of slicing
    requirements?   No


    Already there are several slice definitions, educating and agreeing
    definitions is useful

    - Suggest we allow implementations first using existing solutions, using
    the tools which are already available.

    - Network slicing is important; it needs to be end-to-end and the IETF
    has be involved. We also need to engage with other SDOs (3GPP, et al.),
    including inviting the (SDOs) to participate in a BoF.

    - ACTN seems like a good starting point, maybe this needs to be extended
    for additional technologies like Radio

    - A lot of this discussion needs to be relevant to the IETF, what's on
    and in the wire

    - Process from here for the discussion, is non-WG BoF and then
    WG-forming BoF. We should not exclude a potential WG on this topic, we
    should prepare and investigate, then if we decide not to form that's
    better than not being able to form due to a lack of investigation work.

    - One reason for lots of slicing definitions is the fact so many people
    are working on this topic. Across different areas and functions
    (controllers, orchestrations), and scheduling and APIs. We would need
    to deconstruct the problem space to understand what is needed, and how
    the IETF can help.

    - Of the questions asked through show of hands, people favored forming
    a non-working group and agreed this is an area IETF can work into.

    - Identifying gaps from IETF perspective is the most important aspect.

    3. Does the IETF need to focus discussion and develop tools for slicing?
    (no discussion captured)

    4. Interests to work on slicing?  A lot

    5. Willing to contribute to drafts and discussions? Some