All right, we can get started. So for those who haven't been here, it's Telecom user group. And it makes on alternating times on the first Monday of the month. This is our later in the morning time. Next month, it'll be earlier. And if you would like to talk about anything, you can add an item to the meeting notes. It's been posted in the Zoom chat. And your name is an attendee as well. So we just finished ONES. We have an LFN technical virtual conference coming up in the 13th. And then KubeCon after that, schedule's been announced. Does anyone have anything interesting that they want to add that was from ONES? Or I see Gergay and Tom and a bunch of people on here that have come but just point out some interesting things that happened at ONES from last week. Hey, Jim. Gergay. Yeah, very difficult to remember any highlights yet. I still did not process my notes. But I remember instead, there were these two sessions in parallel. One is the TAG B of session. And the other session was the panel with the, I don't know what was the title, Cloud Native Warlords 1. And I ended up in the Warlords 1. And we had quite an interesting discussion in the chat of the panel about the different problems what we have with the intersection in the intersection of Cloud Native and telecommunications. Yeah, that was a good panel. I'm hoping that we can do more of those. It's hard, I guess, even with the recording, trying to make the recording and then the cue at any being live is good. But I guess that becomes a discussion either way. That the, unfortunately, what was the birds of a feather for the Tocco Music Group, the Zoom links, didn't work. Or they were not clickable, I should say. But that one, we're going to have an updated version at the KubeCon. We were trying to make it a live session so it would be interactive, similar to the panel. I guess I'll point out another one. On the Monday, we put together a, I guess, it'd be a workshop versus a tutorial where we had six different CNCF projects, one after another giving a condensed or dense introduction demo and focused on how to use those projects with either focused on telecom or Edge and had those back to back. So if folks haven't seen those, then as soon as the recordings are available, I'd recommend checking them out because it was, you get six CNCF projects all one after another. We're hoping to continue following up with those projects on how to collaborate and get feedback into the different communities and projects, other projects. I know just from some of the feedback across the groups, the people that were presenting, that they were hearing staff on how they could interoperate. That was new. Does anyone have anything else they want to mention or talk about from ONES? I have a question about the birds of a feather session. Were there any new participants, any new parties who are interested? Only a few people made it on. You had to get into the session to be there alive. You had to get to a PDF that was attached and had a Zoom link, which then you had to type in manually. When that was noticed, then a bunch of links, the session had already started, but I know a few people started posting the link and the Slack channels, but I think by then it was too late and people shifted to other talks. So I did notice a few names I hadn't seen, but there weren't too many, unfortunately. Okay, that's a good learning for next time, yes. Yeah, for sure. It would be a good option for this conference to support live sessions. I think for Pana is... Zoom, and unfortunately it was just problematic to have the two platforms working together. And I don't know if anyone else caught this, but I think it was Monday of last week, either end of day Monday or maybe Tuesday morning. Zoom made a security change that caused problems across the board to ongoing sessions, including I think some of the CNTT, password requirements and waiting rooms and stuff like that. So that probably caused some problems. Also, that was our first experiment in Expo, the platform being used there. And there were a number of parts of it that were kind of clunky for lack of a better word and didn't quite work as expected. So, we're trying to experiment with a number of platforms to make these virtual events more engaging. We're aware that with so many virtual events, there's a bit of virtual event fatigue sitting in. So we're doing what we can to try and make them as close to live events as possible. And this was an experiment with the in Expo platform. And yeah, so we did have a number of things that just didn't go quite as we wanted it to for sure. I appreciate you all trying. I think the public Slack channel for ONES worked pretty well. And there was a lot of ongoing conversations that went even to multiple days over topics from different talks. So that was really good to see. And it'd be nice to make sure those continue past that time period and don't get lost. There's a lot of good content. Totally agree. There's a question and Zoom chat from Irvin's campus. Beyond high level discussions on CNF, is it right topic discuss which particular hardware acceleration technology are employed by members? For example, DBDK or AF XDP and how better to stitch them with containers? All right. I don't think that's a good topic and question. We can just add that to the agenda. I know, sorry, I'm just wanting to ask because is it too obvious? And that's why I just ask a bit because we are working for that for quite a lot. But if it's not a topic for agenda, so you can disregard it, it was just a question because it's beyond the high level of discussion. So just to ask my D, just to make it, because we are a little bit too, I would say, just living on the high lofts and just a question for, I don't know, making hands dirty and some kind of technical discussion. But if it's not a right topic for agenda, please disregard it. I'm not interested. No, that's, I think that's a great question. So I've added it into the agenda. We can come back to that. So is there any other items on events that anyone wants to mention? And I mentioned the upcoming ones as well, LFIN and KubeCon. So they, I'll give a quick update on the CNF conformance test suite. And we have a pretty large group here. So for those that aren't familiar with it, CNCF has, I guess I can just say, has three initiatives. One of them would be this group, the talk of music group. There's a CNF test bed, which is a whole tool chain framework and stuff for working with technology solutions and it deploys the packet. If you're interested, go check out CNF test bed. And then the CNF conformance is a test suite similar to, you'd think of it similar to the Kubernetes conformance test suite. So, or they, maybe the E to E test. It's actually more similar to the Sonoboy side, but it's as far as the configuration, how it's set up. And its goal is to provide a way to test cloud native principles and properties for both CNF's application side and the platform pieces beyond what core Kubernetes E to E tests and conformance are covering. So this gets, could get into items like how do you provide hardware acceleration that the question was just asked. How do you provide it in a way that services can consume it? And you could think towards Kubernetes native as far as implementation with the driver for underlying cloud native principles. And open source test suite, anyone can run it. We've recently updated to, it started with workspace and then platforms were added. Platforms were running as a, you would designate that you're gonna run the platform test separately. Now the workspace, the workload testing or CNF testing has been moved under a whole workload section as far as the namespace and everything. So you can either run workloads, the workload test, the entire piece or you can run categories within the individual tests. And you can also be able to run the whole thing if you wanna test a platform with specific applications that are running on it. And most of the new test focus has been on adding platform test. So this could be stuff like what happens when a node reboots or dies and that sort of thing. And there's been a lot of updates on the usability side from the getting set up based on feedback over the last month. Some of that's to make it easier to quickly get started. Some of it's on feedback if you're a developer and trying to run the test and make changes so that it gives you the feedback you want or change different levels of logging and get a lot more feedback. And then trying to look at what CNTT's needs are for the requirement side of workload platform, working with the badging side, so certification and ideally the CNF conformance will be one of the layers for a checkbox for telecoms to say, okay, it meets these needs, it passes its certified Kubernetes on the platform. It also does these things on platform add-ons like CNI, CSIs, and that's where the goals are. So we're taking feedback there. And on that note, we recently got integrated with CNTT for the testing and it's now running for workloads specifically. Platforms were still being not released yet on the integration that we were using, but it's now running in the CNTT OpenFeed Funk test and those are running. So that's the initial integration and we're gonna continue to go down that path to get feedback and make sure it works in a way that helps those end users, but anyone else can run it directly as well. Does anyone have any questions and comments or anything about CNF conformance test suite? And if you're talking, I can't hear anything, it's muted, otherwise we'll move on. So we had a couple of items on the agenda. I know one person wasn't able to join us this morning so their talk is gonna, we'll bump that to an upcoming meeting. And I think Sadeep was gonna talk with us about 5G CNF deployment models. Is he on the call Sadeep? Not, so it looks like we may need to defer that one. So we have an ODM introduction and then this CNF model, we'll bump those both to a future meeting. All right, we can go to Irvin's question. And this may turn out to be something that would be nice like in a survey, there's been surveys in the past and I know CNTT had a survey just several weeks back for some focused staff on new releases and direction. But we can try to see what feedback we can get in this. So I don't know if y'all can see the question here in the meeting, I guess I'll share mine. So the question is what particular hardware acceleration technologies people are employing and then maybe it's a further discussion on how to use them within containers or you'd say not just containers maybe but containers and Kubernetes and how would we do these in a different way or is there a better wiser than what happens? Yeah, I think of this just how to say we are just looking for some, I don't know, advices or opinions because like we, I think everybody knows DPTK but there is also this address family XDP so XDP or like embedded BPF. So like the both like technologies are like bypassing the kernel in terms for the dealing with the network stack. So just might be, yeah, that I don't know like might be some kind of suggestions from the other members, just what they are preferring or what they are they use because it would be quite interesting to also understand like what are their, I don't know opinions about the technologies. I could answer maybe. So let's say in fact words like I don't know further like it with the containers and Kubernetes. So can you hear me at all? Yeah, go ahead. Sorry, so I would answer briefly in two ways for things we're doing at Red Hat. So EBPF as a platform is really maturing quickly. There's a lot of interest in it from various aspects and very recent versions of the Linux kernel have really improved it in many ways. And yeah, that's definitely a very exciting path. I'll also mention smart NICs. It really depends on your use case and what you're trying to do. But a smart NIC, some sort of FPGA, you can offload a lot of your networking work. You can offload, for example, OVS open virtual switch and really layer OVM on top of that and really create a whole data plane based on smart NICs. It's challenging to integrate this into Kubernetes networking seamlessly. It's definitely not trivial, but these are two areas that we're working on at Red Hat. So there's a third one. This is a couple from Jennifer. So in addition to DPDK and smart NIC, there is another one, which is SRIOV. That's becoming quite predominant as well. And in the smart NIC, again, there is another one, which is the GPUs. So those are the ones which are predominantly being looked at by most of the telcos. Yeah, I understood. Now we're mostly are focusing on the public cloud and the particular, there's like, if we're talking, for example, if we are like some deployment environment is AWS and then of course there is like, they have, I would say they're supporting with this enhanced networking adapter. They're supporting DPDK and XDP. So I just wanted to gather some kind of insights. My visit members have done something is it worthwhile on which one to how to say to shift, whether it's a DPDK or AF6-DDP or they are overlapping each other. And then at the end, it will be one technology at the end. So there is another one, which is a competitor of AWS. It's a smaller company, Stackpad. They are geared towards fully cloud native deployments across the globe and that's geared towards Kubernetes, 100% Kubernetes and they're using fully SRIOV underneath. So if you wanna deploy Kubernetes and virtual machines, they give you 25 GB throughput in your VMs. And that's more than adequate for most of the application deployment. So like I said, these are the three very predominant ones. I'll mention quickly that SRIOV has a CNI plugin that was actually contributed by members of my team. And as long as you have the hardware, if you have a hardware that can support it, you can really, I think that's a very quick way to start getting into high performance networking in the lab. Yeah. Yes, there are actually several SRIOV CNI plugins. Yeah, sorry for plugging my own plugin, my team's plug. Of course, yes, that's true. And this is Anand from NEC. So we have tested a couple of CNFs. So many implementations are using SRIOV with DPDK like SRIVVF, then a DPDK or VPP inside the CNF to achieve this. XTP, what we have seen is we could not find a vendor that supports XTP in the port level. Like there is an XTP driver that bypasses or the net filter level, which gives a throughput similar to DPDK, but for a communication between port to port, which does not go via the network card. So we evaluated a couple of CNIs and they said these accelerations today are not available. But most of the illumination today what we are seeing with SRIOV is SRIV plus DPDK or VPP. And like Redad mentioned, this is SRIV CNI, which is available in OpenShift Maltes. And some of our customers are using this at scale. Do you know, can you tell me what's different between the OpenShift version and the Intel version? So what's the additional value of using the OpenShift SIOV CNI?  Other than saying that it's just very well integrated, OpenShift does come with Maltes, so which is fully supported. So if you want to add an extra SRIOV interface, you can manage that. I can't say much about installation and infrastructure. I do not know enough. Okay. Do you have support both Melanox and Intel cards? I know that Melanox, those SmartNICs are on the roadmap. Some support is already there. It really depends what you want to support, right? There's a lot you can do with SmartNICs. Very, very flexible. So I know that on the roadmap is to fully integrate OVN and OVS via SmartNICs. So that is on the roadmap for OpenShift. I don't know exactly when. But it's not for, but now we are talking about the SRIOV CNI. Oh, the SRIOV specifically. Sorry. Yes. Well, you mean Melanox SRIOV? Yes. Oh, okay. Sorry. I'm deep inside Melanox SmartNICs these days. I don't know for sure which ones. SRIOV is a pretty standard protocol. I don't know if the differences are that important or which hardware are certified exactly, but I imagine that the major ones. I can get you a list if you're interested. Yeah, to add to that some of the Melanox makes us a different OCP 4.5 SRIOV. So what providers allow you to control more of the network and use stuff like SmartNICs and SRV and accelerated networking? I think one of them that was mentioned, if I heard it right, was StackPath. Yes, that's correct. That's correct. Taylor, yeah. Okay. Who else besides StackPath? And I guess I could throw out packet. I mentioned them earlier. Does anyone know of any others? Would we put OpenShift in there? Since we're talking about being able to use... If you start listing products, you have to add your own product also. You have to add what? All product also. Well, I guess I'm thinking, I know that some cloud providers, you're not gonna have control over what would essentially be the underlay. So at packet, you could actually set a player to between machines. And then unless I'm off and it's changed recently, some of the cloud provider, so actually naming, you can do an overlay, but you're not gonna be able to set up the layer too. Seemed to be asking about public clouds, right? Yeah, public clouds for sure. So OpenShift would not be included. I know OpenShift runs on at Microsoft, but I don't know if they actually provide the hardware for any of this. All right. So maybe Azure question mark? Not sure. What's happening with maybe on that and tying in with usage, CNTT or maybe I should say the Elephant Lab for doing testing for the new Kubernetes CNTT implementation. This, I haven't seen the latest on that. I know that there was discussions with various places. No, I don't have the latest info. You don't have it? Okay. See, Gurgay, B1, yeah. It's Tom on here. Tom, do you know on the RI and testing side? Sorry, what was the question? Apologies. Just wondering, I guess this tied in a little bit with, it's not fully open, but what lab is being used for CNTT for RI? I know that Elephant and Jimmy may have input if you're still on. Yeah, it's mainly been driven by the Kubriff project in OPNFV at the moment. And it's been deployed into, I think, an Intel pod within the OPNFV labs. Yeah, yeah, it's currently running on the OPNFV Intel Community Lab. Oh, hey, Michael. Hey, I think there might be a couple of other deployments as well happening and George can add a little bit of detail on that one. Yeah, well, hi there. Basically, it's true. So this is a bare metal lab in the OPNFV context and they're basically three different labs or pods we have available right now to hosted by Ericsson and your Intel lab as well. So from that perspective, yeah, it's a bare metal thing, so you have full control over everything because you deploy everything. But it's also not a public cloud environment, but it's really like a bare metal lab. Sorry, I turned it later. I don't know what the question really is about, but that is what it currently, what I can say, so if it's about SROV and all that, that's configurable. We don't have smart links in the lab though at the moment. Okay, that's interesting. I get to know. So the whole topic was mainly about what are people using and they're talking about hardware acceleration and that kind of goes into what's available technology-wise and then where can you use those things? Of course, in a production internal, you can do whatever you want. It's nice to know what's out there for collaborating. Even, I would call the CNTT maybe almost a hybrid. It's not fully public, but if you're interested in joining CNTT and collaborating, then you'd end up with access while you're working with people. So that makes it where folks who want to know how something looks like maybe if someone was wanting to see how smartnecks or something else would work with the reference implementation and put that forward and maybe collaborate. All right. Does anyone have anything else or want to talk about on this before we move on, let Tal talk about his topic there? And I guess just to mention it one more time on like open or where things can deploy. CNFTestbed deploys the packet and there's a lot of people deploying there. So if you are looking for an open cloud, it works well if you want more control including more direct access to the hardware all the way from boot and bias. Open lab. So if you want all your own hardware, then that goes down a different path. All right. Let's hear about Knap. Is that how you say that? Or Knap? I think I pronounce it Knap or Knap sometimes. Knap is actually a word. So... Do you want to share your screen? Yeah, that'll be a great idea. Thanks. All right. So I will... Here we go. So I'll take about 10 minutes for this and I'm not gonna do a demo. I actually, this is kind of an ad hoc. I thought Alex Vuhl would be presenting today, but when I saw him removed, I thought I would quickly put myself on the agenda. So let me explain the problem. I think you'll understand it pretty well. The problem is... No, it won't be here. Oh, examples. All right. The problem is this. If you've ever used Multis, you know that you need a lot of knowledge to configure the networks. So expand this a bit. I'm giving an example here of a very trivial or straightforward use of Multis. And the idea here, I have two. So I have two deployments. First one is attached to network A, second one is attached to two networks. So as you may know already, there is a special annotation, a CNCF annotation that activates Multis. Multis will know how to look for this and attach an extra interface for this network. And then similarly, we have another deployment here that has two networks, explicit A and explicit B. And now these names here are names for custom resources called network attachment definitions. And these are very simple CRDs that all they do is include the configuration for CNI. So you give the CNI plugin. Here I'm just giving an example with a simple bridge. And pretty straightforward, right? But actually very, very difficult to manage at scale. I think as anybody who's tried to use Multis knows, in order to write this configuration, you have to be a system administrator or at least have access to system administrator information, not just for the cluster, but even for the particular host on which this deployment and its pods will eventually be running on. Because you need to know which technologies are available. If you're using, for example, SRIOV, right? You need to know what hardware, SRIOV hardware is available. If you are configuring IPAM, you have to know who else is configuring IPAM, right? It could be somebody not even in your namespace, some other workload that would need to make sure, for example, that there wouldn't be IP range conflicts. So in this case, since I wrote this, I can be sure that, for example, I have this subnet and this subnet. There's just one comment. So I think that's a fundamental design error in Multis, that the network administration and the attachment of networks to pods is kind of meshed together. Okay, I will tend to, so I'll say this, I think my answer, yes, you can say it's a design flaw, or you could say that Multis is designed to solve one very, very specific problem, but it's only half of the problem. So I would call what I'm presenting today, Multis part two, sometimes I call it. So Multis solves this very specific problem of attaching CNI perfectly, I think. But then, or not perfectly, it also has gaps. But yes, absolutely, this is what I'm trying to show today that this is a big, big problem. A major problem. In fact, if you're coming from the world of OpenStack, you're used to having a network as a service. You have Neutron, and Neutron, of course, has many limitations. I don't think we want something identical to Neutron for Kubernetes because Neutron assumes overlay networks, right? It already assumes that you can create any subnet you want, and it makes sure that you get it. And that's not always the use case we want in Kubernetes and definitely not in Telco. But we do need some way to manage these. And that's the project that I'm really showing you today. So I called it KNAP. And I'll say this is a POC. I think what I'm trying to do here is open up this discussion. And I don't want to be the only one who providing solution here, but I want to, it seems that some of you already know that there's a big gap here. And I have many other ideas on how to solve this too, but this was my first stab. And the idea was to use the operator pattern. So KNAP is an operator. And what it does, I go back to the example. Here's the example, the same example we just saw, but using KNAP resources instead. So the kind is network. So this is a new kind of custom resource. But you'll see there's no CNI configuration here. Instead, I'm specifying a provider. And I say that I want a bridge provider. And then similarly for the deployments, I just use a different kind of annotation. And again, I give it a name, but in this case, I'm not talking about a network attachment definition, but I'm actually talking about these networks. So if I actually did a live demo right now, you'll see that the end result will be the same. The deployment will work in the same way. You're gonna have those CRDs basically, sorry, those network attachment definitions created for you automatically by the operator through the provider. So a pretty simple solution, right? Obviously that all the knowledge has to be in the provider. The provider has to know what to do and how to provide these networks. So it's provisioning them and also deprovisioning them too, right? So for example, if there's a pool of subnets, the provider will know how to give it and unprovide it, return it to the pool if it's no longer in use. If it's SRIOV, you have a very specific limited number of resources, of course. So you'll have some sort of provider running and knowing what resources are available, maybe by introspecting the node, something like that. So this is just a quick explanation of the basic idea. And I think it's very powerful actually, because the idea here is that now I can design workloads that use multis, but I don't have to know anything about the system administration stuff. That's offloaded to this provider. The secret of course is making these providers, right? So I'll go over some of the... So that kind of explains the rationale of what's happening here. The provider is kind of interesting. And I wanna explain how the providers here work. So they work through a system that I call extra thick plugins. And some of you who know a little bit more about multis and about CNI plugins and multis, we talk sometimes and in CNI generally we talk about two kinds of plugins. On the one hand, there are thin plugins which are just one shot executables that run, right? That's kind of how CNI works. It's a command line interface. So you give it standard in, it gives you standard out, very, very straightforward. And you can have a CNI plugin that's designed just like that. It runs, it does what it needs to do and when it finishes it quits. We also talk in CNI about thick plugins. So yes, you run a one shot CLI interface but you have some sort of service. Maybe it's a system deservice. Maybe it's a Docker image running somewhere. Maybe it's something even external to the cluster that's running and provisioning networking for you if it's some sort of SDN solution, for example. Those we call thick plugins because they're not just one shot, there's something running all the time. What I'm doing here with NAP, I'm calling it extra thick plugins. And what I mean by that is that these plugins are running actually as pods within the cluster itself. So that provider, that bridge provider that we signed the demo example is actually running as a pod. Now, why is this interesting? You can also call them I think cloud native plugins if you like because they're actually native within the cluster itself. The advantage of doing something like that is that you can have a network function actually work as a provider. So in an interesting way, you can have a network function, say a CNF running on Kubernetes, which uses NAP here to get, for example, extra interfaces for a data plane if it's SRIOV or something like that, SDN connections to remote sites, SD1. But also because it is a network function, it might be providing network services that it can do for other pods. So a pod could be both a consumer of multis here and also a provider for multis. So that was kind of the architectural decision here in terms of these thick or cloud native plugins. I'll mention quickly a big disadvantage of the solution. Some of you might have already identified it, but if you, multis can only work during the initialization of pods. So if the pod is already running, you cannot dynamically change the interfaces. It's not a feature that multis supports right now and generally Kubernetes doesn't. Of course, you like to think that your pods are very lightweight. So they'll just be restarted with a new interface information if there's there, something there. So right now the way NAP works, you always see all the pods coming up and then they're restarted after the CRD is created. That could be okay and that could be a fatal flaw. So I've really considered another way of solving this is not via the operator pattern, but instead actually being an extra layer in front of multis. So if multis is an extra layer, a kind of multiplexer for CNI, you can have another solution before that that would be make sure to provide those CNI configurations for multis or it could be integrated into multis. As the question was here before, if multis, if this is considered something that multis should be doing, it could be enhanced in that way. But that would be really growing that particular project. So I just wanted very quickly and with this I'll finish my little presentation here to talk about this specific question. Is this kind of neutron for Kubernetes? I would say that a little bit it is. The idea here is to give the same kind of ease of use that we have in an open stack also for Kubernetes. And by ease of use, I mean that developers are able to create workloads without having that administrative information. So it's not so much a matter of difficulty, it's a matter of impossibility. If you do not have that information, you can simply not write those workloads in advance. You would have to create some other system to do that. And I don't know people do that sometimes with Helm, sometimes with other kinds of rendering before the deployment, but you end up having to create your own deployment system to make this work. And I think this removes that requirement. But I also at the same time want to say I the idea is to do here something that's really cloud native and not to duplicate neutron, not to create exactly networks as a service. It's more about network attachment definitions as a service. But this is the point where I really want to stop and open this up. This is me giving one-shot entry into this problem, but I really imagine that a lot of you have other ideas or want to discuss this. So I'll stop here and open it up if there's interest. Yeah, so I think that's a very, very important, let's say thing to separate the network administration and tenant network creation. And I think that's something that we do not have in QBATS and we might need like some kind of an API to manage networks. And I had some similar ideas, but my approach or my idea was to create CRD definitions for the API and to use different controllers to let's say implement different support for backends like the same API could be used, could be used more to sort them or network service mesh or whatever. Networking solution the infrastructure has. But this is I think pretty similar to that in some sense and partly address is the same problem. Well, let's join forces. I would love, as I said, I'm not married to my idea. This was an attempt and as I said, it does have certain disadvantages. And also the real meat here is the providers and how they work. So a demo using here, the bridge provider is relatively trivial. And the way my bridge provider works, it just saves a pool of subnets to a file. So it can manage it and make sure to synchronize on that file to make sure that everybody gets their own unique subnet and then they can return the subnet back. But obviously for more complicated networking solutions, there's much more work to be done during provisioning. For example, you might need to configure a PNF somewhere using NetConf. So the magic really is in those providers, I think. And if there's a standard API for that, that of course would make things easier for everybody. But yeah, if there's interest, I would love to continue offline and see if there's some way we can collaborate to solving what I think is a very big problem that we have with networking. Yes, okay, let's do that. I'm open for collaboration. I'm trying to figure out from who I can get from Nokia to actively participate in this. And when I'm done, I will send out some emails, let's say, because I have a list of interesting interested participants also from the last OpenDef conference where we had a very similar discussion and we had the conclusion that we should have some kind of an agreement on a networking API for Kubernetes. And also we kind of agreed that this should be done as something out of three because the Kubernetes networking seek is not really interested in these more advanced networking problems. Yeah, definitely, anything could start out. I was saying that there's an interest but they're looking much longer term. So how do you deal with something now versus something that may take a lot longer before the design comes out? You've been in the plumbing groups. You know, there's discussions. It's just the, they're looking at a much longer term. Yeah, exactly. And even Moltis was very painful to get where it is right now. There was a lot of resistance to that. It kind of looks like a temporary solution, right?  I was just gonna, this is a, I'm Ryan Tidwell from SUSE. I was just gonna mention here. I'm interested and open to collaborating on this. I've got a lot of background with Neutron been a contributor there for quite some time, kind of moving into Kubernetes space. And I'll just say that the problem that you mentioned here is one that on the surface is pretty obvious to me as well, you know, with Neutron. I think maybe we have an API that's very focused on infrastructure and those sorts of objects where with Kubernetes, maybe we swing the pendulum a little too far and wave our hands around things. And what you're describing here seems to kind of be aiming for that middle ground. And I'm interested in an open to collaboration with this as well. Wonderful. Yeah, I'll say, you know, my focus is on orchestration. I care a lot about the underlying technologies, of course, but I think we all agree that Kubernetes is not as mature as the legacy clouds in terms of managing these resources at scale. I think the scheduling paradigm that Kubernetes has introduced is very scalable in itself, but I think it caught us all off guard in terms of adapting our systems to it. I think this is part of the importance of this tug, right? That we can really discuss these challenges and see how we get there. So wonderful. Yeah, I'll love to continue this conversation. One more guy jumping on board here. Hi, Tel. I'd also like to, well, I don't like to restate the importance of this. I think that was mentioned already a couple of times, but yeah, George from Ericsson, I think that I'd like to be part of that as well. I think I should be able to find your contact somewhere, I guess, so that we can continue like all of us, of course. And some other context to discuss this, right? Let's just start the list in the minutes with the interested parties. Sure. Yes, please. If anybody could add themselves in the minutes in a section and I'll just send a group email to everybody who's interested, including people who didn't speak up. Awesome. Thanks, Urs. A question real quick maybe to end this from Victor Morales. I think that's towards you, Tel, about upgrading to the new version of, I think it's covering the multis annotation for default network. And then there's another question about the de-scheduling. That's in the Zoom chat. Do you see those? All my windows are, let me look at the chat. I'll drop it into the actual Google docs. I'm gonna, let's see. Oh, here it is. Yeah, I am considering the new multis, of course. So I'll say, you know, this is a POC. It really works, but it's a, as I said, I'm even reconsidering the whole use of operators here. I think the disadvantage of having to restart pods could be a major one. Yeah, I could use some help brainstorming how it could work. So very interested in getting feedback and trying out different solutions. You know, if you try different POCs, I think that's the way to find something good meritocracy. All right. I'd like to hear about the differences between this and the approach that network service mesh is taking. One of the things that they're doing is dealing with being able to make modifications after the pod, that we're out of time. So maybe that can be a followup discussion. Yeah, it's an excellent question. And personally, I don't think that multis is opposed to NSM. I think those multis could be an implementation of NSM. I can see all this working together, possibly. Oh, it can. There's been perfect concepts using multis directly. They're definitely complementary on the multis side. I'm specifically talking about the KNAP. Right, right. Yeah, I'm thinking about it too, but I'm sorry, I have a really sharp, I have to leave right now. Oh, I understand. You know, for the group. Thanks everyone. Next call is 1100 UTC. That's 3 a.m. Pacific time. And for the next call in November. Excuse me, just one question. This recording of this meeting will be available? Yes, if I will check with the folks who have access to the recording and make sure it's available. Yeah, please, because I think some key point is because I missed some initial parts. So if you can, yeah. Thank you very much. Sounds good. Thank you. Thank you everyone. Bye-bye. Thanks. Bye-bye.


