Antrea Community, 14 Feb 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Antrea Community Meeting 02/14/2022

Description

Antrea Community Meeting, February 14th 2022

A

So good morning, good afternoon or good evening, this is the andrea community meeting and we are back after a break for the spring festival, and so thanks for joining again the meeting and for today uh we have a presentation from bin and rojan regarding a multicast policy enforcement.

A

So without, um let's not uh I mean, let's go straight to this presentation, so yeah I will be in uh russian. I don't know who's going to present, but uh the floor is yours. Please go ahead.

B

Okay, I will first to introduce the multiple multicast network policy design and later routine view how I will introduce the metrics for multicast.

B

Let me share screen.

B

Can you see the conference page.

B

Yes, we can okay. So far, entry has implant even implemented uh multicast traffic, but there is no network policy for multicast, so all packages will be passed for the further part for security. Consideration reason: it is better to support multicast network policy.

B

Here is the pipeline, and I proposed our first review how lmp table to deal with ldmp, query and idmp report and later it will deal with multicast egress, and then it builds multicast traffic and the multicast ingress for the rdmp table. We will define rules to block fgmp, query and also rdmp report to specific specific pod and yeah, and for the egress we multi-class egress.

B

We will different rules to block or allow the rules of the traffic come out from specific port and for the ingress we will defend rule to allow or drop the traffic to the specific part. Here. Is this ready? I want to reuse the existing defined for in smp, but extend with two members in the rule. Here is the multicast address. That means the members to store the multi-class address.

B

I want to use drop or allow, and another member is igmp means whether the traffic is for idmp traffic or for normal traffic and here's the sample for the definition.

B

So the first feature is to block idmp query to pause, since, in our current implementation and trade agent will send rgmp query to all parts on the node and for this condition, if we should block, if we want to block the addre query to pause, we need to have some change for the current implementation.

B

First, entry alien will create a group for the address for this address in in the idmp query. That says.

B

And then, when there is new port created and reagent will add, support to the admp query group.

B

um Well, there is a part to be deleted and reading that will remove the part from the rmb query group and then, if there is a rule to block admp query to specific part, for example, if we use pod selector, which matches f is f1 and then entry element will check the metapod and and at the same time a trade interview also maintain a list that the port is using, which bucket in the group, then we will update the bucket, for example, for the part which matches this label will give you.

B

We checked that the body is using the bucket advance and we will add, drop actions on pakistan and then, if the rule for to block the smp query deleted, then we will reset the ignp ldmp rule to the original one yeah. This is for the identical query to to block this is the rule to block idm bigquery.

B

Any questions for this.

B

Okay- and the second is lmp report from pod now for this con from this condition.

B

Normally we entry agent has a packing and the normal normal actions in current implementation, but for lmp, v2 and v4.

B

Obs cannot recognize idmp group rise so to improvement. The block we want to implement this feature in entry agent. This means for the idmp.

B

For for idmp protocol we will track the network test is oh sorry, we will check the network source address.

B

If it's from the desired app address, then we will check if it's from the pod and if, yes, we will submit this packet to controller and then the package, the agent and the agent will check if the package should be blocked in in this condition, entry agent will send uh view. We will define a query api to for event to check uh if the package should be dropped.

B

um If, yes, I trade interview not adds a part to the multicast address group and it will have some calc. It will calculate the packet dropped by this rule. If, yes, if it should not be blocked, then an agent will add a part to the multicast group.

B

And the for the the last feature is that to limit the specific part, to send multi custom to specific multicast api addresses, which means that we should block the you know from both the source and the destination and for the ingress. We will check the matched part and then on the node. We will defend several rules to block the traffic multicast traffic that that comes in the metric port. First, we will defend rule to, uh for example, if we want to block the multicast traffic from this app address and to 225.1.2.3.

B

And then we have this conduction rule and later we will allow this conduction to this right and we will also in this condition we will go to the table for multicast ingress metric and in multiple in multicast english traffic. We will define rule to drop the packet and also we can presentation.

B

Sorry, hi, okay, I will continue yeah go and then in this table we can also calculate the number of packets dropped by the by this rule and for multicast egress. It is, I think, nearly the same we will define, we will define the rule on the node that runs the source pod and we will also check the source app address and also destination api address, and also.

