DASH Community Weekly, 15 Mar 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SONiC DASH Workgroup Community Meeting Mar 15 2023

Description

Continue overview of PR348 NAT Scenario with 2 use cases: ClarkLee @ Alibaba
Prior feedback incorporated

Some deviation from DASH model
Unify flow table
Make it an ENI based it can be more standardized

A

And go off camera. So if you can, you guys see my screen yeah.

B

A

Great, so uh what we have are the notes from last week that I sent out those are, on the left hand, side and last time we talked about um pr348 and we had the snat dnat scenario with two: the the use cases from Alibaba.

A

We got most of the way through it and we had um this feedback here that I also sent out in the notes, and then um we were going to save a few minutes this week to go over the rest of it, and this is the the pr right here and then, if you guys have another PR assempting you'd like to cover after that, um chime in or let me know in the chat window. I can monitor that.

A

While we finish up this one, um so does that work for, for you, Clark, okay, yeah, okay, we should get started. Do.

B

A

Me to keep sharing Clark or you want to do it. Yes,.

B

I want to share you. Okay, all right right.

A

It's the up arrow in teams.

B

B

We're sharing this guy sharing this one: okay, okay, can you see it I.

A

B

So um we are, uh we are trying to I'm I'm trying to uh cover the uh a few uh comments uh from the last meeting. um First one, we uh I changed a topology uh connection to the topology. According to the suggestions to um to change the name of the dash device, it must switch rather than the appliance it's in a it's an in a proper name and then I uh I. Add some um label here uh denoting that uh the packets between test device and the VM is VX.

B

Lantern, node, packets and the internet traffic is IP only and this row of the dash device is acting as the net Gateway, because the first change um and then a few okay and then I will show another uh figure. This we combined uh uh I combined okay, sorry a little bit slow.

B

B

It's not big enough. Can you see uh the figure clearly? Okay? uh First, we, uh this is a generic net outbound packet processing pipeline, combined together the ethnet and dnet uh one different uh uh this when the packet from the.

C

B

Let's start it with the outbound flow pack, Urban Flow, when um the outbound flow table is actually one table.

B

uh When the VM sends traffic out, it will uh look up into this table and if it get hit, it goes through the fast fast path and then, if the pack, uh if the lookup miss it will go through the slow path to check the s-net rules and then, if we, uh if I hit it.

B

If the lookup uh hits- and we do, the we select the source, IP and Port, one clarification here is: the port is actually designed uh assigned by some algorithm. We are running, but we did not show in this diagram because we want to make it more simple.

B

We can take it as it's configured, but it's automatically managed by the by the software or some missing logic here, and then we do the with app lookup and set up the inbound and outbound flow table, and if we uh look up into the ethnet Rule table and miss and this packet will be dropped.

B

This is any question on this. uh Album processing file is combined together.

A

I think I have it: okay,.

B

And then the next one is the outbound processes. When the internet packet comes in, uh we look up into the inbound flow table. If it's, if we get a hit and then we do the uh go through the fast path, replace the desk IP and port and encap the xlan and do a routing and send the packet to the VM, and we if the Intel flow table is missed.

B

And then we look up into the s-net Rule table. And then, if we get the rule, we search for the vtap and then we create inbound flow table and album table and then do the rest of the actions in the fast path and send a packet to the VM. And then, if we look up into the dinette rules table and get missed and we drop the packet- and this is a overall Bill combined, the ethnet and dnet any question.

B

uh This is the. uh This is another suggestion that uh we should combine. This ethernet and dnet processing flow together.

A

Right that was a suggestion from Gohan last week, yeah.

B

Yeah it it should be more cleared um yeah, it's more clear.

A

Gohan does that satisfy what you were thinking.

B

um Well, Honey's understand.

A

Yeah he's he's on mute right now: okay,.

A

So I guess we could check with Gohan or Prince.

D

Yeah sorry I was.

B

D

Is your uh is not flow table and dinner flow table combined or they are separate.

B

Yeah uh actually combined one table there. Actually one table.

D

Okay, so so then you can rename.

E

D

Just a flow table does it matter whether this is inbound flow table versus outbound flow table.

B

A

Are you saying just call it flow.

F