Hi, I'm Carl Griffiths, and I'm an account manager in the UK super office team I'm here today to show off our new dashboards in super office To our fellow super office cloud users. You may have already noticed a change to your dashboards. We have gone from this To this and what improvement we have made the usability of our dashboards to begin with the user experience has changed You can actually choose how you wish to display your data Let's start by showing you how easy creating a new dashboard can be by hitting task I can choose to create a new dashboard. I can give this a name Choose a theme and also select how many columns I want within the new dashboard Let's use three as an example I can select who this is visible for and you are now able to choose to pin the dashboard to relevant teams in your business This means you can ensure your entire team have visibility of the visualizations you create Now we have created our dashboard I can now select from our generous library of pre-created tiles If you select the drop-down you can then choose from different categories of data you want to add to your dashboard Let's have a look at the cells options as an example You can then simply drag and drop into the dashboard the ones you want from the library As you can see there are many options to choose from and once selected the information is then quickly visible with your live data Once you have chosen the information You can then customize the sizing of each individual tile to your liking Let's take a look at how simple and easy it is to customize your dashboards once created Firstly, you can change the data set. This may look very similar to selections in super office And yes, they work pretty much in the same way This allows you to make changes to the data within the chart You can amend the current criteria or even add additional data fields to be included on your Tile results Once you are happy with the dates you want you can now choose how you wish to see the layout of your data You can change the chart type. We've actually added some new chart types to our Tile library This means you can even change the chart type once you've created the initial tile We have some standard additional fields to choose from too This is to help with how you wish to visualize the data For example choosing the measurement you want to use and Changing the displayed data is simple You can select which field you want the chart to display by this means I can move from shown as by cell type to now being the cell owner As I make changes you'll also notice the preview will update meaning you are always in control in creating You can also choose to additionally stack or group your data This may be for example wanting to also stack by cell type giving you both sets of data in one chart Finally, we do have additional formatting you can choose from this may be to move the legend for example Once you are happy with your changes, you can simply save and instantly have your updated customized dashboard tile So as you have seen the new customizable dashboards and super office give you complete flexibility To not only choose the data you want but see this in your preferred layout If the dashboards isn't a feature you're currently using in super office I hope this short video has helped offer additional value for considering using this moving forward Thank you for watching my favorite feature of super office for any further information Please feel free to contact the details provided. Have a great day


