Istio Networking Working Group, 25 Apr 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Istio Networking WG meeting 2019-04-25

Description

Discuss multi all-the-things (multi-cluster, multi-networks, multi-meshes).

A

These two networking community meeting today we will have a few follow-ups on previous topics, notably the proposed names for the multi cluster implementation. I. Also, like body mist with us a bit later, I'll follow up on some toc response and we'll also go a bit of order. The github epics, so I propose. We start with your topic. Vadim the multi cluster naming.

B

Can you see my screen? Yes, the document? Okay, so to provide the context in a production environment. You can have multiple clusters connected together. Okay and clusters could be on different on the same network on different networks in different clouds. You can have, for example, compliance regulations, for example, some applications have to be on different network and so on, and you can have multiple clusters and these clusters can be connected by different patterns.

B

Let's say, and currently we have three different examples that describe these different patterns and what I propose is to give these patterns all these examples. You know some kitchen names like, for example, for design patterns. We have neutering, we have easy to run so on. Let's just mainly decide on the name means for the cluster connectivity patterns. Let's say okay, so there are two aspects in cluster connectivity. First is network connectivity. We have either folder connected classes.

B

It's the meaning is that pods can connect pods from one cluster can connect to poles from a number classroom, so it's called like so it's so cold sled network or VPN connectivity, and so on. So basically simply saying it's all the hood connected or want to put connected clusters, or you can have gateway connected clusters. That means that gateways would say. Egress gateways from one cluster can connect to English gateways.

B

They all remote clusters- okay, and there could be some with say, organization that pods from one cluster can connect English sports, English gig with all in all clusters. So the first aspect is the network connectivity and then we have different. It's a woman presence. Sorry.

C

The internet, but on this topic, what do you mean I'm not into how you are going to use it in the documentation? Are we are going to use it because in reality, is your mesh support both in the same booty clusters? You can have a multi class environment with 20 clusters, five of zemana VPN, another 500 VPN and the others each on each in its own network. Exactly.

B

Yes, this is all I'm talking about what.

C

B

C

We are saying that east your mesh supports multiple networks. Each network consists of a set of clusters right.

D

C

Or the other, it's always big right. Okay, right! Yes,.

B

So talking about each pair of clusters, you have different network connectivity between them and you have different deployment elements or groups of clusters or clusters of.

C

Effort for this particular subject: I think we already have an API is I mean in mesh config and and where we define the networks and we use a term networks to mean a set of pods in one or more clusters that share connectivity. So there is an API is that already have and which calls them networks. For some reason, can we keep some networks as we have in API, so we don't have to revs APM.

B

Yeah, it's fun I'm talking about documentation, No, okay,.

E

B

What we document you know the Easter side now we call these patterns like some simple kitchen names and also the developers or users can, you know, relate these names and they can talk. One to another here is.

E

B

Here using another pattern in stone, just like it means for the petals. You.

C

Know the products put, for example, implies a kubernetes, that's not be a good start. Names are oh yeah,.

B

We're talking is.

B

So we can talk about container container connectivity versus maybe annecy yeah.

F

No, we don't do that either right when we're gonna encompass the ms200.

C

F

Yeah, something like direct connectivity.

B

Okay, so the first aspect is network connectivity and the second one is deployment patterns. So here we came up with eight different names. Basically it's about either we have shared control plane or we have multiple control planes or independent or decentralized for symmetric. It's made the cluster Tuesday, so here no names are basically about either. We are talking about clusters, primary secondary cluster versus peer-to-peer or somatic clusters, or we are talking about control planes, either shared, centralized or independently, centralized in engine multiple separate local documents right yeah, one.

C

More data point here from environment working group: we are in.

E

C

To support multiple control trains in a single cluster and we call them environments, so that's kind of a generalization of you can have what people try lots of different configurations, but they operate is the same kind of and it will be wonderful to keep them aligned over.

B

Here right, so we mark here is sure, doesn't mean single, so you can multiples share the control points they can be yeah and even in the same I think.

C

The point was, one control plane is defined as a set of. Oh sorry as a set of configurations.

E

C

Particular environment.

E

C

Everything and very.

D

Different process.

C

And it is not necessary that it in one crime a done completely outside of any class, you can run on a VM. You just have pilot and some stuff running on a VM outside of any cluster, or you can have it in already know. That means that's kind of how you install it, not necessarily how it's logically organized.

