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 Mirskly: 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.