B

Load, the construction id to this drag and then in egress metric. We also define a rule to drop the traffic and then we we can also calculate the package dropped by the by this rule. Yes, this is for the two features for multicast network policy.

A

um Thanks been and anything else to add regarding the design implementation, I don't know otherwise we'll probably check if the community has questions regarding this proposed design.

C

uh I do have a quick question or comment on the api design for this, because um I know that uh you know on on the api. You said this uh is add. There are some fuse added to the acmp or amp ingress or us rules, um but the way I see it, I'm not sure like if the rule would make sense.

C

If, in a single rule, there is actually a normal peer and a multi-cloud multicast appear at the same time, but it actually makes sense and if not, then maybe we could consider doing something different here, for example, adding a new type of rule, which is ingress, multicast rules or egrasmatic class rules. Just to you know, differentiate them from the current rules so that we have clear um structure on how things are gonna be enforced. I I'm not sure if I'm experi expressing myself clearly here or at least have we actually considered this alternative.

B

Okay, I know in fact I also have the same concern on define. If, since there is it's not always the same for multicast rule and normal rule, I want to what I didn't. Why I didn't define new. Is that I want to reuse the existing, um but maybe it's they're not quite related.

D

Actually, I was thinking other way. Could we just use ip block to specify the multicast iphones? Why.

E

D

Need a new field for multicast soldiers.

B

If zooming, for example,.

B

We just use this epic block other than that yeah. We can use that, but if we use every block director, maybe it's not clear for the customer what what it means, maybe customer will defend some address. That is not a multicast address. Maybe a normal app address.

D

But it's fun right: they can, they can have, they have zero, they can in one algebra they can have both unicodes and the molecular side appearance if they want to.

E

B

D

B

Okay, what I want is to make to make it maybe simpler to implement to introduce a less judgment for the ipad rights if we put them together. Maybe we need to start with. This is if this ip is a multicast address,.

D

So is that that chair is pretty simple right.

B

D

It's very simple to check it's a monogamous or not.

B

D

And also for igmp, uh I probably need to understand better if we really want to differentiate rgmp, I kind of feel I'm just thinking about. Should we just use a generic mechanism. For example, we can add a new field for ip protocol and then, if you want to allow this on igmp, you can put the protocol value 2 right.

B

B

Yeah, we can do this I want to. Maybe I think this is a more struct to our chart for the packet.

D

Yeah, my, I think the reason I'm proposing some general wages like, if you add new protocols more and more and you'll end up with many fields.

B

D

Short definition.

F

uh So if we we, we try best to reuse the existing fields. So I think if we can do that, we don't need to introduce a new tab, multi tab for the rule right young. How do you think.

C

uh Yeah, that's what I think I mean.

C

I mean this is a little bit of a personal preference, but from my involvement with the you know, upstream kubernetes, upstream discussions on resources and stuff, it seems that in most cases, if we really really wanted a new resource, that's uh essentially built only for a multicast type of policy enforcement.

C

Then usually what the community would suggest is that we sort of like sketch scratch out an entirely new api, which is simply focused on multicast support, so that we don't have to reuse any sort of like ingress and egress rules and add um really weird fields like it is igmp in there, because um you know it it's uh it's a feud that doesn't really make sense if you're defining a regular acmp and it's sitting there, um so it kind of like makes um defining other ac mps a little bit harder uh or or it's not at least it makes uh the work done in you know, validation web hooks a little bit harder, because now you have to invalidate a lot of um uh illegal combinations of applying a couple of fields.

C

So in that, in my opinion, it will be. You know better off to separate this intent as uh as uh as best as we can so that you know the acmp will stay as is or or we can added some. You know new, maybe rule sets in the is in the acmp, but not to reuse the current ingress and rules. But that's just my personal preference.

A

Young one one question on your comment: um not clear to me: if you're advocating for adding a different kind for multicast policies or a different section in entry and network policies,.

C

I mean my my idea was like I'm fine. If we go with the second, but I would prefer we go with the first. I.

A

Think that's that's my.

C

One here, yeah.

A