Table yeah they're. All bi-directional is what you're saying so. You can't have inbound and they're bi-directional.

F

What do you think.

B

D

Bi-Directional Your Design will can.

B

We confirm that yeah. Actually here we can see the the real table here. It's it's different because we we distinguish the packet Direction, so we um put only we create two table here uh previously. I I mean one table that is ethnet and dnet is using one table, but inbound and outbound is uh different.

B

You can see this picture table key.

B

This is inbound flow table key.

D

What's the difference, I couldn't see, it I mean what is the difference. Yeah, okay,.

B

Yeah, it's clear more clear: what is outbound flow table, oven flow table. We have uh inner source, ipt and port and protocol and BNI as the key and foreign.

B

And the action is different: I can't feel when is rewrite IP and do encapsulation and another one is right: Source IP and do DQ decaturation yeah, so they are different.

D

I guess I didn't quite understand why you need to bring an eye on your own upon that shot. You guys mentioned that you know you're just differentiate, whether it's a very exciting or not right. So what is a? What is the significance of the bi here? What would you use for being right.

B

uh Here a week is oops sorry, this one uh vni is two.

B

Oh sorry, let me check it.

G

Basically, this is for the the from the VM to the public side, so Vietnam were used to identify which service or what tenant to write. So the IP address might be the same. So that's why you have to have the BNI, because this is the inner IP. The in IP is basically the tenant IP.

D

So in this case, isn't that um you know we can introduce some kind of similar concept of UI and then the and then to the classification right. So they would be. uh You know more similar to the dash pipeline.

B

um Yes, we can do some very I updated another place. This is this one, the dnet rules.

B

Actually, this one is similar to eni concept, but um but we all- but this is this one, for example dnet Rule, and we can see that the IPM Port is mapping to the to one v-net and and a address.

B

But additionally, we have a port here.

B

If we eni uh identify a VM- and this actually means a certain VMI plus the service port number.

B

Go on do I, understand correctly this one.

D

I mean I'm still trying to understand the you know the picture here right so um I mean.

D

In the in the dash I think the floor table is bi-directional right, so um I'm trying to understand is it possible to make your flow also bi-directional.

B

Right direction, no.

G

That's one difference is like in the York in the current Dash case. The policy is attached to the B9, but in our case we don't have this attached like uh actions, we basically just say this is a global table, because we we kind of like I, say you like. This is the gateways where every traffic will be applied through. So this is a global rule, so we don't really need to apply in it.

G

So then we don't that's why that's we put the Vietnam as part of the the key instead of a cascading, the cups.

A

Because it's a Nat, Gateway yeah instead.

D

Let's say, for example, for your air snap use case right. So if you, if you first, have a connection that going out, you know, once you see the connection, do you also create the inbound flow table for the coming right? So.

B

G

Global writer, so because it's a global policy, so we don't associate the policy with the Vietnam. You.

D

See no, no for your outbound! You have this v9 here right, so you associate the vi here.

G

Yeah but the the things is like we don't attaching the policy we live in line. We just say hey. This is the global like, say part the. If you see that we have the dnet and the S letter rule, so it's kind of like say the global.

D

No, no, no, no, no I, I'm, okay, so yeah, no I understand the policy part, but I'm always saying that. Is it possible that you know for the flow table for the floating yeah yeah for the flow table that we can? You know adopting the you know, you know same model as a as Dash right. So then you know there can be some kind of videos or those things right. So um yeah.

G

Then, which means that we need to trigger the vni lookup first, then we need to cascading lookups right. So then we need to organizing the the so then it will be the similar right in the sense it's like.

G

If, if I have two lookups, the VN lookup eventually give me some hint to say which table flow table, so it will be multiple flow tables, one for each midnight or I need to create in the hint to put as a key in the flow table. So then large group is the same as this format.

G

I think currently, you will have separate the flow table right for one for each of the main line.

D

Yeah I, I, yeah, uh well, no I, think I. Think in if I understand the you know it just derived what you and I, and then you know in that. Maybe in that flow table there is a healing eye match as well. I'm, not sure you know it's a uh you know physically, it's uh uh maybe the key also have a young idea: hey Prince, have we checked the our Dash? Do we have a young guy in the floatable loot camp or.

