Antrea Community, 7 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Antrea Community Meeting 12/07/2020

Description

Antrea Community Meeting, December 7th 2020

A

Okay, so on the agenda tonight, uh arun and other folks from intel are gonna. Give us some more information about their uh proposal to support cnf use cases in entria, and if we have some time remaining after that, we'll have like an open discussion in case uh folks want to bring up some issues all right, uh our own sideloo, you guys, can take it away.

B

Yeah, thank you antonia. I don't know you can start the slides, yeah sure.

C

C

C

Let me know when you guys can share see the screen.

C

Sure hi good evening, everybody, uh so this is the follow up discussion uh to have a little more deep dive on the cnn proposal. We made a few weeks back uh before we start go with this. um I would like to request side loop to recap, a little bit on the um cnn of use cases and stuff which we discussed last time so sideload. Would you like to give few words.

B

Yes, adam um yeah, as we uh discussed last time, uh cnn and um cnf use cases uh to support uh service, functional chain and also uh by product.

B

We are going to uh provide the details on how we are going to support the multiple interfaces, uh including the sri gov or any subject into any virtual network interface, and also going forward how we are going to support the service functional chain to support the multiple service, functional chains, which is one of the common use cases on the sd one and other areas, and also we are going to expand the solution.

B

uh We are going to show the solution, how we are going to expand uh further on the load balancing on when multiple service multiple function instances are supported, so how we can load balancing within that one. That is what we are going to present today and we start with the use case. What is the current use case? How we are looking it and why multiple interfaces interfaces are required to support the service functional chain from there?

B

We are going to present a virtual network uh virtual networks, how we can create that and how we can maintain within uh andreas scope, and also uh we are going to present how we going forward.

D

B

Are going to support thermal difficulties yeah, I think we can go to next slide here.

C

Sure yeah yeah, thank you. I think stephen wong has some uh question or we couldn't hear yeah.

E

Just in case we've got um newbies here who don't understand the terminology? Can we define cnf, vnf and sfc in this slide, so that people who tune into the broadcast can get a definition and know whether they're interested or not.

B

Yeah sure stephen uh cnf is a cloud native function. Something uh vnf is like um virtual native function. uh Example. If you see firewall, we can have the physical appliance or we can have the vnf and cnf is a cloud native form of the same uh network function and sfc is service functional chain how we can shine together. All these cnfs and vnf's, based on the certain required criteria, and we have details on how showing up cnn, pnf and service functional chain in the next slides.

C

Great yeah, thank you uh silo thanks for the quick summary on what we tried to cover today. um Hope it was. uh It was clear uh for the community people, uh let's go with this right now. um So yes, sidelore mentioned the actual problem statement.

C

Here is the cnf deployment um and network function chaining support on andrea cni right so to enable andrea to support the uh cnf deployment and also service function chain of cnf functionalities not limited to, though, but we say currently it's specific to cnf um for mantria, while while we use andreas a cni for kubernetes um and obviously uh the one of the main criteria for that is multiple interface support on andrea. As all of us know, it supports only a default network interface right now.

C

All the communication goes through the default interface, which is created based on the kubernetes cidr right, so so to support the chaining. We need more than one interface, so we need to add support for that. Also in andrea um actual requirement to achieve this is to support uh dynamic uh virtual network configuration. We will we'll see in in a while like what it is exactly about, and a provider network um and multiple interface support per part.

C

That's what we saw as part of the problem statement too and functional chaining right, so this would achieve the typical cnf use cases so to achieve a typical cnf use case uh using andrea. So we need to support these requirements.

C

uh To make things a little more clear, um so we took an example um specific to sdvan. um Security uh network function, function chaining, um so this we can. We can see that there is a core network here. You can call it as a provider network okay, so it is kind of your building, van or or the isp or whatever right.

C

So you take the core network in this case, um and then you have a kubernetes cluster um so where you have a bunch of micro services running, and so you have the network definitions like a provider network that is left right and then you have virtual networks defined. So these blocks are actually your cnfs, so the slb is the uh service load balance.

C

uh This is a next-gen firewall and sd-wan cnf right, so we are not deep diving into what these guys do. Basically, all I want to communicate here is these are the cnfs which we are looking to uh add support for right um so to to see the actual traffic flows? What we, what we are supposed to um uh enable uh configuration configuring through andrea, uh is like one of the thing is like from one of the microservice um you need to.

C

You need to go through the cnf to change your traffic communication from your microservice to the external network. Okay, this is one use case.

