Minutes IETF99: netslicing
minutes-99-netslicing-02

Netslicing BoF
IETF-99, Prague, 17 July 2017, 13.30-15.30

==

Chairs:  Gonzalo Camarillo
         Adrian Farrel
Scribes: Susan Hares, Kiran Makhijani, Ignas Bogdanos

==

1. Administrivia (chairs) [5 : 5/120]

Gonzalo: Meeting starting.
 - We are going to be very strict on the time.
 - Please speak slowly and give your name at the mike.

2. Purpose of BoF (chairs/AD) [5 : 10/120]
 - This is a non-wg forming bof.
 - Trying to gather information, educate, and to focus
   discussion:
 - 4 main questions:
    - What do we mean by "network slicing"?
    - What are the main use cases?
    - What IETF work is in progress or needed?
    - What non-IETF work is revelant?
 - Draw no conclusions from the fact this is an OPS Area BOF
    - It goes across areas

3. How the IETF would approach this space (and what we won't do)
                                             (chairs) [5 : 15/120]
 [Slides with Adrian's comments]
 Due to the fact that some of you may new, we'll provide this
 information:
 - IETF works on the IETF and its protocols
 - IETF works best with focused working groups
   - clearly defined problems
   - that will be doing deployment shorlty
 - IETF is not a research organization
 - We want tractable problems
   - for imminent implementations and deployment
 - The IETF is not good at "all-embracing" architectures
   - We are best at on-the-wire protocols
   - Internal APIs are are out of scope
   - We don't have a good record of External APIs
     - But YANG may be a counter example

 - How to conduct yourself in the BOF
   - Be civil (please)
   - Listen carefully
     - you may both be right
   - Stick to your time limit
     - We will gong you out
   - Save all questions for the discussion
     - except for clarification comments.
 - Questions we'll review at the end
   - Things to have in mind?
   - What do we mean by "network slicing"?
     - common views or distinct views. Is the definiton clear?
   - What are the main use cases?
     - apply to the Internet and people want to solve
   - What IETF work is in progress or needed?
     - Tweaking or is it going fine?  Do we need new work?
   - What non-IETF work is revelant?

 - RFC5434(ish)
   - Is this a problem that needs to be solved?
   - Is there a criticalk mass of participants willing to work
     on the problem (write drafts, review drafts)?
   - Is the scope of the problem well defined and understood?
     Can we list the deliverables?
   - Is there a resonability probably of success to attack this
     problems



4.
Georg presenting.

Georg: I am 3GPP CT chairman.

We have major discussions going on on how to make collaboration between IETF and 3GPP more
efficient. Tomorrow lunch time discussion includes that.

Benoit: Are you 3GPP liaison?
Greg: I am 3GPP liaison to IETF. Gonzalo Camarillo is the IETF liaison to 3GPP.

We have a deadline for R15 for June 2018. Plus 3 more months for issue fixing.
Deadlines are sharp. We can allow some linger time but that is not easy for R15
and R16.
If IETF starts work for anything that is intended to R15 or R16 it is important
that the work is completed by deadlines.

3GPP currently does not have dedicated requirements - not currently. There is
nobody in 3GPP that can guarantee that any specific IETF solutions is required
for 3GPP. The work is just starting.

Many groups will work on NS in 3GPP but I do not know the outcome of that at the
moment.
That does not mean that IETF should not work on their own on NS.  The IETF usually
goes ahead to provide protocols and solutions.

Description of 5G Network slicies in the SA2 (architecture)

Specs:
    TR28.801 - Study on network slicing
    TR28.531 - provisioning of network slices



5. Understanding what different people mean by Network Slicing
   Addressing the following questions:
   - What do I mean by network slicing?
   - What are my main use cases?
   - What IETF work is in progress/needed?
   - What non-IETF work is relevant?

  a. BoF proponents' view of network slicing
     i.  Terms and Systems (Alex Galis) [10 : 35/120]
         IETF problems to solve / needing work
         draft-galis-netslices-revised-problem-statement
         draft-geng-netslices-architecture

Alex Galis presenting.
Questions that will be answered:
What do I mean by network slicing?
What non-IETF work is relevant?
What IETF work is needed?

[Network Slices slides]
         IETF problems to solve / needing work
- cross domain coordination
- network slicing oam,
- performance guarnatees and Isollation
- Slicing Recoures

Adrian: Could you clarify what you mean by isolation, as many people have different
  interpretaions?
Alex: Separation of network functions by the control plane. Slices will have their
  own management. Two separate slices in the deployment may need to have separation
  for not to interfere with each other. Slices are the management concept, an old
  one, even IETF works on this.

1 Problem - NS Life cycle Management
  a) create the group of network resources
  b) templates assists the life cycle
  c) discovery andmonitoring probes are needed
   Key is a uniform model across all slices.



     ii. Requirements and Gap Analysis (Cristina Qiang) [10: 45/120]
         draft-netslices-usecases
         draft-qiang-netslices-gap-analysis