Welcome folks, we have the Dow Industries trade down at 475, we have the Nasdaq off 251, S&Ps are off 72. That's a down draft inside the Nasdaq folks of 2.2%, 1.8% in the S&Ps and 1.4% in the Dow Industries. Gold. Gold contract up $2.40 trading at 1783, you've got Silver down 5 cents, $22.36 an ounce, light sweet crude down $247, breaking out the lows $74.45, notes and bonds, you get the 10 year note trading up $166, $114.12, $30 a year down a full point plus $196 and $130.13 and you get the 10 year yielding $3.5 today and $Kingdala, $Kingdala's rejected lower price out here, you got it up $275 trading $105, $562, year is $104, he ends at $136, British pounds at $121 to $1 US dollar. Getting follow through here folks and we do have volume expanded so bottom line, now you have the S&P in the lower range, we were talking about this yesterday, bottom line got inside the 403 and that puts game now for the spy into that 381 and right now you're at 393. We go into the NDX100 which is leading this baby down, same setup, same gap it's going after. Now the Q's, the volume's gone up big time. Today we did 41 million shares, you're already at 39 so that's going to bang out 55, 60 million and that gap's wide open. The gap there is 268. We go to the gold contract now, it's intriguing here, there's no doubt, I mean gold's pulled back but gold and gold equities are holding up really well in this market. What you have with gold, bottom line is that you're up $2 out here today, I don't like the setup, I can tell you that, I mean it's holding up and I understand that, it's holding up but like today you're up 119,000 contracts, you're up 320,000, I wish we were down, that is not what you want to see folks if you're a gold bull, that's not what we wanted to see because yesterday you had volume in the gold market, bottom line here, watch this. So yesterday you go lower with 180,000 contracts, higher today with 119,000, not cool and it's going to be all about this US dollar, we finally might get a bounce out of this dollar, you had a rejection of lower price yesterday, bottom line we'll see how this shakes out, you're up 259,000, the higher range has to get it to 106,000, 281,000, which you did do though, you rejected the lower price out here as well as where it went back to strength, so I suspect the way this market is setting up the dollar wants to go higher, markets want to go lower, stay right there folks, come right back.


