Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2018 (Seattle), 16 Dec 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Deep Dive: Network Service Mesh BoF - Ed Warnicke, Cisco & Frederick F. Kautz IV, Red Hat

Description

Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io

Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects

Deep Dive: Network Service Mesh BoF - Ed Warnicke, Cisco & Frederick F. Kautz IV, Red Hat

In this talk, you will learn about some of the Advanced Network Application Design Patterns that Network Service Mesh enables. Network Service Mesh (NSM) is a novel approach solving complicated L2/L3 use cases in Kubernetes that are tricky to address with the existing Kubernetes Network Model. Inspired by Istio, Network Service Mesh maps the concept of a service mesh to L2/L3 payloads. The NSM architecture can be naturally extended to allow interaction of the NSM with the physical network enabling cloud providers to offer value-add services like: Connecting a customers Pod(s) to a network egress specific to that customer Introspecting the Network Service Mesh control messaging to adapt the physical network to serve customer needs better. Allowing customers to request specific physical network services. The NSM community has developed several design patterns for solving problems in K8s that may be of utility to others working in other problem domains in K8s. This talk discusses those design patterns and their benefits.

To learn more: https://sched.co/Grdj

A

So welcome to the network service mesh deep dive, so this is where we pull back the curtain and show you the spider running the show. So if you haven't met us I'm, Frederick couch, this is Ed Warnecke and, let's begin so.

B

A couple quick things: if you have questions, ask them as we go, because if you have a question, somebody else in the audience is gonna. Have that question you do everyone a favor when you ask it so that's the first thing. The second thing is I will be asking you questions in the course of this talk and asking you to raise your hands just to get a feel for what's going on out there, and it's always good when doing these things to calibrate.

B

First, so quick show of hands how many of you can raise your hands.

B

Excellent cool now, there's one other interesting thing: I want to know because I got caught a little off guard, but this the last talk when we do the intro, how many of you are sneaky? Network people, ah okay, more than I, expected cool and how many of you were app people excellent. We got a good blend here, good blend, very, very cool. Now, how many of you guys mid to the network service mesh intro talk?

B

Okay, that helps because this is the deep dive we showed you how easy it is to use and how conceptually simple it is. Last time, as Frederic said, we are going to pull back the curtain and show you the spider, pulley lovers behind.

A

Great, so some some housekeeping, so you can reach the network service mesh cube con events page from this particular link, we're coming to the end of it. So we have only a couple things. Only a couple events left so but go ahead and take this. This will also take you to the network service mesh website. So you can see our slides and and other material that we prepared yeah.

B

What other thing to keep in mind? We will not be doing a demo this session, because this is the deep dive, but both Frederic and I still have demos that we're doing in the Red Hat and Cisco booths respectively. So if you want to get a little bit more of an intro and a little bit more of a demo, those are probably good places to go, get it cool, so the next piece of housekeeping.

B

If you want this slide deck that will take you to this slide deck it's on Google, Docs, I know people are often asking where do I get this slide deck. This is where you get this slide deck.

A

Highly recommend this one, so you're gonna see a lot of good information on here at how on how it works and so make sure you get a good picture. Cool.

B

Everybody good three.

B

By the way, for those of you give talks, nothing beats QR codes, we're getting an entire audience full of people holding up cameras.

B

All right going once going twice and here we go great.

A

So the problem: what is the problem so.

B

The problem is that we've got people who want things that look like this. This is kind of what your app developers one they want something where their pod is running. It does its thing. It gets its normal kubernetes networking, but maybe you need something a little bit more, something that kubernetes networking doesn't provide in this example. It would be a secure, Internet connectivity and you don't really want to think too much about that. You just want it to work and you don't even want to know what security is.

B

That's what you have net ops people for.

A

So this is this is what it looks like in terms of network service special. You saw this particular slide before you came to our intro, so you have a network service. You have the the connection. So if you notice services Sarah's pods, all she sees is the is the l2 l3 connects to to the network service.

