Re: [Teas] Network Slicing meeting at IETF 97

[Lou Berger <[e-mail]>]

Stewart,

Thanks for this information. It would be good if you could help kick off 
the discussion by describing how Slicing differs from current RFCs, ACTN 
and other existing (chartered) work on TE.

Thank you,
Lou



On November 22, 2016 9:01:41 AM Stewart Bryant <[e-mail]> 
wrote:

> 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.
>
> Stewart
>
> On Tue, Nov 22, 2016 at 6:15 AM, Stewart Bryant
> <[e-mail] <mailto:[e-mail]>> 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
>     welcome.
>
>     I have put the slides on dropbox rather than attach them to the email.
>     The slides can be found here:
>
>     https://www.dropbox.com/s/ax2ofdwygjema8z/0-Network%20Slicing%20Side%20Meeting%20Introduction_IETF97.pdf?dl=0
>     <https://www.dropbox.com/s/ax2ofdwygjema8z/0-Network%20Slicing%20Side%20Meeting%20Introduction_IETF97.pdf?dl=0>
>
>     https://www.dropbox.com/s/k2or6sd0ddzrc6c/1-Network%20Slicing%20Problem%20Statement_IETF97.pdf?dl=0
>     <https://www.dropbox.com/s/k2or6sd0ddzrc6c/1-Network%20Slicing%20Problem%20Statement_IETF97.pdf?dl=0>
>
>     https://www.dropbox.com/s/g8zvfvbrtkysjs1/2-Autonomic%20Slice%20Networking_IETF97.pdf?dl=0
>     <https://www.dropbox.com/s/g8zvfvbrtkysjs1/2-Autonomic%20Slice%20Networking_IETF97.pdf?dl=0>
>
>     https://www.dropbox.com/s/d3rk4pjeg552ilv/3-Architecture%20for%20delivering%20multicast%20mobility%20services%20using%20network%20slicing_IETF97.pdf?dl=0
>     <https://www.dropbox.com/s/d3rk4pjeg552ilv/3-Architecture%20for%20delivering%20multicast%20mobility%20services%20using%20network%20slicing_IETF97.pdf?dl=0>
>
>     https://www.dropbox.com/s/e3isn1bxwwhaw8g/4-ACTN%20and%20network%20slicing_IETF97.pdf?dl=0
>     <https://www.dropbox.com/s/e3isn1bxwwhaw8g/4-ACTN%20and%20network%20slicing_IETF97.pdf?dl=0>
>
>     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
>
>     https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00
>     <https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00>
>
>     Presentation:
>
>     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?
>
>     Discussion/Questions:
>
>     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
>
>     Presentation:
>     https://tools.ietf.org/html/draft-galis-anima-autonomic-slice-networking-00
>     <https://tools.ietf.org/html/draft-galis-anima-autonomic-slice-networking-00>
>
>     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
>     networking
>
>     - The service instance component
>     - A network slice instance component
>     - Resource component
>     - Slice capability exposure component
>
>     Suggested 15 work items and issues
>
>     Discussion/Questions:
>
>     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
>     connectivity
>
>     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
>     session.
>
>     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
>     protocols.
>
>     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
>
>     https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00
>     <https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00>
>
>     Presentation:
>
>     Multicast functionality is different for say broadcast, mobility etc
>     cases, so there is a need to function decomposition and function
>     chaining.
>
>     Discussion/Questions:
>
>     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
>
>     https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01
>     <https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01>
>
>     Presentation:
>
>     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.
>
>     Discussion/Questions:
>
>     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
>     solution.
>                 It is generalized for L0-L3 layers and need to be perhaps
>                 extended for L1,L2 and NS. ACTN seems to have a good
>     starting
>                 point for network resource slicing and Detnet may be
>                 implementing a protocol solution for time-sensitive
>     networking.
>
>     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
>                 applications?
>
>     YoungLee:  ACTN also support NFV-constraints as part of abstraction and
>                 connectivity.
>
>     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,
>     beneath
>               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
>     easier.
>
>     Comment 7. For 5G transport, IETF has a role to play. Front-haul,
>     back-haul
>                 and cross haul need transport network abstraction which is
>     needed
>                 for 5G network. Orchestration federation takes each
>     component
>                 to give end-to-end solution.
>
>
>     Georgios: Asked how does it do QoS besides partitioning of n/w
>     resources.
>
>     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
>     problem.
>
>     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
>
>     Comments:
>
>     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
>
>     <end>
>
>
>
>
>
> ----------
> _______________________________________________
> Teas mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/teas
>