Hello, everyone. Welcome to our session about Open Daylight, OpenStack, and Kubernetes integration for high performance applications. My name is Nirik Chil. I'm a product manager with Red Hat, focusing on our OpenStack platform product, and specifically on networking. And here with me is François. Hello, nice to meet you. I'm François Le Marchand. I'm basically responsible for the NVI strategy in Ericsson, which means basically OpenStack and SDN. Yeah, the agenda for today. So François is going to briefly overview why SDN and some common use cases and requirements for infrastructure in modern days for SDN. And then I'm going to deep dive into the Open Daylight project. It'll describe the project itself, the community, and the NetVirt project, which is what we are using for integration between OpenStack and Open Daylight. And we also are going to do an overview of the Ericsson and Red Hat joint NFVI offering, and provide you with some links for further reading. And if you want to get the slides that are publicly available, you can check out the link here or just take a picture. It's on Slider. It's a PDF, you can download its PDF or just use it in your browser. With that, I'm going to hand over to François. Thank you. So yeah, so one of the reasons we are jointly presenting Ericsson and Red Hat is because we are basically providing like a joint product packaging for both OpenStack. Our OpenStack description is based on Red Hat. We are also integrating OSDN controller with a standard Red Hat OSP platform. But the most important, we are jointly working together on the upstream community in Open Daylight. And I think most of this presentation is really focused not so much on the product, but really on what we believe are the necessary properties and capabilities of an OSDN controller to provide a good solution for virtualization. And then on the second part, so it's a bit of recap of basically what we have upstream, what we are doing now with ODL in OpenStack, and then open up to new requirements, including containers and bare metal and how we see this integration with ODL. So picture of myself, that's basically the Tech Museum in San Jose. I guess many of you had a chance to go there or Santa Clara. I was very happy to see my very first router over there, Cisco AGS. It's being released in 1986. So it's about 30 year old now. And it was my very first day as an intern in the networking at university. I really got the task to take an old AGS plus, clean it up, it was full of dust, so I have to dismantle it on the parking lot. And basically upgrade it with the latest and greatest iOS release. At that time must have been like a Cisco iOS 8 or 9, something like that. Because you know what, the top most feature and the cutting edge feature that we needed at that time was GRE, GRE tunneling. And that's very funny because you know, if you look at where we are today, I mean what I was doing back then with GRE is basically we had a complex campus with a lot of universities and very complex networks. And then of course all the labos and so on, they are their own server and they had their own private IP addressing and they did not comply with the overall design rules. And they also wanted to manage their own security of their own VPN and so on. So the solution was pretty simple, build an overlay, build a GRE tunnel between to the multiple sites of the same tenant which is whatever labs in the university. And then tunnel the IP packets through that tunnel and then you create as many VPN and overlay as you want. That was 30 years ago, right? So what we are doing now in OpenStack and Cloud, well, not so different, right? We still have server, we still have application. The application runs on a VM. If there are VMF, you typically only have one application per server. So from that perspective, it's not that different. And then we get an IP tunnel which the new thing is like it could be Vixlan but don't worry, it could also be GRE. So we are not too much lost 30 years later. And why we do that? Well, same motivations, right? I mean, make sure that each of your tenant, each of your OpenStack instance can get its own secure private VPN that could work independent of the underlying infrastructure and independent of your data center fabric but independent of the one network that will connect this fabric or independent from the access layer as well. So same old solutions. However, not to say that nothing has changed, right? Because the networks has grown more and more complex. The requirement has gone more and more complex. This is a typical service provider network. I mean, it's not a service provider presentation because I think most of the thing we do for service provider and of course that's our focus market for Ericsson. That also applies fully to enterprise, right? And especially the large enterprise and as you grow your OpenStack deployment get more than one instance, get more than one data center location that you want to integrate more closely with your existing IP1 network. You will end up with very similar type of requirements. So typical service provider network, you have your access layer, enterprise, residential, mobile is missing but same one, then an access layer or core layer, some peering points where you connect to internet and some of the public cloud services and where they deploy data center. I mean, they of course had ITs and data center for a very long time for their IT applications. But the new thing with NFV is that they will add additional requirement in terms of performance, in terms of redundancy, in terms of the type of application, how do you onboard the application, right? On top of that OpenStack instance, there is specific requirement that is tied to the way those applications are designed in terms of redundancy, in terms of floating requirement. What we see as well is those centralized data center that are like focused on IT, some of the first wave of virtualization, of course, for the applications. But we also see pretty much all the operators have plans to create more distributed data centers for NFV. And the reason they will build those more distributed data center is something that we have done in the past for IP as well, maybe not 30 years ago but maybe 20 or so, which is like, if you want to have a lot of heavy traffic and have good performance, you need to move the content close to the user, right? So it's like caching on the internet, but you want to do it ultimately at the central office where you know your connection, your fiber lane, your DSL lane, your CMTS cable connection lens, right? And you want to inject the traffic right there because then you're saving a lot of capacity. You don't have to carry that traffic from the purring point across your own network. You also get much better latency, which is quite important for new applications such as augmented reality, virtual reality, where we start to see cloud rendering being possible with fiber, with 5G that are getting extreme low delays. That becomes a possibility to do cloud-based rendering of those applications, but it means you need the extra low latency like less than one millisecond run trip, right? Between the end user and the application. So some of those applications are getting distributed and of course is all kind of shade of grain between, right? You know, you have this very centralized data center. Some of the distributed data center could be like 10 or 20 sites, maybe it's up to thousands. That's in the plan of some operators, that extreme distribution and very complex topology occurs. So what about SDN? Why we believe SDN is important? Well, you need to interconnect the centralized and the distributed data center because you have set of NFV that needs to work together. I mean, some could be the control plane or management plane, some the data plane of the same VNF that has to be distributed across the data center. You have requirement to connect your physical access. You know, when if you're running NFV, it means you're getting the traffic still from a physical base station, a physical GPON node that connects your fiber lanes. And you need to get that traffic from your physical network into the virtualized layer. And for that, you also need this kind of first arrow, right? NFV connectivity. You might host application for the enterprise customers. So you will need them to provide them, you know, like guaranteed access for mission critical applications. So connect the enterprise to those more centralized data center where you have more scale. And then of course, you also, you know, want to interact with public cloud in a hybrid type of setup for the operator on application, but of course for the enterprises, right? Which could benefit from, let's say, locally hosted content by the operators, but also do that in an hybrid mode with public cloud together. So more complex type of network setup, a lot of those arrows, each of those arrow has basically its own set of, you know, requirements, you know, like if you go to hybrid cloud, you will need these to be encrypted. If that's NFV connectivity, you will need, you know, one single IP address to handle maybe 100 gig or 200 gig worth of traffic going to a single IP address. So each of those line has its own set of challenges, right? Converge and secure access and so on, and when you also have to deal with how you apply QS in the core network, and not just simple deep-serve QS, if you really want to get like a very mission-critical application, you need to guarantee SLA, to guarantee minimum bandwidth, to compute the path of each and every application into the network link by link, and those type of traffic engineering application is also something that has been done in the IP network for a long time, but not the challenge is how do we integrate that with cloud, right? And that's where we are going. So what does it mean? It means you need a new platform to build cloud connectivity, and that platform, SDN as you know, needs to have all those characteristics, right? I mean, I think we really believe in the openness, not only open protocol, right? Which is the likes of SDN, but also open source, community-driven open source. We are big believer both for that and ourselves, obviously, and many more, right? Collaborative development is very important. API model, just make sure that we define well the APIs that are intent-driven and so on, because we need to create the right level of abstraction at the same time, you know, make sure that we don't hide any capabilities, right? That could be helpful for the extreme layer, and then evolution to DevOps, which is still a bit far away from the operators because, you know, that's kind of complex. I guess also complex for the large enterprise system and many legacy applications, but this is really a key number, not only, you know, virtualization cloud, but also SDN. So the challenge is, you know, if you look at the original set of APIs we got from OpenStack, the Neutron API, they were pretty basic, right? I mean, you can do a bit of bridging, a bit of routing, and that's pretty much it, right? ML2, ML3, and you're done, right? Then, of course, you have much more advanced API when it comes to value-added services, load balancing, firewalling, and so on, but still, you know, from routing or simple connectivity standpoint, they are very simple. I think one of the challenge of SDN is not only to have a platform that fulfill all those characteristics, but it's also that to enhance, you know, release after release, the set of capabilities we provide to the virtualized layer from very basic connectivity functions to more modern IP routing capabilities, right? And if you look at those modern IP routing capabilities, you have things like inter-domain, hierarchical construct in order to scale, all kind of topology constraints for your services, point to point, point to multi-point, multi-point to multi-point, being able to be policy-driven in terms of, you know, routing behavior for redundancy and optimization. Traffic engineering, I mentioned before, make sure you can actually have a very advanced way of mapping the packets to a specific path in your network. Fast-rewrote for, you know, redundancy, very important in a V-domain. There is still those, you know, magical 50-millis gone redundancy requirements for many applications. And also new technologies such as segment routing that provide a lot of flexibility. So all those things, they are not, you know, integrated as of today, right? Or not in a proper way into open stack and the virtualization solution. So one of the things we believe is that it's very important that you build an SDN platform with very strong routing capabilities at its core, because over time, those things are coming down our way, right? As we want to make things more, you know, higher-grade or enterprise-grade, as we want to make things more deterministic, as networks' complexity will continue to increase by doing all kind of hybrid connectivity and distributed models, we will need all those tools to make sure that we satisfy the requirements. So practical example, you know, use case of routing. I mean, some of the things that you can do is routing in a more efficient way. Inside the data center, so intra data center, inside the same SDN domain, one thing is interworking well with your data center gateway, whatever like edge router you have.  To load share the traffic across your first-stage load balancer. And in order to do that, you need to use routing, so you speak the same language than the DC gateway, and you make sure this happens and this happens with the right, you know, like hashing of the flows and with the right level of redundancy and so on. Another thing that is typically done on the MPS network is that you can attach some kind of group ID, right? I mean, you can play with an MPLS VPN. It's not only that you set a blue VPN or a red VPN, but, you know, one endpoint can belong to more than one VPN at a given time. So you can create interesting application like intranet or extranet, where you can see, you know, a red VM and the blue VM don't see each other, but they both see the purple VM that belongs to the both network at the same time. You can do things at a much more granular level. When we talk micro-segmentation, very often you assume some kind of distributed firewall and so on to make filtering, but you can even do better than that. You can not even do filtering. You can just make sure that you only leak the routes that you need, you know, depending on the VM, and the connectivity is not relative to the definition of a subnet. It's not because you belong to the same subnet that you see each other. You can create all kinds of constraints around the routing space. There is even more, of course, interest when you go inter-DC, right, when you want to connect the different instance of your cloud, the different locations. It's also quite important, I don't have it on the slide, but it's not necessarily different locations. I mean, what we see more and more is people running different instance of OpenStack because they may have different projects that have selected different stack or because even if you use the same stack, you will have different versions and you cannot validate all your application at the same time and migrate them overnight, you know, to the new version. So you end up having, even in one data center, many instance of OpenStack, right? And sometimes, you know, one solution, one VNF, will be spread across multiple of those instance and you want to have this automated connectivity. And one of the things that you can use routing very well is to, you know, extend this VPN so that you can have a neutron subnet that is extended over more than one VM, more than one OpenStack instance, more than one location. That's something you can do. And by the way, you can even do it between different vendor of SDN. So of course, you know, we invest in OpenDelight and that's our controller of choice. But you know, like every time, you not always have only one single solution, right? And it's very important that depending on the, first you don't necessarily only have OpenStack, we talk about Kubernetes, but there is also VMware deployment, there is also many different type of beams right now that still exist. And it's very important that we make sure we have a solution that is also open. And when you extend, when you do inter-DC connectivity when you set up a DCI, it's not necessarily OpenStack specific or it's definitely not specific to one specific SDN controller version. And that's one of the beauty of routing that's standardized, right? Through IETF and so on. If you use the proper routing protocol East-West, you can make sure you get this interoperability between different VMs, between different SDN. The other nice property is like its scales. So, you know, we all start small with OpenStack but eventually we go big and some are already big and are getting very big. And at some point, if you want this to scale to the scale of the internet, right? You can use the same recipes where basically if you leverage BGP, you have a set of tools, I mean, nothing extraordinary from a technical standpoint but it's very proven that you can build very scalable networks. You have all the tools in terms of security, which transmission and so on to make it scale. So one example is route reflector that you can build in a hierarchical way so that you can end up, you know, with billions of endpoint and make it scale. Inter-IS, making sure you can connect different autonomous system for scaling but also to apply set of policies that you want to secure your network. And most important, maybe, or finally, is also you can always do that with any SDN technology or baseline neutron, right? You can do baseline neutron and then you will go to a DC gateway and then you will manually cross-connect, you know, whatever VLAN to a VPN instance and you can do the same thing, right? But then, of course, it's a bit autonomic with cloud because every time you will want to dynamically create new VNF, new tenant and so on, you will have to change your DC gateway configuration. A proper SDN solution needs to make sure that this connectivity, this teaching to the underlay network needs to be fully transparent, fully automated and fully dynamic, right? And right now, you know, this is the only solution is to do routing. Why is it the only solution? Because you can make it fully dynamic but it means that it's SDN controller to SDN controller, you set up overlay tunnels. You can make it fully dynamics but then it means you are not be able to map to, you know, the one network in a proper way in terms of SLA and QS and so on because you're building an overlay network and the one network is not aware of your VPN. So that would be a problem if you do that this way. It will also be proprietary and you won't be able to inter-work properly between different domains and then if you decide that you do it on the DC gateway, then you get back those two properties but then it means you have to do some very complex orchestration to make it automatic and so on. So the right choice is to actually make it use a native routing stack on the SDN layer because that avoid any kind of static configuration on the gateway and makes things very fluid. So makes things seamless between the data center between different data center instance and the one. Other things, service chaining. Why is it important? It's important for operators but what they need is not basic service chaining where you will say, okay, for one tenant I want the traffic to go to firewall and then parental control and be done with it. They want to avoid policy driven. They want this policy driven. They want to have this based on their policy server that is aware of the one network of the subscriber of the type of radio access technology. So this could be very dynamic how you want to set up the service chain. So you have very advanced classification that is required per subscriber or per destination or per application. So classification is quite important and you want to do it at scale again. The same way that we started with centralized routing and DVR, then we started with centralized firewall and distributed firewall. Same thing for service chaining. You need to have distributed classification in the underlay. Load balancing, symmetric forwarding, redundancy functions. All those things are essential and they're quite advanced feature that you have on top of it. Routing again. If you look at service chaining but you want to do it across the network then you will have different data center, different segments. And one of the things where you need to have a tight integration with routing again is you can do service chaining using the technology you want inside each of the data center segment inside each of the SDN domain. You can use NSH, you can use BGP, you can use whatever you want. But then the best practice if you want to do this service chaining again end to end between your physical routers between different data center instance connected back to the internet is then to stitch whatever technology you use for service chaining, stitch it at the ingress and the ingress with routing. That's also quite important because you have things like geo-reundancy and so on. You can monitor a service chain. If one of the nodes is dead you can of course protect it different way bypassing service function, load balancing across service function. But if you want to have geo-reundancy you can say maybe a data center is dead and I just want to bypass it. What I will do, I will just remove the route advertisement. I will change the route metrics and automatically I will have my network that will redirect the traffic to the right data center instance. So combining those type of functionalities again is very important to get routing capabilities. Last use case, that's one so the other one they were explained in the context of service provider but they are completely applicable to enterprise. This one a little bit less but even though we start to see that virtual CP type of use case is also something that could appeal the enterprise when they can build it by themselves more like an overlay fashion such as SD1. And one of the thing that you may want to leverage your SDN solution for is basically interconnect seamlessly your existing physical MPL SVPN, the traditional ones where you can add additional functionalities and services that are virtualized. So you don't have to upgrade your router, you can still use your traditional Cisco router, physical box and so on. You're existing MPL SVPN but you can connect it in a smart way to a data center where you will deliver all the new and advanced security services for instance in the cloud model. You have another model that is more applicable to operators likely where you get a very dumb CP, a very thin CP, very cost efficient like 30 dollar type of bill of cost of hardware but then it means you will emulate all those functions into the data center and you will use different type of connectivity instead of layers 3 VPN you will probably use you know VXLAN, EVPN type of connectivity more like layer 2 tunneling from the CP that is very basic just doing bridging and the data center. And then emulate all the function more essentially. And then finally, SD1 is probably the one that is the most flexible where you can virtualize both on premises on the CP itself and virtualize in the cloud. And doing this it allows a lot of interesting properties such as local turnaround of the traffic so you can have CP to CP and local breakout which means you're not dependent of a local cloud but you can still combine with a centralized cloud for some of the more advanced services. So you know connecting your sites together through the cloud or connecting the site to the cloud that's also you know one interesting properties of the SDN controller. So all of those things are basically things that we have implemented in Open Delight today that are available for consumption in a shipable product. And also the title of the presentation was about high performance which is critical again for enterprise but if you think at sorry for service provider but if you think at enterprise they also have data plane intensive type of requirement they also use you know security firewall functionalities maybe at some point you might want to virtualize some of your storage solution and so on. In that case if you don't try it on a flat network you will need also to get high performance. And what we can do we can drive you know with ODL a very flexible way black box router, OVS, SmartNIC or solutions such as fd.io that are new data plane options that are introduced. All those options they all come with different southbound protocol different functionalities and the interesting properties of Open Delight and the reason why we invested in Open Delight is because it's very modular. So you can build plugins for different type of services you can model different type of services you can configure black box, white box open flow centric type of SDN nodes and you can also adapt to different type of data plane. So those are just examples of what you can do and using this set of data plane you can get very high performance virtual data plane very high performance physical data plane with acceleration. So coming to you know what's next. Checking on the time maybe I'm already a bit over time but so what's next? Yes of course we have virtualization but we still have bare metal and bare metal is quite important. Why is it? Of course you have a lot of legacy you know legacy appliances that you're not going to throw away and that you want to make it work. You also have the new legacy which is virtual network function that you deploy but in order to get good performance or because you didn't have time to you know integrate in a proper way and so on use SRIOV and SRIOV is not always a good thing it depends on the profile or I would say the use case SRIOV could be good in a way that you're independent from the forwarding layer and the NFVI layer you just bypass it and go straight to the hardware which give you best performance but that also makes it a bad thing because if you want to use NFVI as a clean abstraction between your VNF between your applications and the infrastructure you don't want to create any dependencies between your NIC card between the way your data center gateway is configured between what your data center fabric is made of can you do layer 2, layer 3 what kind of VLAN tagging and so on you want to abstract that right and from that aspect this is very bad. So you have to deal with those SRIOV network function regardless right I mean there are reality and many of the initial wave of virtualization happen with SRIOV so that's something you need to integrate and they are viewed from the NFVI layer they are viewed like a bare metal server more or less because they go straight to the hardware but also it's a lot of extreme performance that are not going to go away right I mean you might see less SRIOV moving forward as we get you know probably new and better way of connecting the VM with high performance you get rid of your legacy appliances but there is always you know set of functionalities especially for the kairos that you cannot virtualize or you cannot virtualize efficiently right and typically the access nodes when you have specific physical interface radio interface, GPON and so on specific accelerations that doesn't fit very well with generic purpose CPU yet right and eventually at some point we might get there but we might get there on different architecture than XLE6 and up to now we also have to make provision for that so bare metal is there to stay for the legacy reason but also for the some of the high performance type of requirements virtual machine it's still the mainstream approach because it's easy to virtualize you know any kind of legacy applications but also it's actually pretty good in terms of data plane performance if you look at container it's more lightweight from a memory footprint but typically if you have only one you know one VNF is more like a single VNF running on multiple servers which means you only have one VM per server so you know the memory footprint it does not really you know make any difference and since those applications are designed in a cluster mode the boot up time doesn't make any difference either right so those are things that you know VM are there to stay as well for quite some time and then finally of course containers are playing a bigger and bigger role in already in the public cloud mostly applications is getting there in the enterprise a lot of traction in the service provider market there is also application that actually benefit already today from containers I mean application that are not multitenant natively so you release container for that and that's where you get the best fit so you have all three and all three will coexist for quite some time so if you look at your data center now you have the hardware layer typically you know a bunch of switches with a more or less as the end driven fabric I think most of the you know hardware vendor are coming with one way to make this fabric dynamic that it can auto discover itself auto configure itself it has its own tools in terms of analytics and management and so on we just talked for a long time about this open stack layer and virtualization and then now you get container orchestration solutions such as Kubernetes and a couple of others and each of those solutions they come with their own networking solution so now what you end up with is a number of networking solution in the open stack many different SDN controller more or less open you get new things like oven, dragon flow and so on so even new initiative that are doing more or less like an SDN approach and now with containers you get things like Calico and Flannel and yet you know another set of services so it's a good thing diversity and creativity is a good thing but of course you know it creates some practical issues for customers because when you want to run an application that mix and match bare metal VMs and containers because some of the application are pretty complex you have the management, you have the data plan you have the security layer and so on and all of this is one application that is many VM, many containerized application from an end user perspective you get performance impact running layers of tunneling over layers of tunelings you can also maybe you can accelerate I was mentioning before SmartNIC you can accelerate your NFVI you can accelerate your open stack networking but then if you run another overlay software overlay on top of it then you lose this benefit of acceleration you will break things like TCP offload and so on so you need to make sure that you get your best performance a nice and easy way of provisioning the network and visualizing the network and avoid this kind of flu service integration also from the administrative standpoint correlation, trouble shooting is quite important in turn working connectivity burden that's when you have to manually connect each of those layers together pull off IP address and what you use on DC gateway what you use on the container layer create your open stack network and then you have to learn and multiple connectivity solution multiple SDN layers so what is a potential solution to that? I mean we see two solutions and again we believe OpenDelight is a great platform because of the flexibility of the platform that you can basically choose simplest way one single SDN controller that will serve at the same time different layers that will configure your underlay and overlay and manage your physical switches and routers that will provide virtualization to your open stack layer and that will provide connectivity to your container and Kubernetes layer another approach would be to say as many open stack instance or as many SDN instance as you have layers but then it means if you need to do that then when you provision a service at the different layers you need to provision the service with the same model at the different layers and it does layer to talk to each other so you don't have this manual operations happening so in order to do that we also believe that OpenDelight is the right approach because then you can normalize the API and it's all young driven so and it's also compatible with now we have a CNI plugin I'm coming to that natively to Kubernetes we have of course a neutron implementation we are pluggable into new things that are coming in open stack such as gluon and other options so the idea is to keep the northbound API very open but to have ultimately the same way to represent the connectivity between the different layers between the physical layer, virtualized layer and containers to have the same way to express network connectivity, security and so on so that will take a longer time because in order to do service training using routing and so on if you use that as an east-west protocol it takes a longer time what is probably going to happen is some kind of hybrid between those you will get a single controller that can do underlay and overlay that can do overlay and containers but maybe multiple instance of those and those instance will collaborate again through those east-west protocols so how do we do that? two options again if you look at containers I mean one is Magnum which is basically Magnum plus Courier you basically run your container instance but you use the neutron layer in order to integrate with the with the same networking solution than the VMs and that's probably the simple and most efficient solution if you run open stack and you also want to run container solutions together you will be able to use the same backend and that's more or less transparent so that is a very practical option that we have however the impact of doing that is also in terms of performance when you talk about containers and depending on the application if you're really into one of those applications you need to fire up tens of thousands of containers per second in a very intensive way using a neutron backend maybe today is not optimized for that there might be other container-specific functionalities all the layer 4 load balancing and so on that are integrated to Courier you know using LBAS plug-in on the backend but there might be new and more advanced capabilities you may want to do natively on the container layer so the other option and both are compatible more or less is to get this native CNI plug-in for OpenDelight and we started an upstream project in ODL that is focusing on providing that CNI plug-in capability and as you see this plug-in capability is also has to work with the data plane that will have to satisfy two things first is that containers you want to use the NFVI rules to do service chaining, VPN, load balancing, analytics, whatever but you want this layer also to be able to support any of the native kernel services kernel networking services such as IP tables for security and so on that the container might request and you need to make both at the same time and if you use an OVS DPDK then you're bypassing the kernel and you're not applying everything so there is a bit of complexity where we need to integrate really this kernel layer services together with DPDK there is also if you want to run your VNF over containers and if it's a data plane VNF then you need DPDK or it's one of the challenges also to integrate DPDK so this is coming there is some of the early version of DPDK support for containers that's some of the challenges that we are solving right now in the data plane perspective but the great news is that once you do that with for instance OVS or some of the mainstream data plane then you can integrate it in a seamless way between your open stack and virtualized domain and the container side Bermet Hall that's another challenge and when I say Bermet Hall there is a way to integrate appliance storage and so on in the same overlay than your virtual service while you want to do storage on the same overlay for instance if you want to distribute some of the storage capabilities that a remote VNF can access some of your storage that is more centrally located you want to have this goes through a VPN and so on will simplify a lot of things having the same analytics tools from a network behavior having the same course tools and so on we are talking about course before I'm talking course at the networking layer make sure you you tag the packet with the right DSCV and so on and make put it into the right queue right so there is interest in you know making those work in the same overlay and it means basically the end controller can program rules into the overlay switch but if you get a SRIOV or Bermet Hall appliance you have to configure the top of the rack switch and that's why it becomes more complex because you have some top of the rack switch you can program with OpenFlow some with OVSDB some are more like IP rotors you can only talk NetCon for EVPN or those type of rotting protocols to them so this is where again the modularity of OpenDelight is helping a lot because we can adapt to different type of switching fabric and we can make sure we program the Tor switch to connect the appliances to the overlay but we can also bring up the DC fabric right and that's the natural evolution of ODL is now moving forward to use it also as the automation for the fabric and that has a lot of benefit also to synchronize the different layers and give you like a complete and synchronized view of the overlay and underlay you know correlation of what happens on the overlay where the traffic between 2VM is mapped on which link and do like all the analytics and so on on top of it okay so that was the last slide on the you know the new things coming and then leaving now to Nier to come to the actual project thank you thanks François okay so I'm well aware of the fact that I'm standing here between you and lunch so I'll do it quickly so OpenDelight in in a nutshell it's basically this cool SDN platform that you can build it's highly modular, extensible and we think is the key benefit of OpenDelight because as you just saw we are talking about very complex use cases and nobody here knows really what's the next thing here what's the next protocol is and so on and we want this to be really a kind of generic platform that can adjust as you go and this is very like a typical picture of the architecture we're talking about kind of the controller platform in the middle and then it's really pluggable again both on the southbound side so different protocols and interfaces you can talk to the virtual switches physical fabric and so on but also on the northbound side so you can talk to different orchestration agents like OpenStack, Kubernetes and so on and the beauty of OpenDelight is like on the core there's this service and plugins there's the runtime, the model driven API the data store which are really common as a base platform and then basically you can write different type of applications on top of that and we can cover diverse use cases for edge services, for IP routing for optical transport, for physical fabric management for overlay management and so on and this is really the benefit of ODL in terms of OpenStack integration we are primarily talking about one project in ODL called NetVirt which is basically the technology we are using to integrate between OpenStack and OpenDelight via Neutron some key fundamental facts about this integration is that Neutron is still where you define the networking API so we are not replacing Neutron Neutron is still the de facto API on the infrastructure but we are just implementing Neutron API as a backend with OpenDelight which is really important going forward because we want to standardize on Neutron as an API and basically not replace it and here Red Hat and Herrickson one thing I wanted to highlight is something we did in the last upstream release for on in OpenDelight which is basically integrate the NetVirt project with another project called VPN service which was a different one and this really shows the convergence in the upstream community around NetVirt as kind of the major way of integrating OpenStack and OpenDelight which is again really important because we bring all these use cases all this know-how from Herrickson and others in the community into the NetVirt project and getting NetVirt more feature rich and robust so NetVirt is basically an application developed on top of OpenDelight we have pretty powerful implementation for L2, L3, AccessList, Net, DHCP, IPv6 and so on and the idea is to configure and manage the overlay network so basically everything that Neutron provides today but also top of REC switches currently using the L2 gateway extension using OVSTB and obviously Tenant Networks for OpenStack it uses NetCon Fenyang to model the topology that's a key kind of architecture piece of ODL but it's really modular and extensible so currently we're using OpenFlow and OVSTB in NetVirt but we are looking into stuff like NetCon, PGP and other southbound interfaces to manage new southbound pieces as well so Francois mentioned the CNI plugin for Kubernetes we're also working on VPP which is part of the FDIO integration so this shows how powerful the platform is because we don't need to reinvent everything add new agent, new stuff we can just reuse the platform add more plugins and integrate into new systems and technologies just really quick about Red Hat and Herrickson so basically what we are doing is we are providing together again Red Hat and Herrickson we're providing a converged LFEI infrastructure we are working on different tracks under VI, SDN, subterfine infrastructure and containers and basically aligning what we are doing in terms of upstream initiatives and product maybe Francois you can just quickly describe how you are certifying the platform yeah just very quickly on this slide you see what I describe our joint solution with the open daylight based controller but we are also selling it and I think that's one of the way we are bringing the technology to the market as a certified solution which is a turnkey solution that you can use with all Herrickson and Red Hat component pre-certified including Herrickson, VNF that also could be consumed in a modular way so you can pick and choose best of red and it's all obviously open and all based on the open source upstream type of model yeah and last but not least for further reading you can check out the link here about the network project and some product documentation and we are running out of time take pictures sorry we're running out of time but maybe we can take like two questions there are two mics here and I have this one as well questions or comments, feedback what did we forget thank you very much okay, thank you very much bye