C

You and I in the.

H

um I think yes, I, think the CT lookup is based on eni as well. Okay,.

D

Okay, okay, but somehow, but somehow the the impact doesn't have a uni right.

H

In what direction should have Enis in it.

D

No, no sorry I mean yeah I know ours have, but this one doesn't have this one, though, that that's why the the lookup key is different right, so is it for the internet. They have no way to know this, which unit it is so, therefore, the only matches the outer header five Tuple. Yes,.

E

So yeah another key difference that Gohan, you said right about bi-directional flow in dash. You basically learn one entry in the flow table right and then based on the direction you can swap the source IP and destination IP, but it's kind of physically one entry. In this case. If, when you get the outbound packet, you have to actually learn two different entries in the Pro table: they're, not the same entry. Dash is different.

E

One entry is only one physical entry and you swap the destination in Source IP, based on the lookup, usually based on the implementation, but here they are completely different keys right. So, if you think about the hardware implementation point of view, you have to learn two different piece for like one pack from one packet.

D

But the entire session also, you know, even though it's a flowing tree, but the action would be different right. So you know the the inbound versus outbound I think uh the action would be different, so I, don't know how the differentiate that okay I feel like uh still there there's some difference here in terms of action right. So but more my thinking, you know the reason I'm thinking is, you know this flow table will have other attributes.

D

For example, you know the TCP, State tracking or the sequence number tracking right, so all those things might be comma. Therefore, you know I'm trying to figure out if there's a way to unify that. Therefore you know whatever whatever develop on the dash. You know for those other Flow, State tracking will be reusable right. So you know if we don't have that kind of similarities, then you know um you know you know, since it has been developed, a dash wouldn't be uh useful for this, and vice versa, right so in terms of flow tracking.

D

There's a lot of commonalities there. So therefore, I'm trying to figure out if there's a way to to to to to unify, does it make sense.

B

You mean you mean to combine a more feature in this one.

D

No I mean you know. Flow track itself is a is a complex, uh State machine right. So you know, for example, you may need to track the full TCP State. You may track the sequence number. You may value, there's a window size right. So there's a lot of uh you know different features Associated just with the flow table tracking, but if we can unify you know the flow. The flow table format between you know this one, the dash pipeline, then we can reuse.

D

You know whatever the feature developer, for one project will be a will, be reused by another project right so that that is my main uh uh motivation to to together since unified in terms of flow table, because the one of the key one of the key for the dash project is this. You know the dpu can do stats state for things. You know which this means that flow tracking right. So so that's one of the key fundamental feature for the for this. uh You know the the dash project. Therefore, you know the float table.

D

You know I, think it's a fundamental feature, fundamental building block that can be reused crash multiple. You know these Dash scenarios.

F

But I agree with Gohan because whatever gets done in dash will be highly optimized over time and you want to take advantage of that. You don't want to to to have a different way of doing things. That's not as efficient. You want to reuse as much as possible. There's a lot of companies who are optimizing this right now, and you definitely want to take advantage of that.

D

Yeah, you know, for example, in the future. You know ha right, so the main ha is about the flow table, a chair right. So therefore you know if we can, if we can have a single flow table, you know modeling, then whatever they did in dash. You know can be also reused in other project. If we are fundamentally, you know having some difference in terms of flow table, then you know, then the work cannot be leveraged right.

D

So because uh I don't know if you guys use H3 or not, but you know I think HP is a very, very key feature.

G

Yeah, but uh at this moment, ha is a handled uh by the platform because different platform HJ stories different at the moment, so we so that I'll be very interesting to see that how we could unify all these uh different approaches right, because my understanding is like a dash right now. It's just Define the behavior models, so this behavior model may or may not be. The real Hardware like like models, because the hardware could use in people could be something else.

G

The implementation could be different, but just say we just defined as a behavior model at this moment.

G

So that's why I will see that if you could combine them, but that's just a software or the from the conceptual point of views. That's fine for me!.

D

I mean that's what we need right: I, I, don't know what you mean by behave me. You know every we Define the behavior model and all the you know the dpu vendors that the Implement Dash will be conformant on that behavioral mode. That's what we need right. So you know I mean I. Yeah I mean for Atria. I saw yeah. Of course. There's a you know difference, but fundamentals is the flow replication right, so yeah. So so exactly right. So that's my point right. So yeah.