Item number SCP-129 Object Class Keter Special Containment Procedures SCP-129 is at large in the world and infects large numbers of humans and animals daily. As such, containment efforts are focused on treatment of infected individuals and on eradication of any or all member species of SCP-129. Although at least 98% of the world's population harbors a natural immunity to one or more species of SCP-129, outbreaks that reach stage 3 or higher must be contained as quickly as possible with infected individuals quarantined under highest risk-contagent protocols. In the event of stage 4 or stage 5 outbreak, in addition to the above procedures, data expunged. Description SCP-129 is a series of different species of fungus that can infect any animal with mucosal membranes. Infection by SCP-129 can pass through up to 5 stages, depending on exposure to further member species of SCP-129, individual resistance, and other factors, with each stage of infection facilitating progression to the next stage by weakening the individual's resistance to subsequent infection. Due to a combination of historical events, most humans and animals are naturally immune to SCP-129-4 through SCP-129-1. Therefore, outbreaks of stage 3 infections are quite rare, but have the potential for widespread infection, if not swiftly isolated and contained. All known cases of SCP-129 have followed a 5-stage progression, although data expunged, possibly due to mutation. Stage 1 The first organism, SCP-129-1, attacks the victim's mucosal membranes, multiplying quickly and unobtrusively. A faint yeast-like smell might be detected, but beyond that, SCP-129-1 is asymptomatic. A second organism, SCP-129-2, can then infect the host, causing the victim to experience symptoms identical to those of acute viral nasopharyngeitis, the common cold. The decreased efficacy of the host's immune system due to infection from SCP-129-2 allows SCP-129-1 to become entrenched further. SCP-129-1 and 2 generally leave the host body within 4-6 days. Though both species are fairly widespread, and most of the population has little to no protection against either organism, they pose little danger themselves, except to facilitating infection by SCP-129-3. Although SCP-129-3 is usually stopped by natural mucus, stage 1 infection changes the composition of the host's mucus, so that the host is significantly less resistant to SCP-129-3. Once established in the host, SCP-129-3 alters the host's mucus, lymph, and blood, such that other species of SCP-129 can thrive in the host. Symptoms of stage 2 infection include greatly increased mucus production, a nagging cough due to excess phlegm, a lingering low-grade fever, increased sweating and salivating, a somewhat increased preference for vegetables, and the complaint that certain fruit juices taste odd. Infection by SCP-129-3 generally lasts anywhere from 2 weeks to 4 months, before being driven out by the immune system, unless the host enters stage 3 infection. At least 80% of all humans have experienced stage 2 infection at some point, but due to natural immunities, in spite of stage 2 infection, and the relative rarity of stage 3 species, few have passed into stage 3. Stage 3 In the absence of SCP-129-3, nearly all animals are immune to the three species that cause stage 3 infection. However, a small number of stage 2 victims can become infected with one or more of these species. In these cases, the fungal infections become entrenched in the host and cannot be removed without extraordinary measures. Individually, the three stage 3 species elicit different symptoms in the host. SCP-129-4 causes increased tear production, lacrimation, slight yellowing of the eyes. SCP-129-5 causes the host's nails to thicken and significantly increases earwax production. SCP-129-6 data expunged, in particular, bright yellow urine, and small pellets in the host's feces, both of which smell strongly of yeast. However, a victim who becomes infected with all three of these species will, within hours, develop flu-like, or worse, symptoms, and become bedridden for three to five weeks. Afterward, though the victim appears to have recovered fully, in actuality, SCP-129 has spread throughout all systems in the host's body, marking passage into stage 4. Stage 4 Victims who reach stage 4 appear generally healthy, and indeed may be more lively and energetic than at any time since first contracting SCP-129. In actuality, SCP-129-1-6 have spread throughout the host's body, completely infiltrating the subject's immune, respiratory, circulatory, reproductive, and central nervous systems. Mycelia from SCP-129 species also permeate the host's skin and replace some percentage of the host's hair. These hyphae, which are nearly indistinguishable from the host's natural hair, are used to propagate SCP-129 to other hosts. Any potential host that comes into contact with Shed-Off Hyphae has an extremely high chance of becoming infected with SCP-129. Hyphae seem to be equally contagious from any part of the host's body. Despite, or perhaps because of, increased susceptibility to SCP-129, stage 4 victims are much more resistant to viral and bacterial pathogens than uninfected subjects. All known subjects who have reached stage 4 have either progressed to stage 5 or died within six weeks. Symptoms of stage 5 infection depend on a variety of factors, including the particular stage 5 species that are present, as well as genetic, physiological, environmental, and any number of unknown factors. However, as in stage 4, all stage 5 victims are highly contagious and can infect victims who had previously shown complete immunity. Notable manifestations of stage 5 symptoms. Witnesses riding in a commuter train car described a woman suddenly blowing up like a balloon and exploding, but instead of blood and viscera, the contents of the car were covered in spores and filaments. Analysis later showed that the victim was infected with SCP-129-9, SCP-129-14, and SCP-129-4. All persons and objects in the affected area were quarantined, euthanized, and incinerated per protocol. Several casualties, including foundation personnel. May- Following a string of disappearances in data expunged were tracked to a cave several kilometers from town. Inside, investigators found several pulsating mounds of flesh and vegetative material. Although most were unrecognizable, a few of the entities retained some human characteristics and were identified as some of the missing citizens. Researchers theorized that victims of this combination of SCP-129 would interact normally with the populace, attempting to infect others, until, after a period of time, they would come to the cave, how and why they were brought here is not known. Upon arrival, the victims would be changed into the pulsating vegetative flesh mounds, which appear to be organisms modified to provide a long-term source of sustenance for SCP-129. This suggests the flesh mounds could potentially live for several years. All topsy revealed the presence of SCP-129-10, SCP-129-11, SCP-129-14, and SCP-129- Site Quarantine and Sanitized Per Protocol. Item Number SCP-135 Object Class Euclid Special Containment Procedures SCP-135 is to be contained in a partitioned plexiglass chamber, at least 7 meters to a side. All sections are to be completely sealed off from one another to avoid cross-contamination. SCP-135 itself is to be in a central section, with 1.0 to 1.5 square meters of floor space, with a 5 centimeter wide runoff trench around the perimeter that drains into a tank, the contents of which are to be piped into an incinerator at the end of every week. The remaining space in the containment chamber is to be used to house five chemical-harvesting vats, one vat per partitioned section. A single-access corridor is to lead from SCP-135's section to outside the chamber. No personnel are permitted within SCP-135's effect radius. All maintenance, taking of samples, etc., are to be carried out by remote-control robots. Disciplinary measures need not be taken against personnel that violate this rule, because the direct consequences of SCP-135's effects have been deemed consequence enough. Robots are to be maintained and cleaned by level 1 personnel. Once a week, SCP-135's section is to be hosed down, with solution U-82B, until only its outer coating is visible. In emergencies, flamethrowers may be employed to reduce mass quickly. Due to the potential catastrophic effects in the event of cross-contamination, at no point are SCP-329 or SCP-427 to be contained within the same facility as SCP-135. Description SCP-135 is a human female, age undisclosed, that promotes rapid, uncontrolled cell growth within a radius of 2.25 meters from itself. It remains rigidly in the fetal position and has never been observed to move. SCP-135's effect is carcinogenic to animal tissue and induces malignant neoplasia and plant and fungal tissues in 100% of recorded exposure cases, with severity and disorganization increasing exponentially with closer proximity to SCP-135. Within 0.1 meters, cells will not die, even under conditions where they would normally, causing SCP-135 to be steadily buried under a continually growing mass of plant matter, fungal matter, and microorganisms. This undying state extends to SCP-135's cells as well. SCP-135 has been shown to lack an epidermis, instead having a crust of mixed plant and fungal matter that has incorporated itself onto SCP-135's skin, interspersed with tumors and patches of raw dermis. SCP-135's lungs, diaphragm, and intestines are ruptured, and growth extends into the chest and abdominal cavities. It has been fitted with wide diameter plastic tubes for use in draining excess biomatter. The foundation came into possession of SCP-135 after it and a surrounding ball of growth rolled off a cliff in the Rocky Mountains, crushing a hiker on the trail below. Class B amnestics were administered to the civilians and law enforcement personnel involved, and the incident was covered up as having been caused by a pair of male goats that slipped and fell off the cliff edge during a dominance battle. Later examination of the growth revealed the partial skeleton of an adult human female, with osteosarcomata covering 90% of it. SCP-135 was found in the space between the skeleton's ribcage and pelvis. A viable DNA sample was recovered from the bone marrow of the pelvis, and testing confirmed that the skeleton belonged to SCP-135's biological mother. All personnel involved with SCP-135's retrieval and initial testing were later diagnosed with various forms of cancer. Out of the blood affected, only blood is still alive at the time of this writing. Attempts to terminate SCP-135 with sustained gunfire, flamethrowers, caustic materials, vacuum, and extreme pressure have all failed. Further termination attempts are forbidden by order of 05 due to SCP-135's potential uses in cultivating useful bacteria. EEGs confirm full brain activity. No attempts to communicate with SCP-135 are to be made at this time. Item number SCP-164 Object Class Euclid Special Containment Procedures Cultures of SCP-164 should be contained, using Standard Class III Biohazardous Procedures, and stored clearly marked within a refrigerated biocontainment unit, at 10 degrees Celsius. While pathogenic, SCP-164 is not highly infectious. While researchers working with raw cultures or infected subjects should use caution, latex gloves and face masks are generally effective at preventing the spread of the disease. Any personnel inadvertently infected will be subject to six months of chemotherapy upon first showing symptoms, and surgery as necessary. Civilian outbreaks should be handled using Cover Up Procedure ALEPH for contagious materials. Description SCP-164 is a strain of cancerous cells that cause sarcoma like tumors and host bodies. While cell DNA appears to be primarily derived from human DNA, the cells now effectively exist as unicellular, asexually reproducing parasites. Several characteristics make SCP-164 remarkable.   Chemotherapy and surgery are effective in treating the disease in nearly all stages. Tumors produced by SCP-164 that grow larger than a certain size will, in 75% of cases, follow normal behavior for cancerous sarcomas. However, in 25% of cases, host bodily materials will be utilized for the creation of a new, separate organism inside the tumor. In the case of multiple tumors, some or all may follow this behavior. Said organisms will apparently begin as zygotes, fertilized ova, and replicate, much like fetuses. Externally, this appears no different from normal tumor production, and may go unnoticed in initial stages. Oddly, mature organisms identify as being completely unrelated to the original tumors, corresponding with a previously unknown species of ordered toothida, squids. Removal of organisms show that they are entirely viable in marine conditions, and will perform normal actions such as locomotion, catching food, basic defense, reproduction, etc. However, said organisms will also remain entirely viable in the original tumor, rarely moving or shifting position, continuing to grow at a regular rate, until the host is killed. The existence and nature of the organisms, SCP-164-2, is often not realized in civilian cases, until biopsy or surgery reveals the developed organism. SCP-164 organisms and tumors may interact with host physiology in interesting ways. The following cases are particularly notable. Female D-Class, 23 years old. SCP-164 tumors spawned on uterus walls. Host body apparently recognized the tumor as a human fetus, and was delivered normally containing viable SCP-164-2 specimen after nine months. Male D-Class, 30 years old. Tumors spawned on the spinal cord, disrupting the central nervous system. As a result, movement from SCP-164-2 would occasionally cause subjects limbs to flail, suggesting a cross-wiring of the nervous systems of the two organisms. Biopsy lent support to this hypothesis. Male D-Class, 25 years old. Tumors spawned near the esophagus and windpipe of the subject, in a location that with ordinary growth would normally have blocked off said passages, and quickly killed the subject. Instead, the growth of the tumors shifted to the back of the neck, preventing subject from dying before the normal point. Dr. Rapp suggests that this may have been a deliberate action taken by SCP-164. Item Number SCP-199 Object Class Plant Containment Class Euclid Special Containment Procedures A garden of SCP-199 has been built at Site-19 for research and containment. The garden is kept in a ventilated containment unit with artificial light suitable for plant growth, and an automatic watering system. The ceiling is covered with an electrified grate, capable of destroying instances of SCP-199-2. The entire chamber is to be surrounded with a Faraday cage to prevent admission of SCP-199-3. Instances of SCP-199 or SCP-199-2 found outside of containment are to be destroyed with fire or pesticides. Description SCP-199 is a species of fern within the Hymenophilaceae family. SCP-199 is tangentially related to filmy ferns, but is more tolerant to temperature, humidity, pollution, and external damage. The rhizomes of the plants can attach to and grow on most solid surfaces. SCP-199's appearance is similar to that of Thalos liverworts, but its fronds are unique to its species. The fronds of SCP-199 will form into bladders approximately 10 centimeters in diameter, designated SCP-199-2. Eventually, they will fill with hydrogen gas generated by SCP-199, detached from the main plant, and drift into the air. SCP-199-2 will eventually float at one mile above sea level and begin to ripen. During this period, SCP-199-2 will emit SCP-199-3 at an initial rate of one signal per hour, steadily increasing as SCP-199-2 ripens. Once SCP-199-2 is ripe, it will burst, releasing its contents. In most cases, SCP-199-2 is empty, and its explosion will not have any consequences. Occasionally, the explosion of SCP-199-2 will release seeds that grow into new instances of SCP-199. SCP-199-3 refers to radio signals produced by SCP-199-2. All radio signals consist of a high pitched male voice, speaking in Mandarin Chinese, giving analysis reports, consisting of observations made from SCP-199-2 and status reports of SCP-199-2 itself. Analysis of SCP-199-2 has shown that neither the source of the voice nor the radio signals exist, as most instances of SCP-199-2 are empty. SCP-199 seems to thrive in polluted environments, implying that it is adapted to grow in heavily populated areas. In addition, SCP-199 is resistant to most pesticides. SCP-199 is most commonly seen growing in chimneys, gardens of large cities, and inside of industrial factories. SCP-199 was originally discovered after residents of Xi'an reported balloon-like objects colliding with hotels and interference with radio devices. The source of SCP-199-2 was found to be a patch of it within the center of the city. Instances of SCP-199 have been since discovered in several large cities, most notably New York City, Los Angeles, San Francisco, Beijing, and Tokyo. Analysis of SCP-199-3 From 09-12-2017 to 09-19-2017, large-scale analysis of SCP-199-3 was conducted by the Foundation. Large containment cell number 45 at Site-9 was temporarily converted into a simulated urban area. Five instances of SCP-199 were moved to the area for testing. The following is a transcript of SCP-199-3 transmissions, as well as notes in italics. This is Staffman Fox Tale, launched successful, entering watching mode. Transcript of SCP-199-3 after launch of SCP-199-2, name and rank vary per instance. Targets found, beginning following mode. Transcript of SCP-199-3 after floating above simulated civilians. Targets performing clumping, engaging. Targets entering phase, engaging. Transcript of SCP-199-3 after floating above a gathering of simulated civilians. Engaging in Armageddon. Transcript of SCP-199-3 after floating above a gathering for two minutes. Armageddon failed, disengaging. Transcript of SCP-199-3 after floating above a gathering for five minutes. It is unknown what would occur if Armageddon was successful. Evasive drift initiated, course moved. Obstacle encountered, moving from course. Transcript of SCP-199-3 while avoiding buildings. Single target engaged in protection lists. Retreating. Transcript of SCP-199-3 after floating above a member of D-Class personnel. Disguised as a New York citizen on a balcony. Single target engaged in that of protection. Standing by. Transcript of SCP-199-3 after floating above a member of D-Class personnel. Disguised as a New York citizen on a balcony. While the balcony had flowers. Non-target found without that of protection. Coloured blue. Transcript of SCP-199-3 after floating above a balcony with flowers without a civilian. Colour changed depending on type of flower. Standing position recovered, entering malign phase. After this was recorded, SCP-199-2 instances actively avoided balconies. Unintelligible. The Paragon. Emitted by a contained instance of SCP-199-2 while floating above Site-19. Payload ready for deployment soon. Standing by. SCP-199-3 as SCP-199-2 became close to explosion. Sorry, it looks like we have a May Day here. Please avoid future infertility. SCP-199-3 before explosion, when SCP-199-2 was empty. We have a complete deployment ready. Pleasure to serve you, sir. SCP-199-3 before explosion, when SCP-199-2 had spores. If you could tell them I loved them. One instance of SCP-199-2 emitted this while idle and appeared to be cut off mid-sentence. Context unknown. Many variations and idle phrases cut out of this document. Addendum. On 09-21-2018, residents of Istanbul, Turkey reported a collective cloud of over 50 instances of SCP-199-2. Before Task Force could respond to this, all instances simultaneously burst. Instead of seeds, SCP-199-2 released an acidic slime that caused severe damage to a road intersection and created three casualties. An ongoing disinformation campaign was released, crediting the source of SCP-199-2 to be a bioterrorist attack. The source of this phenomenon was identified to be a patch of SCP-199 on the outskirts of Istanbul. The Task Force attempted to use fire to destroy these plants. However, SCP-199 reacted with a fire and exploded into acidic green slime, injuring five Foundation agents. Following destruction of the patch, analysis of the soil revealed that SCP-199 had been planted there four weeks earlier. This new variant of SCP-199 has been tentatively designated SCP-199-B. SCP-199-B has also been reported in Mumbai, Lagos, and Mexico City. Near the patch found in Lagos, a partially biodegraded plastic seed packet was recovered buried underground. The front of the packet had a symbol resembling an eye, with a red iris, with a green substance covering a third of the eye. The back of the packet had a symbol strongly resembling the Foundation's shield logo, but with the arrows pointing away from the shield and three vertical bars covering the shield's inner circle.