Cristina presenting.
4 requiremetns:
    1) Slicing resources and requirement description
    2) Cross-Domain Coordination
    3) Performance Guarantee and solution
    4) Network Slicing OAM

Conclusion:  2 dimension chart
1) conclusion: need new home to resole the red regions
2) Need extension work for green


Adrian: what is the differennce between soft and hard resource requirements in NS?
Cristina: I can give an example.
[Discussion deferred to list to avoid confusion]

Comment from floor (repeated by Adrian): Does hard mean mandatory mean and soft mean
  optional?
Cristina: Not necessary.



  b. Network virtualization and network slicing (Daniel King) [10 : 55/120]
     draft-king-teas-applicability-actn-slicing

Daniel King presenting.
Ted Hardie: you mentioned how multidomain had a couple of different meaning, and one of
  them was across multiple administrative boundaries. Whether of any of these TE networks
  are multi-ASN?
Daniel: In theory the framework supports it. Whether that will be deployed or not is a
  different question. One provider can provider a large portion as a broker and the other
  would use that as a poll of resources.
Ted: Do you anticipate someone will be acting as an orchestrator above to create the
  overall setup?
Daniel: Overall yes.

... Daniel: We see there is request of compute and storage informatio from network slices.



  c. Applicability of network slicing to IoT (Jari Arkko - PEND) [10 : 65/120]

Jari presenting.
   Useful Access Network Properties from an Internet of Things perspective:
       Separation (traffic separation, resource guarantees)
       additional control (e.g. low latency, topology control, DETnet-style reservaion)
       scaling up/down (run own 5G network in factor),
       flexibility (tailor services to sitaution, allow evolution (features/sw)
   Observations:
    1) much is doable wtih existing tools
       a) are there missing ones? ... Unclear, can always do more
       b) learn to walk before running (short timelines, incremental process)
    2) Be careful with the assumpotion of silos (draft-arrko-arch-low-latency)
      - technical and business things




  d. Routing and Forwarding in support of Networking Slicing (Stewart Bryant) [10 : 75/120]

Stewart presenting.
    Overlay services the customer
    Underlay services the overlay
    Need stronger tie between the underlay and overlay
    Need to be able to constroke bespoke networks and assurred networks (critical
    networks, deterministic networks, regulated applications)

    Transport new network types
    Enhance the capbilities of the Internetwork

    Current work (SR, SFC, DETnet, ACTN, in TEAS)
    New work: Enhance SR with more instructions, Fine grained path specification,
    integreate SR and SFC, carry SRC and SFC over IP, strategies to reduce head of
    line blocking.
    Current and new work builds VPN+.

Adrian: Can you answer the question I had before on the isolation?
Stewart: It is such that if I am running an appication on one layer I cannot tell that
  the other network does not exist. I have the resources that I need even if I am
  sharing them.

Janos Farkas: 802.1 is working on a similar type of behaviour.
Stewart: I want to add similar type of guaratnees to a underlying packet network. At
  the moment it is best effort, would be good to be able to ask for more from the
  network itself.



  e. Network slice management and orchestration (Hannu Flinck) [10 : 85/120]
     draft-flinck-slicing-management
Hannu presenting.

Benoit: Clarifying question - can you clarify what you want to standardize in the IETF,
  as it seems that you want to make a full oss system. You talk about lifecycle
  management cross-domain orchestration
  - What is your goal in the IETF?
H: There are interfaces that need to be defined here.
Benoit: What are those interfaces?
H: Some of them are nonexistent.
Benoit: I like that
H: Data models compatibility, abstractions, interface supoort for recursion.
Benoit: interfaces - APIs, understood.  Between what functions? Do you want to
  have management functions on devices, or cross domains?
H: This may not be the business of ietf.

Sri Gundavelli: Do you foresee any new protocol definitions?
H: No. Possibly extensions of existing ones. Multidomain creates some policies
  that are not supposed to release very sensitive information and we need to
  encapsulate the data models.



6. Open discussion (chairs) [20 : 105/120]  [NS = network slice]

Gonzalo: Discussion. Please keep in scope and be concise.

Adrian: There is nothing that precludes presenters to going to the mic.

Tal: Question for George. We  understood that 3gpp is not waiting for our work, and we
  can define SN architecture on our own., Who is the target audience of the work that
  we discussed today?
Georg: I am not certain what you mean by target. My understanding that you are self
  esteemed to work on your own. If you keep these things under your radar most likely
  your solutions will be selected but I cannot promise that. There will be an evaluation
  process.