G

We can yeah that's why I'm also like, from a straight point of view it just my because my experience and like at the age, the more like I say just to the state you got to do the flow level. Think you can do the data plan flow. Sync, you can do the control ground for the sync, but the end of the day just say: I need to make sure both sides are in sync. But how do you do that? It's a very render specific.

D

No, no, that I, don't I, don't think you know we have a basic design right. So you know you know. The point is that let's say you know on the dash they did the edge of the flow sync right. So then you know you play if they if they want to onboard the you know this scenario and you also require ha which requires a flow sync lame, but your your flow table is fundamentally different from you know their flow table. You know the dash flow table definition.

D

Then they may have to come up with another implementation of the H3. The flows increase right so which is not.

G

um I, don't think so right, just over the flow is the flow right. Just the key might be different, but the flow at the end of days, just entry in the hash table you're, just thinking from so the from the the that point of view, you're just thinking the hash to entries from one side to another side.

F

No but they're not you're, not using a shared table if you're going to use different key formats right, you can't just say I'm going to use a different key format and use the same Table app. Does that make sense.

G

Let's start with that again.

F

You're still you're saying it's the same, but it's not the same. You need a different table because your key format is different.

G

Yeah so in this case, I.

F

Probably was thinking right now we have one table, one pool table: okay, we could combine this into one flow table, so it can be shared and perhaps the keys as appropriate. So it's actually you can separate it, but it's still one flow table. What you're suggesting here is like having a a whole nother flow table which is separate from the dash flow table, which is not very efficient by the way, because the flow table is like the largest consumer of of all the memory and you're talking about separating.

F

You know the two flow tables two different.

G

Types of flow tables, yeah I'm, not sure that if you want to think same, for example, you what you have like say two like uh features on one car, then you have another two car. Each have one features so you, which means that you will think that particular table off so I, don't think we will only have one. If we only have one table, then we limit ourselves right, say: for example, you have one table for the net another table property for the for the we need to mini.

G

Then my question is like: do you want to make sure that both car must be have the exactly the same table? Then we pretty much have like I said only one table or you say: I can have a and b combined to do the single for the net and ANC combined for the we need to be.

D

Oh no I, I, I, I, I, okay, I, don't think we get to that kind of details right now, right so I think, oh in general, the you know what I'm saying that the approach you know the you know, for example, some fundamental approach. uh You know it's better to align. So therefore you know the the because the vendor invested a lot and you implement the flow table. You know for flow track. You know because because you know no matter whether it's not or you know, we never National.

A

D

And what the fundamental you know building block is you know the flow tracking you.

H

D

State tracking, the TCP State tracking, all these things right so, but if we I I'm I'm, not saying that you know the flow table should have exactly the same match field. You know same action field right, so I think that depends on you. You know use Case by use case, but some fundamental data structure of the flow table you know, should be aligned. Therefore, you know the investment of the whole community on dash can be reused.

G

I understand that that's why I was seeing like good. Have we on? What's the requirement for the ha at this moment what we allow that uh module was able to do the sync. My on from my point of view, this is the kind of requirement from my side because we could have a different applications running there and then we will have different tables. So then that's why I would say surprised that you see to heard like you say you can only do the A to B sync, you cannot do the AB AC sync.

G

So that's my what.

D

Is a BSA sync.

G

So, in the sense like I, say, I have one feature because it a lot. Eventually, it's a logical table level thing not a physical table level. So in the sense like, if I have two tables in on a I can do the table one. Do the A and B with the car B to the sink then table two I have a and C to do the same because of my service could be deployed at different locations.

G

It's it's very common here. You cannot understand. Hey I have to using a B for both Services.

C

G

So that's why I was saying like if you say the HK can only do only one table, then that's the limitation right.

D

Oh, no, no I, well I think. Maybe we're talking differently. I'm saying that you know the ha currently, the the Assumption the flow table is one logical flow table with bi-directional right. So I think that that's a you know we we do not care about. You know how the vendor exactly implement, but logical and the behavior model part. The flow table is one logical table right. So currently, I think what two we're talking about. Also the behavior mode, but it looks like your behavior model- is too logical table right. So we.