C

um I don't know it's some smart song here yeah, you see that so the next use case is actually from the core network to one of the micro service, pod and another use case is possibly like, so we're not even getting into any of this uh services. It's communication from the core network to the external world right. All of all of these communications has to go through a chaining.

C

uh Mainly you want to load balance it and you want to traffic shape it or or our kind of firewall protection here right and then the sd-wan use case is achieved at this exit and it goes to your right provider network right. These are the use cases. These are the traffic flow patterns which we aim to support um when we climb andrea, can support these enough use cases.

B

uh I want to add here why virtual network support is required and multiple interfaces. You can.

C

Oh sure yeah so um basically to um yeah thanks uh cylo, so uh the virtual network support is required here uh to to enable chaining between the cnfs right. So when a packet reaches your slb, there should be a way for it to uh communicate or go through your further chains to the external network right. This flow is defined by the crd, so we have virtual networks between defined between cnfs to have your communication moving forward yeah. So any.

B

Questions and also to add to our own here we are not suggesting any changes um uh to service functions like slb uh nextgen firewall. There will not be any changes within the applications or microservices.

C

Exactly yeah, so these will be seamless the configuration. What we try to achieve with the virtual network and things will be seamless to the cnn functionality itself.

D

Hello, I have a question, so the virtual functionalities are deployed as part or they are deployed as virtual machine appliances.

C

These are not parts, a pretty good question, um so these are the virtual network, which we kind of picturized it here. This is going to be logical, so basically you're going to create another interface here right, so the interface subnet would be defined uh in terms of the virtual network. Crd.

C

Those are parts yeah exactly those are parts. This is the logical communication path for you, where we say it's as simple as that, you have a subnet defined here, so the gateway for this interface would be the gateway, the the right net, the left network of your nfg.

C

Yeah any other questions here.

C

Okay, let's move on uh this is the sample uh virtual network crd. So, as we saw here, these are the virtual networks which we plan to define right if there is a cnf use case not limited to one or two just we showed an example here, um so um this basically tells us the subnet right. So what subnet um I'm belonging to? What is my gate vip address in this case right, so we define virtual network one virtual network. True, and uh there can be you can you in this flow?

C

You can even use srov interface itself if the, if the part supports or the cnf uh the platform where the cnf is running, it supports the sri ov. um We have a crd defined for sreob use case as well right, it's from the andrea point of view. It's another network interface in this case for us right. So the key point here is um the subnet information uh for the virtual network is maintained in the global ipad right.

C

So uh we would expect the andrea controller um to provide uh the ipl, provide the uh ipam um for this specific subnet in this case right. So, if some, if, if a pod is defined like when we go through the um network, chaining uh crd, it may be a little more clearer. uh So when some when, when a pod or a cnf, is trying to join um network chain right, so controller should realize that and he should be able to assign an ip address using the global life app right.

C

So we're going to use a global ipam uh to to allocate ip address. So uh current traditional thing with andrea is like we have a local ipam right so per uh per agent uh which handles the agent-specific communication for agent-specific uh part default uh network right for service function. Chaining, we will be having a global ipam um which will be used to locate ip address on the cnf scope.

C

F

So in your example, here uh you different sublights in the spec that I mean when user creates a cr, they they specify the sublet me yeah. That's right!.

C

That is expectation. uh Okay, it.

F

Is coming as part of the crt definition showing the case of the uh functional chaining? uh Who will allocate the sublets your issues.

B

Are yeah here uh we are defining the networks, actually virtual networks, how many we need it uh based on that and later, when we are defining the service function, and we will mention that um between the uh you can go to the.

C

Ci yeah, that's right! So if, if you see the cr, it would be much clearer, yeah.

B

Here you can see that between the slb and nextgen firewall, you can see the virtual network, one.

F

C

Yeah, so this this is what tells us. The controller has to now see this visualize this based on the network chain, and he should be able to locate um one interface on slb towards the subnet and one interface on next-gen fireball towards the subnet.

F

Yeah, I'm just trying to understand uh in the completed solution. uh Do we have an automated way to allocate sublets for every virtual network.

B

uh We can do that. uh We'll come back on that one here. That is good idea. Instead of hard coding and subnets yeah we'll come back on that.

C

Okay sure yeah, that makes more sense. Yes, yeah yeah. For now we we focused on defining it through the crt yeah yeah. It makes sense to have it dynamically assigned.

C