China, India, and Pakistan, what we're calling Southern Asia. Nor else in the world do you have three nuclear-armed states with hotly contested borders that have come close to war many times. While we're focused on Russia's invasion of Ukraine, this is a hotspot you can't ignore. This is the latest. How does the Biden administration's new Indo-Pacific strategy consider security dynamics in Southern Asia? The Biden administration's new Indo-Pacific strategy is significant in that it integrates India and South Asia into what has previously been largely an East Asia strategy and seeks to really define both Indian Ocean and Pacific Ocean equities when it comes to free, open, and connected Indo-Pacific. But the reality is, when we're thinking about Southern Asia, a crisis between India-Pakistan or India-China will most likely start on land, and that's somewhere where the strategy really hasn't adequately addressed what might be crisis escalation and how the United States would factor into preventing or mitigating a future crisis. How might the Russian invasion of Ukraine impact an already tense security situation in Southern Asia? Well, it's a really good question. The Russian invasion of Ukraine is having impacts across the world on everything from food security to energy security, and Southern Asia is not immune to that. But what's most interesting here potentially is how the Russian invasion is impacting India in particular. India has long depended on Russia as a critical security partner. Most of its military gear and material is actually of Russian origin, and its major threat is from China. That's where India is most fearful that it could get into a war that it could lose. And this war is leading China and Russia to get closer and closer. China has basically stood by Russia right before the invasion. China and Russia announced what they call the No Limits Partnership, which is a great concern to India. And I think it leads to a lot of questions about how these states will behave. Will Russia back up India if there's a conflict with China? Will China back up Pakistan if Pakistan and India have a conflict? Or will China try to take advantage of that kind of conflict and potentially open a two-front war for India? And I think Russia's actions in Ukraine lend more uncertainty to all of those sorts of questions. India and Pakistan appear to be upholding their latest ceasefire agreement. What lessons should we draw? It is very significant that the February 2021 resumption of India and Pakistan's ceasefire agreement along the line of control has held as long as it has. And I think it's interesting the lesson here is twofold. One that I think both India and Pakistan recognize the dangers of escalation, that it's much harder to de-escalate and contain crisis between the two countries, especially with China as a complicating factor. But I think the other lesson is that without some sort of durable formal mechanism for crisis management and conflict resolution, these ceasefires have a tendency to break down. Over the last 20 years, India and Pakistan have had ceasefires that have broken down, whether due to a terrorist attack or domestic political constraints. And so we risk going back into periods of high ceasefire violations and cross-border incidents that can spiral out of control. What are the prospects for future nuclear talks in southern Asia? This is a really good question. The fact is, even though these countries have been advancing, developing their nuclear arsenals, have been building their capabilities and have had violent clashes in recent years, they really don't have a lot of mechanisms for coordinating, de-conflicting, talking about whether something was deliberate or an accident. And I think the prospect for actual talks, actual strategic stability dialogues like we saw between the U.S. and the Soviet Union decades ago, it seems really low. Just a few weeks ago, India accidentally fired a cruise missile into Pakistani territory, which fortunately did not lead to an escalation. But it's the kind of thing that highlights why it would be really stabilizing for China, India, and Pakistan to figure out a way to talk about how they approach conflict and stability and how they manage their nuclear arsenals.