G

Could have a multiple logical, but it really depends on the services right. So right now, I we only put one net at the services out, but internally we could have more. So we we all could put other services out as well, but in general we need to think about how we can make the dash accommodate them right. So we should not like I say that should be the only model like that right.

F

By the way, this is if this goes into this community, it does.

D

Mm-Hmm yeah and I I I I agree right, so you know it's. uh It has to collectively you know to to decide how we want to. You know, build the you know, build the infrastructure that support all different, uh um all different scenarios right, so how to identify well as a common block that can be used on different scenarios right. So therefore, you know when the when the people working on some fundamental blocks, it can be reused instead of say: okay, you know yeah. Of course you know we can also go with the direction saying.

D

Okay, you know, let's, let's for each scenario, we just Define, you know our own. uh You know pipelines right so those things, but then you know it's going to be a little bit difficult for the vendors to reuse, their Investments right. So, whatever the engineering investment, they did I.

F

Think that's where this is uh the conversation is going so, let's say Alibaba wants to write some applications even outside of that. Okay, that's fine, and anybody can do that. But what we're doing here is we are publishing the behavioral model so that six or eight dpu vendors, who have already built like an infrastructure already over the last couple of years- and they want to reuse that and so when we Define something we're trying to make it easy for all the DP vendors to be able to go and implement it.

F

So it's not about Alibaba implementing it's about all the dpu vendors implementing each one of them has to go out and implement this feature set. You know over time, and so that's why you need to reuse because they spent a lot of time, as goons already mentioned, it connection, tracking and flow tracking. All that stuff they've already spent almost two years now optimizing optimizing, optimizing all the time to get the connections per.

F

Second, you don't want them to go and if you want them to reuse as much as possible, because that was a lot of work to optimize it to get the performance that they're getting. So you want to reuse as much as.

G

Possible I understand that part so I, that's why we'll see but like a challenging part is like say say: for example, I could combine this one with the connection tracking, but the question is that, like I said, we should not determine that. Like I said what this is the only model or we can chewing it because my take is like just let's say: hey you have a bunch of features. I can select the features based on what the my business needs right.

G

It should not be say hey because of the dash, then this is the only model we can use right. I assume this is a building block. You have a just like a Legos, so you can assemble them based on the behavior models, so you, but it doesn't mean that that's the only way to do that.

F

Yeah but I almost think that we're talking past each other, because this group is defining the common methodologies right.

E

You can always.

F

Go out and say: I'm going to add these other things, but in order to add these other things, you'd have to tell the DP vendors to go and build these other things which haven't been defined yet.

G

Right, that's that's the purpose for this meeting right, yeah.

F

But you're, what that's? What I'm saying? Is it's not really. This is that. So, if it's your UK use case- and you present it to us- then anybody's free to go and use that use case, it's no longer an Alibaba or a Microsoft use case anymore. It's a dash use case that anybody can use.

F

um This looks like a good use case. Like I'm sure everybody understands that this is a good use case. It's not like. We have never talked about that before, um but because you know it will be a fundamental building block and everybody has to go out and implement this over time.

F

Trying to get this common is is great. Some things, maybe we'll never make it into Dash, because they're very Nation, only one dpu vendor does it for one specific customer. Well, that's a neat application that can be done somewhere else.

A

F

This is not a niche application. This is a very uh actually a kind of a normal Cloud application that one would expect yeah.

G

I agree with you yeah, so that's why you're like how we can definitely.

D

I think you know, especially for this one right so that you know the only thing I think is looks like. Is that for your outbound to flow? You need the winning eye for the inbound flow. You don't need the vi right. So that's a that's a that's a that's a lookup key things right, so you know the action. Of course you know we also have to differ. You know in terms of Direction. The action will be different.

D

Of course you know the action would be different, but I think that the on the flow tracking, you know the key side. How can we unify uh that part.

B

uh In my understanding, if we want some, uh for example, the to unify the flow table, we can do that and but the key will have to expense some of the key or combine these two together to get the most common keys in one uh in one flow entry right and- and you put together the two actions and as some control Flags to denote that the uh this flow entry hit and we should go inbound, Direction and that's I, think that should be okay. If we want to unify the flow table.