Thank you. um The another main thing here is like the interface creations at the pod scope. We expect it to be pushed through the power annotation right, so assuming that this is for your primary and and the default network based on the kubernetes crd right. So that's not. That remains intact for the multiple interface and sfc use cases.

C

We we plan to use per notation to push the interface details to the specific part.

B

Anthony and janjan last time has given the feedback uh to have the multi-kind of annotations. We are going to follow the same.

F

Okay, um yeah, probably uh I've, also checked more inputs from more people here, at least previously we saw people like martha's, um but probably we can. We can ask more people and to see what's european sure.

G

Yeah you're- probably talking about me uh changer, so um so, because we had a use case if you go back to the packet flow iron outside. um So our use case was that we wanted to basically have a part that intercepts traffic like.

G

It could be basically connected, um like your sov. Let's say: usrb is also partly set, um so whatever traffic is going from one uh port uh from resident one and that's a namespace, I guess uh to resident two uh pot- is going through the srb.

G

um Let me there's a br our plot right, so we want to have a packet flow where whatever traffic is going from one plot to another part, it's intercepted by another plot.

G

Right, maybe I can draw something yeah.

C

Yeah, I I I yeah.

H

I think the understood.

C

That yeah yeah, I think at least we have uh side lou, myself and rama- has understanding on what you are actually proposing. um You're clear right. I think you guys are discussing on the slack.

F

Yeah, I I think it's like uh in our top. It's like some something like servicing searching. uh So basically you want to insert some servicing in for some specific traffic flows yeah. Finally, you want to get the bike. The traffic after water service to the original uh folding path.

G

Basically, I think markers I can. I can draw something here: you guys see it yeah. So let's say we have. This is part one part, and this is another part, and let's say this spot is usually sending traffic to that part. So it goes directly right. So the idea is that the packets are not going directly to the other part so that it first goes to a second port. It's intercepted basically interceptor pattern and then goes to the other part.

G

So this this part can do some traffic shaking that's just busy idea, but not only for part-to-part traffic, but also for inquiries and equals. So it's just like let's say here's some increase going to that part, so it wouldn't go directly to that part. It would also first go through this interceptor and then go into the pot right. That's basically our use case right.

C

Yeah yeah yeah yeah. Maybe we can deep dive on this. uh We would really want to discuss in detail also marcus on that to understand if this can be supported based on the generic functionality. I know that you guys are trying to. um I mean, like the hijack the flow from obs bridge right. Maybe if I understand this correctly, um maybe we.

E

C

To understand more on your proposal as well to see if there is a way we can map it with what we propose now.

B

Okay, yeah, that will make sense marcus. We can collaborate and we'll see the common requirements or how we can support with the current existing mechanism. What we are proposing or any extension required in the generic way to support it. We will deploy that yeah. That's great.

C

G

You, okay, great.

C

Yeah, thank you um yeah. So this is the network chain. Crd. The main point to understand here is like, as we discussed, we talk about the left provider and then write provider network, and then we have a chaining attribute network chaining attribute which talks about chain between what cnfs the chain between the cnfs right. So in this case we take slb and there is a virtual network one in between these two.

C

So basically the slb and the next hop is going to be your next gen firewall so connecting these two cnfs, uh virtually through your virtual network model right. Likewise, your next-gen packet, when the when the next-gen functionality is done, the packet forwarding has to happen by default to your through your virtual network too. Ideally, this is actually virtual network. True sorry for the typo, this is virtual network two, um and then it goes to your sd van use case.

C

So once the sd-wan cnf functionality is achieved, he's going to go through a default uh network right from here.

E

C

Of your provide yeah yeah, exactly thanks, it's going to the right provider network in this case right. So basically, the packet originate from here goes through this chain of uh chain and then goes out of your right, broader network right. This is what the crt is about. So now the andrea controller needs to understand this and define the virtual network, create the virtual network assign the specific parts into the service function. Chaining yeah anyway,.

B

um I think in the previous one we can stress that what are the interfaces are required for the each part? uh The previous cr shows it right um yeah next, one upon annotations here.

C

Yeah so, uh and as as we see that we we send the pod annotation uh to say there is a virtual network, uh one so we say eth1 and the e3 interface for virtual network two right. So if you take, um if you take uh nf, uh ng is next in firewall right. So next in firewall needs to be part of your virtual network one, and he needs to be part of your virtual network through as well right he's going to ingress the traffic here.

C