B

And we have a table of different implications, but this one I guess we can some poor and published least able to describe today describe the user to the users reasons where they should return. Okay. So here we got some Leon in different points say there are some practical implications. So, for example, in one settings we the operators which they have to provide and configure access to the next api's that they had to configure site has to communicate with remote pilots.

B

In some cases you have to create and replicate either kubernetes services or you have to create history service centers. You have to install again a server, for example, some say: ok, so here we should. We can do it later, this implications table or say with options, prescribe de options for the noodles, but first I propose that you know finally we'd somehow the side boat, I, don't know on the names. So without the current name state options to choose and they don't know what should be the process. How should we proceed from here.

C

Can we avoid a decision by just not using multiple names, just using one name, it's multi class current. You have choices on how you deploy, but that's not relevant to anything.

B

Yeah, so this is what I propose: how do we call these deployment options? It's all multi classify multi cluster mesh. Let's, let's read what is not agree. How do we call these deployment patterns.

C

But what is really the difference between them? I felt when this has a difference, because in a in a mesh in a multi cluster mesh, you can have both at the same time. So it's not really I.

C

Don't really see why there are two cases. It's one case, and in that case you will need ombre in a multi class admission we have can have both type of network in both types of. However, you want to call it I mean having one cluster. Would you have a pirate running and using only gateways and using what you call the second method and all the other cluster using the safest method or you can have half of alfalfa?

C

You can have each region use a particular shared control plane with multiple abilities zones, and then you look to the other ability to do the other regions. So it's a mixed or option use as a continuum across pretty much I saw.

F

In the description before we describe the the variant, various options for bridging networks is just multi, never right. We kept multi cluster and multi network as two separate topics and in part, that's the reason why the API is structured. The way it is right. It allows us to talk about those two things independently.

C

And I would say that really is a second part: I mean how you organize. A control plane is about how you breach the networks, not how you deal with multi cluster because in reality, is a pilots in each network need to have visibility into that network. So if you issue organize with the second option that what you call peer-to-peer each peer is really a network with its own locals. That is with a pilot that is managing their particular network and it sees all the endpoints in that network and can only load balance within that network.

C

B

C

Know you can also have a mix where, where you know you can have a pilot that is having visibility to all the networks across the entire mesh, but you still use this kind of pilots that are local and only have visibility into the local network. As you know, failover mechanism so to mekinese can be combined and should be combined and used together in in a production environment, because each of them has benefits, and you should not sacrifice one or choose between them. You should actually try to deploy both of them.

C

You know as much about yes.

B

Right initially, so you can have multiple like 20 clusters, you can have multiple networks and you can have multiple paths patterns applied between different clusters. This is agreed a yes okay, so what is left is just to give names, catchy simple names to these patterns. Okay. First second, also in the pot to put connectivity on the same network, you can decide to use it the connectivity, so you can still decide it for some reason or more control.

B

You still direct all the try to use splitter eyes on the years and you direct the traffic between de trees, okay, so I have these issues are III I claim that they are orthogonal so have metal kind of um you know that snake.

B

So you have never connectivity here as if it's in this table to option spot to fold or container to container, and you can have data connectivity, and then you can help these lead patterns, which you mix, which we'd apply, which we deploy applied in different cases, okay in the production environment and you mix them. So what is left is this. Give them means that's all simple names, and here these are names or deployment oxygen for for these patterns. It's not like the whole mesh it's this here.

B

We apply, for example, prime primary secondary cluster connectivity or deployment, and in another case we need apply peer-to-peer deployment, cost deployment.

F

So redeem, when you say primary secondary, are you referring to the control plane, a cluster.

B

So here I primary secondary cluster and they need the primary is the one that has control plane and secondary use, a secondary class. Let's use this control plane and the primary coffee here the names are, you know we either name the clusters primary secondary versus peer-to-peer symmetric clusters, or we call the pattern by control. Planes like shared versus separate control,.

C

Points, so is there any case where we even want to have a single control. I mean as an example in the documentation is wonderful to show how a control plane can be configured to see. End points from all networks, but in a practical.

F

Cases there are people who are running.

C

C

It's always, it always should be multiple operatives owns regions, but it's.

G

Multiple control points is.

C

Exactly is what the protocol control planes it's one control, plane logical is that may run in multiple clusters or multiple abilities zones.

D

Cluster, where your cluster spends through multiple availability, so exactly.