Norm Finn: This is a scale question, are we talking about 10, 10K, or 10M customers?
Adrian: A question in the room: Who thinks it is nearest to 10 customers per link/node?
  Who thinks it is neare to 100? I mean 10 slices, 1000 slices, or a M of slices.
   10/links/node: slicing 10 customers link or node - 20 hands
   1000/links/node - 20 hands
   1 million/links/node - a few optimists in the room
Gonzalo: Note there were a very few people raising hands,

Alex Galis: Before VPNs were invented the answer was very diuffernt and moved from few
  to many. Slicing will increase in scale as it gets more mature, the answer will be very
  many, as that is going to be an abstraction on which everyhting dpends.

Danielle Ceccarelli: As summary - we have different types of domain (radio is out of our
  business). Transport that has different requirements, personally I agree that that
  requirements can be addressed by IETF technologies -  I do not see a huge need for new
  work.  Then the cloud NFVi, packet core (out for the moment), we have a lot of solutions.
  Maybe you could start to make those domains work together, I see ACTN as a perfect
  starting mode. We already have YANG models.
Gonzalo: ????

Luang Chun: My observations: helping the room understand what 3gpp think what NS is.
  NS defined by 3gpp includes RAN part and packet network. There are requirements saying
  that NS management system defined by 3gpp should relay/advertise link requirements to
  transport NMS, to decide which transport technology to be used, and option 2 is assuming
  that 3gpp NS NMS has an approach to know that for itself. Another point responing to
  Hannu - I do not agree on transport being NS subnet instance, NSSI may include core
  network only or ran only, or both. It does not include transport network. NS in 3GPP
  only includes RAN and CN. There are no direct overlaps between the definitions of NS.

JeffTantsura (IAB Shepherd):  There are no requirements coming from 3gpp. If it is very
  3gpp focused it will result in niche solution. NS is not new: we have been doing L1 VPN,
  and L2VPN for a quite while, but we never looked into the resources. Mobile edge
  computing requires a notion of NS, that means networking resources to be used and
  deployed. We should focus on industry problems and not on 3gpp only,. They are not
  telling us anything therefore we are not doing anything for them., In my perspective
  it is wrong to focus.

Dave Allan: What we want to avoid is the mistake of conflating all the requirements of
  NS to be satisfierd by all the network. There is a RAN component in the network.
  ... many of the functiona are only collocated.  Therefore are many of the slicing
  requirements will be isolated from the network, and will be handled by the collocated
  equipment and that will not extend beyond the network around those nodes. This is
  about intelligent arrangement of resources.

Sri: Provisioning domains - MIF WG has a work on mPVD. Many concepts are presented in
  that work, suggest to look in to it.

Warren: A large amout of discussion seems to assume that the network exists everywhere
  and looks the same. That does not work like that. Networks are built to expected uses.
  If you expect to go and say that I weant some capacity with latency guarantees, that
  mean that the network needs to be build with more capacity to ensure that. This means
  things will become way more expensive. We cannot assume that happening, if poeple are
  ok with that but providers are not going to build up to that level.

Igor B: I fully agree with Jeff and disagree with China mobile person (Luang Chun)
  NS is a packet switching layer. This is how things use to Bs slice user, but when we
  talk about the constrains, this is north of network into management and we have to
  deal with that,

Xie: We have a smilar view on requirements. IETF working on transport network to provide
  a service for more general use cases. Those works should be useful in the IETF.

Benoit: Trying to understand what is required for NMS part from IETF. We are dealing
  with networking in thet IETF, and here I see orchestation. Do you want to have all of
  this done in the IETF? If not, which parts?
  There were talks about APIs. What do you want to have from the IETF?

Alex G: There is no need to wait for the requirements coming from 3gpp. It is to
  ensure that this transport network can carry one service well and not all of them.
  We are talking about embedded management protocols in the network and  that includes
  new ones that need to be created, the coordination of all this slicing, either one
  domain or multiple conf protocols related to discovery which need to be created
  autonomically, new protocols needed for the creation of the resources, network
  functions and slice creation and instantiation. new protocols are needed for
  elasticisty of the slices. Less resources, more network functions, and this needs
  to be dynamically created.  This is pure management of transport network. This work
  will add value of substance. It is a form of traffic engineering. To answer on
  isolation - there can be many network types, SDN line and no SDN line, and it should
  cover all of these parts.  Solutions for these problems are within 2 years to catch
  with the industry.,