from our studios in the heart of Silicon Valley, Palo Alto, California. This is a CUBE Conversation. Hello and welcome to CUBE Conversations. I'm James Kobielus, lead analyst at Wikibon. Today we've got an excellent guest and who's a CUBE alumnus par excellence. It's Yaron Javiv, who is the founder and CTO of Iguazio. Hello Yaron, welcome in. I think you're coming in from Tel Aviv if I'm not mistaken. Right, pretty close to Tel Aviv. Thanks, German. Nice seeing you again. Yeah, nice to see you again. So I'm here in our Palo Alto studios and so I'm always excited when I can hear Yaron and meet with Yaron because he always has something interesting and new to share about what they're doing in the areas of cloud and serverless and real time streaming analytics. And now data science. I wasn't aware of how deeply they're involved in the whole data science pipeline. So Yaron, this is great to have you. So my first question really is, can you sketch out what are the emerging marketplace requirements that you at Iguazio are seeing in the convergence of all these spaces, especially real time streaming analytics, edge computing, serverless and data science and AI. Can you give us a sort of a broad perspective and outlook on the convergence and really the new opportunities or possibilities that the convergence of those technologies enable for enterprises that are making deep investments? Yeah, so I think we've sort of anticipated what's happening now. We just called it different names and we'll probably get into this discussion in a minute. I think what you see is that traditional analytics and even data scientists, science was starting at sort of a research labs, people exploring cancer, exploring impact of weather on people's mood, et cetera. And now people are trying to make real ROI from AI and data science. So they have to plug it within business applications. Okay, so it's not just a data scientist sitting in a silo with a bunch of logs that he got from his friends, the data engineer, and he scans them and generates some namesets and runs to the boss and says, you know what, we could have made some money a year ago if we've done something. So that doesn't make a lot of impact on the business. Where the impact on the business is happening is when you actually integrate AI in chatbots, in recommendation engines, in doing predictive analytics on analyzing failures and saving those failures on saving people's life. And those kind of use cases, those are the ones that require a tighter integration between the application, the data, and the algorithms that come from the AI. And that's where we started to think about our platform. We worked on the real time data, which is where when you're going into more production environment of not data lakes, you need very good, very fast integration with data. And we had this sort of fast computation layer, which was day one microservices. And now everyone talks about microservices. We certainly started with this area. And that is allowing people to build those intelligent applications that are integrated into the business applications. And the biggest challenges I see today for organizations is moving from this process of doing some research on data, historical data, and translating that into a business application or into impact on business application. This is where people can spend the year. I've seen a tweet saying, we've built a machine learning model in like few weeks and now we've waited 11 months for the productization of that artifact. Yes, that's what we're seeing at Wikibon, which is that AI is the heart of modern applications in business and the new generation of application developers in many ways are data scientists or have, you know, leverage the skills and tools for data science. Now looking at Iguazio's portfolio, you evolve so rapidly and to address a broader range of use cases.  Now I see that you're a bit of a data science workbench or pipeline tooling platform. Can you connect these dots your own and explain what is Iguazio's portfolio? I think they're all nice marketing for the same technology that we've built. Okay, just over the years, you know, people have four years when we started so we had to call it something else. People at that time thought that analytics sort of incorporates data science and when we said continuous analytics, we meant essentially fitting data in, running some of them, spitting some results. This was sort of opposed to the trend of Hadoop, which was a data lake.  So continuous analytics was sort of a term that we've came up with, maybe not the best, you know, described that you're essentially taking data in from different sources, crunching it through algorithms and generating triggers and actions or response to user requests, okay? And that was sort of a pretty unique and sort of pioneering this industry, even before they called it streaming or in a real time data science or whatever. And now if you look at our architecture, our architecture, as I explained before, is comprised of three components. The first one is a real time, multi-model database, you know, about it pretty exceptional in its performance and its other capabilities. The second thing is a microservice engine that allows us to essentially inject applications of various skies. Initially we started with application that essentially do analytics, grouping, joining, correlating, and then we started just adding more functions into other things like inferencing, image recognition, sentiment analysis, et cetera. Because we have this function engine, it allows us a lot of flexibility and find a really fast parallel engine on a really fast data can generate remarkable results. And then the industry started calling this microservice thing a serverless. We sort of even were ahead of the game of this serverless game. The third element of our platform is essentially having a fully managed pass, a platform where all those microservices and data managed through a self-service interface sort of think about it as a mini cloud. And you know, we've recently in the last two years we've shifted to working with coronaries versus using our own proprietary microservices orchestration originally. So we've went into all those three major technologies. Now those fit into different application. One of the very interesting application if you think about edge, in the edge you need to serve a mini cloud. You need a variety of data sources and databases with columnar rows, streaming, files, et cetera. We'll support all of them on our integrated platform. And then you need those microservices that could be developed in the cloud and then just sort of shift into the enforcement point in the edge. And you need some orchestration there because you want to do software upgrades you need to protect security. So having all the integrated stack created an opportunity for us to work with providers of edge. And you may have noticed our joint announcement with Google around solution for edge, around retailers and N IoT. We've made some announcement with Microsoft in the past. We're going to do some very interesting announcement very soon. We've made some joint announcements with Samsung and NVIDIA all around. Those errands we continue. It's not that we're limited to edge just that what happens because we have extremely high density data platform. Very power efficient, very well integrated. This has a great fit in the edge. But it's also the same platform that we sell in the cloud as a service or we sell to on-prem customers. So they can run the same things. In the cloud it sort of happens to be the fastest most real-time platform. And in the edge it's sort of an essential feature that you cannot just ignore. So you're wrong. Yeah, Iguazio is a complete cloud native development and runtime platform. Now serverless in many ways seems to be the core of your capability in your platform. Nucleo, which is your technology. You've open sourced it. It's built for prem-based private clouds. But also it has is extensible to be usable in broader hybrid cloud scenarios. Now give us a sense for how Nucleo and serverless functions become valuable or useful for data science or for executing services or functions of the data science pipeline. Can you connect the dots of Nucleo and data science and AI from the development standpoint? Sure, sure. So I think the two pillars that we have as technology the most important ones are the data. We have about I think like 12 patents on our data engine which is a very high performance and Nucleo functions. And also they're very well integrated because usually serverless is stateless. So you end up, if you want to run data, you have some challenges with serverless. With Nucleo you can actually do stateful use cases. You can mount files. You have real-time connections to data. So that makes it a lot more interesting than just Lambda functions. The other thing with Nucleo is that it's extremely high performance. It has about 200 times faster than Lambda. So that means that you can actually go and build things like a stream processing engine. If you joins in real-time of very private database activities, you can just go and do collectors, we call them. Those things go fetch information from weather services, from routers for doing cybersecurity analyses, from all sorts of sensors. So those functions are becoming like those nanobots in the analogy of those movies is that you just send them over to go and do things for you whether it's the data collection and crunching, whether it's the inferencing engines, those things that, for example, get a picture, compare it with the model, decide what's in the picture. And this is where Nucleo really comes into play. The interesting point, you see now an emergence of a serverless pattern in data science. So there are many companies that do like model inferencing as a service. Essentially what they do, they launch an endpoint, a URL endpoint that runs the model inside. You send a vector of numeric values and you get back in numeric values and they conversion that. It's not really different than serverless. It's just way more limited because I don't just want to send a vector of numbers because usually I need to send real data like a geolocation of my cell phone with some user ID and I need this function to cross-correlated with other information about myself with the geolocation and then give me commendation of which product I need to buy. And then those functions also have all sorts of dependencies on different packages, different software, environment variables, build instructions. All those, this is really where serverless technologies are much more suitable. Now, it's interesting that if you'll go to Amazon, they have a product called SageMaker, I'm sure you're familiar with that, which is their data science platform. Now, SageMaker, although you would say that's ideal use case for Amazon Lambda functions, they actually don't use Amazon Lambda functions in SageMaker. And you would ask yourself, why aren't they using Lambda functions in SageMaker?  Okay, because Lambda is not capable of storing large content and machine learning models could be hundreds of megabytes in core. Lambda is extremely slow, so you cannot do high concurrency inferencing with Lambda functions. So they essentially had to create another serverless and call it with a different name, although if they just would have approved Lambda, maybe it was more Swiss Armenian. So with nuclear, we've taken the other approach. We don't have the multiple resources that Amazon have. So we created one serverless engine, one serverless engine that does batch processing, stream processing, can store lots of data, even run continuous services. So all the different computation pattern with a single engine. And then sort of you've started seeing all this trend in data science about, yeah, we need to version our code, we need to, you know, record all our package dependencies and all those things, yes, serverless doesn't. So we just had to go and type more into the existing frameworks. And you've looked at our project, we have a project called Nuclear Jupiter, which is essentially a data scientist can write some code in his data science notebook, and then he clicks one command called nuclear deploy. It automatically compiles his data science artifacts and notebooks, et cetera, and converts it into a real time function that can listen not only on HTTP then, it can listen on streams. It can be scheduled on various timing. It could do batch. So many other things. And the interesting point is that if you think about data scientists, they're not the best programmers because they should be the best scientists. And this is, that means that they actually have a bigger barrier to writing code. So if you serverless framework, that also automates the logging, the auto scaling, the security, the provisioning of data, the versioning of everything, and package dependencies, if they just need to focus on writing algorithms, it's actually a bigger back for the buck.  So the value in their eyes is smaller than the value in the eyes of data scientists. So that's why we're actually seeing this appeal that those people that essentially focus in life is writing math and algorithms and all sorts of those sophisticated things that they don't wanna deal with coding and maintenance and operations. And by also doing so, by operationalizing their code through serverless, you can cut back to market, you can address scalability, you avoid rewriting of code. All those big challenges that organizations are facing. You're right, I have to ask, you know, that's great. You have the tools to build, to help customers build serverless functions for AI and so forth inside of Jupyter notebooks. And you mentioned SageMaker, which is an AWS solution and which is up and coming in terms of supporting a full data science tool chain, for pipeline development among teams. Do you have high profile partnerships with Microsoft and Google and so forth? Do you incorporate or integrate or support either of these cloud providers own data science workbench offerings or third party offerings from there's dozens of others in this space. So what are you doing in terms of partnerships in that area? Yeah, obviously we don't want to lock us out from any of those. And you know, if someone already has his workbench then I don't want my customer to say, yeah, you're locking me into your own workbench. In our workbench, the things are really cool because like our Jupyter is connected for real-time connections to the database. And it has sort of other cool features that essentially you're getting like a huge speed boost. We have, we've done some tricks that we've announced with NVIDIA, around feeds and integration with GPUs, like creating a pool of GPUs from each of one of the data scientists running on a platform can essentially launch jobs on this pool of CPUs of owning the GPUs, which are extremely expensive as you know, but what we've done is because of all of our technology beside the actual database engine is open source we can essentially just go and install packages and we've demonstrated that to Google and major and the others.  And I make it very close to what we provide in our managed platform, not with the same performance levels, but functionality-wise the same functionality. So how can you name some reference customers that are using Iguazio inside of high performance data science workflows? Is a, are you, or are you just testing the waters in that market for your technology? Your technology is already fairly mature. So as I told you before, although we, you know we sort of change messaging along the lines we always did the same thing. So when we, we do continuous analytics and we've spoken like a year and two ago about some of the use cases that we run like, you know, telco operators are running real time, you know, health predictive, health monitoring of their networks and auto healing networks and those kind of things. They all use algorithms to control those, those applications we work with right-dailing customers so we can feed a lot of data, generate real-time maps and do fraud detection and other applications on all those things. So we've noticed that all of the use cases that we're working with involve data science. In some cases, by the way, because of the sort of politics that we've, once we've said we have analytics or continuous analytics, we were sort of sent into the analytics with the organization, which we're more focused on sort of data warehousing because analytics is still sort of data warehousing and ado. And the actual people that build the application and sort of those data science applications and sort of real-time AI or incorporating AI into business applications are more the development and business people. This is also why we sort of change our naming because we wanted to make it very clear that we're our technologies about building new applications. It's not about data warehousing or faster queries on a data warehousing. It's about generating value to the business. Now, if you ask a specific application, we just announced a few weeks ago the investment of Samsung in Iguazio, part of that essentially has two pillars beyond getting a few million dollars. It says one thing is that they've adopted Nucleo as their serverless for their internal clouds. And the second one is we're working with them on a bunch of data science use cases. One of them I think was even quoted in the amount we've made with Nucleo. So there are also no, what I can say or not say, but essentially those are real business application. That's really at least three of those that involves, you know, in intercepting data from users and customers doing real-time analytics and responding really quickly. One of the things that we've announced that's because of the use of Nucleo and some tricks that we've done with Nucleo, we actually, what report their performance? Yaron, do you see a fair number of customers embedding machine learning inside of real-time streaming, stream computing back months? This is the week of Flink Forward here in San Francisco. I was at the event earlier this week and I saw at least they're presenting a fair amount of uptake of ML and sort of stream computing. Do you see that as being a coming mainstream best practice? Streaming is still the analytics bucket, okay? Because what we're looking for is applications which are more interactive. You know, if you think about like a chatbot or like doing predictive analytics, it's not about streaming because streaming is still, you know, it's faster flow of data, but it still sort of has delay associated. It's not responsive. It's not, you know, it's not the aspect of latency is less critical in streaming. Okay, the aspect of throughput is higher on streaming but not necessarily the response time. You know, think about Spark streaming. You know, it's good at processing a lot of data. It's definitely not good that the response one would put Spark as a way to respond to user requests on the internet, okay? So we're doing streaming and we see the growth but I think where we see the real growth is embedding it to real applications.   So how do you impact the business on three pillars of the business? Okay, the three pillars are, one is essentially improving your operation or reducing the risk. It's essentially reducing your cost aspect. The other one is essentially how do grab our customers or make customers more successful? So this is around frontend application whether it's bots or doing targeted marketing or those kinds of use cases and also how do you grow your market which is again, around recommendation engines and those kind of things. So all those things, if you won't have AI incorporated in your business applications in a few years, you're probably gonna be dead. I don't see any business as a sustained competition without incorporating the ability to integrate real data with some customer data and essentially go and react based on that. I changed the subject slightly. You mentioned NVIDIA as a partner recently, of course, you announced that a few weeks ago at their event and they've recently acquired Melanox and I believe you used to be with Melanox so I'd like to get your commentary on that acquisition or merger. Right, yeah, so I was a VP data center at Melanox. My last job, I'm still good friends of all the guys there including the CEO and the rest of the team. We met in Megenson last week, I was in Israel so we've talked to the NVIDIA guys as well. I think it's a great merger. If you think about it, Melanox has sort of the best networking and storage technology on sort of the Silicon side and NVIDIA has sort of the best GPU technologies. Melanox also acquired some compute chip technologies and they also have very nice photonics technologies. Then Melanox today is being by all the cloud providers. My previous role was essentially owning those technical engagements with like the Azure and the rest of the gang. So now NVIDIA coming with the computation engine and Melanox coming with sort of the rest of the pieces around storage and networking make them a very strong player and I think it sort of threatens Intel because if you think about Intel they haven't really managed to come at high speed networking recently. They haven't really managed to come with GPUs that sort of combat NVIDIA technology. So I think that makes NVIDIA sort of a pretty strong vendor in that space. And another question is not related to that but you're in Tel Aviv, Israel and of course Israel is famous for the startups in the areas of machine learning and so especially with a focus on cyber security I think Israel is like near the top of the world in terms of just the amount of brain power focused on cyber security there. What are the hot ML machine learning related developments or innovations you see coming out of Israel recently related to cyber security and distributed cloud environments? Anything in terms of just basic R&D technology that we should all be aware of that we'll be finding its way into mainstream cloud and Kubernetes and serverless environments going forward, your thoughts? Yeah, so I think there are different areas that you know the guys in Israel also look at what happens in the sort of the US and there are players in all the different things. I think what's unique about us as a small country is that it's always trying to think outside of the box because we know we cannot compete in a very large market if we don't have innovation. So that sort of triggers this sort of innovation part because of all the security aspects in the country then also there's a lot of cyber. But you know something I've seen one cool startup that's also backed by our VC is doing sort of think about like face unrecognition pretty cool technology of since they could take a picture and make it such that machine learning would not be able to recognize that. Sort of anti cyber attack for image recognition. So that's something pretty unique that I've heard but there are other startups working on all the aspects of DevOps and automation and auto ML and also cyber, automating cyber security and various aspects. Right, right. Thank you very much, Euron. This has been an excellent conversation. We've really enjoyed hearing your comments and Iguazio is a great company, quite an innovator. It's always a pleasure to have you on theCUBE. With that, I'm going to sign off. This is James Kobielus with Wikibon with Euron Javiv and we bid you all have a good day. Thank you.