G

D

By the way, I'm not sure, if you guys see it, we did a survey Multi cluster deployment model as a community, and we published the result of the survey probably a month ago to discuss that is tilde, il and surprisingly, I. Think a slightly larger chunk of the users are more in favor of using single control, topology with split horizon and there's also sufficient large amount of user. I interested in gateway connect. He connected control playing multiple control playing topology. We have so I think both are interesting for sure.

B

Maybe to clarify here there's no.

D

Pretty much supporting inside is suing who won namespace yeah you're talking about the future, so we're we're on the survey about a month or two ago. That's all. We support a single control playing with split horizon, which one connectivity, maybe.

A

We can rename the single control brain to master no.

C

They're all peers, they're, all equivalent abilities. It's one set of configurator. The main distinction, I think is: if you see one consistent configuration in all the mesh or if you are seeing this joint configuration right.

F

It's a global deployment, whether with a regional short write with regional replicants right. That would be a typical deployment.

B

And also remark, I think that's the horizon is just implementation and.

C

I would say anyone give me two equal India to it's also implementation. It is as part of the networking and how network is mean happens to be implement. It doesn't matter. If you how you organize a control plane, it should support both modes. Always, yes,.

F

So the team I don't know if you looked at the talk, I wrote a while back about this actually wrote a long talk. Yeah.

B

F

Where with there's there's either a global control, plane or a federated set of control planes, and then there's the distribution of control, plane, replicas and then there's whether you're a multi network or single Network right and then that's gateway connected multiple V pcs. But that's that's a kind of tertiary detail in your decision-making process.

A

It seems that the right naming with big global control plane, not single master, correct yeah.

F

For the control plane, it's either global or its federated right, but.

C

F

Doesn't and I still have a global.

C

F

Has nothing to do with the actual deployment target of the control plane bits? It's just talking about one match versus many measures, because you could say global mesh versus Federation measures. Yes, but here we have fractured.

B

My skull sorry here the whole document I, am talking only about a single mesh, it's not about the derivative. So then.

F

We make sure to use terminology, so we can least distinguish trade because there are. There are definitely as many people like tool in point people out there, whether you're gonna run each mesh separately and then they're only gonna, bridge subsets of the services right right. So it's it's a it's a an extreme form of split horizon.

C

Actually, that's a very good idea if we are saying split horizon networking to refer to the connectivity to two gateways, because that's what it does. It's also split horizon config ready we're talking about because in that multiple control planes you are describing here, you really have a split view of the configuration. In one case you see some service entries. Another case you see several different service entries and the octal rules can be different, bigger.

F

Customers, I think that's actually what I'll end up doing.

B

Yeah still do clarify. The whole document is about multi class of series mesh. It's not about your second option of federated meshes. So when we, the users want to get with a single service, mesh multi classes, series mesh, they will replied, run presents so.

C

What I was saying is in this context: they will have the option to deploy, I mean they'll, have a split horizon networking either one network or multiple networks, a different view, and they.

E

C

Split horizon or single horizon control, plane or configuration, so the configuration can be either a single set of data does matter where you put it, but it's the same configuration everywhere or it can be a split horizon configuration where different parts of the mesh will see slightly different coffee. We see different side cars different tools because they are localized. Basically.

D

C

B

Are but again, this is the implementation distinction so for the users I think what is important is implications so either you have to replicate kubernetes services or you have to educate history, every census that provide the IADC your eyes or not, but.

C

But you might see I think that's implementation, detail I mean that's something that operator and the config system will take care of. Is that some system user do not see what the user.

B

Will see yeah the users of these.

C

Tools that you are building I mean there's a whole installer, and these two operator, and all the tooling that we are building, will hide all those things from from the user. What user will see is either one one configuration that is consistent across the entire thing, or he will see different configurations as only user visible difference that they will have.

A

F

I'd like to figure out, you know the: what is the order of determining that the layout that the customer is going to make like what? What is the first piece of information that they want to understand in order to make a decision about how they're going to do their deployment right? Is it the network topology? Is it the organization of clusters, or is it their administrative domains.

F

You know I understand that what we factored into the decision so which one drives most of the decisions.

C

Well, networking and control are clearly some things that he cannot be changed and they're fixed and you cannot avoid them. So if you cannot have a flat network, you don't have a choice. You have.

D

C

Administrative domain: again, you don't have a choice right.

A