A

Everything in the cloud is a cloud to her, so she cannot see what's what's inside that cloud other than the fact that she's getting her service, but as you can see inside the cloud we've actually chained, firewall, pod, VPN gateway, etc. So we provide a nice easy way to abstract this, but also get you. This still get you the details that you need.

B

So really quickly onto the solution, so the solution is this is the link to the network service mesh intro DAC. We will do a really quick run through of some basics here, just to set the tone, but we spent an entire talk talking through how this looks. It is simple to people to consume it, how it looks in as simple the people who operate it and all the rest of it.

B

If you actually go behind the curtain to see the spider pulling the lovers, it's a lot more involved, but we're going to do a really quick hum a few bars version here. All.

A

Right so a couple things to notice: we have a firewall pod, that is, has a label apical firewall and we have a VPN gateway pod that has an appt apical VPN gateway. So these are how we know what pod provides, which particular the aspect endpoint of that service exactly.

B

And then, if we get something like the firewall pod, so the firewall pod exposes the secure internet connectivity service, but it also consumes it, and this is super helpful because it makes your firewall pod can be dumb as a rock, because all it knows is it's applying firewall rules and there's going to be somebody who comes after it who handles other aspects of secure Internet connectivity? What those are it doesn't know or care, but how will it'll it hints to us? So we can apply.

B

Policy is when it asks for an l2 or l3 connection to the secure Internet connectivity service. It puts a label on that request, that is a people's firewall, so.

A

Yeah so rocks that connect as a firewall. It's pretty smart Rock. So this is the. This is what the definition looks like. So you see, we have a match that match the source. Selectors app firewall and the destination is VPN gateway. So when it connects to its own service, secure Internet connectivity, then this is the definition that that tells where to go and looks like Ian has a great question.

B

Yeah and you have a question: oh this file can be written by the app developer. If there are the ones deploying the network service and points it can be written by some net ops person who says here is am will file in some containers if they're the ones putting it together. um It's just like when you put together services in kubernetes. There are many people who may provide those services. It becomes a question administrative Lee in turn, iliev, who produces it.

A

B

B

Cool and then the question becomes, how do we connect Sarah's pot off the sort of general consumer who's, not part of providing the service, and in this case you have a match it. Doesn't it matches anything that falls through that doesn't actually have labels on it and the match has a route that says: okay, connect this to something that is say that has a label app equals firewall as destination labels.

B

So that's the hum a few bars version where now we're gonna dive into the architecture. Everybody's still with us show hands awesome cool, so there are kinds of to wait. You know there are two ways to abstract problems in general. One is you can focus on the implementation. This is kind of what happened in cloud, one dot o. We took all the physical things in the world and we slapped a fee in front of them when we called it good- and this had one really really nice characteristic and a bunch of really bad ones.

B

The really nice characteristic was nobody had to rethink anything. You already knew what interfaces were in subnets were and everything else, and so it was kind of familiar ish. The second way you can do it is to be developer focused. This is very much the way that kubernetes has gone. It focuses on what exactly is it that you need as a developer?

B

So when you look at how this applies to things like adding additional networking services to the world, if you were to do this in a way that's implementation focused, you would start adding virtual interfaces and virtual subnets and all kinds of things, but the truth of the matter is: that's not actually what developers generally care about every now and again they do, but generally they don't what they care about is number one.

B

They want to get their normal kubernetes and networking services, because the normal kubernetes networking is awesome for what it does and if you need more than that, what you really want is to be connected up to something that functionally does the things you need with the other packets or frames that you're dealing with and those things may be things like connectivity to isolated resources. Protecting you from threats um allowing you to talk, talk to various things, load-balancing, coifs, etc.

B

And so, if you look at this, it's not any one of these things that you actually want. It's some Venn diagram of the and that intersection of the Venn diagram is actually what we call a network service and there are still interfaces and subnets and all these implementation details there, but rather than making you hobble them together with 1990s networking concepts, we abstract them. The thing you care about: okay,.

