Hello everyone! So, being freelance translators, chances are everyone watching this video is bilingual, at least bilingual. And you speak two languages more or less the same, more or less fluently. So, I wanted to talk about being bilingual. You've all heard how great it is to be bilingual and the advantages of being bilingual, and they're all true. But today, I want to talk about the disadvantages of being bilingual. So, let's get into it. Disadvantage number one. You can sound pompous. So, you're talking about the Divine Comedy. And I might say, well, as Dante said in the original Italian, in the middle of the path of our life, you'll find a dark jungle in the middle of the street. That sounds pompous, especially when everyone's kind of watching, not understanding what you're saying, and just know that you're rattling off something. On the other hand, everyone in Italy has to learn the Divine Comedy and knows at least the open and section by heart. So, you know, for an Italian, it's still kind of pompous just to blurt it out for no reason. But, you know, everyone at least knows it. And so, it's not considered all that pompous. By pompous, I mean haughty like you're above everyone else if you speak another language. Because every now and then you're just going to start using words, expressions, or quoting literature in another language in the original of, you know, whatever language it might be. And it can come off a bit hoity-toity. So, I find myself sometimes trying not to do that and try to be a bit less embarrassed about it. So, be careful about that. Disadvantage number two. This is a big one actually, and this is when the wrong word can come to you. Now, this happens a lot usually with stuff like metaphors and similes and euphemisms. You're used to saying something one way to an expression like, let's cut to the chase and you might just translate that directly into whatever language, other language you speak, and it makes no sense. This happens a lot with expressions like that. He has an axe to grind or skeletons in the closet or waiting for the other shoe to drop or stuff along those lines. You usually can almost never translate them literally into the other language. And yet it comes so natural to do so that very often you'll use the wrong expression. This also happens with words, by the way. And at least for Italian, I know there's certain words that like pretend that you have a word in Italian pretendere and you have English pretend. These mean to very pretendere does not mean to pretend. And yet it's spelled almost exactly the same. And so it sounds like it should mean the same thing. Another one is incidente and incidente. Incidente actually means accident. And so you have these two words that are very similar and yet mean different things. And so very often it's very easy to confuse those two. There's another example that I've heard of a German person once saying, Oh, we should become pizza. And which is an odd thing to tell someone. Oh, we should become pizza, except the verb become means to get. So this German person was obviously saying we should get pizza. And there are other things that I've been made fun of for in the past. I said, well, one thing that I never lived down in college was once I was talking about how my ears were tapped. I meant my ears were blocked, tappati in Italian. And it just sounds so natural to say my ears were tapped. And my roommates made fun of me for a long time because of that. I've also found myself saying weird things that actually might not have anything to do with being bilingual, but just my brain. But I've like plane station. I use the word plane station for airport and co-students instead of classmate. I don't know, but that might just be my brain being wired incorrectly. Anyway, so that's the disadvantage number two is using the wrong words. And this is probably very common if you speak more than one language using the wrong word expression in various occasions. Disadvantage number three, mispronouncing words. So and this happens a lot. Unfortunately, I could only think of one occasion, which was I remember and this again was in college. I was making a speech and I was saying how something was innovative. And then everyone made fun of me because I kept saying innovative, innovative and it should be innovative. And I was thinking innovative. Anyway, I found out years later that actually had I been in the UK, it would have been fine because you say innovative there, which I would have been fine. But anyway, but this happens all the time. You know, you mispronounce words because you have very similar words that are pronounced differently in one language rather than the other. And so you'll mispronounce them. Let's go on to the next. I think we're on number four now. Disadvantage number four. Mispronouncing people's names. Now I have this a lot in the States. You have a lot of people with Italian last names. And so I'll see an Italian last name, like say, M-A-N-C-I-N-I. And that's a common Italian name, Mancini. And I'll say, oh, your name is whatever Mancini. And they'll be like, oh, no, Mancini. My last name is Mancini. And then I really feel like saying, no, it should be Mancini. It should be Esposito, not Esposito.  And I found over the years that I'm the one who's wrong. This person, whoever lives, has been in the States for many generations. And their name, if it's Mancini, it's Mancini. That's the way they pronounce it. And that's the way it is for them. And so, you know, as much as I would like to say on the original time, it should be Mancini. Yeah, in the original time, it's Mancini. But the way they pronounce it is Mancini and that's how it is. And so, you know, you don't really have to correct this. And this happens with many other languages. I know, like in the States also, you have the last name Choi, which is a Korean last name and it should be pronounced Che. But they spell it C-H-O-I and they pronounce it Choi here. And yeah, you correct it all you want. But, you know, at this point, if someone's last name is Choi, they go by Choi and that's it. So, and chances are when you're dealing with two different languages, yeah. And you see this especially in places where you have a lot of, like places like the States, where a lot of people came here from other countries and so you have a lot of this mixture of last names that then get their spelling and their pronunciation changed. And so, it tends to be a very common thing depending on where you are. Next, disadvantage of being bilingual. I think we're on number five here. Let's say it's number five is, oh yeah, this is a big one, being asked to translate and interpret all the time. I mean, I wish I had a dime for every single time. I got song lyrics, I got movie titles, I got just random snippets of conversation or, you know, an article or this, that and the other that I have to interpret or have to translate from one language to the other. And chances are if you're bilingual, you're going to have to deal with this and you're going to keep having to deal with it. There is no antidote. It's going to keep going on. So, deal with it, unfortunately. Next, disadvantage of being bilingual is what I have. Making other bilingual people mad. Oh yeah, making other bilingual people mad. So, if you are a, I don't know, an Arabic to English translator, let's say, or you're bilingual and Arabic and English, and then someone else is bilingual in Spanish and Portuguese, you might tell them, you know, you might say something like, well, your languages are very similar. They're nothing as different as Arabic and English. You know, and that can make them kind of mad because they'll be like, actually, there are a lot of, you know, nuances and because the languages are so similar, there can be a lot of things that can trip you up or, you know, that you need to understand between them. And the fact is you're both right in a way. And so, yeah, you can make other bilingual people mad. You know, you might think we're all in the same boat, but then you start saying, we're like, I am doing the Chinese and this language and so you have no idea what I'm dealing with. And yeah, they have no idea what you're dealing with. You have no idea what they're dealing with though. So, you know, it's a cool down. And look, all languages are different and it's true, a lot of them have more similarities between each other than certain other ones do. And that's the case. On the other hand, you know, a lot of them have different nuances and a lot of different issues. If two languages come from two countries that are side by side, chances are these countries at some point in history have clashed. You know, you take like, you know, some might say, oh, Korean and Chinese, well, I know there's also Sino-Korean and so there's a lot of similarities. Yeah, but on the other hand, they've clashed many times throughout history. Like, I know they have issues now in Korean between the Korean-Korean and Sino-Korean and all that because one is more Korean and one is more Chinese-influenced and they're trying to... Anyway, that's the whole issue there. And this stuff you have to keep in mind when you're translating that maybe you don't have to deal with if your two languages are Chinese and Portuguese, right? So, anyway, something to keep in mind. There are lots of nuances and yeah, a lot of different languages. Next disadvantage, number seven, I guess. Disadvantage number seven is... Oh, yeah. Another disadvantage is you miss out on stuff growing up. This could be TV shows, childhood games and songs or stuff like that because even though you're fluent in another language, you only grew up in one country, chances are. So you didn't grow up in the other one. And even if you speak the language fluently, you probably didn't grow up with the same watching the same cartoons, you know, or the same TV shows or stuff like that. And I know I had this coming to the States. People start talking to me. They think I'm from here, but I didn't grow up following American sports. And so I feel very much like a fish out of water when that happens. Also, I didn't grow up watching American cartoons. And I remember people would be talking about Animaniacs or this, that, and the other and I had no idea what they were talking about. On the other hand, if you talk about the cartoons we had in Italy, especially like, well, I mean, you know, all the ones of Cristiano Davina and my favorites were Cavalieri de Los Odiacos, Olia Benji. Anyway, those I can wax lyrical about. On the other hand, someone else who speaks flu in Italian, but didn't grow up in Italy, might not know anything about them. And so you kind of miss out on that.  And you kind of feel like you're lacking in that sense. And so you do feel like you're missing out in a way. At least I felt that way. And also other issues like, you know, I come to the States and I hear people complaining that when you call a number, you have to pick press one for English, press two for Spanish and people are complaining about that. And I'm like, I mean, I came from Switzerland. We have four different languages there. Everything's in at least three different, you know, three of those languages and many times in four of them. And so I mean, to me, it seems like such an odd issue, but depending on where you are, it can be an issue. So there you go. And finally, the last disadvantage of being bilingual is actually, well, yeah, this is sort of a disadvantage is that you might be a different person in each language and this can happen in many different ways. You might actually even speak with a different voice. This sort of does happen with me. I've noticed with various languages, you know, the main ones are Italian and English, but I know it's also when I speak Chinese and stuff like that, I have a different octave. I don't know, a different voice is kind of weird. But also you end up just being a different person. You think in a different way and you might find yourself acting in a different way, liking different jokes, liking different things. And you notice it's a lot probably if you watch comedy, you watch something funny in any one language and then you try to translate into the other language and it doesn't come across as funny at all. And you realize that you like two very different types of humor depending on what language you're watching. And so this is very interesting to me because, yeah, you realize that you are kind of a different person in each language. And I noticed this quite early on. I worked in a place for two right out of college. I worked for two years in an Italian speaking place and for two years everything was Italian. And then I trans and then I changed job and I moved to an English speaking office and everything was in English. And I realized I was two very different workers in these two different places. Obviously there are different companies. So, you know, that contributes to it. But a lot of it was the language and because I'm just used to expressing myself in a different way depending on the language. So I think this is very interesting. And I try now, I said this is a disadvantage but I'm going to switch it to an advantage. I try to use this to my advantage. What I'll do very often is if I have an issue that's been bothering me for a while that I've been thinking about for a while, something that I'm stumped about, I find, you know, if I've been thinking about it in English or what I'll do is I'll try to go through it in English. Maybe in my mind go through like I'm having a conversation with someone. Having the conversation and going through the issue in English and then later again in my mind, I'll go through it. You know, at another point in time, I'll go through it in Italian and see if maybe it sparks something different or something new. It gives me a different way of thinking. Obviously if I can, what I try to do is actually talk about it with someone in two different languages and then try to see what comes up. But even just thinking about it in these two different languages, many times could spark something new that you hadn't thought about in the other language. So yeah, that can be a disadvantage that you use to your advantage. So that's it. These are some disadvantages of being bilingual. Once again, being bilingual is a tremendous advantage. Of course it's an advantage. And if you have a chance of being bilingual or, you know, of learning a new language or if you're wondering about it, then yes, you should learn a new language. It always helps to learn a new language. And so, yeah, it is a tremendous advantage. But you've heard about all these advantages. So I just want to talk about some of the quote unquote disadvantages. All of these to me are quite small disadvantages and kind of just, you know, the price you pay for having that huge advantage of speaking another language. So I don't think they're much to worry about but with something I get to whine about, I guess. And there are things that come up every now and then and, you know, that we have to deal with if you have more than one language. And so, yeah, if you know of any other ones, feel free to let me know. And if any other disadvantages come to mind, I'm sure there are other ones. And, you know, everyone finds themselves in different situations, especially depending on what language combination you have. So, yeah, I hope you found this useful and or interesting. And don't forget to click like if you did and don't forget to subscribe if you haven't. And I will see you on the next video. Thanks, bye.