But I would say, the administrative domain is the most important right, because you make a choice based on that and then like for the network you go with. Whatever is recommended right. If you have multiple networks, remember.

F

That when you deal with any one, individual, they're, probably thinking about their administrative domain, first right, if what we're trying to do is pick terms of ours right that resonate with people and they understand easily right, then aligning with their decision criteria is probably the best way to go about. Choosing the names.

F

So the other way to do this by the way is to pick fairly recognizable names for what we would consider the most common use cases and give them names like, for instance, the I have multiple clusters and they all have their own networks. I've heard that describe is archipelago mode right, which sticks with our nautical terminology, and then you could describe that and right.

F

You could outline what that use case looks like, and then you could talk about some variation within that use case right without trying to have a kind of perfect ontology of multi network global versus single mesh, no federated non federated right. All those dimensions, I'm trying to lay everything out in a grid.

F

So that's the other way of approaching this problem. Right is not to do it by matrix. It's just. Let's take the common use cases and give them names that resonate.

D

Yes, so I think single resonate well with the mesh admin rights over mesh admin I'm in charge of my single mesh and if there's multiple meshes, they assume it's multiple mesh, admins I.

A

Like proposal, I think that is that's a really sticky name and I've heard this. It resonates with me at least.

F

Single mesh, multiple network right, yeah,.

A

Exactly and so I think the way I hope you do to agree. We have to get rid of the cluster or we're routing and I think the other one is not too bad, but we have now cluster a well serviced, something which nothing.

F

A

F

Definitely need to fix the ecology, yeah argument with that right.

A

Gateway connected is not the bad name, but I think I keep a Lago would probably be kind of. You know better name for that case.

F

Right, you could say you know Gateway connected ie archipelago, both agree. We.

C

Do network that we used before he's not so bad yeah.

F

Multi network is okay; I just don't mind that.

F

Then we can talk about the control, plane, deployment topology in terms of availability right right right. It's almost like. We could separate that as a separate topic and just say: look here's how you plan for high availability.

C

Requirement any name we choose to be easy to spell archipelago I'm, not entirely sure how many innocent yeah.

D

F

I'm, it's okay to have more than one name for a thing right. That one is a descriptive name and one is a a a met before because that's what my archipelago is right. It's a metaphor.

A

Names I think we should all stick with one name. We have like enough concepts that you know people need to get familiar with, so the the fewer new names and the fewer confusion we.

C

A

With a single names and so one, we.

C

Have is perfect, I mean I, think we know 22 very much I mean beautiful network is clear, easy to understand for that part, I think we should stop worrying too much yeah.

F

I would tend to agree, but.

G

Great single versus.

A

G

Or intra versus internet work.

A

Based I guess on people who spoke like if there are 27 people on the call, so so.

D

You have an opinion, please say: I'm, not a single match single network single match, multi network and federated mesh. Those.

F

Would be the primary I think? Yes, okay,.

C

I'm not entirely sure what federated mesh means to be honest,.

D

F

To administrators customer right.

D

It's too much more than you so.

F

It is peering right, but you can say you can call it mesh peering actually, but.

C

With movie viewing environments that we are adding for single cluster be a federated mesh, even if you're in a single cluster, we still have different admin domains, because his name is.

F

Kamesh multi network will split horizon no.

C

No, no, that seeing single class sync network, but you still have my implements I've, been staging.

F

C

F

Don't think we need to distinguish that we could just put that into I. Don't think we need to name that I think we just need to describe it.

G

It seems to me that, where the the system's run, that provide multiple administrative domains is irrelevant and whether they run on the same cluster or not doesn't matter so you're.

E

Either knocking about one.

G

Or multiple administrative domains, which may be represented by multiple deployments of Sto.

C

Would you don't need any question what it means you can they.

G

Can run on the same cluster or multiple clusters non.

C

G

Or bare metal, it doesn't matter.

D

Control plane, which is what we had before, that.

G

Control plane is a a deployment implementation detail. Whereas are we agreed that mesh is synonymous with administrative domain.

F

So Edgar when you say that kubernetes is already given the name to that thing, what thing do you mean.

F

If you're referring to multi cluster right, they refer to multi versa means to do unified scheduling across many homogenous kubernetes clusters, right, which is a little different than what we're trying to achieve here. Yes,.

E

Right because, well at the beginning of the call you were talking mainly about the ho ho GE, what you were talking all motocross ring in the base government set. Oh so I was still thinking about that. What kind of configuration.