Egress the traffic here right, so that that definition is pushed to the part as part of the power.

B

Notation and then we have one diagram also, I think we can explain.

B

C

Sure yeah um yeah so to have a little more uh details here. Right so provide a network. It goes to the ngf um and then it goes to your virtual network, one as we discussed it goes to sd-wan and goes to, um though we say sd van. Basically, it's your right. Basically, it's your provider network- and this is your left right and network sorry right provider network.

C

This is left and then right right. So basically, when the communication goes from your core network to the internet, in this use case, um we go and virtually change this through my service flow right. So to achieve the corresponding service level uh agreements for a specific flow.

F

Could I could I take a look at the old uh channing cl again.

F

F

So why we need to define the gateway ip and the subnet for the live network and provide network.

C

um You you need to give the gateway address for your left, roider, okay, use case right, so in this case I would assume that your the guy who is connecting to here he should have a gateway address which is supported by the slv here.

B

It is basically defining the provider network, one uh junction. It is similarly kind of virtual network.

F

I see yeah assuming uh we can also use the cr to define that in the right. I just want.

E

F

Understand why we handle left and right separately? Yes, yes, yeah! We can define there also.

B

As using the network cr, we can define these two things.

F

C

Okay, so basically, we need to this left and right is required, as in a way to means get the origination of your traffic and your your exit of your traffic right. This is your ingress of your traffic. This is your egress of your traffic.

B

Basically, we can define using the networks, cr network and right network. We can mention in the chain actually right. That is also other.

C

Yeah, that's okay, yeah yeah! I got your point. Yeah sure yeah make sense. Here we can modify.

C

That yeah, so the the key points to mention here um is like what we look at uh from the anterior point of view right. So when we talk about chaining in this case, um so any um so because we still talk about cnf being part of the same cluster right. So as far as entry is concerned, any communication within the cluster is going to go through the tunnel right.

C

I hope we are not missing any use case, which is not using the tunnel in case. If you are talking between parts or pardons enough, um is only through the tunnel right yeah, so um yeah, nothing, oh sure. So uh the key point here is to say, like uh whenever you define a new interface, uh we need to configure the obs bridge as in a way that the service function chaining is handled through your tunnel. It's not going to reach your default gateway.

C

uh The default gateway is used only for your left and right provider network right. Otherwise, if you have n number of chains, you are not limited to two or three right, so we can do n number of chains. So all communication between chains um are going to go through the tunnel as far as your cnfs are bound to be in two different nodes right. So if your cnf network cnf uh is actually in node, one and sd-wan is in node two. uh It's going to go, use your internal communication.

C

So if both the cnfs are being a part in the same node, it's going to use your typical um in node communication right, it's going to be locally terminated! It's not going to go through your uh it's not going to exit your obs bridge right. It's a typical use case, typical andrea use case. Like any part, two part communication within a node is local.

C

Any part to part communication between nodes is going through the uh tunnel, so we still maintain the same flow um for communication between cnfs among parts.

C

It's clear right.

A

Yeah yeah so as far as a packet routing, so when packets need to go from uh ngfw to sd1. That means ngfw is aware of the ip address of sd1.

C

Exactly yeah yeah, that's what the controller's job now to visualize this and assign the corresponding subject, as you can see that 3033.2 and 33.3 right, so two interfaces we have, um which is assigned with the corresponding same.

C

For example, let's say, let's say like virtual network one right, both of them owning an interface on the same virtual network, one. So this this is visualized by controller and he assigns the interface ip and then he has to do a routing configuration as well route configuration as well to put the packet. Let's say you have a ingress here. The egress of next-gen firewall should default to your this interface right. As of now, the andrea has the default route towards your default network right, for example, so we are going to have.

C

We are going to modify the default route to always go through your right side, network.

B

And also we are making, we are preparing the demo. uh We are implementing that, maybe in next to two weeks or sometime, we can provide the demo.

A

Yeah I was more asking about uh so the next gen fire will, when it's uh sending sending packets. How does it know that sd1 was assigned the ip address uh 33.3 here, yeah.

B

C

Service chain yeah.

B

C

Yeah right uh side load, so it's based on service chain right. So this is what we see. This has to be visualized by the controller now right. So this, for example, if you take an uh next-gen firewall, he is part of your virtual network one, and he is also part of your virtual network too. Sorry for the typo. This is two right, so he's also he's part of two different. Do two different subnets right. This is when, when the controller reads about your network chain, he he sees this right.