Hello and welcome to the Grand Line Review, your source for everything One Piece. And today we are going to be giving our ever charismatic captain some always deserved focus.  Like the way he can just walk into any situation and boldly subscribe to the Grand Line Review, which results in regular One Piece content being uploaded straight into Luffy's YouTube feed. And I would highly recommend that we all emulate Luffy on this particular matter, maybe not others. But Luffy is a character who, against all odds, has been able to sustain the interest of readers and watchers of the series for more than two decades now, and you don't really get to that stage by being a simple meat nommer. Luffy's intelligence may be, you know, questionable, but as a result, he has a special brand of thinking that no one else could ever hope to invoke. And with this unique brand of thinkery, Luffy perpetually shatters even my expectations and I've been reading the series for quite a long time now I'm old. But Luffy just keeps pulling off stuff that I'd never dreamed he'd be able to do. And I assume that's because I don't have access to that special Luffy brainwave. And yeah, not all of these decisions end up working out wildly well for our captain, but for the most part, they generate just enough chaos or are a straightforward enough approach that often it ends up being the exact right course of action at any given time. And so today we are here to highlight those moments, many of which encapsulate the sheer charm that is One Piece. So with that out of the way, let's begin. Welcome to the top five times that Luffy shattered your, or at least my expectations in One Piece. Number five, accepting Robin's invitation to join the crew. So we are going to kick off this list with some super classic One Piece. And you know what? This moment may actually be so ancient that people have long since forgotten that this interaction was shocking in any way. However, when you look back on the context of the alabaster arc, one does need to highlight the masterful way in which Oda masked Robin's eventual joining of the straw hats. And it was all thanks to a certain Nefertari Vivi because our eyes were focused on her. We just bent an entire saga fighting to save her kingdom. And if the established formula of One Piece was going to continue, then Vivi was most certainly going to be the next official crewmate. But then Oda pulled the old bait and switch, leaving our ever determined princess to rule her lands and leaving us with the consolation prize of a former antagonist to board our ship. But of course, the reason why this moment is on this list is obviously all about Luffy's reaction in which he did after briefly hearing Robin out, immediately accept her request to become a crew member because, and I quote, she's not a bad person. And in retrospect, we obviously all know that, but at the time, there were some pretty dark clouds surrounding Nika Robin. But none of that mattered to Luffy because his incredible mind saw Robin in her simplest incarnation. And so he just decided to say, sure, why not? But this was also quite remarkable because it was the first time that someone had joined the crew without Luffy having invited them. Which is why I will insist that this is a brilliant point in history where Luffy just up and shattered our expectations. And compared to everyone else who joined the straw hats, this was just so easy. Robin put forward a demand, Luffy accepted it and history was made. Number four, leaping straight into combat against Kaido. All right, now we are cutting straight from Alabasta to modern day events to the climax of Act One of Wano which sees a dramatic reveal of Kaido's dragon form as well as a terrifying demonstration of his supreme power, which immediately made clear if it wasn't already, exactly why Kaido was considered to be an emperor of the sea. But as per usual, none of that mattered to Luffy because he made an instantaneous decision to swoop on up and hit Kaido in the dragon noggin because he was being a bit of a prick. And this moment was shocking primarily because of how it was portrayed in the manga and there is a huge difference in the anime and manga which I suppose we will go over because that's what I do. Basically in the manga, Kaido performs his borrow breath then we see a brief reaction of Luffy looking from afar and the next time we see anything from Luffy he had appeared right above Kaido to smack him in the head. However, in the anime this action was shown in its entirety, we see Luffy's shocked face and he gets all angry which is kind of out of character for Luffy and we track him running towards Kaido which ruins the eventual surprise of seeing Luffy strike the emperor out of nowhere because it's not out of nowhere and we've known for like two minutes at this stage that this was exactly what he was going to do but I really cannot emphasize the effect this had in the manga enough. It's not that it doesn't make sense for Luffy to launch into conflict with an emperor because we did see that on Hawkeek Island but Oda had set it up narratively that that was the last thing that we as readers were anticipating in the chapter. You know, here we are, we've only just landed on Wano and already Luffy has caused unprecedented chaos by tackling the big bad of the entire arc. A classic Luffy maneuver right here, devoid of any real sense, logic or planning and hey, this is one that didn't work out too well for Mr. Captain although as with everything in one piece in the long run it certainly did. Number three, declaring war on the world government. Moving to the glory days of any lobby now and by the time that Luffy had reached Robin via invading the island and defeating a member of CP9 or on his own you would have thought that this was about the most shock that he was capable of generating. I mean, this was I think the first example of the straw hat straight up raiding an island and it was incredibly exciting but Luffy was going to take things a big step further as when facing the reality of not just CP9 but having the entire world declare war on him Luffy instead decided to take some initiative and declare war on the world first and while in the end it achieves the same outcome it does so with significantly more style and flair and not only that but it sent a powerful message to Robin that her crew was not afraid to make the entire world their enemy just so that they could have her back which was very powerful because Robin's life story was about the world being against her and this is also another one of those situations where this event might be so old that people have really forgotten its initial impact because before now Luffy and the straw hats were still small time pirates. I mean, yeah, Luffy had beaten a wall out of the sea but it didn't earn him all that much recognition in the grand scheme of things.  This was quite the boss move and without a shadow of a doubt one that shattered all expectations that I had of Luffy at the time. Number two, punching a world noble. All right, here we go. I feel like many of you are probably expecting this and for very good reason because it is one of the most incredibly satisfying events to have ever occurred in one piece and even knowing Luffy as well as I did by this stage I still did not expect him to go quite this far and it's actually very interesting because weirdly enough this one simple punch held far more power than even declaring war against the entirety of the world government as we have just seen on any subbie. I mean, striking a world noble was a serious enough offense for a marine admiral to be immediately summoned to take retribution upon the offending party and as we know, Luffy is always the offending party and I guess it's not that we didn't know this going into it but Luffy knew the risks of what he was doing and he did it anyway because Luffy and by this time you'd think that we could have predicted behavior like this but I guess just because of how high the stakes were this time around, there was a sense of no not even Luffy could go that far. It would put a target on his head that would probably destroy the entire crew which very well did as it was directly responsible for the decision to separate the crew for two whole years and I guess, yeah, that all worked out for the best in the end which means that yes, we do get to have our cake and eat it too.  So well done Luffy. However, this is not what I would call the most shocking action that our captain has ever performed but just before we get to that though I'd like to briefly go over some honorable mentions because really just about every action that Luffy performs in one piece is shocking to some degree, even if it may not necessarily be worthy of adding to his official CV and we have some very simple examples of this such as the very dawn of one piece where Luffy was talking to Kobe and then just blatantly stated that he doesn't like him. This was one of the moments where I knew that one piece was something different and not necessarily representative of the goofy aesthetic that the series presented but you also have a number of fantastically hyped moments of decision-making from the straw hat captain including when on punk hazard he very readily accepted an alliance with Trafalgar law despite being told that these things generally end in betrayal and this attitude would also be taken into the Hawkeek Island arc where he temporarily joined forces with the fire tank pirates and both of these situations are ones in which I feel the most boring logic driven captains would come to question how wise such courses of action would be but not however wonderful Luffy and then there's the examples of when Luffy is just incredibly bold like when he decided to invade impaled down alone in order to save Ace because that's right Luffy was prepared to take on the entire prison complex all on his lonesome because that's what he wanted to do at the time and you can really look to any saga any arc, any interaction really and find an example of Luffy invoking his bizarre left field thought process but I can't think of a better example than today's number one which is announcing that he will become the pirate king while standing right next to the strongest man in the world and promptly telling him to shut up. Oh Luffy your ignorance never ceases to amaze me but this interaction is solid gold and it starts out with Luffy defending white beard from an attack launched by one so crocodile which is already kind of shocking the idea that Luffy feels that he needed to protect this guy from someone like crocodile and look if it wasn't Luffy this could probably be taken as an insult and that's before we get to the literal insult that Luffy throws white beards way because yeah Luffy decides to be something of a smart ass as white beard politely notes that Luffy's straw hat looks an awful lot like the one that used to be worn by redhead shanks to which Luffy replies in his best teenage voice oh you know shanks yeah I'm holding this hat for him which once again if this was anyone else I feel like they would have received a guru guru infused smack down but this is not the crowning achievement of this interaction because white beard takes Luffy's insolence in his stride and then warns Luffy that he is out of his league on this battlefield to which Luffy replies and I quote, shut up that's not for you to say I know you're trying to become the pirate king but I'm going to be the pirate king not you and there you have it not only did Luffy just tell the strongest man in the world to shut up but he also claimed that he would surpass him to become the pirate king and I really don't know how much more Luffy you can get than this to stand right next to quite possibly the most undisputed individual source authority on this planet and proceed to talk smack is the paramount example of why I love this character there is no force on this planet capable of keeping Luffy in line not the Marines, not the government not the overlords of the world at large and not even the most physically powerful individual that one piece has to offer in my eyes Luffy is less of a man and should more technically be considered some kind of natural disaster because he is completely uncontrollable and it will often result in untold destruction that ladies and gentlemen is our captain and until the day this series ends I am convinced that he will only continue to shatter our expectations but what do you guys think? Please do leave your thoughts down in the comments below or even join my discord server and if you're keen for some more One Piece content then please do go and check out some of my other videos or even subscribe to the channel for regular One Piece glory to live it straight until YouTube feed but for now this has been the ground line review and I'll see you next time.