Benoit: Can you come back to my question? Do you want to standardize the arrow in the
  back of the diagram only? [refers to Alex's slides]
AG: No. Green arrows too. The bottom, some of the two middle boxes.
Benoit: You want to have full NMS?
AG: Embedded set of protocols. It also does not show how it would be linked to
  classical NMS. We need to cover full FCAPS., We need it urgently.
Benoit: I have been involved in those NMS cross domain cross-controller aspect in
  FCAPS. This is complex. This is what you have on the arrow on the top. You want to
  work on service level. That is easy to create those models and derive APIs. The hard
  part is how do you map that to different underlying technologies. This is like code
  that we have to write with if statements covering whatever that is transport or
  deployment situation (whether that is DC or some other place).
AG: There can be a number of items that need to be standardized. This mapping has to
  be done per slice. This mapping has to be multiple. How to put together all things
  together is a template, which has to be uniform. Otherwise the slice in 3gpp will
  be completely different than the one in my pocket. It is not that hard, it is just
  complex.

JeffT: To bring to IETF any solution of slicing will require recursiveness. This should
  be discussed about now. Our APIs are as good as are our data models. They might not
  be worse as we expect. There needs to be attention on the IETF side to provide the
  right data models.

Gonzalo: cutting the mic lines

Chunshan Xiong: We have 7 layer OSI architecture. For slicing, difference layer and
  different SDO have different understanding.  In IETF we want to focus up to layer 3.
  In IETF we work on ipv4 and ipv6 packets, and for VPNs in IETF, we have l2vpn, l3vpn,
  even people say that peer to peer can create application layer VPN.  If we start
  slicing we need to restrict layer that the slicing is.

Erik/akamai: A prior work on this topic is the GENIE, research network.  It is a
  national scale interconnect of cloud computing. This is a first time I heard the
  term NS.  There is a running code and opportunities to play with that. This stuff
  has been around in the R&D environment for a while. If you try to provide better
  than best effort service it actually can be done.

xx (??): I have never seen use other than experimentation outside of those communities.

Anton Ivanov: What was presented as a set of use case: it is so large that I can not see
  how a piece of work for a BoF can be defined. If we add historical use cases, Genie
  is not the only one. vCPE as a product is a classic example of NS and predates NS by
  years. If we keep this as ietf work so not serving 3gpp and we keep a wishlist we
  will not get anywhere. This need to be cut down.

Gonzalo: If we find that we find whether there is work relevant for ietf and the
  internet we will work on it.

Jari: Respond to the cost comment - things will be limited by the market behaviour. If
  lots of people request and pay for that it is great. I do not think that is a major
  issue.  I think  concern, I would wonder more on the complexity piece., IETF does a
  lot of great work on this and we need to expand that work, but we should not get
  totally crazy by accomodating all possible requirements.

Gonzalo: mic lines closed.


7. Answering the RFC 5434 questions (chairs) [5 : 110/120

Adrian: please hum if you now are more intelligent now than if you came to the room?
  some hums.
Adrian: Please hum if you are more confused
  a few hums.
Adrian: Is the scope well defined and understood? Do we have a clear understanding
  what NS is, do we believe that there is a problem called AN to investigate further?
  silence - no hum
  [applause follows]
Adrian: Does the problem need to be understood?
  more hums than before
Adrian: Is the problem now better understood?
  not many hums
Adrian: Do you think it is not well understood?
  more hums
Gonzalo: we have a stronger hum now,
Asrian: If we were starting work, for some work that needs to be done, who in the room
  would be willing to work on this by writing and reviewing?
  I see 30 hands.
Adrian: Why would you do that? Is this a problem that needs solving in ietf, and a
  problem that needs to be addressed?
  quiet hum
Adrian: Is this not a problem to be solved in IETF
  quiet hum
Is this a problem that does not need to solved
  tiny hum

Greg Mirsky: To me it was clear that there is not one problem but a bunch of problems.
  We need to look at the problems separately, there are problems that I am interested to
  work under netslices that go here.

Gonzalo: we got the answers to the questions that we asked.  Now the BOF chairs will have
  a beer.



8. Conclusions and next steps (chairs and ADs) [10 : 120/120]

Gonzalo: After this BOF, we'll post the minutes and then close the BOF.
  The hard part is to summarize this BOF.


Benoit: Summarizing. What we do at the end of the week we will have iab/iesg meeting
  where we will review this BOF.
  - Your conclusions are right. I see a lot of people in the room.
  - NS has got a specific notion in 5g but we heard that we do not have those
    requirements.
  - We may have use cases that are not 5g requirements. I am not surpeised by that.
    Many terms and use cases that are not 5g. I still see different definitions of NS,
    one here, one in 3gpp, one in actn, one in routing.  The group would need to
    harmionize this.
  - We want to have NS management, slice management, We want to have OAM. NMS/OSS
    - I am confused here. I want a pony here, I want a button that invents bandwidth
      and loss of zero. behind the nms/oss there are a lot of things happening. How do
      you map to the network below. Depending on location. There are partial working
      parts in ietf, but heard that there is nothing required.

  - I heard there are need to have compute, storage, and routing.

Gonzalo: What the proponenst what should do when you are doing your next steps?
Benoit: Discussing with the other proponents.