C

He sees this and he is going to configure um your agent. The agent will get the configuration request as in form of the part annotation to define the specific thing. That's what we are also going to use the global ipam to get an ip address from the specific subnet.

A

Not really I'm talking specifically about the next gen firewall software, which is like processing packets, and when it's done with uh with a packet, how does it send it to the next app yes yeah? Who sets that a destination ip address once the destination ip address is known? I understand how the packets go to the back.

C

Cnf right so, basically, when the next gen firewall is, is done with this job right he's going to push the packet out. So when it comes to you, the typical route lookup is happening. So when you do a typical route lookup, so your default route is going to point towards this network.

C

This is configured as part of your uh chaining.

A

Why is it default so.

F

I'm telling you I I think it doesn't know the ip of the st1. It's my understanding. It's just now. The last hope is submitting.

B

C

C

So it's a typical example of your anterior right so in even in andrea, so any traffic which is uh which is destined uh any ip address right. So we have a default route: zero, zero, zero right, uh it's by default point towards the um andrea zero. The same the same logic is followed here. We just modify your e0 to the eighth one in this case, for example,.

A

Okay, but my my packet going out, it has an ipad error. What does the destination ip field says in that ip editor.

C

So your destination ip address will be your um actual destination, ips and then internet, for example.

A

C

Yeah so, but then, when you send the packet, you are going to do natting in this case, so he's going to go with this.

C

Your destination will be your internet uh traffic, your your end, destination.

A

Yeah, that's never rewritten yeah. That makes sense. We talked about this last time, yeah right! Yes, uh we have a question on the chat. um I can read it if you want so.

C

A

C

um I don't see there, yes, exactly.

A

I can read it for you from puja. Will we be inserting something in the geneve overlay header or use a tlv to track the chaining.

C

um Not really yeah go ahead slightly.

B

Yeah, we are not inserting anything for the chaining, because we are completely depending on the uh sfc cr, so based on the cr, we are going to route the topic. We are not using jenny header because of rtlb, because if geneve is not supported, only vxlan is supporting. Then it is not easy to support.

H

C

H

Telemetry to see how the package is going right, yeah feature, if you know, if it's going through four or five different chains, if it gets dropped somewhere or something happens to the packet, uh how do we track it.

B

Yes, puja for telemetry and debugging purpose. We are planning that, but for the functionality point of view we are not using that for the telemetry and for the other purposes uh we are going to use that.

H

So you're going to use like a geneva okay. Yes, yes, yes,.

C

Thank you any other questions. We have.

C

C

Yeah, so uh we're going to take a faced approach in this implementation um so before the one one of the base requirement for us to support the sfc is the multiple interface support right so that we are taking it as a phase one implementation on andrea uh once that is uh once that is achieved, um so we will. We will enable support for uh sfc with single function chain.

C

So, while we discussed a few weeks back um uh antonio antonio and then had a question like hey, how do you guys going to support multiple service function chain right, for example, if specific flow wants to go a specific chain right? Currently um it is. It is not as per the phase two it will not.

C

It will support only a single sfc so, which means any packet which is going out of a specific part from for not the part for from your leftward network is going to go through a defined single uh single defined, uh sfc.

C

Okay. So, as a phase three, uh we plan to support multiple service function, chaining on andrea as well, using the classifier that we still are defining the requirement for. So it's still in the early phase of defining a requirement to support multiple sfc.

C

uh Functionality support multiple interface and sfc is achieved as far as what we discussed in slide six to eight. If this is achieved, which we can safely climb, that multiple interface and sfc support is enabled in andrea um for multiple service function. Chaining, that's what I said. We need to have a classifier based definition, which we are in a very early stage to define that we are working on a requirement to define multiple service function in.

C

C

Yeah, um that's all we have um any specific questions.

F

So I have another one so in your chair, I think you only need a chain for a given services, only a single instance right, um but in the practice uh does any solution. Support like a multiple instance of a single service like you can.

B

Yeah, yes, uh along with the classifier, we are going to support multiple incest instances of the single chain uh example where next gen firewall you might based on the load. You may uh uh span some more um next gen firewalls, you can say 8 or 10 or 15 parts. You respond on a next gen firewall load, balancing between them based on the mac address. We internally we defined the solution. Just we are getting.

B

We are reviewing that one, so we can present in the next when we are giving the demo, along with that, we can present uh load balancing. Also.

F

