SDNRG Agenda IETF 90 Thursday, July 24, 2014 0900-1130 EDT (Canadian) ================================================ CHAIR(s): David Meyer Nick Feamster AGENDA o Administriva 5 minutes - Mailing list: https://www.irtf.org/mailman/listinfo/sdn - Web: http://trac.tools.ietf.org/group/irtf/trac/wiki/sdnrg - Scribes? the first is about terminology, nordmark suggested this o Agenda Bashing 5 minutes David Meyer o SDN Layers and Architecture Terminology 30 minutes draft-haleplidis-sdnrg-layer-terminology-05.txt Evangelos Haleplidis We have a couple of updates since London we added more peer reviewed literature. We also added as was requested, some correlation with the RINA architecture. That use this kind of IPC (?) mechanism for creating interconnections and it is a hierarchical architecture. We also added a section for the cap that yakov provided us some text. In order to make more clear the distinction between the control and management plane We addressed as much the comments included coverage for 2 additional protocol. One of the thing that has been coming up a lot during the last IETFs is the distinction between control and management. One question on the list was “Why?” "Why do you need to make such a distinction?” We believe it is a valuable tool for when you have to make design choices for an architecture so having such distinction can help to make a better design choice and also we believe that the management plane is also part of SDN and it has been ignored a little bit by the community. So we created a sub-section that precisely discusses this point (characteristics between control and management) based on the discussions we had here, we defined the following characteristics to distinguish the two. 1st: timescale: how fast a plane reacts, how fast it needs to update control plane: fast, management plane: slower time scale 2nd: persistance. Control plane is usually associated with ephemeral state and the management is associated to persistency (changes after hours, days, weeks, months...) 3rd: locality. control was usually distributed and located close to devices which tend to change with the concept of SDN and management was centralised and remote. Now the distinction based on locality has been shifted a little bit. The CAP theorem is good tool to analyse that. The CAP theorem tells us that the control-plane that was usually located on the device is local and fast and that it is available all the time to make decisions while the management plane is centralised and has a consistent view of the state of the network but it loses the connection to the devices the availability tends to be in question. If we centralise the controller you increase the consistency but you lose part of the availability. If you have any further comments on this please stand up. [yakov stein] you summed it up very well assuming that there is no partitioning going on. You proved that the people who called the OpenFlow concept a control plane simply didn’t know enough about what that means. It is actually a management plane. If simply have to stop saying that what you do in SDN is separating what you do in control and data plane but separate from the management plane. [kostas] I want to highlight that now we start the opposite discussion because before we had a management protocol that did control. Yakov has just introduced OpenFlow as a management protocol. no more comment on control vs management? [diego] I have been in a couple of previous SDNRGs and the difference between control and management was so much discussed and it became almost religious. Happy to see there is something now with definition. This proposition is very much a language. There is a compromise, applying something like CAP. In the case of partitioning there is some constraints but I like it, this is a very elegant way to deal with this never ending discussion [david] no size fits all, so nobody will be happy with every aspect of this but what we try to do is kind of optimise the surface area. This idea is that if you disagree with something it must be minor. [dirk] the CAP for networks paper discusses how you can play with the dimensions of the CAP theorem. We already referenced that paper in the document. We will change a section to notify that we selected yang and netconf for the interface [can’t hear] For the comment that Dave made trying to get consensus, one of the comment we had last IETF is that the operational plane is not actually a plane, because there is no communication between one device to the other. But we decided to defined it as a plane to be considered equal to the other planes in order to be able to group things. We use the definition of plane being the distinction between areas of operation. [yakov] do we really need another plane. I don’t want to go to a complete hierarchy, but if you talk to a service provider, they typically have their business process (often call BSS(?)) then operational process (OSS), then network management system. What we call the management system, they can divide it in four or five different pieces. The control plane can also be divided in two or three different pieces and forwarding has the layering. So if we really want to get every one of these, that’s gonna be hard to document. What do we really need for the purposes of the SDNRG? [kostas] the point of the operation planes is to link with NFV the fact that you have a management plane talking to an operational plane. We don’t only try to capture what has been done now but what we probably expect to see. It may be possible that the operational plane is more evident in the future. [yakov] I didn’t know we were going that way. Many people here were at the NFV. But if you want to go to NFV, the word you have to define is orchestration. If you open that, this means many things to many people. You can say what that word means but no one will agree. I didn’t think that was in the scope of this document. The portion which does workload datacenter application CPU part and the part that puts VNF in different places and the typical management portion, think of management system or looking glass, we can put an app which is the real orchestration and this will gonna be one big thing which does all these pieces and that’s the joint optimisation problem I was talking about yesterday. At some point that’s gonna be a real concept. [kostas] I think you are talking about a different draft that we should start writing. It makes sense though to have a clear disclaimer saying that there is a split opinion of if it is or it isn’t a plane, as it is right now in the text. It would be funny for this document to be deprecated fast by another that goes in the direction you are going. So that gives us some future “compatibility” both for things that are happening today and for things that will come up with virtualised environments. [yakov] if we want to keep this as a place holder maybe you should say something like orchestration is out of the scope of this document. [david] yes that is a great suggestion we also had a comment at London about how NFV relates to this architecture. From our point of view, NFV is actually on the management plane, and the operational plane to request and reserve resources. Our document does not make any distinction whether it is physical or virtual. Having such operational plane help to group such resources. [yakov] the problem I have with that. Ok with a management plane. But what if you slightly extend it to virtual function which are not necessarily network functions (e.g., pure application functions). If you go there, it is very far away from the SDNRG, it is more like a compute management stuff. For me it does not belong to this document. The reason we added this text, beside it was discussed last IETF, was to point out the kind of interface used for NFV. [yakov] yes, but a lot of other things will used interfaces and may not necessary be communication oriented, so again it is far from SDNRG. As long as you don’t put to much text on it, it is ok it is one paragraph text [diego] I agree with Yakov. This operational plane looks like stretching a bit the limits. There is a connection between NFV and SDN but I don’t know where to address this. What we would expect for NFVRG is a software layer to control the virtualised network and SDN will be put in sandwich there. [dave] keep going please What we did not addressed in this document. We did not include anymore SDO(?) activities, Scott provided some info just to illustrate other work is done in SDOs. We believe such work should be illustrated in the wiki and constantly be updated. We were requested to include research about SDN. We did include some paper that already discuss this but we think that the wiki is also a good place because it needs to be continuously updated as well. We were asked to create a matrix of SDN projects vs the model we defined. But as these projects are constantly be updated, it makes more sense on a wiki. [yakov] do we really need this wiki? There is many things already out there (e.g., sdncentral…). Why do we have to do that here? [kostas] we are not proposing to have this wiki page. This slide says what we are not addressing in the draft. [kostas] we say that this does not belong to a draft that will be a frozen document [kostas] as it was proposed in a previous SDNRG meeting, if people feel the need to make such a thing, then the wiki is appropriate. We don’t say take this text and put it there. Thank you everybody for the discussion and comments on the list. We believe the document is mature enough [dave] Lars, can you give some advice, the authors of the draft want to publish, as the first RFC coming out of SDNRG. Can you give us some insights, as not full consensus [lars] unlike the IETF, you don’t need consensus. It is not a requirement at the IRTF. The requirement is that the group needs to describe what consensus the document had. If you have conflicts about that document, you can express that in the text, a paragraph in the intro and abstract where you say “that was discussed and did not get consensus because of X, Y, Z but at least there is consensus enough that it could be published as-is”. You can sure have another document expressing a different viewpoint. That’s possible. [lars] for me it doesn’t sound that you are stuck, it is a difficult topic. [dave] yes, it is why I want to publish it, otherwise it won’t terminate [lars] you think they are stuck? [dave] no. [yakov] we don’t have contentious issue left. What we have now is about the exact nomenclature but at this point we all have pretty much agreed on. Nothing big remains, just a matter of how we call things that are put in the doc. [dave] anybody to comment on that? [ed] I need there is a need of a statement about orchestration is not in scope. Very important aspect. [dave] ok [lars] NFV and SDN are clearly related but unlike the IETF where we clearly separate the topics the working groups are working on, this is not required at IRTF. It is ok to have some parts of SDN and NFV are overlapping and discussed in both group. That’s ok. IRTF is much more liberal than IETF in that sense. You don’t do standard but experimental. As long as you are aware of the other RG and coordinate with them. [dave] so we make the changes suggested today and move it to the queue for informational. o Design and Implementation of an OpenFlow Hardware Abstraction Layer 20 minutes Kostas Pentikousis [yakov] you call this open flow. How open flow specific is it. If instead of using open flow you use something else? How much would change. Contradictorily you said something like we want software reuse and OpenFlow cannot be reused as it is fundamentally non modular and any time you try to something in there it messes up with what you had before so I don’t believe I will ever see service providers using only open flow unless they put something like frenetic (?) on top of it. How much of it is a concept of how to do a hardware layer for some kind of think that might be much better than open flow and how much is this open flow specific? [kostas] the software reuse is not reusing the control plane or code for the control plane and then change something. It has to do with what I mentioned in the beginning that you have a velocity in features and we want to have a diverse set of devices which can be controlled with open flow. Remember that this is a research project even though we have a couple of SMEs doing real work. The code reuse here has to do primarily with the fact that you have a multiplexing benefit by having a cross hardware platform layer. So that you can actually have less code to do on this kind of thing. Imagine that you have the easy case of an NPU (?) for example and you want to support 1.2, 1.3 and onwards. How difficult would it be for ofelia in particular to move beyond open flow 1.0. If you have an experimental facility that has open flow 1.0 you cannot really use it if one part of the experimental facility has 1.3. [yakov] so you say reuse of the infrastructure drivers, not application code. [kostas] applications are beyond the scope of this project. If I know it is OpenFlow below I have assumption and don’t have to think of the version. It is a small project, we have plenty of space to propose new things that could be done on top of that. [kostas] so why OpenFlow and not FORCES for example… [ed] you seem to relegate hardware specific function to netconf. [kostas] the netconf is for the cross hardware platform layer. [ed] how much do you think the use or abuse of vendor extension in open flow can play down the road here [kostas] so moving to 1.5 for example [ed] yes [kostas] this is built on top of ofelia. In practice it is difficult to move beyond 1.0 in practice. This is a way to get out of this to some extent at least for the kind of experimental networks that we are thinking about and working on in Europe. In the end, the whole point of an experimental facility is to be able to try different architectures on top of it. [ed] migration between management and control plane. How that will be addressed? [kostas] Out of the scope of the project but would be great to discuss [kostas] there is actual software that you can download and that works. Our Windows sysadmin installed it without any problem. o OF-DPA (OpenFlow Data Plane Abstraction) 20 minutes Joseph Tardo (the presenter is Shahram Davari) [yakov] those chips are actually not so futuristic. Probably the slides have been made 1.5 years ago. You can get them right now [shahram] which company [yakov] we can take it offline. [shahram] network processor, this is not network processor [yakov] no, not a network processor, an actual physical instantiation of flow tables. Several are available on the market and people in this room can tell you [uri] on the software switch how do you define slow versus fast, what is the metric? [shahram] CPU can make so many packet per second and hardware switch can do much more, let say 1000. Like 1/2 Tbps but with CPU a few Gbps [uri] we may have a discussion about that because if you measure performance per physical port I would not say thousand doesn’t sound right. [shahram] ok, just that hardware is several order of magnitude faster than software [yakov] do you do group table on hardware? [shahram] yes we do [shahram] that is what is not really done well right now [dave] how many people are aware of this table typing pattern (ttp) (?) work in the ONF? [dave] ok quite a few [andrew] by saying you can do L2 bridging and layer 3 routing you say you can program the hardware. You not really bridging nor routing you program existing hardware by removing what hardware make natively and add a glue layer [shahram] yes [andrew] so you are adding extra stuff on top of network to achieve what network does today [shahram] yes [dave] short in time, so only short questions [yakov] in the example you showed, you have several flow tables and each one had a single field. Is that a limitation or you can actually do multiple fields [shahram] of course multiple fields [yakov] and you don’t show action set/list [shahram] we can do both of course [jamar] this would have been more useful if you didn’t tight it to a specific protocol like OpenFlow. You provide the API and other people would have better ways to program this [jamar] I am sure there is overhead in the translation, do you have any number [jamar] what performance figures do you have for table updates for example? [shahram] I don’t know [jamar] your SDK [shahram] the SDK is fast, but the translation I don’t know [jamar] can download from github but I need a switch from you [shahram] yes [jamar] why not in the linux kernel, why do I need the SDK? [shahram] the SDK is to communicate with our chip [shahram] if it is a kernel driver I can communicate with the kernel [shahram] we have not considered it. It is easier with the SDK [andrew] you said software is slower than hardware. Yet you moved a lot of native hardware function to software so what is the benefit? [dave] that is the entier topic what is ttp. I try to map 1.3 and beyond to existing hardware [shahram] yes, it is mapping existing hardware. [dave] we need to cut it off here o NEMO Language (NEtwork MOdeling Language) 15 minutes draft-xia-sdnrg-nemo-language-00 draft-xia-sdnrg-service-description-language-00 Susan Hares [?] too far to hear, does not use mic [susan] it can work in conjunction very well because this has (?). This is looking at the abstraction layer we learned when we did (?) [… ] same area, not exact same piece [dave] does this language, NCL, does NCL has a formal description? [susan] yes, the formal description we are still playing with as we want to be sure the formal description and the code are in line. So it is not yet public, it is an early report. [susan] we hope to send to the list the formal description and where to download the code o Alpha fair traffic engineering using SDN 15 minutes Peter Ashwood-Smith [dave] why would f be convex? [peter] the is a book about that, I can’t cover that here. It is not obvious, but trust me they are. [yakov] this is nice. My problem is that it is only batch mode. In many cases, you are not allowed to preempt existing flows. You should find a way to do it online. [peter] the non splitting reason is that they are ILPs. I can’t talk about the work on ILP we are doing, it is proprietary. Yes, I am aware of that problem and there are lot of people working on that. [yakov] ok we can talk about that offline [luyuan] nice presentation, why does it has to be combined with segment routing? [peter] it doesn’t have to be combined, but I am a believer that combining the best things together is a good way to get the best network. The best graphics to show what is going on, the best computation, the best forwarding and I am very biased towards source routing. [luyuan] source routing has a lot of merit, we use it for years. The algorithm part is important. [peter] yes the two are not related [luyuan] if you do that if you want to tag, think about scalability, how many neighbours you can handle, from server to server,… up to many nodes [peter] absolutely. My point number two here (slide REMARKS) is indicating that if you want to get good optimisation you need to use all the cut, you have to use all the capacity across all the paths. That implies a large amount of state and anything that you can do to reduce that, wether it is distributed or centralised, will have benefits in terms of how the network performs. If there are other mechanisms to do that, that’s fine. Source routing, whatever way you do that is a good way to achieve that. Those optimisation algorithms do not work with loose routing mechanisms. I have to place the traffic on exact link, in the exact place in the network. With loose source routing mechanism, the math is no longer tight to what the network is doing. [luyuan] excellent point. If you want to tight to each node precisely that mean you might have a lot of segments. You say to reduce the state but there is a balance between no state (you would have to put everything on your packets). How do we reduce the FIB size but still make it. It is a balance, it is not one way or the other. [xiaoqing] to clarify. It is a joint optimisation between routing and flow grade allocation. [peter] the routing is an input of this problem [xiaoqing] ok, so it is about route allocation. [peter] yes, there is an interesting sub-problem here where you want to produce, what I call, a reasonable set of routes between sources and destinations. It is not every single possible route between source and destination but what you as a human would consider a reasonable route to be used and then the problem is how do you place the flows on those routes and how do you assign portion of these flows so that you optimise [xiaoqing] because you example really just shows on the flow grade [xiaoqing] is the decision of the routing part of the problem or input [peter] it is part of the problem, I did not covered it. It is a tricky problem. What do you do, produce the k-shortest paths? or? It is sort of an open question, what is a reasonable set. You want to have coverage over the entire cut through the network between that source and destination [xiaoqing] if you consider this as an SDN application, what would be the mechanism for having all the flows [xiaoqing] why do you have to do it in hardware, is it just for speeding up computation because software solvers for that exist since a long time. Problem formulation comes form 1998, right. [peter] why in hardware. you need a mechanism to deal with very high performance for vector operations. There is a lot of sharing of resources in between those vector operations. If you have a general purpose piece of hardware which can do massive vector processing and has efficient way to share informations between the operations then that general piece of hardware can do the job. I am not aware of any such piece of hardware but I don’t know all available options. An FPGA is perfectly capable of doing that, we looked at GPUs. We have a sub-project trying to do this with GPUs but we jumped to the FPGA after we ran into a lot of problems with the GPUs in terms of memory sharing. In terms of using multi-core processors, it is a non-starter here, too many issues with memory sharing between cores. If you know some hardware commonly available that can do this, I’d love to hear about that. Recently intel just announce they will combine FPGA and Xeon (?) core to use in datacenters, this application would be ideal for that. [peter] what was the first question? [xiaoqing] you come with a centralised decision. How do you enforce all the flow rates to all the applications [peter] the output of this algorithm is input to traffic policers and forwarding entities on devices are the sources of these metaflows. The forwarding entries would be programmed to take some portions so to add up to the proper percentage that is supposed to go on a particular path. There will be some error while doing that particularly if you have few IP flows matching the rule. If you go packet level you might have reordering problem. So there is a degree of precision between what you want and what you have, the the more you scale, the more precise you are [xiaoqing] offline discussion will be needed. o Cooperating Layered Architecture for SDN (CLAS) 15 minutes draft-contreras-sdnrg-layered-sdn-00 Luis Miguel Contreras Murillo (Carlos is presenting) [?] Is this research taken by telfonica I+D or other group. [Carlos] yes, my colleague is from telefonica I+D and Diego will join us as document co-author o Autonomics and SDN - Complementary Concepts 10 minutes Michael Behringer [yakov] I like the first few slides, they are almost what was yesterday in the NFV context. This distributed vs centralised is a compelling story. I would say that’s gonna be mixed, you can put functions where it is the more suitable. [yakov] SDN doesn’t really need to be centralised, the idea is only to remove some functionality out of the box. You could do that distributed. But the assumption you see most of the time in SDN networks is that you have some things distributed so you have reachability to the boxes, for example vanilla IP routing to get to the controller. Do you assume to have some legacy /non-SDN mechanism. [michael] yes you have IP but all I need for the autonomic infrastructure to come up is link local, our implementation is based on IPv6 link local. As long as you can do IPv6 you can have this and it makes an overlay network. Yes at the end of the day it is IP but it is not configured IP [yakov] I am working with a company that does sensor networks and hundreds/thousands of devices talking to each other, very non SDN but they have to bring the information back to the “real” world and there are several gateways where they can connect so that makes a combined SDN and ah-hoc distributed situation and there are interesting problems there. o Application-based Network Operations (ABNO) framework 15 minutes http://5g-ppp.eu/wp-content/uploads/2014/04/TOUCAN.pdf Daniel King [uma] do you have any prototype or implementation for this architecture ? [daniel] in a couple of slides