A

So we got three easy pieces easy-peasy. So first is the actual network service itself. So you've seen this in the intro slide that we had before you have so the network service is the thing that that the user wants. The network service endpoint, provides that particular service or portion of that service, so it could be the firewall VPN gateway, and then you have the connection that connects you to that particular implementation of the service that you that you want so keep those three ideas in mind because we're going to be making use of them extensively.

A

B

And it's important to realize when you deal with an l2 l3 connection, the payload it is carrying is an IP packet or an Ethernet frame or for the more exotic among you in the audience, the sneaky network people, maybe an MPLS frame or something else more exotic, yeah.

A

And just for clarification, so for those of you who are looking at SDO and saying how does this compared to its OS? Do is l7 l4, so you're you're working with application HTTP drew a stream that stream would be TCP we're looking at l2 l3, so we're looking at IP, MPLS or various other payloads, and so very great. It.

B

To be clear, an sto style application service smash will run just fine over a network service master it'll, never and over. Here and honestly, we will never know that it's there either because it's way over our heads.

A

So the abstract components so to start off with, we have what we call a network service registry, and so the network service registry is composed of what network services are present. What are their endpoints, and so the endpoints are the the pods and so on that we showed before what and what what are their manager. So, in other words, I have an endpoint who which NS MD is the manager that and will.

B

Be saying a lot more about network service managers in the moment exactly.

A

So the way that this looks is so this is actually a proto protobuf, and so this so you provide a network service. The network service has a name, it has a payload, so the payload being IP Ethernet, MPLS, Jerry or via clan or so on, and then we have something that matches. So those are the matches that you saw before the network service. Endpoint distance also has a name. It has a payload as well. It has the name of its network service manager and, again we'll come to more on this in a while.

A

It has the endpoint name. It has a series of labels which is used to provide information about that about that particular endpoint and a state like. Is it up or is it having trouble.

B

Cool and then the network service manager is the final one and again we'll say much more about network service manager shortly, but effectively a network service manager has a name. It has a URL, which is how you talk to it. If you need to talk to the network service manager- and it has a little bit of information like ok, do we actually do be actually hear from this guy recently? Do we know he's still there do we have a state for him, etc.

A

All right, so every network service manager, I, guess we'll call it a domain in a scenario it has every pot. Every node has a network service manager, yeah.

B

So we're good to talk about this first in the abstract, then we'll talk about it concretely in kubernetes, because it turns out that you've got whenever you have a network service registry. There is some domain of network services and network service, endpoints and network cetera that it encompasses right. We call that the network service registry domain every time you have a network manager.

B

There is some domain of network service, endpoints network service clients and data planes that it's actually managing and we'll see concretely what this means in kubernetes shortly and of course, you could have any number of network service manager domains within that are filling into a network service registry and in.

A

This scenario take note that so imagine this is a kubernetes cluster for a moment right. So there is one network service registry, so multiple network service managers that will publish to that registry and will read from that registry and work out where their network services are coming from yep.

B

So no important things to realize so different network service managers will advertise the network service endpoints that they have to the network service registry. This is the only point of centralization in the system and then the network service managers will communicate with each other peer-to-peer to set up the l2 l3 connections.

A

So for the for the kubernetes version, so the the network service registry itself is implemented and makes use of CRTs. So it's an application that makes use of CRTs, and so basically, all of the state is where network service, endpoints and so on are stored with within within those series and we and we pull from them and so beyond the network service registry. Everything else is done. Orthogonal, II and.

B

This is super nice because then you can say: okay, well cube, control, get NSC and you'll get from kubernetes the list of network service endpoints that it's got from the registry, because we're using these custom resources in kubernetes in the API server, and then the network service manager is loaded. There is running as a daemon set on every single node, so every node is a network service manager domain and has a network service manager.