F

Yeah, so just coming back to the names right. Obviously, single mesh single network is the kind of this simple example, and we could just refer to that as mesh right and then, if we would refer to single mesh multiple network, you just call that multiple multi network mesh right, if you're, looking for synonyms right, because we're probably gonna have synonyms that are people are going to use in kind of paragraph achill contexts when they refer to these things.

B

Yes, I still have a question regarding single mesh, multiple networks, so we still have two different deployment patterns here, so we can have multiple networks single mesh and we can have either shared control plane or we can have multiple to both wings. That.

C

Becomes federated so it's it's federated single Network, federated multi, network, okay,.

F

Custom I want to be very careful and reserved Federation to mean multiple administrative domains, AB distinct offense, the horizon.

C

Agreed but you can have.

F

Everything else.

C

A

You can still have the control plane, have visibility of all the networks that.

G

Sounds like single mesh yeah.

A

I do think my stuff. What.

G

I'm, saying is that, when we're talking about the use case, where you have multiple administrative domains, you have not all services available to not all other services that that another way of saying that might be multi mesh, that iterated mesh.

A

G

Will by definition it does right? Okay, so then we have a four by four matrix of single versus multiple mesh and single versus multiple network effectively yeah well,.

C

One thing we have used in the past was to say that mesh equivalent with the admin identity domain, meaning domain or root CA no.

F

Names also, yes, means that typically aligns with administrative domain, not.

C

Only because if they I mean you could have a single root, CA I mean one large organization which shares a root CA and everything trust each other and trans identity. But have each team manage its own? So it's federated, but wherever.

F

Then it's a hierarchy right, they have intermediate, CA is, and they choose whether or not to trust each other across those infinite series.

C

Well, if you have which ta you kind of trust everything I.

F

Know you know how to verify the.

C

F

Don't you haven't made a decision about whether to trust it or not,.

B

Yeah still you talking about the single mesh, okay, we have common dossier, we have the same names, we have the same administrative domain, but we still can have a control plane in each cost.

B

Wait. How do we call this petal, but.

C

It's not that you have a single class; that is that you can have different views of the configs in each cluster depositor.

G

Is a relevant cluster is a is a is a host topology yeah.

F

You can have different uses the services, but that what we call split horizon for.

C

B

Okay, so how do we call the norms need Verizon women.

G

Single mesh single.

F

Network yeah, so I, don't think we split horizon is a refinement of single mesh, probably in the case of single mesh Multi network right, but I. Don't think we need to give a specific name without split horizon single mesh right. So split horizon is a a refinement of single mesh right.

B

On topic, yes right, he has agreed split horizon is a requirement of a single match. However, you have additional deployments deployment, padam implemented by theorem or a single mesh, which is not surprising. It is respite or s, and if you think about it, what.

C

B

C

It's effectively split horizon config.

A

Which one are you referring to the Gateway connectivity right.

F

Or the end point.

A

C

A

B

Network ID, let me open the connotation.

B

B

Currently, we have two different examples. First, one it's called cluster where service rival router using is to split horizon years. This is what we have. You know. A single pilot here again pilot has access.

B

This is a first example and.

C

Single horizon whole horizon control. Plane. Yes,.

B

I guess designed by cost in and you co can use implemented.

B

Here we have additional deployments 18. It's called a tree connected clusters implemented by Shriram here, so he redefined in global global to use global citizen. It's okay, you deploy in a circle and you have multiple control points. It is still a single mesh. The root CA that the same names.

B

C

The coalition be similar interval back and everything else, but it split horizon because each generation set can see the different set of context. So.

A

They are both split horizon, the difference is one has a single control plane and the other has the control plane in every cluster I.

E

A

This is like we talked about of two by two matrix, but I think we actually have the trolls a matrix as well, which is quite orthogonal, so.

C

We should probably.

A

Handle it separately, you.

C

Can have a controller in each data centers, as the difference between the cortex is in one is the first one, all the control trains exactly the same. Config no matter where you are is the second kid you see different on fixed I mean one case: you'll see a service as a service entry in the other cluster. You see it as a normal service.

A

C

Synchronize synchronize is true, whatever CI CD system and see exactly the same config exactly the same thing everywhere.

F

C

F

C

Is it you can deploy a propane everywhere, but it will still be based on the same same configurations right.