B

This is one point I'm saying and and Eddie actually say that um we for uh conceptually, we have a logical table to sync up uh or sync up. One table or I want uh two table or or even more should be the same and consume uh I think consume almost the same memory. We can. uh We can discuss that uh detail, but in con conceptually they are making no different. If we want to unify the table at the front table- and it's also fine.

B

And in our use case here, because we are acting as a Gateway, so we don't care about that um from from the inbound side from the package from the internet, we don't have any vni, so we don't have uh want that as the key and that's the that's why we are uh organizing the table in this way.

I

uh uh You you could, though, have an eni right on the inbound, um for example, um like the dip is part of a global address space right on the inbox on the inbound flow and like are those dips.

I

um You know like I mean those dips could could be um like partitioned into. You know, Enis, like it's possible that the flow lookup in the inbound Direction when it comes without a vxlan and cap, would require like a dip lookup to determine an eni and then the flow lookup, um so like I I, think it I I definitely think it can be unified. It's a it's a matter of um like what do you use for eni on the inbound flow?

I

um You could use just a reserved eni or you could do some kind of pre-lookup before the flow lookup.

B

uh Yes, yes, you are right and then that would be some. um For example, in our use case, it's not it's not meaningful right, so we just strip it. If you say hey, we uh want to unify the flow table from this point. This perspective uh we can add a a for example. um Wild Card thing like like like a global one or all zero or or anything.

A

G

A

A good plan, but.

G

Then there's a the meaning difference, because the one side is only in the dip, the other side in the dip. So because then there will be some confusing also. So, if you want, then the question is: do we want to overload the dip to say hey for the album It's inner dip for the inbound? It's Auto dip.

A

So it sounds like a little bit of confusion versus not having a unified flow table. That's the decision.

F

I, don't think, there's any decision. There is just making a point. Okay,.

A

D

You know um saying: let's say you know, um you know you can have the lookup here right. So you know, based on your you know, inbound or outbound. You have a different lookup e, but they also point they. They first point into a single flow table, which is bi-directional and for the dash. It just happened that uh you know we don't have to use two. You know this Luca to find the flow table, but you have to use you know two different uh set of lookup key.

D

You know, depending on the direction, to find the same flow table and at least you know for the flow table wise, they can maintain a common. You know data structure for.

D

For for their tracking purpose right so.

G

Before that you're talking about the the TCB tracking part, yeah yeah,.

D

G

Because once you go in, you know they're being nice, so that's probably will be shared foreign.

D

D

G

You are not today, like a PCB tracking I, assume it's a separate table like not the same thing, but at least four people right.

D

Hey I HD, it's in the P4 uh I haven't checked that uh you know I, think you Intel did the DCB tracking right so do we also have that kind of interaction? Or you know the um right so I think we have one TCP State machine tracking the flow States right so.

H

um I missed the interaction question, but we have one flow table for the connection tracking that utilizes the TCP States as.

D

Well, yeah, so.

G

Restaurant, that will be the separate table right. It's.

H

G

H

The separate table so.

G

It's basically I can just like it's a Lego block. I can say, hey do the matching with this table, then there's another logical table I can employ for the tracking purpose right. The.

H

Nat will have to be a different table other than the main flow table. Gotcha.

G

Gotcha yeah: that's why I would say like it's more like the Lego, so so block.

D

So then you have this different match, but you are going to pointing to uh uh you know single flow entry where, on that side, you'll have a Ying out and then based on the Ying out. You have a different direction right, so you're not going to bind this action directly to this match right. So.

G

You mean like for the tracking period for what.

D

The tracking right, so you know tracking things yeah right, so they then from from there, then you can decide whether they see in or out and and then go with different actions right. So because because you you will you will first use the use, this match lookup to find the flowing tree, and then you know, and then you know, then you look up those uh you know TCP State and then after that, then you, you have a you. You derive the direction and then from the direction you will go with different actions right.

D

So that sounds like we can't. You know, reuse the basic and you know dash dash flow right. So for this purpose.

G

Why you want to do that? I can't assume what the benefit of that, because the reason, if I feel like it's more complicated to write, because you kind of say okay I- need to overload these impact or netting action to other table right. Is that what you mean.