B

And of course, you also need to run some kind of a data playing to do your cross connects, and this can be any number of things. Network service mesh is completely agnostic as to what you plug in there as the data playing. We do provide one, but if you don't like it- and you want to do your own as you'll see a little bit later on the deck, the API that has to be exposed. If you're a data plane is dead, simple, mostly because we don't ask you to do very much. Yes,.

B

um Network service mesh you'll, see when we get to the data play an API. It is speaking an API that specifically asks for the creation of cross connects and your V switch would expose that API, so it can create. The cross connects, but you'll see that when we could dip the rule until the API in a bit.

A

Great so the next thing is we have network service, endpoints or so, and this in kubernetes these all end up as a pod. So if you saw the demo that I gave before with the bridge domain, that bridge domain was then deployed is a pod yep and.

B

Then you also wind up with network service clients. These are pods like Sarah's pod that want to be connected to a network service and again they end up talking to their local network service manager.

A

All right so now.

B

We begin drilling into the API, so people like api's, oh good, I,.

A

Should have raised my hand so all purple, all the purple edges you see here are G RPC, so just just so you know so we're gonna start with a network service, endpoint registration. So the registration message has a network service, a network service manager and the env endpoint as well, and so what happens is the the endpoint will will call register, NSC and say I am exposing a bridge domain or I'm exposing a firewall and will will notify the network service manager that that it has. It is ready for connections and.

B

Then the network service manager will do a few things. It will, basically, you know, make sure the network service manager references itself, because it's the one in charge of that and then it will translate this to the CRTs that are going into the API server and go stick them up in the API server so that when you do Cube control get NSC. You will see that network service endpoint listed.

A

So the the next part is the the node as well, so the so the client will ask for a network service, and so what it does is it is. It creates a a connection, object and it and it specifies the mechanism.

A

So mechanism is where you ask I'm looking for Colonel interface, I'm, looking for a MMI, f4v host user, and so you can see in the east, in the action and the service, we do request network service and the response is going to be a fully specified connection and part of the reason that we specify the connection here is: you may have partial parameters there.

B

May be some partial things you care about about the connection that you may put in there like.

A

You might want to know what is the interface I'm gonna, be as an example, so.

B

One thing to keep in mind here is: these: are local connections, so one of the distinctions we make in network service smash- that's super helpful is if all I really want to do, is get an Ethernet frame from here to there. How many folks actually want to be forced to deal with how it gets there not saying you can't, but what to have to no choice.

B

Who keeps inviting the sneaky network people so what network service mesh does? Is it allows you to specify what kind of local connection you want now for a normal application like somebody who wants to just be connected to secure corporate Internet connectivity or Internet connectivity, you're just gonna? What a kernel interface dude, you really don't want anything hard or complicated. You just want to run your damn app, but if you're writing a network service, endpoint or you're doing anything, you're writing a C enough.

B

You probably want to use a higher performance mechanism like mem if', and we will allow you to specify that as the thing that you want and we will give it to you, so you do have options, but the things you don't see at a local connection are things like VX Land GRE. These are remote connection mechanisms, not local ones. Now, obviously, if you're passing you through net frames or you're passing IP packets as payload, you can put those things in the payload.

B

That's awesome, but you don't deal with that in terms of getting from pod to pod. Yes,.

B

Yes, absolutely it's purely scope to the connection not to the pod. The question was: could he have a single pod that asks for one Network service with a kernel interface and a different network service with MMI off? And the answer is yes, the mechanism is scoped to the connection, not to the pod other questions very cool, so, in this drill, set a little bit more into what goes into a connection object right, so it's got an ID.

B

We put the information about the network service, it's a connection for in there and it actually has a mechanism and we'll talk in a second about mechanisms, and then there are two interesting things here. What is the labels and we've talked about how the labels get used for all kinds of cool things like routing, but we also have in here a set of values that we call the connection context now connection contexts. Are cool mechanisms get negotiated between you and sort of the next hopping? Your system right, like I, need a kernel.