A

You can still see the same thing. The other means, then you know reading directly from the whatever.

C

A

Api server, you know, I am I actually opposed in the past to this method because it involves, like you know, changing your cube, config file to access other cube, API.

C

In many ways see same configure different projects.

B

Yeah, so my question is: how do we call these two different implementations or patterns? I mean the one is of UC and hosting the other serum I am.

A

Actually, for like completely dropping the one where we read from the kubernetes service directly and proposing the model where we used I think it's the Gateway connected.

B

A

The first one still looks like a hack to me and nobody can come visit me. It's not a hack.

C

A

Anything your cube config file to put that the secrets for the other cluster, the pilot becomes very busy reading from multiple cube, API servers- it's just not. This is seem scalable.

F

And, under the only distinction, is how many boxes in between the arrow between the control plane and its source of information right so I like I, really don't want to go into that right.

F

We have to focus on. You know the use cases here and what use cases we think people are going to look for when they deploy.

G

In production and.

C

It's mostly just ok,.

F

Let's, let's not focus on what stable either right we want if we want to be forward-looking right and pick stable, naming that's gonna survive. Even if the internal implementation details change so.

C

How about we stop? We merge empathy. We see that it's a one multi cluster support, both split network and splits, split config, so.

F

The other way to do this, right is to say we have mesh peering right.

F

But I don't think we want right and the reason why we would do that is we wanted to recommend people run one control plane per network I.

F

Don't think we want to say that doesn't.

C

F

Know, I didn't strictly have to be, but that would be a typical pattern right and the reason why you would do is because you were worried about network partitions, but I, don't think that's a better set of terminology than the ones that we just mostly aligned on I. Think.

A

This is very much an implementation.

A

It's not like different config, because in both cases you can have the same. A pilot can learn about services in another cluster directly. We are, you know, peering with another pilot or necessarily like or from MCP from Ghale directly. It doesn't need to read the cube. Api server, so I mean I, wouldn't even get into that level of detail. How that's finally discovered the services in another cluster Louie.

G

I like what you suggested before, and that that whether you're running multiple deployments of sto or not, is just part of the H, a question yeah and it doesn't need its own name. It's somewhat orthogonal right. We just hold up deployment, topology choices.

F

A

F

A

F

The two topics.

G

We cleanly separate the two topics. There's gonna be a continuum of how far you want to go to make the thing redundant to multiple levels of failure, and they all don't need their own names. It's all can be grouped under documentation that talks about high availability, yeah.

F

So we just have, we have we have mesh topology and we have deployment topology and those are two fundamental topics and they can be treated right. One informs the other.

B

Yeah there is another implication here for the users lecture: okay, so in one implementation, the remote and local services they are named, you know in the same way and they're all bound together, so the local version and the remote wants this load bounce between them in the second implementation. You'd have overriding. So if you have a remote version, this remote version is called once you define a local girl with the same name. The work of learning will overwrite a movement. Do it still? You know a.

C

New simply, we can fix this eventually, even if you I mean we still allow overrides, but in the second case we could still have a robot. You can make better robot. As you can see, we can still take into account a different proposal to do that. It's just going to not implemented. Oh.

B

G

Think the important opportunity here is help users build a mental model and, what's being what Louis and Costin Andre are suggesting, are higher level constructs to help people build that mental model and where the control points are deployed or how many you have of them are not as important.

A

So I recorded that Shannon and, like the meeting notes, the fact that we want to separate a deployment apology from the mesh topology I hope. That's great time is everybody reviewer and, of course, I find a move. Update is document. This part.

F

Right so it when it comes to mesh topology right, we either have single mesh or multi mesh, there's a specialized use case with one single meshes to the horizon and then there's the control plane, the valid control, plane topologies and the network topologies, which we should talk about and then there's probably a document about common use cases that pull those together with recommendations.

A

So but federated multi mesh, we haven't really like implemented.

C

C

F

Use case driven discussion right that if you have a mesh and someone else has a mesh and they want to talk to each other, how do you set it up? Yes,.

C

F

Don't care like the division of the administrative domain.

G

B

B

We have different names for different for different services and you have different cereals that would.

F

Be probably quite common right, yes,.

F

Maybe maybe not.

A

Just to go back to the single mesh, we have the single mesh and we say there is a specialization for the split horizon, so that is for the single mesh, multiple networks. Typically.

F

A