And I think the microphone is live. So OK, well, welcome to a session on supporting virtualized telco functions with OpenStack. I'm Bruce Davy from VMware. I work in our networking and security business unit, which is the group that brought NSX to the world. Some of you may have heard of that product. And I've been working at VMware for a couple of years now since I came in when VMware acquired Nasera. Hopefully some of you heard of Nasera as an early startup company in the space of software to find networking. And before that, I was a networking guy in Cisco for a long time. So I've been doing networking in the sort of telco space for quite a while. And so what I want to talk about today is how we're attacking the telco space from a perspective of virtualization and how that fits into the bigger picture with OpenStack. Maybe I'll ask a few questions to the audience. So how many people here have been sort of following NFV for some time already? OK, so maybe two-thirds of people who have some NFV familiarity. So the first part of this presentation will be maybe a little bit of recap for you folks. So what I mostly want to focus on today is the networking aspects of NFV. And it's a little bit confusing that NFV has network in the name. But in fact, when a lot of people think about NFV, the first thing they think about is actually compute. So they say, I'm going to take some function that was previously implemented in some box, and I'll move it into a virtual machine. And hey, Presto, I've done network function virtualization. And so I guess if I only convince you of one thing today, I just want you to think about NFV as being bigger than just taking things out of a box and putting them into a VM, that there's a larger component around particularly virtualizing the actual networking components. And that's what I'll spend a lot of time talking about today. So sort of bullet two here is talking about how network virtualization fits in to the NFV landscape. And then as we start getting into some of the slightly more detailed parts of the presentation, I want to talk about service chaining specifically. Service chaining turns out to be something that has a lot of application in the telco environment. You want to be able to create some customized collection of services for a customer. And that entails functions that might be implemented in different virtual machines or different boxes being connected together to some kind of chain. So I'll talk about sort of what are the problems in that space and how we're tackling them. And I'll at least make the assertion that some of the things that you would like to be able to do with service chaining are actually not that well supported by Neutron today. And so there are some of the things work well, some things there's probably room for improvement. I'm not a Neutron developer or even particularly a Neutron expert, but I've at least spent enough time looking at what you can do in Neutron to sort of see where it does and does not line up with objectives for service chaining. And then I'm going to spend the last couple of minutes just talking a little bit about OVN just because it sort of fits into this space a little bit and it's just, it's a super exciting development in the space of virtualized networking. It's much more broadly applicable than just the telco space, but it definitely fits in here. And I just wanted to mention that it's something that some of my coworkers are driving the charge on. How many people went to the OVN talk on Tuesday? Just a handful of people, good. So you people, you won't learn anything new from that last bit but for the rest of you, I'll just cover it real quick. Okay, so let's launch in. This is one of my favorite pictures about NFV. This actually comes from a pretty old white paper produced by Etsy, a bunch of people got together and started fleshing out this NFV architecture. And I think I first saw this paper sometime in 2012.  And I actually know what almost all of them do, which is not always the case when I look at a picture of telco equipment. And so you notice all of those boxes, they come in different shapes and sizes and they're sort of vertically integrated. They're kind of like the mainframes of the telco industry. And then if you look at the right-hand side, this is where we want NFV to go with taking all of those sort of siloed, vertically integrated boxes and moving them into a much more kind of cloud type of architecture where we use standard high volume servers, storage and networking, and run all of these functions as virtual appliances or virtual machines or maybe even containers, but some kind of virtualized form factor on top of standard commodity stuff. And so for people in the OpenStack community, the sort of the right-hand side should hopefully look pretty comfortable and familiar. And what we're trying to do in some respects is help the telco industry sort of move from what is really a very sort of 20th century architecture to something that is much more contemporary and leverages the technologies that we have today. I have learned over years of talking to telco people, you should never say to a telco person, oh your problem is just like this enterprise problem that we already solved. But there are a lot of similarities and we are definitely trying to leverage some of the capabilities that we've developed over the years for enterprises and public clouds. And so now there's a lot of reasons why telcos are pretty excited about this kind of shift. By the way, how many people here actually work for a telco? Okay, quite a few. So hopefully some of this will ring true. Obviously telcos are under lots of competitive pressure and there's a lot of reasons why this sort of moving to a more cloud-based architecture would be a good thing. So in maybe no particular order, if you think about rolling out services as a telco, you really don't wanna have to go and dedicate a box to a service. Because over time that service is gonna become either more or less popular. If it becomes more popular, you're gonna have to buy more boxes and then at some point it becomes less popular and now you've got boxes that you can't do anything with. Much better to have a pool of capacity and then deploy services on top of that capacity and increase the amount of capacity you allocate to a particular service and do that in an elastic way. And so you can now sort of think of your services as being decoupled from your hardware and that maybe the demand for a service even fluctuates on a minute-by-minute basis so you can allocate more of your generic compute storage and networking resources to the services that need it. Another big issue is how long does it take to deploy a new service? When I first started working on network virtualization, the number one reason that we found ourselves getting into conversations with customers was that they wanted to be able to virtualize their networking and deploy network services as quickly as they could deploy virtual machines. This is very much the case for telcos. The time to deploy a new service in the telco environment is often measured in years. So to be able to get it down to more of the kind of, I'm just gonna install a bunch of new software who are running virtual appliances and spin them up in a highly automated way is obviously very attractive. And then finally, in order to sort of provide more differentiation, it'd be really great if you could customize the services to different customers. So then instead of saying, okay, here's my service take it or leave it, you can say, okay, you know, Mr. Customer type A, you get this sort of very premium fancy bells and whistles service and Mr. Economy conscious customer, you'll get the more basic and less high frills kind of service and be able to do that in a way that doesn't require me to have a lot of different processes for those different services. So that's kind of all of the aspiration. And the thing I didn't mention on this slide is of course cost. And I kind of leave that off just because, A, it's kind of obvious and B, I think it's a mistake to focus only on cost.  And so while it is important to control cost, I think it's important to focus on the benefits in addition to just driving down cost. But obviously, you can't afford to ignore cost in any case. So this is another slide that's pretty much stolen from another Etsy white paper of sort of overall NFB architecture. And just kind of, again, I kind of liked this picture for a couple of reasons. One reason being that even though a lot of people kind of over fixate on taking what used to be in a box and putting it in a virtual machine and declaring success, what we actually see in this picture is this virtualization layer, what's labeled NFVI on network function, virtualization infrastructure has virtual compute, but it also has virtual storage and virtual networking. And then sitting underneath that, you have the physical infrastructure, compute storage and networking. Above that, you have the virtualized functions. And so a virtualized function would be something like a virtualized firewall or a virtualized instant messaging system. Any of those things could run inside of VNF. And you can think of those as basically applications running in VMs. And then you have to manage those things. So you have VNF managers. You also have to manage the infrastructure and you have to orchestrate the whole thing. So it shouldn't take too much of a stretch for you to see how OpenStack sort of fits into this picture. Your OpenStack actually plays a lot over on the right-hand side here in terms of orchestration and also infrastructure management. And then if you kind of zoom in on the virtual infrastructure layer, you see kind of pretty good mapping of some of the components of OpenStack with Nova for compute, Cinder or Swift for storage and Neutron for networking. And it's that third piece, the networking piece that I'm gonna focus on in the rest of this talk. So I wanna stress again that network virtualization is a different thing from network function virtualization. It's an unfortunate sort of collision of terminology, but network virtualization is what we do in the other product that I work on NSX. It's what Neutron provides in OpenStack. It's essentially about providing virtualized networking capabilities in a cloud data center. Network function virtualization is taking things like firewalls, voiceover LTE systems, all kinds of telco functions and virtualizing those comprehensively. So it's more the NFV is kind of an architectural shift from a siloed architecture to a cloud architecture. Network virtualization is a component that lets us provide virtual network services in the way that Neutron does. So at least for the purposes of this talk, you can think of NFV as the big picture and network virtualization as one component within that picture. And the reason that we need network virtualization, first and foremost is that this whole system has to be agile. So if you're going to make this successful, it can't take you as long to provision a new service in the new architecture as it takes to provision it in the old architecture. And a good example of this is when we first started working on network virtualization sort of back in the, I guess late 2000s, like 2008, 2009, lots of people thought they were going to go and stand up a public cloud service and compete against Amazon. And so they would figure out some way to virtualize compute, some way to manage the virtual compute, and then they would find that they couldn't actually automate the provisioning of virtual networks. That was actually the problem that got Neutron started and it was the ability to fully automate the provisioning of virtual networks that led to our network virtualization product and also to ultimately the creation of Quantum and then Neutron within OpenStack. So making the whole thing agile and easy to automate is really critical. The another really important point is you need multi-tenancy in these environments. You're carrying the traffic for potentially hundreds of millions of customers, they're not all getting the same services. So you need to have some mechanism for providing multi-tenancy. You might also have different organizations within a single telco having control of different resources. So multi-tenancy comes up a lot and again, that's something where it's really hard to do that if you haven't virtualized the network. You want to have network services that are independent of the underlying infrastructure. So for example, if you want, say, logical routing between certain parts of a service, you don't necessarily want to have to go and go through a physical router and you don't even necessarily want to have to go to a special virtual machine to get that routing function. It would be better if that was kind of built in to the network virtualization layer. And then finally, service chaining, the idea of taking multiple different services, sorry, multiple different functions and composing them into an actual, useful end-to-end service. You want to be able to do that in a fairly dynamic way. So to be able to say customer A is gonna get a firewall and a NAT and a load balancer and customer B is gonna get a video optimizer and some other function and we're gonna put those different classes of traffic into different service chains. That's gonna be much more easy to do in an agile way if you have some software layer to stitch these functions together. So here's a fairly standard picture of what Neutron looks like, hopefully not too many surprises there.  And then over time, there's always a set of core APIs that let you access the kind of core Neutron services. And then you tend to see these API extensions because there are all these different pluggable backends that offer different types of service. So the product that I work on NSX provides its own pluggable backend which sort of replaces the sort of default plugin for Neutron and lets you get access to the networking features of NSX. Some of those are core Neutron features, some of them are accessed through the API extensions. And so anyway, Neutron essentially lets you perform all these network functions by calling APIs and then there are various different consumers of those APIs that basically let the overall open stack system create services that contain networking components. Okay, so what are people actually doing with NFV? So part of my job is I kind of go around and talk to our Tolco customers and try to figure out what they really want to do with NFV. And while there is a lot of aspiration around NFV, there's two use cases that seem to come up again and again that we're actually seeing people put into pilots and early production. And essentially these divide between two different types of operators, the mobile operators are mostly focusing today on how to virtualize their Evolved Packet Core. And the Evolved Packet Core, I've got a picture coming up in a minute, but you can basically think of it as a set of functions that are responsible for getting packets from your mobile handset off to the internet and doing a bunch of things like making sure you get the right services based on your data plan. And then there's, so we see that as kind of one very popular use case and there are some pretty big trials going on around the Evolved Packet Core. And then the other one that we see a lot of for the operators who are fixed or wire line is doing some kind of virtualized CPE. So taking a set of functions that would have normally lived in a customer premise device, functions like firewalling, routing, maybe some encryption, those kind of functions, instead of doing it in a CPE, moving it into a virtual machine is actually operated by the operator and potentially not even on the customer premise. So just to go into these in a bit more detail, here's a picture that I borrowed from somebody who actually understands mobile networks. And the main thing to see here is that on the left-hand side, you've got the radio network, that there is actually some work on doing virtualization out there, but it turns out to be fairly difficult to virtualize things out in the radio. So typically you have the radio network and then coming out of the radio network, there are a couple of interfaces that deliver effectively packets into this Evolved Packet Core. And a bunch of stuff goes on in the Evolved Packet Core. I don't need to belabor that, but it's things like figuring out who you are, figuring out if you're authorized to get types of service, and then applying the correct services based on that information. And then ultimately, you wanna get a connection to the internet or to some other data service, potentially a corporate VPN. So there's a bunch of stuff that goes on in that Evolved Packet Core, and that's a sort of a standard telco architecture, and the thing you see there is quite a few different functions or traditionally implemented in different boxes. And then I mentioned the virtual CPE. So virtualized CPE is taking functions that you'd like your customer to have in which he or she might expect to have running on their premises, but actually hosting those in a virtual environment. And somewhat confusingly, it's not just a matter of taking things that lived on the customer premise and sticking them all inside a virtual machine. It's actually taking those functions and moving them into the cloud somewhere, typically into a data center that's run by the telco operator, and then you can run them inside virtual machines. So you still have to get the traffic from the customer premise into the data center somehow. Maybe you get it in over a L2 connection, maybe you bring it in over an IP sec tunnel, somehow you get the traffic from the customer premise to the data center, but now all of the complicated services that are somewhat custom and that would traditionally have required configuring a box on the customer premise, all of those functions now get moved into a data center where they can be provisioned in software, automatically by software. So this is actually a very compelling use case for how NFV can make an operator more agile because now they can change the services that a customer gets very, very rapidly without him to go and visit the customer and reconfigure their equipment. And in this environment, network virtualization plays a pretty important role. So if you look at network virtualization solutions, they come in a few different flavors. Most, well quite a few vendors now have a network virtualization solution and some of them have just L2, some have just L3, some have a mix, some have firewalling. So those are what I call the native network services that kind of come as part of your network virtualization solution. So you're gonna get some of those services which for example, if you have a distributed firewall as part of your network virtualization solution, then you could offer firewalling services to the customer directly. As opposed to the picture up on the top there kind of suggests maybe running a firewall inside a virtual machine. And there's maybe a bit of subtlety here, but you can always run stuff in a virtual machine and make that a service available to a customer, but you don't necessarily always want to do it that way because of scaling issues that it's often quite a bit more efficient to actually make it sort of part of the virtual infrastructure layer. Clearly, I've mentioned that you wanna be able to do this in a very agile way. And so if I bring up a customer and that customer needs five different functions, I'm gonna need to spin up a bunch of VMs, connect them together into a service. That means providing networking connectivity between those. And I wanna do all of that without actually going and touching a networking device. I don't wanna go and have to configure VLANs or access control lists or any number of bits of hardware. I'd like to do this entirely in software. I think I mentioned multi-tenancy already. And this is now starting to get us into the topic of service chaining. So that picture on the top there is a very simple service chain. And in the next slide, I'll go into some more detail on service chaining. And then the other thing is, this is all pretty much independent of my underlying physical network topology and it's also independent of location. So I can now offer these services to a customer pretty much anywhere I want, subject perhaps to latency concerns. But so moving away from the old model where I would have had to say, I have a certain set of functions that are actually located in boxes that are sitting somewhere. Now I can actually move these functions around very freely. And anytime I move a function, I want it to stay connected to the other functions. So that means I need the networking to be agile as well. So I know there's, I guess a decent amount of information in this presentation, I hope there is. But so I just wanna stress again that if you only take away sort of one or two things from today, I think a good part of what I'm trying to get you to understand is sort of how central the neutron and virtual networking piece is to this whole landscape. So now I'm gonna sort of go into part two of the talk where I'll go into a bit more detail on service chaining. So that picture at the top you've already seen, it's a chain of services. And it's actually what I consider a kind of trivial service chain. And a better example of a service chain would be something like this one down the bottom, which you'll notice is actually not a chain, it's more of a sort of a general graph. And that's really a better way to think about service chains. They're really graphs of services. And this is an example where the first box in the chain is doing classification. So now I'm gonna figure out what kind of user does this traffic belong to? And based on that classification, what set of services will I give him? And then based, I'll either take the upper or the lower path through those services to try to give something sort of custom to this class of customer. Creating that kind of topology of services, this is basically bread and butter for network virtualization. If you think about what does Neutron do? What does network virtualization do? It basically lets you create topologies amongst virtual machines. So if you think of each of those VNFs being a function implemented in a virtual machine, a firewall, a NAT, a load balancer, a WAN optimizer that all I'm really doing with network virtualization is creating this topology. But I can now do that in an automated way and with high agility. So I was chatting with one of my colleagues just during the break and he said, so what's actually hard about service chaining? What's the big deal? And I think what turns out to be difficult about it is, I mean, none of it's rocket science, but the hard part is ultimately about efficiently providing customized services and making sure that the packets go where they need to go. Traditionally, that was done by manually stitching things together, using things like VLANs and routing to steer the packets between a set of boxes. So if you think about what we need to do in this fairly simple example, we need to classify the packet and the classification could be drawing on quite a lot of data, some of which may not even be present in the packet. And at some point we've classified the packet and we figured out that it needs to get some sort of service. So what we really wanna do is store the result of that classification with the packet so that we don't ever have to classify it again. That's a classic example of metadata that I wanna carry something with the packet that tells me something about the packet that I can't actually figure out by looking at the packet. So if you look at sort of where the arguments are heating up about how to implement service chaining, they tend to focus on how we carry metadata. And if you look at VXLAN, which is the kind of the de facto standard for building network virtualization overlays, it actually doesn't have a good place to carry metadata. There's kind of some sort of hacky ways that you can carry it, but there's no kind of good general purpose way to carry metadata in a VXLAN header. And so we've done some work on suggesting other ways of carrying this metadata. There's another packet format called Genev that we're working on. Again, I don't need to go into details, but just to say that's kind of one of the core problems is I wanna carry information about the packet all the way through the service chain. And you could even imagine like after the packet goes through VNF3, that chain could diverge again based on the class of the packet. So I might need to carry that metadata sort of all the way through a very long and complicated chain. So that's pretty critical. There's another piece to this, which is that even though I'm drawing these chains as pretty simple things, if you're gonna do this at scale, then you're gonna have to probably have multiple instantiations of these virtualized functions. So say that firewall function up the top might actually be implemented by 10 or 50 different virtual machines. So I better have a way to load balance the traffic across that and I better have some kind of high availability story about how I deal with the failure of some kind of service. So those are the kind of things which I think need to get tackled in service chaining. And as I've kind of alluded to, some of them are pretty straightforward today. Building topology is not that hard, but carrying metadata, dealing with some things like load balancing, not entirely cooked today. Here's a pretty useful reference if you wanna read more. That's from the IETF. It's written by a group of operators and vendors talking about how to do service chaining in a mobility environment, like the Evolve packet core. Here's another service chaining example. This is taken out of something that we do in the NSX product. So the top picture is what you'd like things to look like logically, things going between a couple of different virtual machines, going through a router and also getting firewalled along the way. And then down the bottom is the sort of physical picture of how we'd like things to look. And so the sort of, I'll just back up a second. The sort of interesting thing here is that when traffic goes from, say, the web tier to the app tier, you don't just want it to follow the shortest path. You actually want it to follow a kind of non-obvious path through the firewall. So that's another example of something that's kind of critical in service chaining. You should need to be able to redirect packets into functions that might not actually sit on the data path for those functions. And that again can be done pretty straightforwardly by using overlay encapsulations, but it can also be helpful to have some metadata to make sure that packets that need to go on this detour get there and others that don't need to get there don't get there. And then one of the things that we've implemented is we have a firewall that sits inside the hypervisor kind of as part of the V-switch. So we do firewalling on traffic as it goes directly from the web tier to the app tier, but we also have the ability to selectively redirect traffic to a third party firewall. So we can do kind of basic firewalling in the V-switch and then more advanced firewalling in a virtual machine. And we don't send all the traffic to this third party firewall but only a subset of it. And so this is another example of kind of non-trivial service chaining where even packets from a given customer might take different paths based on something that's either in the packet or in the metadata surrounding that packet. So that's kind of service chaining. And I noticed we're getting close to Q&A time here, so let me speed up a little bit. I just want to point out that so some of this stuff is just very basic neutron like building topologies. Neutron's really good at building virtual topologies, it gives you all the ability you need to do that, and it does some amount of service insertion for things like load balancing and firewalling. This is not really a complaint about neutron, but there's not a general purpose way to express that I want to attach metadata to packets. Part of the reason is because there's not even a general agreement on how to do that in the networking community. And then some of the ways of inserting services, like inserting a service that's actually not in the data path for a packet. As far as I know, that's not supported in Neutron today, and nor is the idea of like, selectively directing packets to a service. So that was kind of my quick summary of like, if we're gonna actually make this stuff really work with OpenStack, there's some opportunity here to extend the sorts of things we do in the virtual networking layer of OpenStack. So the very last thing I want to do is just my quick advertisement for OVN. So OVN is pronounced OVN, hence the logo kind of looks like an OVN, and it's built on top of the OpenV-Switch project, which hopefully you've all heard of. So what do you need to know about OVN? From this presentation, not very much, except that OVN provides a open source virtual networking layer that is basically targeting OpenStack environments. It's targeting a few other environments, but so you can think of OVN as a new option for providing open source virtual networking in OpenStack environments, which is clearly applicable to everything I've talked about. It's gonna support a whole lot of different capabilities like security groups, ACLs, logical switching and routing, can be mapped onto different types of overlay, and will support all the kinds of environments that OVS works on today. And so if you were one of the fortunate few who put their hand up, you could have seen a demo on Tuesday, and since many of you didn't put your hand up, that presentation has been videoed, and it's listed down there, OVN native virtual networking for OpenV-Switch. You can also, if you're that way inclined, get involved in the development of OVN. It's being done as a sub-project within OpenV-Switch, and you can download the code and all kinds of stuff. You can read a blog about it. So that's kind of all I wanted to say about OVN, but I think it's actually a really exciting development given that when here's a lot of negative things about neutron networking, at least I've heard quite a few this week, and I think often people conflate all these different components of neutron, and so we actually have tremendously successful customers running on top of neutron on top of NSX, but most people probably don't run neutron on top of NSX, they run neutron with say the standard OpenV-Switch plugin. Here's another attempt at least providing an open-source plugin that could be very scalable and robust for neutron. So to sum up, there's a lot of thrust behind NFV. So this is kind of the old joke that with enough thrust a pig will fly. That may or may not be appropriate in this environment, but there's definitely a lot of people who really want to see NFV succeed. I would count myself among them, but certainly our largest telco customers really are betting very big on this. I'm actually pleasantly surprised at how well NFV has taken off, that there was not that much incentive for traditional vendors to jump on the NFV bandwagon, but they seem to be responding to the wishes of their customers in a fairly encouraging way. So the big thing here I think is all about agility, about getting new services out quickly and also making it easier for Operator A to be differentiated from Operator B. There is some amount of cost driving this, but I don't think it's the only thing to focus on by any means. There's actually a lot of overlap, or certainly a lot of interest in OpenStack, from the NFV community. That's kind of interesting because, you know, I think most of you would probably agree that OpenStack is kind of not for the faint of heart, that it requires a fairly high level of sophistication, and I think a lot of the telcos are just effectively saying, you know, we're gonna make the investment to become OpenStack experts because we see it as the best thing out there for managing these kinds of sort of cloudy environments. I didn't really talk much about this, but NFV is really about moving away from siloed architectures to more open architectures, and one of the things we need to be very careful of is that we don't end up in just a different set of silos. So if today, you know, I sell traditional telco equipment, and tomorrow I stick it in a virtual machine and then put a hypervisor underneath it and bundle the whole thing up and sell that on my own hardware, I've only replaced one silo with another and inserted the extra cost of a hypervisor. So that's kind of not a good outcome. So what we really need is more kind of open horizontal architectures. That's kind of the approach that we're taking in the work that I do at VMware. It's also the approach that the OpenStack community kind of broadly takes. So I think that's another reason why OpenStack is so interesting for NFV. And I think I hammered this point enough now is that doing NFV, it's not just about virtualizing compute. It's about virtualizing everything, and that means networking and storage. And so hopefully I've made that pretty obvious and you can get a sense of what it's gonna take to make NFV successful. So with that, I'm losing my voice, but thank you for your time and I'm happy to take a few questions or applause if you prefer. Sorry, that was horrible to have to beg for it, but sorry, anyway, question there. So quick question. You talked a lot about service chaining and the need for metadata. I think there's been a lot of work that's been done on a network services header. And I know if you wanted to comment on that and how your system kind of or the way you approach that here. Yeah, so the network services header is I think a good example of one of the approaches to carrying metadata. I think it's basically work going in the right direction. And essentially we're at that sort of stage. I spent many years going to the IETF and I don't go as much as I used to, but we're sort of at the stage now of arguing about exactly where the bits go on the packet as opposed to the overall structure of information. So I'd say that's kind of a good thing. Great, okay, I'd like to see that there. Other questions. I was told to allow time, but that's super quiet audience. Was it all crystal clear? Awesome, awesome. All right, here's the question, okay. Yeah, so I'll just repeat the question for those who didn't hear it. So the question was, given that there are already some open approaches to doing virtual networking, why do we need another one? And I think that there was a sense that we needed to, you know, open V-switch is still the most popular, you know, the most popular V-switch in OpenStack environments. And we wanted to make Open V-switch kind of a first class candidate for virtual networking in OpenStack environments. So we kind of looked at this as not so much, let's go and build another virtual networking solution so much as let's incrementally grow the capabilities of OVS so that, you know, one of the reasons why people have had mixed experiences with Neutron is because the default OVS plugin kind of not that great. And so having something that's more robust as the default would, I think, be a big win. Other questions? Okay, we're gonna take a follow-up from the front row here. So the question was about, can you pass VLAN tags all the way up to the guest with OVN? I don't know the answer to that off the top of my head, but I know that adding such capability would be pretty straightforward. So whether it's getting done, like there's a long road map of things to do with OVN, but definitely that could be done. Okay, if there's no one else, here we go, one last one. Yeah, I was wondering, any estimate on when the optimized version of the OVS would be out? Sorry, could you repeat that question? Any estimate on when the optimized version of the OVS? So when you say the, so the question is, when will the optimized version of OVS be out? So are you talking about any particular optimization because we're kind of optimizing it all the time? So it would be the DPDK version. So the DPDK version of OVS, I mean, as far as I know that's available today, that I'm not sure exactly what state of maturity the DPDK version of OVS is in, but there is definitely a version today. So that's a long discussion about all the pluses and minuses of DPDK, but in general, if you want it, if you have an environment where you need a DPDK optimized version of OVS, I'm pretty sure it's available today. Okay, well the question is getting further and further from my expertise. So it's a good time to stop. Thank you so much for your time.