B

Interface I need a mem I off the connection. Context is negotiated between you and your network service endpoint. So, for example, if I need a source IP that source IP is coming in the connection context from my network service endpoint. If my network service endpoint wants to make sure that I have routes that point to it say, I'm a VPN gateway and we want routes for the corporate Internet that comes back from my network service endpoint. In the connection context.

B

Now the rest of the system will simply pass this on through, but it's a crucial element, because there are lots of these fine details, but you don't want to actually deal with if you the consumer generally, but you want to make sure they happen, then for mechanisms we talked about different types of mechanisms and, depending on the type of mechanism they'll have parameters.

B

If I'm asking for a kernel interface, it may have the interface name if I'm doing them, if' there'll be a socket file, name those kinds of details, and then you do get mechanism types. We talked about how you might get a kernel interface, if you're a normal everyday application, you might get a mem if' interface or an SRO v NIC or a hardware interface. These are all mechanisms from our point that connects you to a network service.

A

Right so the next part is the actual network service request between the network service manager. So when you're crossing between node to node, then what we do is we. We have the connection and we pass the connection on, but we also add in some additional information into that. So, if you notice the network service request is pretty much the same API as the client to the to the NSM demon, but NSM daemon to NSM daemon. We also include the other information. Like my see, do we have a cell phone that.

B

A

So it also includes information about what do I support, VX, LAN or my data plane supports the excellen-- and GRE which one and with these parameters and pass that on to the remote side and so and so what we. So what you see is in. We have two mechanism type, so you can see like VX and VX times you had GPA, GRE, etc. There's.

B

No end of the creativity of the folks in the IETF. This list will grow for all of time. I'm. Sorry, we can't make them stop, but here's the thing you never have to know the guy writing an application. Pod never has to know again what the hell. These things are. If you're writing a CNF, you never have to know when all the people who are beating down your door last year telling you you have to have MPLS over GRE, show up again and say: no, that's not good enough anymore. We would MPLS over UDP.

B

You don't have to rewrite your CNF, because that's all handled by the network service, mesh, yeah.

A

And so this mechanism type this remote mechanism type, is added by the NSM, and then it is stripped by the by the remote NSM side as well, so the so the client and the and the endpoints never see the the remote mechanism, information that is being used, so it is strictly encapsulated and stripped on the other side served on your side keeps a connection and what they have to worry about. Very simple yep.

B

So this is sort of the the big perfect picture here where we see all the different steps and the last one is when the network service manager on the remote node goes to talk to its network service. Endpoint guess what it uses exactly: the same network service API that the client used to ask the network service manager for that connection. So it's the same API, it's the same parameters. We've got a remarkably small number of api's and many of them looking very close to each other. So the system is very, very simple.

B

So now we're going to talk about how you interact with the data plane, you may recall that I said that we're really super agnostic about the data plane. The network service manager does not actually program your V switch directly because that would weld us to a particular V switch. So, for example, a lot of the folks in network service mesh really like VPP, because it's a super performance super easy data plane to work with. That does everything, but we don't directly program VPP.

B

Instead, what we have is a data plane, API and that data plane API, is pretty simple. It has a streaming RPC called monitor mechanisms that allows us to find out what things the data plane can do. This data plane can do SR, v6 + VX LAN. So if someone has to be for MPLS over UDP I'm, sorry, that's not something I can do, and it's got very closely. It's close semantics to what we've seen before I can request a cross, connect and we'll see in the next slide.

B

What a cross connect is and I can close a cross connect.

A

B

Exactly that's exactly what I was so easy, and so what a cross connect is is really flippin simple. A cross connect is two connections, a source connection and a destination connection. So if it turns out that the network service endpoint that I am talking to is on the same node, that I am, then it will be a source connection that is local and a destination connection that is local.

B