Single mesh multi networks so, and how do we call the thing, the single mesh Shh Martin networks? That is not split horizon, that is the global we.

F

Just call it we just call it single mesh.

A

Horizon so it's kind of unfair to all that the specialization I will call the other one. So.

F

The the multi network single mesh, where every the everybody sees the other services equivalently, regardless of their network topology I, think we still call single mesh in the situation where they don't see the set of services. Equivalently I think we call that split horizon.

F

One is better aligned with the terminology around DNS with horizon right, and that's really the thing people are trying to achieve because they're running services in different topologies physical topologies.

A

Okay, I'm convinced now, based on this analogy, so by definition we assume everybody can see all the others right when they cannot we're gonna use the split horizon.

C

G

That synonymous with multi mesh.

F

We're not using the multi mesh term, so the implementation detail of split horizon for services is massively overlapping with federated mesh, but I think we've eliminated. If you want to call that multi mesh.

C

Cases where you have different domains in different yeah.

F

We confusion between federated mesh and multi mesh I.

G

Personally, find split horizon confusing I can only think of a VM with two network interfaces. I, don't know what it means in the mesh context.

F

I mean the typical meaning is your DNS resolves name a to an IP and my DNS resolves name to a totally different IP.

A

In bridging, like you know, to bridging, there is.

F

A

World you're coming it can have one meeting. That's.

F

Why I'm, okay with multi mesh as a synonym for that.

A

F

Split horizon around services: okay,.

A

But then and then we will have a federated multi mesh Confederation.

F

Is by definition, multi much yeah.

C

Organization, that's.

F

A generation- that's Federation, that's multi, mesh or.

C

Federation, the.

G

F

A

F

Remember multi mesh is the implementation detail? It's it's it's. You have different configs in different places. Federation.

G

Is the description of the separation of administrability.

F

G

Doesn't have to be, we could define multi mesh as being multiple administrative domains.

A

I think what we saying we should basically replace horizon with multi mesh and also have Federation. On top of that, to.

C

Clean up the confusion, because it's apparently no other same mood, image to means the same sync so.

F

Yeah, either way, we're gonna have some confusion between these two things yeah and we have to choose a refining term to describe the behavior of look. It's a single administrative domain, but you are controlling where services are visible, based on your own criteria, right because that's effectively what you're doing I.

A

Personally, don't like split horizon at all: I think it has different meanings in different contexts and if we can replace that with multi mesh they'll be awesome. So.

F

I might have a multi mesh is right. Just the same reason. We had a problem with multi, closer and multi control. Plane are people conflate it with deployment apology.

C

I personally see it as different resumes.

A

F

So if we can find a term that describes the the behavior, which is the the desire to separate service visibility by region or locale without using the word multi I would be all for it.

C

Horizon doesn't have that much I would.

A

Say like either global view or some other you. If that's what you want very very narrow taxes.

F

So you could say well yeah. It is widely used in DNS right for this use case, but we could say service discovery, regionalization or localization or partitioning, either way we're gonna wait, it's not the primary term right. It's going to be a refinement within the documentation. It doesn't have to be a first class reference term.

C

A

That's different costing because that refers to.

A

G

To go back to your suggestion of thinking about how somebody makes a decision about their topology and and the the hierarchy of these decisions, it seems to me one of the the the highest, if not the most highest hierarchy of these decisions is mi one administrative domain or multiple right and having a word for that. That is, that is clear, seems important and I would say. I would suggest that that at the bottom of the criteria we've been discussing is whether services can resolve to the same or different destinations.

G

That seems like a feature which is true, no matter what your truck topology is and I wouldn't.

F

Disagree with that I think in the the when a person walks up to sto, they're, probably already thinking in terms of their own administrative domain, right as the the most common audience. No question.

C

Centralized decentralized.

C

A single IT department that controls the entire organization you are centralized and then you, each team, is managing its own.

F

So I, like I'm, happy to use a term like service discovery partitioning or something like that right to describe the use case and yes, I. It's a detail. I still think single, mesh and Federation are the like. Those are the two entry points into the the discussion that, like that I like this administrator domain, that's the terms of thinking it right there intuitive and then multi network or single network is an implementation detail and service discovery. Partitioning is an implementation detail of your mesh, as is AJ.

D

F