news update. Good morning folks. This is Steve Rhodes coming to you live from the shores of well what is very sunny Delray Beach, Florida. This is your 11 a.m. update. We got a little bit of a mixed bag out there that mixed coming from the Dow and the Dow transports. They're both up 60 points for the Dow. About two tenths were sent about three tenths for the trannies. They're up 42 points. Otherwise, the other U.S. indices are trading to the downside. The S&P is off three tenths. That's 13 points. Nine tenths for the NDX 100. 121 points there. About eight tenths for the Russell. That's off 15 points. The semis are down one and a half percent. 46 points there. Gold's off six bucks. Trading at 17.91. Silver's off 13 pennies. Twenty-thirteenths a print. Light to be crude. Trading out at 87.52. That's back a buck. 33. Natural gas is having a nice move today. It's up 37 cents. $9.08 is the print there. And the 30-year treasury is off nearly one point. Trading out at 140.18. Let's go take a look at that nine-panel market update chart. We begin with the ESMini, the upper left-hand corner. What do we know? We know that the ESMini yesterday closed above the top of its weekly profile. That low was 42.77. It doesn't matter that it does it on a Tuesday or a Wednesday or a Thursday. It's got to do that on a Friday. So that's the level. Prices above that resistance area. 42.77 and close above that on Friday suggests that the market continues to motor on higher. That is especially true or helpful with that spot volatile next being well below its 50-day exponential moving average. If we look at the NQ, now if the NQ closes below yesterday's open, that'll generate a bear sash candle. That would then generate a sell the D point. Your price target would, one price target would be the top of the daily profile. So we've been above for two consecutive, now three consecutive sessions out there. So 13.419 would be the first level of support to be observing. Of course, it's going to depend upon what that candle looks like at day's end. US dollar index, nice rally. It held support at the 104.92 level and it's found resistance at the top of its daily profile. Resistance level to be observing and watching is 106.58. We take a look at Goldilocks just consolidated with inside its daily profile out there. That's between the range of 17.75 and 19.12, I believe it is, 18.13, 19. What is Stevie talking about out here? And it can take like it's over, also consolidating with inside its daily profile. That's between 1974 and 2069. Lights we crude has got support at the bottom of its daily profile. It's got trend line support out there. If it closes below that though, that says curtains at price of wood head lower. We can see that the natural gas contract is testing its prior high. That high is at $9.38. You take that out. You've got an A to B equal CD to the upside. That sounds like higher energy cost to me. 30 year treasury right now is sitting just below the bottom of its daily profile. Closed below that could be suggested and moved to 135.26. Folks, stay tuned for the Trader Zed show. But if you're off to start your Tuesday, have a terrific one and look forward to seeing you again soon. Take care.