uh Okay, uh let me understand, I think, for the first hope I think I can stand on your classifier can decide, which will be the instance 200, but for the intermediate uh hope. uh How could the last hope decide, which instance of the last hop to for the traffic.

B

uh Based on the service function, definition, satisfaction, chain, definition, left network and right network right.

F

Sure, for example, in this example, if you have multiple instances of ng file, um how slp knows uh which will be the last one yeah.

B

So every every slb we will have the mac address based instances. We are go um example: you are having the next gen firewall. Maybe 10 instances are running then, along with the slb, we are going to bring up a kind of small load balancer along that one. So yeah keep track of all the instances of the next gen five volts. Then.

F

uh Yeah, it's based on the micros.

B

F

A

Sorry, in this case, is the load balancing done by slb, or is it done by obs.

B

uh We are still debating that. Okay, we can. I can come back on that one. So, but at least we need to track all the mac addresses of instances which we are spanning so that we are going.

C

Yeah, thank you. So we we plan for a demo on on this. Like uh we have implemented, uh hacks is kind of a poc solution on the andrea we targeted to give today, but then there are little more pending on that. So we would definitely be able to uh showcase that by uh next community discussion.

C

Okay, um so maybe we can take up this topic uh further with uh marcus um marcus. You would like.

F

I could ask one more one more question before that, so in your in your planner, you plan to use the same os bridge as entry or untrained uh overs bridge or beyond bridge, or you you plan to create a new one.

C

It's the same bridge. There is no additional bridges required in this case. Maybe we need to add sniff additional flows, yeah, okay, additional flows. uh Indeed, the current poc also targets your target, the existing code. As far as you give the subnet information, so it would create another via pair and define the obs flows automatically for the new set of addresses, but in zero you can also create another bridge.

F

Right for the secondary interface.

C

uh Yes, we can, but do we see any benefit of doing that.

F

I I don't know originally, I I probably just just like I. I don't know how you are going to either flows or injury. I was thinking if you uh want to add a different set of totally different set of flows and they don't want to interfere with the existing flows.

F

Maybe you can create a bridge.

B

Yes, both we have thinking through actually so at least we are currently implementing with adding the additional flows right and we will think through if anything is conflicting with the existing clause or any problem we face. So obviously we create the second page. The work will be the same more or less here.

F

Right, another thing that, um since you were connected to the pride lateral right, I assume it's a villa network, then you need to add the uplink to the bridge um right yeah. um I'm not sure that we're impressive until you are behind the bridge or not, if you add, move any physical need to the bridge in some cases for you, you even need to move the ip to the bridge. So I I I didn't sing solo attack. I'm not sure what will happen if it's the same bridge.

F

Maybe I don't get that correct. Yeah.

A

Sorry, why do you think they have to move the interface to the bridge.

F

I mean uh if, if we want to kind of provide the network, it must be some willa network right.

A

F

So you must have a physical interface to be the uplink on the bridge, so you can send the pile to the milan network.

F

Is that true or not.

F

I guess so, I guess either you direct a connected interface to a bridge or you create another bridge and it connects to bridge.

F

uh Sure, however, let's talk about since I didn't really spend much time so maybe don't have much to discuss here.

C

Yeah we can, um as cylo said we will. We will deep dive a little more into see like how what benefits we may have with two different bridges yeah. The currently like the flow is defined as in a way like you are giving another subnet and um you go and modify your obs flow that because it's going to go through the uh tunnel right, so you will just mask your source address and exactly the same same kind of mechanism um like how it goes between node node right now, yeah.

F

Okay, um if we can see your uh example implementing like the flows and the bridge setup, and probably it's clear to us to understand.

B

Yeah, exactly whatever you see, we are implementing it demo, so those flows. We can review it in detail.

C

Exactly yeah, that's what we target uh to give today as well, but somehow it got delayed a little more than what we thought.

C

Thank you so marcus, so you you want to go a little more on your use case and we can try see if maybe you can go through the use case and and see. Maybe if you can visualize it here, is there a way that we can use this service function uh chaining for cnf to achieve your use case as well.

G

Yeah yeah, that would be great yeah. What we're currently doing is that we deploy.

G

um A daemon set and the daemon set is also within it container, changing the open flow rules to redirect the traffic to to those pots right.

G

uh I think I sent this open flow rules to the channel so um that currently works quite well, except that we have problems with increased traffic, um which I think iran he's also in the chat he's um he's mentioned the exact problem in the chat.

G