So it's gonna inflame what you're trying to do right, but if we're trying to what we're trying to do is explain concepts to people and then we're gonna give them use cases that are gonna help them make a decision about right what to choose right, how to actually go to production right. So when we describe multi network, we're gonna explain why you might want to do it or white my you might have to do it and if you have to do it, here's how you do it right.

F

That's that's what you would do with an implementation detail, but.

C

If you go to a customer's, the first question is: do you have an IT department that is controlling all the networking everything or each decision?

C

G

Part of that conversation is also do you need to coordinate with another organization who.

E

G

Their own administrative domain, or do you operate in isolation and.

E

G

I would I would suggest that the the answer that we operate in life in isolation is not as frequent as we think so. Yeah.

A

Three right, Shannon and I. Actually, like a lot dislike this, we should be able to produce somewhere this decision tree that people can follow and be directed. You know to recommend it architecture or recommended deployment order for them. I think it. This is very good, but once you are like let's say you have administrative domain or multiple, let's say: if the answer is one administrative domain, then how do we again like name that difference? Because we haven't made a decision on that.

C

We agree to agree on a network, but.

A

It's not about the control plane here, it's about like the horizon.

C

Configuration so configuration can be centralized or decentralized.

F

And I, don't think people think in those terms, I think they think in the terms of I'm, only going to make certain services visible in certain localities and like whether it's one or.

E

Ten gigs right.

F

But that's the terms that people are thinking it so I think we want to use terminology that reflects that and not the detail of the control plane. Yeah.

E

Alright, thank.

F

You so yeah, so I think you know whatever you split horizon or you know uniformed service discovery or partition service discovery to describe the distinction right. We can eight like we can protest. Some of the terminology with users and I can go to our UX group and I asked them probably.

C

The visitors yeah.

F

So partition service discovery I would be fine with that as a starting point and.

E

F

Told look, these ores understand, split horizon then you know, maybe we should shift, but one.

C

Thing I learned is that usually PM s-- and UX people have best our best to fake names and engineers to pay what is usually a waste of time, but.

A

We're just like differing procrastinating and making.

C

F

What we do is we will pick names right and we'll list the the synonyms for that scenario and we'll go and ask people who are not us. Yeah.

C

F

What their feedback is and does it help them understand? The use case.

E

F

We should also list out what we think are the kind of top five to real deployment. Apologies. We think people will use most of the time or top three and a couple of sub variations of them and document them. Yeah.

D

Should we do a.

D

D

F

Like I'll actually ask the PM's here to run it by customers, we have enough customers, we can reach out.

C

A

So some of the things are documented in the meeting notes, but so so, basically just to go back to the like the survey's visibility. So we have. We have a partial partial service partition.

H

F

A

Partitions right.

F

And you could say: partition versus uniform or global.

D

Using my side, car network policy or even our back to scope, my services all.

F

A

F

Well, I mean even forgetting about the actual physical implementation details, the network. What are the reasons? People partition service discovery right it's to indicate to consumers what they can or cannot use in a particular regional context, or look physical or calorie contexts? You cannot call you know the US.

C

F

It's more about helping people understand.

F

Between services.

F

Right people choose meaningful names for a reason, hopefully.

A

Okay, so folks, who are actually five minutes over time but I think we did make some progress on this. So thanks to everybody who really commented, I think it was a very productive discussion. So some actions out of this is I, guess the UX study right so the PM's and valuation. We asked some of the UX.

A

F

Work with the diamond refining the anomaly sure, then we can run it by I'll. Get the product managers to run. That.

A

And like Vadim, I, I suppose you're like update the document based on everything we discussed and somebody will have to go and change the is to IO site right. So we have to fix that documentation. So please feel free to open issues and just assign to people only.

F

Wait until we've done a little bit of UX study right.

A

A

F

In terms of like effort right, this should be done as a sprint. So look.

E

F

Till we resolved it and then we can go and do this holistically because we don't want to keep redoing it right.

H

I will look stupid to the community too if we keep changing our names. Okay,.

A

Well, yeah, so what we definitely have to like once where's the DA. We should all keep using the same name schists. Otherwise people would be very confused all right, so there were two more topics which I'm actually glad to have deferred, for you know for the importance of this topic related to motocross there, so they are not super important. I we can like follow up in two weeks from now, but with the you know, the toc response, it's in the document and I also put I open the github epics and put the link in there.

A

So we can like discuss in two weeks all right. Okay, so thank you very much. Everybody see you in two weeks and enjoy the rest of your day.