If it turns out that I need to go to a remote place, it will be a source connection that is local at a remote connection, that is the destination, and if it turns out that some other NS MD has asked me to connect to an NSC for it, it will be a remote connection for the and it will be a local connection for the destination. But semantically.

B

All your ever dealing within a cross connect is to connections that you are cross connected, meaning whatever IP or Ethernet comes in one side you send out the other and vice versa. Everything is point-to-point.

B

So a really good way to visualize this topologically and I'm gonna stop and do cartoons for a second from the point of view of the network service client. All it sees is this little green line. That is a local connection and then magic happens in the cloud in the middle and from the point of view of the network service endpoint. All it sees is this local connection that magically packets and frames come to and fro long, and that's all you see if you're the network, service, client or endpoint.

B

If you drill down into the world the network service managers say what you discover is: there is actually a data plane next to the network service, client and a little yellow, teal diamond. That is the cross connect that takes you to a remote connection. Now this is the same literally. The same remote connection object on both sides and then a data plane that cross connects that to the local connection for the network service. Endpoint.

B

Now again, I promised you cartoons how many people like cartoons, everyone likes cartoons cool. So imagine that we have a happy packet. All of my packets are happy. It starts at the network service client. Maybe it's an Ethernet frame or an IP packet. It goes into the data plane. The data plane cross connects the packet from the local connection to the remote connection, where it probably picks up an encapsulation.

B

It goes through the network. It arrives on the other end of that remote connection where it gets. D capped by the data plane gets cross connected to the local connection to the network service endpoint, and then it arrives there. So that's that's the extent of my critique skills. I'm, sorry.

A

B

It's a happy packet and, of course this works the other direction as well.

B

So these are the data, the api's that we've talked about so far, we've talked about how network services get registered, how they get requested and then how the network service manager talks to the data play now. We're going to talk about monitoring monitoring is fun so for all of these objects that we talked about, we have streaming G, RPC, api's, that let us monitor them.

A

Great, so in the monitoring, so you can see that it has a initial state, so we're going to transfer initial status to what's going on. We have an update and a delete, and so the cross, so the monitor is a. It will effectively give you information about what type of cross connects that currently has, and so this is particularly useful, because, if you're, if you're an NSF monitoring your data plane, then you can ask it like: maybe your NSF dies and then it comes back up. Yes, I give me the initial state transfer.

A

So now you know what the data plane knows and then you can then continue to get updates in a very simple way, and so we try to keep this as simple as possible, and this API is also what we were able to use in order to hook in things like sky dive to work out. What was what is going on within within my network, which is what you saw if he came to the to the initial demo. That's that's what drove the the UI that we have so you know.

B

I mean effectively what it comes down to is your network service manager has a really strong interest in knowing what your data bling believes. The state of the world is with regard to cross connects because the network service manager doesn't actually touch packets and the monitor cross connect all lets. It know in real time. What actual state is there in terms of cross connect state? So there's the second set of state you might care about, is connections now most network service clients are kind of dumb as a rock they're going to have it.

B

A NIC container that runs sets up their network service connections and then exits in the app runs. So most clients are not going to call monitor, cross connect for their network and monitor connections for their network services, but they could, and we would tell them the state of the connections that they have. So if something goes wrong with the connection you know they get informed and then for remote connections, it actually gets to be super important, because you've got to network service managers.

B

They really really want to know the state of the connections that they have between each other remotely, because that actually lets them know the health of those connections and, as we will see shortly, we can do really cool with that, like Auto heal.

B

And then, of course, when we get to the far end, the network service manager can use exactly the same local connection, monitor connection API to see what its network service endpoint believes, are the connections in their states, so the monitoring ends up. Looking like this, and now we come to the harsh reality of life.

B

Pods die in fact, pods are designed to die. The entire point is that they're disposable, but it turns out that in network service mesh every bit of important state in the system you share with your neighbors, so the local connections, the cross, connects the remote connections. All of these things are being shared with your neighbors and in fact, in the case of cross connects you have information both on remote connections and local connections in those cross connects.