So maybe we can have a look at that later too, um but I wonder how our use case will now um map to your proposal, um because if I see that it's um it's, uh I don't understand yet how your proposal would work with uh pot to pot traffic like in the same cluster.

C

Yeah, so maybe what we can um is like, okay, so part, two part, uh possibly that the the actual thing right. So the part has to default its traffic to um to the cnf right and.

E

B

C

Yeah, basically, the cnn will be your gateway right. Just take a take a home home use case right, so we all have home devices connected and then there is a gateway router at our home, uh so assume that gateway router is your cnf right. So all the communication has to go through your uh gateway. In this case, your cnf right, like like how I talk between my device, one two device, two at home right through my home gateway, router right.

C

So maybe we can have uh communication go through the uh cnf, um so the cnf can't decide uh whether to allow the traffic means. Basically, you can do a traffic shaping there.

C

That is one possible thing, but maybe I mean slightly, you want to add something with this.

B

No, you go ahead and yeah just I try to understand marcus use case uh marcus. If I understand writing with the use case, you want to redirect the traffic between the parts right.

G

um Not necessarily redirect um so it's more like a filter, so uh it should end up at the same pot right so this uh like, if we have now, let's just draw this cnf here right, so it's definitely connected here to the network and it will have traffic sending from that part. Now, let's say like traffic. That's going from that point to this part here should be intercepted by another part, so, basically like a filter so but that uh network function is then not rewriting the packet. So we're not.

G

We directing the traffic uh the changing the destination ip to another plot right. So.

E

G

Like going as uh as a filter to this network function, in your case,.

F

uh Do you assume there's no changing application now so, for example, for your for your source for investing port?

F

This should not be aware of the service you inserted.

G

F

Perspective from your post perspective, they should not be aware of the services um you applied right, um they're, just talking to each other. From their point of view, yeah.

G

So they're talking to each other here, so it's not changing any any packets this and let's just call that filter yeah.

F

Probably you don't want to use secondary interface, whatever right, the port just have one ip and one interface.

G

um This port could also have another one, so we could like have a second interface, also connected to that interface to that network here and uh like uh so, the traffic shaping is handled by by one interface, and this interface is what we use for.

G

I don't know for um for http traffic, sending out some data or something also done in the port.

F

But what ip will be used for your traffic? uh These two interfaces will have ipls both have ipvs, so only one individual appearance. In your mind,.

G

Both both have an rp address, yeah.

F

Okay, you're saying uh for traffic require shipping. We can use the second interface in the secondary interface ipos to communicate.

G

Yeah yeah exactly yeah, so it's it's not a problem. uh We were trying to use maltose to add a second interface would just and that second interface would just uh do the traffic shaping. I see.

C

So um what is the actual use case? We try to address with actually it's basically a traffic shaping right, so um yeah. We would like to know.

G

So what we can do is, for example, is uh two two six uh two use cases like. Let's say we wanna um security. We don't want dynamically, decided that this bot is not talking to that part right, so the filter just doesn't allow it or it does rate limiting reducing the the amount of traffic. The most part.

C

Okay, so this can be in one one way. This may be a bottleneck right or unless you have some ways to overcome that um just trying to understand more, it means basically, the expectation here is: every traffic must hit through and cnn right, exactly yeah. So it's between part it's within the node or uh across nodes. It has to go through your cnf, exactly yeah.

B

Yeah, sorry, no, basically, you are trying to use the cnf to filter the traffic and rate limit, so you are going to implement the functionality within that particular cnf or you are going to use the flows to control like acl flows in the obs.

G

Now the functionality is in that uh in the pot, so the flow, so it should be done in in user space from the plot, like the decisions based on application labels and so on.

G

So it's a little bit more complicated right. It's not just possible to do that with uh with some rules. That's why that's? Why is there a specific process funny with.

B

That yeah yeah markus is it will be the single part or single cnf, or is going to be multiple cnf. So in future you are going to use to shape the traffic.

G

Well from our from our users, we just need one: okay, we don't need, we don't need multiple, okay,.

C

Yeah so silo. The key difference I see here is like um the actual service function. Chaining will be handled based on the route modifications as well right. So in this case uh it should be seamless uh for this use case. If I understand this correctly right so part, a to part b um should be seamless. uh I mean like. We cannot modify the routing table of pod to divert the traffic through cnf. It may.

B

Be an easy case.

C

Yeah but yeah right so.

B