I understand I, I understand yeah, it's better to be clear because yes, so, basically airing a completely different type of object for multicast network policies. Is there any case where this could be a bad user experience? Because I'm just talking thinking aloud here, because there could be a policy, a security configuration which we normally could express with a single policy, but now requires us to create two different objects: yeah.

C

That's true that that's a that's a valid, that's a really valid concern, but I mean in that case something like you know: you have a you, have a single applied to and some egress rules and some multi-class uh multicast egress rules. You know something like that would uh would would be a little bit clearer, but.

A

Yeah, but I don't think honestly, this is a big concern now follow me. Probably I'm saying something stupid normally uh an application.

A

Let's say the types of traffic sent by an application are completely distinct between unicust and multicast traffic right. So it's typically like uh like uh the same the same application it probably if it sends it needs a configuration for multicast traffic and then another configuration for unicast traffic, so it might actually make sense to have them into into distinct objects.

A

Don't know much about multicast, so maybe I'm saying something stupid.

A

In any case, uh I tend to agree with your statement young that it might be easier to define such this policy in a new object, and it will also require less, I can say, less special casing for anthria network policies, because we don't have to worry about flags and invite combination of invalid uh attributes and so on.

A

And so there are comments on the chat, uh so first wiki is correctly suggesting that we need to open up these uh for public review, so the contents that has been reported here should be available on the entry github for allowing the whole community to review, and then there is also a common, a comment from zhenjun. He would like to consider something where you have action deny protocol igmp and so that later we can support more protocols as well so um ginger. So basically, you are suggesting to consider igmp another protocol in entry network policies.

A

D

Yeah, I just want to explain my previous comments with this example. If we are the more generic way to define protocols- and it can be like something like this- you have a political field- individual that can be uh igmp and later it can be icmp and other parts of support.

C

It already has, I mean we already have a product called field which can take ccp, udp or icmp right. So I I I didn't know that why we would have to need a sigmp flag here. I didn't know the context, so um if, if we can integrate this igmp um protocol into the product called field, that will be the best case scenario. In my mind,.

D

Yeah, I think the the reason I guess it's more like it's lgmp product makes sense only for multicast.

G

I wanted to ask: why do we even need this igmp flag if we already specify that it's a multicast address.

D

A

That was my question.

D

Yeah, probably bing can can explain more, but for my understanding that we want to separate block igmp.

G

I thought that was a mechanism through which we implement. This is by blocking agmp messages.

D

uh Bing, maybe you can clarify, I think you can. We want to see. For example, we allow multicast for the we block lgp. That's my idea.

B

But this is a parity defined by ipm.

B

This is why the first is to define xmp, to block smp queries and the smp reports from port and towards pause.

E

um Actually, I think the requirement is that so um the user might configure the np network policy to um drop some hmp package from the specified port. All uh so I mean that's, maybe we don't drop all ignp packets, but only the lgmp reports from um one two three of pulse, but we could allow the agmp report from the port four five. First, one.

B

Yeah and I think in this way we can block some posts to join specific multicast address.

B

So, for example, the customer are using it for, for the tv show, only the paid customers can we can access some resources, then maybe they can define some multicultural address that only specific users or maybe ap addresses can access. This multicast can join this multicast address and receive the tv shows from the sender, or maybe this is a star.

F

uh Being on the team, I think, maybe offline, we can discuss um about the the requirement whether it makes sense to the multicast use case. So I think it should be a action item to be in to get something clarified, especially about the requirement, but in general I actually agree with tianjin. I think if we can't do something generic in a generic generic way, we do need to introduce those specific fields. Otherwise, maybe we have to yeah. We extend our entire network policy, but we just unnecessary.

F

So I think maybe you can just think about how to reuse the the fields to see how to support multicast and if it introduced some complexity, complex logics into weblog into the logic, but it it can. It can simplify the user um in face interface. I think it is um yeah. It is worse. It works for us.

A

Thanks vicky um yeah, the only other question that I have is that more from an operational perspective like now, do you have uh do we have? Do you have a a poc for lisa? Do you have a working implementation uh just want to figure out. You know once this is reviewed by uh the andrea community?

A

How, then, how far we are then for having a a working solution.