B

So if the network service mesh manager dies, it can relearn from its neighbors the state information not about what it scribbled out in some database before it died in the whole world, changed on it. No, no. It can find out in real time exactly what's going on in the world and reconstruct itself in Sapa start operating optimally. Again now the other thing I'll mention is, as Frederic mentioned, the monitor cross connect is the same API be exposed north from the network service manager to manager. So things like sky dive can do monitoring in topology.

A

Great, so Auto healing so I have a VPN gateway. Pod, happy packets, going through. Suddenly my l2 l3 connection between my firewall and Gateway dies or the pod dies itself. So now we have unhappy packets or do II know we can actually reroute you independently to the other VPN gateway, but that's on there and without the firewall pod having to do anything, it doesn't have to be even aware that the VPN gateway pod went down yeah.

B

So keep in mind the local connection from that firewall pod to the data plane is still good. So all we have to do is update the cross, connect to point to a different network service endpoint and everything is good. So what death of a network service end looks like a network service mesh? Is a breif network connectivity blip, followed by everything? Being okay? Okay, again,.

B

How does what so here's the deal? There are some things in the network service that have state. If you are stateful, we have major life. No worse, my auto healing for you right so you're, absolutely safe. All network services are kind of interesting, particularly since one of the things we don't have in the picture that we're mulling is the same thing that lets us. Auto. Heal also gives us mechanically the ability to update the graph dynamically for existing clients.

B

If you change policy now, if I do, that, I very well may make things worse than what they are right now. So there's a question about what the wisdom is there, but for auto, heal you're, never going to be worse off, so we're almost done so remember. We talked about the three easy pieces, so three easy pieces, plus three implementation details gives us six easy pieces right. So these were the initial three easy pieces network services, network service, endpoints, l2, l3 connections.

B

Then we added network service managers, cross, connects and monitoring.

B

But again it's very simple. Almost everything is just request close and monitor so really quickly. We're going to go very fast, cuz we're almost out of time, 2k, eights and beyond. So we talked about this abstract picture. There's a reason: I talked about the abstract picture, and it's because when we project out into kubernetes we can actually imagine a world where you have network service managers that are external to kubernetes that are actually registering network service endpoints from the outside world into your cluster.

B

And then your network service managers can in exactly the same way talk to them and get your cross connects. So you could imagine a next cluster a second cluster doing this. So now you've got cross cluster behavior for cross cloud. You could imagine an en SM for an existing OpenStack or VMware VIN. You could even imagine getting network services from your physical network, so proxy Network service, tn SMS. So these are really dangerous people seriously.

B

They are the light sabers of the NSM world. They can cut through anything and if you are not strong in the force, you will cut off your damn arm. So with great power comes great responsibility, but it turns out that you can literally put together a proxy network service manager that is pretending to have networks in service endpoints that it does not have.

B

It has no network service in points, but it advertises them say advertising one with app equals physical hardware, because you want some kind of fun thing to happen in your physical network and you can put in policies that are basically hijack the request for your network service to your proxy.

B

Your proxy gets the remote network service connection requests. It looks at it possibly munge as your physical network, possibly Munch's the request, and it turns to someone who actually really does have an endpoint. When the response comes back, it can possibly munge those parameters and you wind up with an l2 l3 cross connect here, but in the middle you may have changed your network. You may have slightly changed the remote connection, so, for example, if you're doing SR v6, you may have added SIDS to the SID list to do traffic engineering.

B

All kinds of interesting things can be done this way. Not all of them are a very good idea. In fact, a great many of them are terrible idea, but some of them are brilliant. All right, I think we are actually out of time. So, if folks want to talk, I will walk out of the hallway with everyone else and I would be happy to answer any all. Questions and I'm sure Fredrik would as well absolutely.

A

B