Good morning and welcome to the Vermont House Human Services Committee today is Wednesday, November, March, March, and the first part of our morning we're going to be having a discussion about impact of age 728 and act relating to opioid overdose response services. The impact on our Medicaid program, one of the pieces in the bill that we passed that's sitting in appropriations relates to prior authorization as it relates to Medicaid. So that is our just that is our focus today and we have with us to help educate us is Ms James who is the, actually Dr James sorry your PhD. Who's the health care director from the Department of Vermont Health Access and the Commissioner of Diva. Andrea do love. Very, very excellent, excellent try Madam chair, thank you very much. And how do you I apologize how do you pronounce your name. It's delivery air, but no worries. It's lovely three name. It's actually three words, all of the almost all the letters of the alphabet practically but it's a pleasure to be here and I really appreciate the opportunity to talk with you today. Commissioner for the record Andrea delivery air commissioner for the Department of Vermont Health Access. We were anticipating Nancy Hogue our director of pharmacy joining us as well I want to make sure she's on here. She may be having trouble connecting. She is also one of our subject matter experts that we're anticipating having joined today. We're here today to talk about the fiscal implications. But first I really want to take a moment and appreciate the work that you're doing with this particular bill this. These topics are near and dear to my heart. As I have not personal experience with the issues but certainly someone I was very close to has been impacted by these issues so definitely appreciate the work you're doing. It's a very thoughtful insightful work that has happened over this the course of, I can see the many drafts here that that you're really taking the time to try to address the crisis that we're in so thank you. I wanted to start there. But as we dive into the fiscal implications specifically for Vermont Medicaid you'll see there would be a significant impact with the proposed changes. And if we don't have Nancy yet I'm wondering if missa we you and I may want to walk through this together. I think that probably makes sense. I want to ask a naive question and perhaps. After the words said it, what we were going for was not to totally remove prior authorization and are are very clear reading of your memo. We wondered if, if those words weren't clear, and if in fact what you were responding to was a remote total removal of prior authorization. Great question and I really, I really do appreciate that I think for us. The, the change to include Medicaid in the bill I think was probably our biggest challenge. Simply because the, our responsibilities to manage the whole class of drugs is the fiscal responsibilities to manage the class of drugs would be impacted by the change by us being added to the bill. And that said there the legislative report that we have provided in the past has been a solution to this and I know I've been doing some research on the history here and I know that this very similar conversation happened I believe in 2019, if I have that right. 2019. It happened. It was a bill started in the Senate. Yeah, and I think it was because of what was perceived as the fiscal implications that's a compromise was to not include Medicaid but have a report. And when we look at the report and the numbers, what we see in the report, and this is, we may not understand all of the, how things work. But when we see the numbers in the report, and we do analysis based on that, we don't quite come to the same huge impact that you presented us with. I understood. Okay, that's very helpful. Thank you for the background on that, and this will be today's presentation will be a comprehensive and more holistic look as to what you were seeing the report, versus what you've seen that report. And I hope that this provides some clarity, but just to circle back just a moment, we are more than happy to continue providing a report to you, if that is acceptable versus having Medicaid named in the bill, if that's the direction you determined to go in. What I'd like to do today what I'd like to do is now that Nancy has joined us. I'd like to hand off to Nancy to walk through the fiscal impacts here to further explain how we arrived at the numbers that we have. And, as you know, this is managing access. We want people to have access to the medications they need, while also being fiscally responsible. So, with that I'll hand off to Nancy, if you wouldn't mind, Nancy, she has the information and she'll walk you through. Good morning. Good morning. Good morning. I'm Nancy Hogan I'm the director of pharmacy services for diva. I've been in the state for 12 years. And I'm certain I've been in front of this committee before so it's nice to see everybody. So let me just walk through how we arrived at that fiscal impact it really was composed of three separate impacts. Significant impacts is since we since the bill prohibits us from really managing the MIT class as we do currently. We will not be able to collect the supplemental rebates that we receive on these products today so we we. Yes, you probably know Medicaid receives a federal rebate on all medications that that are dispensed for Medicaid members. In addition to the federal rebates which are statutory and are always available to us. We negotiate additional rebates through a consortium sovereign states drug consortium. Vermont was a founding member of that consortium back in 2003. And through that consortium we're able to negotiate additional rebates that we call supplemental rebates. So these rebates are negotiated directly with manufacturers and of course they're willing to give us these additional rebates when we can help drive utilization to the preferred products. That $4.2 million is related to the loss of the supplemental rebates, not the federal on the Suboxone products on on I'm sorry on the buprenorphine products. Are there any questions about that before I move on. We do have a question. Wonderful. Thank you so much Nancy question on the supplemental rebates are the supplemental rebates dependent on prior authorizations. Yes, they are the manufacturers always require that their product be listed as preferred, and that any competitor products be listed as non preferred. And there are different, I guess I would say tears for those agreements. So it depends on the product and the offer, but sometimes they do not want any other products preferred only their product. And there's a certain amount of rebate associated with that kind of structure. And then other times were allowed to have two preferred products. And then the rest have to be non preferred. And then, you know, it just depends on how the agreement is structured. So, but yes they always require that non preferred products require a PA. Yeah. Yeah, I was just, I want to follow up on represent smalls question. Because not quite sure that the answer got at what she was trying to get at I'm going to try a different way. With the preferred product that you're able to get the rebates on. Is there another way to communicate that to prescribers. So that they understand that if it's clinically appropriate that they actually prescribe that drug, as opposed to a non preferred drug. So essentially accomplishing the same thing without having to do the current process. It's highly unlikely that manufacturers would accept that structure. You know, prior authorization is very effective at moving utilization. And that's why they typically are looking for that. So I don't think that would be very effective one and number two, I don't think that manufacturers would accept that as a strategy. Follow up question on that then. So I'm hearing that the agreement that you have with the manufacturers is that there has to be a prior authorization on non preferred products. Am I understanding that correctly. Yes, that's correct. And so are there prior authorizations for preferred products. No, there's no prior authorization on two formulations of buprenorphine that are preferred on our preferred drug list. And one of those is Suboxone film. There is no PA unless the dose exceeds 16 milligrams in obats, office based practices, and there is no PA either buprenorphine naloxone tablets, which again, only if it's over 16 milligrams. If I could follow up. Thank you madam chair so the report that we received that outlined in 2021 there is some, you know, I think it was over 1000 prior authorizations for Suboxone, where those all due to quantity being over 16 milligrams. That's correct. One of my questions is that they're understanding the sort of fiscal impact that you've outlined. We're wondering to what extent, like a sort of scaling back of different components, you know we outlined maybe four different things in this one was dosage limits. One was the first 60 days, and the other were designated medications. Say if we were to align it with the statute or non Medicaid insurance, and to make it just about no prior authorizations, if it's within the dosage limit without have a significant change on this fiscal impact. So if, in other words, if we were still able to apply the PA to the non preferred products, but if we open if we raised the if we allowed providers to use up to 24 milligrams in the office based practices, is that what you're saying. Yeah, that's one configuration of it or another. So I'm interested in your response on that. So that would not have a significant a fiscal impact because then the fiscal impact would be limited to the number of PAs that were denied for over 16 milligrams, which, you know, we'd have to look at the, I think Lisa, it may be testified to that last week, but the number of those that are denied for over 16. So the fiscal impact would be that number of PA denials, and that that is pretty close to what we estimated for the second fiscal that we estimated that was just under $700,000 was prior authorizations that were previously denied that would now not be subject to PA so therefore all those would be approved essentially, and we estimated $688,000 point five for that. So what I what I'm hearing is that the at least the component about one designated medication, not receiving prior authorization, maybe one of the smaller ticket items on this list, but then to be clear about the the mono formula of buprenorphine. What are your thoughts on on that as far as how it contributes to this amount. Well that certainly would be part of the contractual negotiation with the manufacturer. And, you know, there isn't as much of, there isn't really a fiscal impact in that case, the issue there is more clinical. But we would have to make sure that that was, you know, not going to affect our contracts. And at this point, it is in non preferred position. So I. And but so also just to be clear, the kind of first thing on our list of potential exemptions for for prior authorization was any medication under within the FDA dosage limit. So that's not where you see the majority of this fiscal impact coming from when people can essentially pick and choose between preferred and non preferred as long as it's within the dosage limit. The, the fiscal impact is if we change any of the preferred or non preferred product status. So we currently have two preferred products that's allowed. That does not that allows us to collect those supplemental rebates if, if any of that changes, if we either move a non preferred to a preferred, or remove a PA on any of the non preferred that's what would affect those contracts. Yeah. I just wanted to add a clarification for Rob Whitman. One of the, one of the questions I think that he's driving at is in each seven 28 under section three, the definition of health insurance plan is changed to include Vermont Medicaid. As a result of that section for subsection a where a health insurance plan shall not require prior authorization for prescription drugs for a patient who is receiving medication assisted treatment. If the dosage is prescribed within the US FDA dosing recommendations would now apply to Vermont Medicaid. I believe the question he was asking was, would that provision alone result in the fiscal impact that diva has provided for the committee's consideration, because of the removal of prior authorizations across those therapy that therapeutic class. In consideration of the language in that section. Yeah, yes, it would affect the supplemental rebates. So I think that, thank you, thank you for that response, but I'm also hearing that the concept of having the one designated medication, perhaps exempt that you could essentially designate as your preferred option because again you have over 1000 prior authorizations for group or northing because it's above the quantity limit. You're ultimately approving many of those prior authorizations. Right. I mean there's only so few that you'll ultimately deny so you're triggering prior authorization for say suboxone, which I'm assuming it's, which I believe is your preferred medication. You're going through all those prior authorizations, you're approving the vast majority of them. And so this, what I'm hearing is that that's a larger fiscal impact and I'll defer to others as far as I'm happy to hear that you're willing to continue this work I know that within the house we are under time constraints as far as how much more we're anchoring and tweaking we can do with this I think will probably and and the amount of sort of time to get back information quickly. Maybe one of our constraints say that we can delay action. In other words, if the appropriations is not going to vote out a bill with the with the this section in it. Without given your, given your fiscal note, but if you all can work with representative Whitman and others, if there is something we heard testimony that there is there are some barriers. And we are there are some barriers for folks who whose insurance is paid for through Medicaid. And if there is a smaller step or a more targeted step that will not have such an immense negative impact on the rebates and things like that. So if, or if I'm fantasizing but if I'm not fantasizing if you all would be able to continue the conversation. We can always propose an amendment on the, we can delay action on the bill until next Friday. And so a week from Friday, or something like that. I'll just jump in. Yeah. If I, if I'm fantasizing. No, I think you're, I really appreciate you taking the time. And these are, I think we're willing to, I think we're willing to definitely collaborate and try to work toward a solution that meets everyone's needs I am curious though. Who you're hearing from regarding barriers because that is, that's a concern. I also have done some research of my own with our hub providers, and they are not experiencing the barriers, or at least that's what they're sharing with me. I absolutely recommend you speak with some of them. That's who we go to for expert advice because they see such, you know, hub and spoke providers are are, I think one of the valuable contributions in, you know, in our landscape here in Vermont. My only, I, yes, I think that makes sense and whether we do it, when I say informally, ie a small group. Absolutely makes those connections. So is there anyone specific with access to the hubs have on some level more to do with where are they, and the hours they're open, some of those kinds of structural issues. Some of what, and I'm going to look to representative Whitman and small. Some of what we are talking about are the spokes. And the spokes that that you know that that's all. Okay. The spokes but I, I hear you and we will, we will do that and if you could actually provide us with, you know, either some names of some folks that we could connect with and then we can connect with our own. Absolutely. Absolutely. I think it benefits all of us to have more information so I will follow up with a couple of names for you, and that would be great and in the meantime. Is it appropriate for for Nancy to review the rest of the items on the fiscal impact at this point. I'm absolutely you did the work and that will be educational for us, whose, whose focus is policy and we'll figure out how to pay for it later. Okay, great so then I'll hand it back to Nancy and then we'll have some follow up discussions after this. Thank you, Andrea. Yep, there was just one other so we talked about the supplemental rebates and then we we also talked about the previous, the PAs that were beat that are being denied today what the fiscal impact of those no longer being denied would be so it was 4.2 million for the 688,000 point $500 for the previously denied PAs and then the the significant there is a significant impact for not being able to prior authorize a drug called sublacade because sublacate as you probably know is a long acting buprenorphine depot injection. It's a new drug and it has no competition in the market at this time. There is a competitor product that has been trying to get FDA approval but they've been struggling to get their product on the market so we don't expect any competition in that class until at least perhaps the end of the year, or even into 23. So, it as with many new drugs, it's very expensive, and it is anywhere between 10 and 15 times the cost of the oral medications. So we had to estimate an impact of removing a PA on that product, even if the utilization of the product is is minimal. So we estimated a sort of bottom impact that of all the people in our fiend that we dispense, if only 10% of that was shifted. I'm sorry if only 8% of that was shifted to the depot injection that that would have an impact of $12 million. So it, because this product or these collection of buprenorphine products. This is our number one drug spend. It is also our number one drug by volume, and it's been that way for close to 10 years. So, that's why the physical impact is so big because we use so much MIT in the Medicaid program, and because this particular is such a high price point. It's about, you know, it's in excess of 20. Let's see, I'm going to do the math in my head here. It's an excess of $20,000 per patient growth. So it adds up very quickly. So if 10 if if we shifted another 8% to that product that would be 12 million. And then we just set sort of, you know, if things really escalated and we saw as much as 25% of the utilization shifting then that would be a $30 million impact. So we tried to give sort of the low worst case scenario, if you will. So that's where those numbers are primarily derived. Representative Small. Thank you. And so looking at these projection numbers is, is this increase and anticipated increase which is why the department's including it and its fiscal impact. Or am I understanding that you chose the most expensive product to show fiscal impact. This is an anticipated impact. We took every single drug available in in the class and determined what the fiscal impact would be. So, so that's why, you know, for example, we included the 688,000 because that was an incremental impact to no CPA. So we looked at every drug, figured out the cost, and it's supplicate surfaces to the top just because it is the most expensive drug in the class. And we do control utilization of that drug with a prior authorization today. So that's why that has such a big impact. I really appreciate the, and we appreciate the, the explanation. And I will again repeat that we are policy committee. And what keeps coming into my mind is, how do we ensure that Vermonters, who are struggling with opioid use disorder, get their medication, when they need it, how they need it. And so as you I have to admit, because I'm not a money person, which is why they keep me far away from there as possible. When you personally, I have a hard time with the worst case scenario, because I'm looking at it in terms of both the immediate for the individual or the individuals and then the potential cost avoided. And those individuals are then able to work, able to go to school, able to more able to raise the family, but that's what I really appreciate. Commissioner, you're speaking on behalf of diva your willingness to and it may go nowhere, and I get that. But your willingness to in the next. Next week to continue the conversation that I know you've been having with representative Whitman and sometimes with representative small, in terms of, is there something that we can do, or is there something in the report that we would be more helpful as we move forward. Or something as simple as you come back with a way to, but all of that I mean, because I as much as I wanted to try to find holes in your analysis. I'm having trouble finding holes. I really am not disappointed to hear that. And, and I think the joint fiscal offices is breathing a sigh of relief as well. Representative McFawn. Thank you, Madam Chair. Madam Chair, just to clarify something with me a week planning to have somebody from the hubs and spoke program to come in here, because it appears on one side we're talking about Senator McFawn, you have a good question. Are we planning on connecting with whether the we is a committee, or whether the we is the continuation of the small group that worked on this is at this point up in the air, because we have basically until we basically have a week to do this. And so it may be a piece of this and Senator McFawn has said that she will provide us with a few names of spoke people. And I would also recommend hub, if that's okay with you. Okay. Now I'm chair. I never got to my question. Oh, sorry. The question is, on one side, with the small group, we're hearing that people aren't being served as well as they could be. And on the other side, we're hearing that there is no doesn't appear to be any problem in the hub and spoke program. So I want that settled. That's what we're trying to do. That's what which means hearing from other people and talking to other people and you know, it's not going to be a perfect system. I mean, you know, the goal is improvement, right? The goal is that we improve and make it accessible while also being fiscally responsible and balancing that scale as much as we can. So I appreciate the opportunity and we are absolutely committed to work with with all of you and others. Thank you. Thank you very much for responding so quickly this morning and coming to have this conversation. I really appreciate that. Okay. Oh, wait. I have a question on chair. Yes. No one could do we can't hear you. I just have a quick question. Representative small Whitman and myself are scheduled for appropriations day at one would you like me to ask them to postpone. No, like just to still go and present. No, I mean, I think that it is Wednesday. I think that will make them very nervous. My suggestion would be to say that we, we understand the appropriations is going to do something to that, you know, that we prefer they not, but we understand they're going to do something that we may be coming with an amendment. When the bill is when the bill is put on the floor, we will be asking for it to be delayed to the last possible date, which is I think Thursday, I mean, you know, or Friday to see if there is a step that is fiscally responsible that we can take. And with that, this ends, we're going to take a pause or we're going to take a pause or move directly are people waiting people are waiting so thank you. Everyone from diva really appreciate it again. Thank you so much. Thank you very much.