F

Yes, I think, being you already made, made some poc code to implement network policy for multicast traffic.

B

Yeah some poc, but no code only for the open flow.

A

Rule I see so basically, you created a code that generates the required open for rule and what is missing is like the api changes and all the processing of the of the cia of the entry network policies to create these rules is that correct.

B

A

Okay, and uh so ideally, if this is a put for review- let's say publicly, then this could be a target for andrea, 1.7 or 1.8. What do you think might be the most suitable target.

B

Okay, have you later update the code after it's talk on google.

F

A

I was actually simply asking whether you think this is more uh an item for on 3i that we can target on 301.7 or that you would like. Instead, uh you think it might need more time and therefore should be targeted for entry at 1.8.

F

Yeah, I think the um the first thing is to finalize the api the only way to analyze api. Then we can maybe discuss the implementation based on that. So I think yeah you can move the design document to the github or google or google docs and share with the community for more discussion. Then I think at least in entry 1.6. Let's finalize the api design.

A

Okay, yes, that's that's a good idea.

F

So so rogen, I think yeah rocha also have another part to yeah to share with us.

H

uh Sure I will share this with.

C

H

uh I will share the multicast metric design uh in the next few minutes and I have created um and github issue for that requirement and.

H

As we can see that we have two sections of multicast metric required requirements, as I copied from the prd doc and.

H

So you can anyone's.

H

And we have two sections for the multicast matrix requirements and one for parts, states and another is what multicast group stands so um and and so to show both of the stats I need to. uh I will introduce two cuddle commands.

H

um The first one is um get multicast stats that shows uh multicast, that's in part view and basically it this command will implement uh these four requirements. That is multicast package drop by transmitted by poi interface multicast. I can draw a job by received by the file interface here here. The chest meet and receive means ingress and egress, and also igmp package, discarding asset accepted, and then all of these requirements are also shown by different multi different network policies.

H

So uh in the in the json view, you can see that for each network policy we also show the stats here and also. This is the aggregate aggregate steps for one part, and we also have another kokado command called multicast group called members in this command.

H

We show the mappings between multicast group and the multicast parts in the whole cluster, so we also have. We also have these two requirements that that's uh we don't. We don't need to expose these stats in the in the cluster. While we only need to show uh these two in the uh per node, so I will introduce another command called multicast. That's that that shows the inbound and outbound stats for both these inbound and r1 multicast sets for that part.

H

Okay, uh that's the uh that's the apis! I want to basically want to implement so here next. I will talk this apis in detail.

H

So just so, basically for the the kubocadoc commands.

H

I want to, you know, accumulate the stats on different nodes from an entry agent and aggregate them in the.

H

Entry controller so.

H

I will reuse the the struct called nostalgic summary that the the no stats memory is previously definedly used by implement implementing network policy stats.

H

So I will add, this extra field called multicast- that's here that contains the multicast, that's in the in that in that node.

H

So um so there is uh uh uh there's a network policy reference here and also, uh uh although these fields, I think they are self-explanatory uh for for their network policy and also, I will uh add, a field called group join this, and this list is a group of multicast ip address that the pod join, and this view is later used by that command.

H

H

Also, um so how do we get this stats.

H

So for first ping, pong job upon job ignp allow ignp job this test. We can uh uh obtain.

H

Sorry, uh there's something wrong with stuff.

H

Okay, um I will um so there's some. There are some stats at the final instruct. uh Also I need to wait to I need to describe. How can I get this stats and the ignp allowed an idip job?

H

They are retrieved by processing packaging of gmp ignp report message uh as being described. We don't do not implement network, implement, blocking or accepting igmp message by by adding obvious flows. We are implementing by using packet processing or packing in of ignp message.

H

So uh when uh when, when we are processing ignp republic doing packing, we can create some data structure to store the stats, while processing ignp report message and also a function that created by b, is uh um uh that I can create. By being that, I can use to query if that uh is that ignp report message will be allowed or dropped.

H

uh So so, after this, after after the process I described the step of the ign loud and ngmp, jobs will can be up can be obtained by the h8 engine and also we have. We need to collect inbound job in our bank jobs along with inbound and album in the multicast stats. uh This stats will be created by passing the uh passing the flows I added um in the in the pipeline.