Outside of Africa, nine children and a young father have been killed when a van and another vehicle slammed together on a rain-drenched Alabama highway during a tropical storm. Butler County Sheriff Danny Bond says a nine-month-old girl and a 29-year-old father died in the Saturday afternoon pile-up of about 18 vehicles, including an Alabama sheriff's youth ranch's vehicle carrying eight other children aged 4 to 17 who were killed. The ranch is home to Alabama's needy, neglected or abused school-aged children according to its website. The cause of the crash on Interstate Highway 65, which was awash from the powerful storm, was under investigation. Fresh news updates


Good afternoon. I'm Dr. Lewis Myers. Welcome to Health Care Today. I'm honored today to have as our guest Mr. Bill Schubert. And if you've lived in Vermont for any period of time, you've probably come across Mr. Schubert because he has been involved in a tremendous number of issues in the state and in a number of places. By birth he grew up in Morrisville, Vermont and has written about that in some of his writings and in some of his books. He attended Phillips Exeter Academy and Kenyon College where he majored in French. He went on to be an entrepreneur and started a number of businesses and has also been involved with, as chairman of the Fletcher Allen Health Care some years ago. He now writes for V.T. Digger commentaries on a very regular basis and he's written quite a bit about the health care system recently. I'm going to talk about some of those issues today and some of his own experiences. I should also tell you he's a published novelist and has written a number of books. One of my personal favorites I can recommend is this book Lila and Theron, which is a lovely portrait of a couple growing up in early 20th century Vermont in the countryside. So without further ado, Mr. Schubert, welcome. Thank you, Lewis. It's good to see you. I thought we would start with an article that you wrote recently. So you've made it sort of a public domain about a health issue that you had and a serious health issue and your experience with that. Can you tell us a little bit about that? Yeah, I was having difficulty. I do a lot of work in the woods and I would get out of breath as anybody would. But if I'd been lying down or sitting and I stood up, I was struggling to get air. And I went to the hospital and they wanted to check me out to see if it was a cardiology issue, which it turned out to be. And I went to the stent lab and they checked me thoroughly there and I did not need any stents. So I was only in the lab for, I don't know, 20 minutes or so. But they said I had a valve that was down to about 20% function. So they explained to me what a TAVR procedure was, relatively new, and that that's what I should have. And I did. And they were phenomenal.  I took the minimum anesthesia protocol, was awake for the whole operation, which was an hour and 15 minutes. They go up through the groin, up, and they move the old valve out. And they put a new artificial valve in and they make sure it's working. And as I said, I was on the operating table for an hour and 15 minutes in post-op for a couple hours and home the next day with a little list of things I shouldn't do right away, like chainsaw or split wood or run up and down stairs. And it was terrific. And I have to say the quality of care was terrific. And I made a point of sending a letter because I have been hard on the system. I sent a letter both to the board chair and Dr. Leffler, who's the president, and just let them know how grateful I was for the quality of care I got. This was at the University of Vermont Medical Center. University of Vermont Medical Center, yeah. In your article relating that, you also said that you happen to be very well insured in terms of your health care insurance. And you wondered if the average Vermonter or perhaps the Vermonters who are struggling would have gotten similar care. What were your thoughts about that? I don't think that people are triaged around their ability to pay. I don't believe that's the case at all. I know that a nonprofit by law is required to treat anybody who shows up. I think there are people who are afraid of hospital billing, afraid of what they don't know, that they avoid going in for treatment.  And I talk to an awful lot of Vermonters who have just sort of given up on the system and say, well, I have to... Or they have a local federally qualified health center or clinic that they go to and can trust. The availability issue is important. I know seven days last year had written extensively about this, about the wait times for some of these procedures. But they got you in pretty quickly. Yeah, and that's a really complicating issue. Because did they get me in quickly because I'm writing about the health care center? Did they get me in quickly because I was a former chair of the hospital? And frankly privilege should have nothing to do with access. And that's not the way the world works, I understand that. But I think in an ideal health system or educational system, or criminal justice system, any of the complex systems, I'm not against privilege, but it shouldn't be a factor in something that we view as a basic right. You also wrote very recently in a long and thoughtful article in the VTD or commentary talking about non-profit versus profit hospitals, which is in the country, I don't know how the percentages break down, but here in Vermont we essentially think all of our hospitals are non-profit. And you wondered whether or not the University of Vermont Medical System, for example, which includes UVM, Porter, Central Vermont, and then three small hospitals in the New York side should retain their non-profit status. Can you talk to our viewers a little bit about what it means to be a non-profit hospital and how hospitals qualify? The way it's set up in Vermont is, and this goes back quite a ways, you cannot get what's called a certificate of need to start a hospital unless you register as a non-profit. It has to be non-profit. There are no for-profit hospitals in Vermont. Now, obviously the term non-profit and for-profit is open to some interpretation, although technically in statute it's not. They're very distinct, very carefully defined issues. And so by definition, any hospital operating in Vermont in order to maintain its certificate of need has to be non-profit. Non-profit carries some obligations. That means that you treat anybody who presents regardless of their ability to pay. It means although you can have retained earnings for future investment, they're not profit. You can't make profits. And the question that I raised, and I want to be really clear, I was not recommending that either UVM Medical Center or UVM Health Network lose their non-profit status. What I was saying is we have to be more assertive on the regulatory standpoint in understanding what non-profit means and what are the obligations of being a non-profit. In other words, bring that back into consideration at the regulatory stage. Can you talk a little bit about some of the areas that you would have some concern that the University of Vermont Medical Center, for example, has drifted away from its non-profit responsibilities? Well, there are a lot of things, and we don't have the time to go very granular, but pharmaceuticals, I mean, they get a government-enforced discount on pharmaceuticals. They mark them up very considerably. And when asked about that, they say, well, we need that revenue. Well, that was not the point. The point was is that very expensive pharmaceuticals would be made available so people could afford them. There's that. There's the whole issue of retained earnings. And to me, I think one of the most critical things, Louis, is the issue of when you do a deep dive on the expense analysis of any hospital. The question is, how much money in the budget is spent on administration and how much is spent on clinical care? And that ratio is really important in a non-profit. And I would argue that based on the figures that I've seen that are now in front of the Green Mountain Care Board as well, that there are real questions about how well that's maintained. We know that in websites like Charity Navigators, you can go on Charity Navigator and look up, if you're thinking about donating to a particular charity, how much they spend on administration, how much on direct care, where would University of Montt Medical Center fall on that at this point, do you think? If you can navigate the Green Mountain Care Board, you can see for yourself, it's not great. It's not great. Some deep dive analysis has been done on initially 200-odd academic medical centers around the country, and then it's been adjusted for bed count so that it's a fair peer group. And UVM doesn't do all that well. The compensation in the administrative level is extremely high. You mentioned that there, and this may be also part of one care, but that there were 17 administrators whose salaries averaged $480,000 a year. It's 19 who make a total of 16. And when you add that up, I mean these are people like chief legal officer, but it's not clinical. It's all oriented towards the business. And that's one of the major obligations of a governing board who cannot be paid by the way, is to impose on the administration a compensation philosophy. And UVM is very clear, both Medical Center and Network are very clear about their compensation philosophy. And that is they want to be at 50% of compensation for everyone in the country. So they're comparing themselves to Mayo, Kaiser Permanente, Mass General, Sloan Kettering. And I would argue very strongly that you have to adjust it for bed count, you know, how big a hospital is this, and also for the region. You know, so they use this to justify these extraordinarily high. So you mentioned regulatory boards need to look at this. Who is the regulatory board that would be looking at, for example, are they living up to their nonprofit responsibilities? Well, that's a really complicated question because since the Shumlin administration, when the Department of Health was sort of moved into the governor's office and not really clearly put back, and we now have four departments of health, and the Vermont Department of Health, which used to be responsible, sort of is not so much anymore, and then the Green Mountain Care Board came in and they were responsible for regulating. But the question is, who sets the vision and who regulates? And it's devolving to the Green Mountain Care Board to do both. And that's not a bad thing, but it's important to be really clear about it. So the Green Mountain Care Board's mission is evolving as well. Ultimately, you know, you can look at the legal system, which for for profit and not for profit is defined federally, but certificate of need is defined in Vermont statute. And then the Green Mountain Care Board has their own regulatory power, so it's complex. Speaking of complex, and you mentioned Governor Shumlin, of course the One Care program was negotiated and passed under the last part of his administration, and then Governor Scott has carried it forward. So we've had almost seven or eight years now of One Care, and you've written recently about that. Can you talk a little bit about what One Care is and where you think where it is right now? I mean, the philosophical tenet behind One Care, I agree with and a lot of people do, which is you don't charge people to repair them. You create a different incentive where you're paid to keep people healthy.  And One Care was designed to say to a hospital, okay, in your catchment area you have 70,000 people. We'll pay you this much per person on average to keep these people healthy. Don't send us bills for surgeries and all this other stuff. We're going to pay you a really good amount of money. You're not going to lose money on this, but your job is to keep people healthy. I think the term for this is population health. It is, and also, capitation. Capitation, yeah. And that was the idea, and not a lot of people oppose that. The problem is One Care, Vermont, you know, was set up to do this. And after, I can't remember whether it's six or eight years of operation, health care costs have continued to go up. So the reality is they couldn't deliver on mission. I should, I mean, as Vermonters know, we recently saw huge increases in the hospital insurance rates that the insurers who are still left in Vermont will be charging. And, of course, now they're going to make it very difficult. Yeah, and I have to say, I mean, I have a relative who was just laid off at a law firm, and he was offered COBRA. And for him and his wife and his 12-year-old daughter to have a gold policy is $4,000 a month. That's $48,000 a year. There are a lot of Vermonters who don't make that in a year. But, again, that's a different issue. I think what people often confuse is, they say, oh, MVP or, you know, Blue Cross Blue Shield, they're raising their rates again. If the Green Mountain Care Board is going to give the requested 23, 24, and 28% increase in one year to the three hospitals in the network, it's Blue Cross Blue Shield, which is a nonprofit request to pay those bills. So you can't give the hospitals a huge increase and then not give the insurers enough to cover the cost of those increases. Why do you think that, obviously, one care was going to improve overall health. It was going to control costs. The figures indicate that it's doing neither at this point. Why do you think it has, it is failing, so to speak? I think it's partially because the system itself is failing. I don't think the leadership was ideal. It's vastly complicated by the fact that a lot of the funding is federal. I mean, that's one of the things that we forget in Vermonters. We say, oh, let's just fix our health care system. Well, the reality is, our health care system is part of a national system. You know, what Medicare and what Medicaid are willing to dole out controls a lot of what we can do and what we can't do. So I think there are a lot of reasons why it failed. And as you know, Blue Cross Blue Shield just said, we're not going to be a part of it anymore because, frankly, as a nonprofit, it's not working and it doesn't work for us. And I have to say I respected that decision. You have written eloquently about, and you've mentioned here today about the need to look at the whole system in terms of education, in terms of child development, et cetera, as all part of the health care system. I think one question I would have is, is this putting too much on the health care system to try and fix all of these problems? Or should we be focusing on letting the health care system work on people's medical problems and letting the other responsible agencies take care of these other problems? That's a really, really good question. And one of the federally imposed mandates is that hospitals invest in community and, you know, they do these reports, these community benefit reports, which are pretty useless, frankly, at this point. But the question you raise is an important one to encourage viewers to just Google the term social determinants of health. It's a foundational document that basically says part of population health is access to education, equitable treatment, a social life, access to health care, nutrition, housing. They're all part of the same thing. And then they say, oh, we have a health care problem. Oh, my heavens. We have a public education problem. Oh, dear, we have a housing. They really all are integrated. Somebody living on the streets of Burlington is not going to have good health care, regardless of why they're living there. So we have to look strategically at how these things are interrelated. You're right, Lewis. It is not on the UVM Health Network to solve the issue of homelessness. Although I would say that from a mental health standpoint, we have failed miserably in understanding that there's a legal equity between physiological health and mental health. An awful lot of doctors I talk to when you mention mental health just go, uh, black hole. Well, federally, there's supposed to be parity, correct? Yes. But it's never really worked out that way. Well, let me ask you this. If you were the governor or the secretary of Health and Human Services or had a magic wand to begin to change our health care system, what are some of the things you would do? You've been looking at this now for decades. The first thing I would do would be to convene Vermonters. And I would bring them together from all socioeconomic and I would say, what do you think of the health care system? What's your experience? What could we do better? You know, and I would listen to that and I would evoke story, opinion, and data. And I would put those together and then I would essentially reverse engineer a new system. I would say, okay, what would an ideal health care system look like for Vermonters? What would be the spectrum from a community doc to a small clinic to a federally qualified health center to a community clinic to a secondary hospital to a tertiary care hospital? What would the ideal deployment be? Can I ask you one question? Sure. Because I know that you have written historically about Vermont and have a great sense of the history of the state in recent decades. Was Vermont's health care system broken when you were growing up? You had family doctors in every town. You had a central hospital, I guess, in Burlington. People were able to see their doctor for probably far less than it costs now. Was it broken? To me, it wasn't. I remember going skiing with some friends of mine in the gravel pit behind our house and I broke my arm and I knew I was pretty sure I'd broken it and I went home and mom wasn't there so I walked down to the hospital and I said, my arm hurts really badly. I was skiing and they x-rated and they put plaster on it and sent me home and my parents came home and said, what happened to you? And I said, I broke my arm. And, you know, Dr. Phil or Dr. Calcanny would come any time day or night to your home if you had an emergency. They had office hours. People paid what they could afford and they knew, you know, they might charge our family ten dollars for a visit and someone else too. Now they wouldn't even be permitted to do that. They'd probably have to charge everyone exactly the same amount. And when I was eight years old I was diagnosed with a slipped upper femoral apithesis which I worked really hard to pronounce and I got it wrong and I kept saying slipped upper female apithesis and people would say what? But, you know, and I came to the de Gauss-Brun hospital and I was there for two days and they put a pin in my hip and then I went back to Morrisville. Well, we haven't really even talked about primary care which is sort of the foundation in many ways of healthcare and which is certainly struggling now but, you know, we haven't talked about private equity companies which are swooping in and buying up nursing homes and increasing doctors' offices practices but I think it gets back to this idea of how do we get sort of back to the future to quote the old movie. If we knew that there were certain parts of the healthcare system that were working well and are now we've sort of broken it how do we get back to that and use the best of what used to be and with some of the new developments that we can use now? I think the real sort of existential question we have to ask ourselves unlike 130 other countries in the world many of which are poor we don't recognize healthcare as a human right it's a business and until we ask ourselves and answer that fundamental question we're not going to fix it I don't expect to have a national healthcare system in my life I will be grateful if we have one in my children's life In the meantime going back to my in our last couple of minutes we have going back if you had your magic wand you mentioned convening Vermonters to actually get opinion stories and data where do we go from there what would you do next? I would as quickly as possible develop a primary care deployment system so that people entering the system did not enter an emergency rooms which is the most expensive way in to the healthcare system they enter through a community health clinic or a community doc everybody would have a primary care doc and then based on the acuity or the seriousness of what the primary care doc finds they would be escalated up the system to the appropriate level of care and it may be a regional hospital we don't need to do everything in Burlington it feels sometimes like they want to do it all including primary care so we try and build back the primary care system definitely that to me is the highest priority and how do you attract what would you do about the University of Vermont medical system has it gotten too big or is it about the right size or how would you redirect its energies I don't like oppositional stuff you know I would say look we're in a regulatory position to insist on change let's co-engineer it let's talk honestly about what population health is it's quality, access and cost so let's agree on what that is let's re-engineer the system you will always be a critically important part of it but you may not do everything it seems to me that they do some things very well we have a fine medical school residency programs they've got some great specialists at the University of Vermont certainly I know for my own patients that they have been a huge help when we have very sick, very injured patients I wouldn't argue any of that but the question is as you said can they do everything and still manage to do anything well the other thing I would finish with Lewis is nonprofits don't compete they collaborate so does every hospital have to do joint replacements does every hospital have to do dialysis is every hospital going to have to do cart T-cell technology the first pill of which cost $420,000 or do we leave that to Sloan and Mass General and refer people there and refer people to places that are doing the best work centers of excellence well this has been a wide-ranging discussion we will have to have you back on this show and I would encourage listeners and viewers to read Mr. Schubert's articles in the VT Digger and wherever else he's publishing because there are some of the best articles being written right now in Vermont about health care thank you so much for being here really appreciate it nice to see you