D

uh Yeah I mean because the basic the flow data structure is, we have one flow table right so then, from there I think we derive those actions, derive the direction and then go with different actions.

D

I mean that's how the behavior model defines.

G

That's that's why I was saying right now. We also Define the separate behavior model right and then we were reusing whatever we could use is. My point is like say, for example, for the necking case: I may or may not need the tracking.

G

So if some cases I need to track, I will enable that, as a feature to the edge cascading, the the flow table lookups. But if it's the case not I, don't necessarily to enable that right. So I try to see why we have to get the tracking involved.

D

So you uh at least you need the basic tracking I've seen package. Then you need to flow timeouts. Those kind of things right. So that's.

G

Right and none like see the services like because it's already depend on like say my customers- how they want to put their services onto this platform right, so I was just providing bunch of building blocks. They would decide to see what they do. That's why I would kind of like say: I, don't want to mix all these pieces together because then I kind of forced my side to say Hey. You have to do that.

A

Ash model at that point: yes,.

D

You don't need the flow timeout. Sorry I didn't get that part.

G

I need a full timeout, but not necessarily on the tracking timeout right.

D

You don't need to like quickly to time out your flow if you have received the same packet being packet.

G

That depends on use cases right so.

D

You don't you may.

G

D

You don't you don't want to efficiently use your flow table because you know you have millions of flows, you come and go quickly and then, if you don't, you know time out your flows as quickly as possible. You may run all of those those uh flow table interests right, so yeah.

G

And that's in the meaning for also yes, we have a single flow. Then I got more necessary to have it because sometimes in some cases I might float might be static. That's also possible, so it really depending it's already kind of where I deployed this. In that scenario, at the Box every number, if I put it on the edge, where I want my customer just to get on the the cloud, then they are trafficking.

G

It well known, Define, very simple rules, but if I own the in the border of the like a public Cloud, then I won't be able to control. Then I agree with you, so it's meaning it's flows. That's why I say tracking may or may not depend on use case.

D

Yeah, okay, so I think maybe you know we're all here. You know trying to trying to help right so yeah yeah.

A

D

You know I think it's a fundamentally right, so this use case. um You know people want to I guess from the vendor's point of view, we, you know the many, the vendors doing the work right. So therefore um you know they they want to I my impression they want to see a more unified approach, so they can Implement once and then you know be able to tap on different use cases. That's why they are here. That's why we build the community.

G

A

Okay, so I'm gonna do a time check. um We have six minutes left. It sounds like we have to flow, lookup um question or more discussion here. um Do you want to take this back into Alibaba, or what do we want to do here?

A

um Eddie and Clark.

B

Yeah we may discuss later or the Orient if we are combining this together, um uh yeah.

A

One more I can provide pointer, more pointers to our documentation too. If we need that um go ahead. I'm sorry, yeah.

B

Yeah and uh uh oh another change I want to mention- is that uh uh I changed the DNA rule format. So it's more easier for uh for you to to understand how the teenage girls, uh for example, uh this this part, is for cleaner uh clarification. This one right.

C

Yeah I think yeah.

B

Yeah, when the internet traffic, okay, this is not the first one right, okay, first one! So uh here we can see how we previously we uh have this, how how to obtain the v v net right.

C

B

And uh we changed this okay, in which one right here we changed and.

C

Now I think you made it a global table right. So there's.

B

C

But I I think based on today's discussion and also what uh John was also mentioning. I believe if we can make it as an eni based, then I think it will become.

D

Okay, standardized.

B

H

Eni base yeah I.

B

Think it's okay, it's okay! For uh especially this one! uh These two combined together uh I, will check the eni definition and and use that way to uh for this to change this table organization right. It's! Okay! I will do it later after this. Okay.

A

B

Plenty of time, yep, yeah yeah, that that's almost all uh the the changes in this hrd today.

A

Thank you. Thank you very much and that's a huge amount of work. We really appreciate it and um thank you. Everyone on the call for the discussion and the contributions. Reshma John, everyone on the call, Gerald I guess um we I'll give three minutes back.

A

Okay and I'm gonna stop the recording and thank you for uh the thought on this Alibaba.

A