H

So, as you can see in the pipeline and.

H

There are some.

H

I have add a table called multicast ingress per metric and also multicast ingress per pound metric, because we are collecting the stats based based on for each pot and.

H

So you can see in this flow. uh The network test is for each part in that entry in in download and create a network test to match, match it.

H

So so after uh so when, whenever when the multicast traffic goes through, this apply, the uh the traffic will go, will go to uh go to this network policy first and uh and resubmit to the table. Multicast egress per par metric uh I described and so prepared stats where we collect uh based on passing, passing the flows.

H

uh I I ended here so after after getting this stats in the h engine, the this desk will report to um and entry controller and aggregate them. Finally, we define the public apis for display these stats through group cuddle and the api group. I think it will be stats and tree.

G

H

And these are the api endpoints also, uh I was considering commitments, integration and uh I have checked the discussion in this thread and I think committees is not suitable for this kind of stats, so I will not plan to integrate it and that's that's the end of my presentation.

H

Please, please ask questions if you have any sex.

A

Is there any question for questions regarding romantic statistics.

G

uh The celebratory I was just pointing out on the chat that this api design may need to change a little bit if the multicast api presented by bin for network policies is uh updated to incorporate like.

A

Yes, that's a good point.

G

Because I think, as it is right now it it makes sense because bin was proposing to introduce dedicated fields for multicast addresses and and igmp switch in the network policy type. But if we converge to something more generic, I think we also need something more uh generic here, um mostly referring to the part tied to stats for multicast network policies.

G

I think that's item 5 in the list here: 5 and 6. Yes,.

A

That's correct, so we can say that perhaps we want to have first conversation about the apis for multicast network policies and then following the outcome of that conversation, uh the apis for multiple statistics will be determined.

A

Okay, any other comment: question curiosity.

A

Okay, it seems that uh it's all in terms of community questions for today. So thanks a lot bin and lua chen for doing this presentation, we look forward to seeing a specification, a proposal for multicast network policies on github so that we can finalize the api design and proceed with the implementation.

A

Yes, so if the community doesn't have any other topic to bring up for today, I will probably consider this meeting concluded, also because we are just we have just three minutes left, so I will just wait for a few seconds in case. Anyone has any additional topic to bring up.

G

Oh, we have 13 minutes left. Oh.

A

That's right, that is right. We have 13 minutes left. Actually sorry, I you know now, I'm amused that uh meetings are 50 minutes long to give time for to people to move to the next meeting, but I didn't. I did forget that the entry committee meeting is actually an hour long scheduled for an hour so yeah. We have plenty of time to discuss new topics. So if you have anything to propose I'll wait for a few seconds before closing the call.

G

Well, I just wanted to make a quick announcement that the uh the old entry apis, which date back to before the 1.4 release, have been like officially removed and they won't be present starting in 1 1.6.

G

So those are the apis ending in. I think it was tenzu.vmware.com and we replace those apis by entry, dot, io, apis and so yeah. We no longer serve the previous apis starting now, and uh we're able to remove all the mirroring uh code that was taking care of mirroring old api resources to new api resources for backwards compatibility.

G

So we've been supporting the old apis for about a year now. So, um as per the deprecation policy, we can remove them.

A

Thanks antonin and uh for uh community for developers of the entry community, this simply means that in case they are still using these apis. Maybe they will realize that the prs would the code in the ps will stop compiling right, so they just need to rebase and update their code.

G

Yeah, that's uh also a big change for users right, but that's why we supported the old apis for a year.

A

G

A

G

Upgrade in a non-disruptive fashion, but you have to do an intermediate upgrade. So if you're using entry 0.13 first, you have to upgrade to 1.0, for example, and then transition your uh your crs and then using.

E

G

Mirroring controllers, and then you can upgrade to one docx 1.6.

A

That seems like a reasonable, reasonable, upgrade buff, okay, so anything else for today.

A

All right, so it's all for today thanks everyone for attending, and uh I wish uh the community a good evening or good night up here. If you are the united states a good day or a good afternoon. So thanks for joining again and talk to you in tweaks time,.