Basically, they're having they're going to have the card which will shape the topic when the traffic is coming. To that part, it will, the part will have the rules or something shipping yeah right, so it is yeah.

B

I think use case is more or I think it's a different from currently what we are proposing in the sfc site. Right we can think through. Can we use uh sfc like you, can assume that a slb kind of one part, but um it is not changing? We have to think throughout that one.

F

Yeah, I think this one is stephen from saying cf. Actually, in an england technology, we call it service service, insertion.

B

F

Want to insert some service- and in our case we saw some service- can be some physical network service, for example, a platform that you want to insert service for specific traffic for the once the service being enforced. We want to continue the folding parts um yeah, let's smile and something with the problem.

C

So marcus is this a supported use case in some other form? I mean, like others, see a nice or support this or I'm like. Maybe we're just trying to understand um if this is an implemented or kind of a working solution?

C

uh From your point of view- or I mean, are you exploring this as a new use case for andrea.

G

Are we using that already similar with uh on top on istio.

G

So istio is like, um so it's a very, very similar light idea, just like, instead of doing it uh it still because he has just for those who don't know have like there's a layer, seven boxy for each part, and then the communication between each bot is then always ejected by by the side car uh who could also do uh weight limiting or um could also decide to drop the traffic right. um Just like, I think, it's more elegant to solve that problem on the a3.

G

So that's why we bring in basically this um yeah this this kind of functionality in uh on layer. Three, that's! Basically what we want to.

B

C

Yeah, so our current sfc proposal may not address this um right, so it should be seamless. uh If we are okay to modify the route update on par then, yes, uh ideally it should be seamless right.

F

Actually, I I was thinking about um I'm just thinking a lot, uh I'm just actually I'm thinking. um uh If we take your service training approach, uh what we what can happen, we can still define a chain and then uh for the classifier. uh We just need to define some way to say um for given traffic, for example, from port one to port.

F

Two uh using uh this traffic should enter the chain and then also she will have some flower in the os bridge to to capture the packets and then redirect your searching and, of course, in a specific case, uh marcus one uh in his chain. He has only one service, and that is some shipping service, uh but to make it more generic, we can still uh use your chain definition.

F

uh We can allow multiple services in the chain, for example, we can do cheaper and then ng firewall, but at the end of the chain, uh there's no right network.

F

We just see the parachute follow the lawnmower floating pass to a thousand import based on ip address, for example,.

B

Yeah with classifiers, we can use that one yeah.

F

B

F

Yeah, that's just my you know some rough ideas.

G

We define a chain like that one here, that's just either a chain, then we have some matching that either increase or equals is matching. That or parts are matching this chain right.

F

uh Right, basically, the classifier in arranged proposal.

H

F

That classifier implementation will just um probably based on some matching criteria, to see what path should be uh for the tool that you can.

G

A

Has to happen it's a chain with a single service right.

F

Right in this specific case, it's a single.

F

C

Yeah so basically.

G

Any traffic it would cover our use case, yeah.

B

Yeah and I think the classifier we can cover that but use a particular use case where we have the multiple service chains.

C

Oh okay, so maybe I I can take this offline with you to understand more slightly, but maybe I was just trying to understand how the classifier can be used uh between parts in a node and- and there is a kernel communication right.

B

We can add in the classifier certain rules cscl rules anyway. Obviously they are taken in the similar.

H

B

If that is matching the particular criteria, we can divert that in.

B

Kind of use case.

A

So basically, in that case, uh the left network and the right network right, those are the actual default pad network default community spot network. Yes, yes,.

F

Right, you can see it.

A

Okay, guys so sorry to interrupt. We have like two minutes left, uh so I think we can keep discussing this offline and uh since we have a few minutes left, is there anything that anyone wants to bring up.

B

And tune in our side, we are going to provide the demo offline. We will discuss with you on the slide.

A

Okay, perfect and uh please send me the slides uh arun, so I can upload them to um oh sure, wiki.

C

Sorry we missed to send that last time.

A

No worries no worries, I think those have more info, so I mean you feel free to send both slide decks if you want, but.

E

Sure, thank you.

A

uh And yeah, so I think uh next community meeting on december uh 21st, we can do 30 minutes on the entry retrospective release retrospective with a stephen wong, and we can reserve 30 minutes for the for the demo.

A

Okay sounds good great. Thank you all right! Thanks everyone for joining thanks, arun uh and uh side lou for the presentation and I'll see everyone in two weeks.

G

All right, thank you. Thank you. Thank.

H