Good morning members, officers and other members of public who are viewing the live streaming of this meeting. Welcome to this meeting of the Grants Advisory Committee. My name is councillor Sue Allington and I am usually the Vice-Chair of the Grants Advisory Committee. However, the usual chair, Councillor Jos Hales, is not with us today so I will be chairing this meeting. For the information of the public the role of this committee is to consider and make recommendations to the lead cabinet member for resources, Councillor John Williams, on applications made under the Council's Grants Scheme. Councillor Williams then makes his decision taking into account our recommendations. May I remind all those in attendance to keep their microphones closed to them and close to them and speak clearly throughout the meeting. Right, with item one, do we have any apologies Lawrence? Thank you Chair, just the one apology today from Councillor Jos Hales. Thank you. I can confirm that the meeting is quarreled. Item two is declarations of interest. Do any members have interest to declare in relation to any item of business on this agenda? If an item subsequently becomes apparent later in the meeting, please would you raise it at that point? Nobody speaks, that's okay then. Right, the minutes of the previous meeting. We have the meeting, minutes of the meeting held on 26th of October up for approval today. Does anyone wish to make any amendments to the minutes? And you haven't heard anybody? Right, thank you. The minutes, can I take the approval of these minutes by affirmation? Thank you. So the minutes of the meeting held on the 26th of October are approved. So item four is the six month progress report on the service support grants to the voluntary sector, which updates us on the progress of the programs funded by the Council in this financial year. I'll now hand over to Emma to introduce that report. Okay, thank you chair. So on page five, this service support grant report is for information only, it's an update report. Six month reports are requested from organisations who received £10,000 for more per year. So this report and report reflects quarters one and two this financial year. And there's three organisations that fit into this category. We have Cambridge Council for Voluntary Service, CCVS, they were awarded £11,400 per annum and that is for support for voluntary and the community sector. Second organisation is Citizens Advice, they are awarded £100,000 per annum for advice services. And then we have Homestart Royston, Buntingford and South Cambridgeshire, Homestart Cambridgeshire who are awarded £13,711 per annum. This is to provide early intervention, volunteer-led, home visiting support and specialised family support groups for vulnerable people that often have complex issues. So as far as offices are concerned, all three organisations are on track and achieving their objectives. Just want to quickly note on page nine within the Citizens Advice Agreement, outreach was suggested for locations where this might be best placed. We've had some recent discussions with their CEO and we've agreed that they will work with us to devise a plan of outreach in the six locations in the reports with sourced and continuing funded by the John Huntingdon's charity. And this will be either in-person sessions or online with a person on a screen on the other side. So that's just a little bit of further information and what we'll do is we'll also arrange another meeting in January 2024 just to monitor progress on that aspect of the agreements. I'd welcome any questions. Thank you. Excellent. I was very impressed with the reports I have to say. Any member want to have a word? They seem to have listened to us really. Yeah, they seem to be doing more in our district, which is very welcome. I was impressed that they are covering a significantly wide area of our patch and that they were seeing for the money that's available. It's not, I mean, it is significant, but for the money that's available, the case studies and so on are really helping people who need help. And I'm very aware that there are an awful lot of people out there who need help. Peter. Thank you, Chair. Yes, I'm always impressed with the capacity of citizens' advice to support so many residents. I know I've sent a couple of people to them in recent weeks for advice on various matters, so that's definitely money well spent, I think. Yeah. Welcome, Sunita. Sorry about that. It's fine. The traffic and the roads at the moment are not necessarily as easy. Yes, I was really impressed. And the home start in Royston covering our patch. Again, they really do play a significant role. I know it's not council's business, no primary business to help, but that's what we do as a district council to ensure communities and individuals within that community have as much support as possible. And I think we should go on doing it. And finally, the Cambridge Council for Voluntary Services. Again, a really good report, and it's well worth people reading it and realizing quite what they do and knowing where to go to get help for your residents as a council. So thank you very much for that. I'm a little concerned that we shouldn't move on to our decisions. Well, we will make our recommendations to him. So apologies have been received from Councillor John Williams. He's feeling unwell. So we will continue with the community chest grant funding applications. And no doubt he'll be able to look online and see what we said before he makes his decision. So Emma, would you like to take the first one from Water Region Land Beach Action for Youth? Sorry, can we just confirm on the options in the report that we're happy to note the progress of the funded projects? Oh, yes, I do apologize. And by the sounds of it, we don't need to highlight any concerns for further investigation or action as you're concerned. No, we're agreed. Thank you. Sorry Lawrence. Right, so moving on Emma. Just firstly, I'd just like to mention that two community chest projects have not progressed as expected. And as a result, this funding has been funded to us. That's £2,000 from Longstown to Grasshopper's Cricket Club. That's the whole amount that came back to us. And then £360 and 24 pence, which is part of the award that went to Cockwheel Counseling. So what we've done is we've added this to the totals for the general community chest fund. This gives us an updated balance of £21,027.45. We've received two applications this month, totaling £4,000. And yeah, so I'll just go into the first one, which is on page 27, which is Water Beach and Land Beach Action for Youth. This is a free youth club benefiting 136 young people aged between 11 and 16. It's open twice a week. And regular activities include sport, art and craft. And sometimes they put on additional activities such as music, tuition, youth social action and pastoral support. And funding is needed to run a cooking project once a week. That's for 48 weeks. This is for the years, seven and eight members on how to make nutritious low cost meals whilst utilising food that has been donated. Total costs for this project are £4,252.80 and £2,000 has been requested from the community chest. Water Beach Parish Council contributed £2,000 and Let's Cook have funded £250. Just to note that they received funding from us through Children and Young People's Grant. That was back in January 2022. And this was something similar, which was their creative cooking programme, which was open to all children. So this funding is more specific for years seven and eight. Thank you. Thank you. Any comments members? Peter? Thank you, Chair. Yes, this seems like a really good project. Those of us who attend the Climate Advisory Committee have heard councillor Dr Bhattacharya on several occasions telling us that people just don't know how to cook these days. And I think this is a good step to get the younger generation cooking for themselves, rather than buying pre-packaged food. So, yeah, I definitely support this one. Sneeta? I like this project because it just doesn't focus on how to cook. It focuses on nutrition and therefore I support it. Yes, I support it too. And it's good to see that the Parish Council there is giving substantial support. That's to be applauded too. Yes, I was impressed with that. And those of us who went to school some years ago and learned to cook, and we were at school, but perhaps not there. But there weren't quite so many fast food outlets at that time. I don't think, certainly not on the farm that I have done. So are we happy to agree this nods all around? Thank you. Yes, we agree that. Can we move on then Emma? Yep, page 28. This is from Social Enterprise East of England C. It was set up to promote and power connects and grow the social enterprise sector in our region. They benefit from wealth experience in this sector with experienced consultants delivering their research training events and other activities. And what they'd like to do is create a supportive network of social enterprises, also with other organisations and individuals. And this would basically create businesses as well as address local social challenges. They're already in contact with some local organisations that are familiar to us, such as CCVS and Camber to Acre. And they held their first engagement event in Camborn Community Centre that was a couple of weeks ago, which showcased businesses that are helping communities and how to support local residents in challenging times. And what they'd like to do is they've applied for £2,000. And this is for eight days of one to one follow up support for people that went to that event. And this basically runs one staff member at £250 a day to provide that support. I did go back to them and said, what exactly would you do within this support? And they've given us some examples, which would be including digital tools, working with some of our micro care enterprises, you might be familiar with as well, and various other support like grants, you know, who wants grant applications and things like that. So it's quite bespoke to that particular individual. Thank you. Thank you. Any comments from anybody? I suppose my first thought was social enterprises east of England, which seemed to be a very large area. And I wondered how and what evidence they had for focusing here and at Camborn to provide this service, if you understand me, why did they suddenly decide that Camborn was the place where they should be supporting and helping a community centre and getting things off the ground? And did they provide any evidence to show that it was a need? They haven't. But what I understand is that obviously this is one event that took place in the east of England. And this is what they would be doing in other areas as well. And this funding would go specifically towards organisations in South Cambridgeshire. So I could go back and find out a little bit more if you wanted me to, of course. It seems like an extremely good idea. I just thought they seemed to have sort of landed. Do you know what I mean? It troubles me a little. I mean, the idea is great. But follow-up engagements after the event slightly concerns me whether or not you should have been before the event. And can we monitor what the money is used for? Is that something that's possible? I'm not sure. I'm quite, I'm meant to be convinced about this. Did we have any support from any of our councillor colleagues for this? I don't believe Jane. I don't think no, not on this one because it's a general, it's not for a specific parish. So in those instances, we don't tend to do that. Yeah, I'm also sort of sitting on the fence this one. I mean, the line I'm looking at is catering £1,200. You can get a lot of sandwiches for that. I do, right? I think they just gave us a breakdown of everything, including what they needed for the event, but the specific funding this would go would be that one-to-one support. It's a follow-on support. There's a general reluctance here, and I think this is where we would have gone to John and said, how did he feel about it? Can we leave it with us being, having some concerns and perhaps wanting to follow up a little bit more specifically about why they landed on Campbell, and a bit more evidence about them and where they're coming from and where we're going to about it, and see, and also some feedback from John about how he feels about it. Yes, Chair, I think that's a good way forward. I mean, what probably concerns me most is, I mean, and I'm perhaps asking Emma this question, did they come to us in before the event for any kind of financial support? Because I'm slightly nervous about, you know, the things being done and gone, and now they want some money to follow up. And I just think that if they'd fully funded, if they had a fully funded event, that would have been part of the fully funded, you know, the funding. It seems almost an afterthought, give us some money. Yeah. And I'm just not comfortable with it. No. Emma? The application came on the 3rd of November. I think I believe the event was on the 14th, so it was quite, it wasn't that long before obviously the event, so maybe they only just found out about the community test. I don't know the whole reason why, but it was before. Yes. Everybody happy to defer at the start? Not a straight no, but definitely a defer. Okay. And those were just the two that we've got. Yes. That's one for the question. Emma, you say that we have two projects that we've returned the money. Did they give any reasons for this, or is it just? So, the Longstown to Grasshopper's Cricket Club, I think that was for netting, if I remember rightly, and I think they needed some permissions, and I think that was the problem, I think working with the, I think the parish council or somebody was against it, or it was a reason why they couldn't do it. Cogwheel counselling was a small proportion, because they were awarded 1,400 and 360 came back to us. I don't know the whole reasons, you know, why, but I think that they have continued with the project, but just a small amount had to come back, so. These things happen sometimes. Yes, yes. And you put in for a grant, but you also, at the same time, go through the process of getting permission from this, that and the other, so I can understand that. So, the next meeting is scheduled for the 25th of January, so I could wish you all a very happy Christmas, and say thank you very much, and that was the shortest meeting in history.