DASH Community Weekly, 25 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SONiC DASH Workgroup Community Meeting Jan 25 2023

Description

PR309 (Prince): Dash-Sonic - Update for Scaling/Underlay Routing/ST/PL encoding
squash & merge done
https://github.com/sonic-net/DASH/pull/309
PR322 (Kristina): Update dash-sonic-hld.md
delete/close per guidance from Prince, will go into API format
https://github.com/sonic-net/DASH/pull/322
PR320 (Kristina): Update README.md to include EasyCLA and ICLA
fix spellcheck
https://github.com/sonic-net/DASH/pull/320
PR301 (Keysight): Adding SAI api tests for CRUD operation
squash & merge done
https://github.com/sonic-net/DASH/pull/301

PR289 - Still needs volunteer - Dockerfile.saithrift-client has a static tag in the FROM instruction

PR296 from AMD: Add DASH metering to Sonic HLD
https://github.com/Azure/DASH/pull/296

Pickup discussion re: Metering with Q&A

A

Community called January, 25th and so go off camera here. What I'm presenting on this side is the notes we took last week and the things we talked about and last week we talked about um pr296 and we had some slides from AMD where they talked about um adding to the processing pipeline, specifically metering and the changes in the pipeline here here here and here, and we didn't quite get through this metering bucket IDs.

A

If we want to pick up that part of the conversation and then switching topics, we talked about moving to the Linux foundation and I, put in a tip in the notes for the easy CLA I put that in the notes that I sent out on Saturday and then of course PRS. So I didn't know.

A

If we wanted to kick off today talking about PR's or if we wanted to pick up this metering bucket, IDs conversation, um you guys tell me, are there any urgent, PR's I know that Prince has been working a lot on was it 309. 309 has had a lot of comments, Prince.

B

Yeah 309 I have addressed most part of it. Yep I.

A

Saw that because hanif had something he asked and then um Vijay and it looks like it's taken care of so we had an approve of changes. So has everyone seen three 309 update for scaling under the routing service tunnel, private link, encoding.

C

Yep yeah, okay,.

A

So his next step for meat prints to go ahead and squash and merge. Then.

B

Yeah yeah I think we can Mudge yeah okay.

D

I can do that later on I'm. So sorry that being delayed and haven't added any comments here, but uh we'll look at it and continue to add.

A

D

Want me to merge it, you can merge, it and I can probably add comments on top okay.

A

Sounds good cool and then, um if you want to go through any of this was just prince. Should I just um delete this one or squash emerge it since you're going to do an API.

B

Yeah I I. Don't think that one we can. It should match because it's kind of an open-ended case awesome. So.

A

B

I can close that.

A

Up complete, slash close, that was just me. Okay, great um and I need to fix the spell check on this. One I know that I just need to make some time to do it. So maybe today Chris, you help me with that.

E

A

I have to fix the spell check on 320. I. Think I can do it myself, though yeah um so anyone else before we move on to a different topic, any PRS. You guys want to talk about.

C

Pr 301 uh I had some comments yesterday from Anton I picked them so I think we are ready to March.

A

We got one righty time right. Okay, so I hope you guys can see. Okay, this one is adding to my API test for changing update, delete operation, okay, foreign.

A

A

Sorry I'm just taking a quick look: okay, God, okay, uh anyone else or should we move on to picking up the metering conversation.

A

So let's do that then.

A

um I can either stop presenting and let was it Vijay talking about this or Sanjay.

F

Yeah um yeah I shared my screen. You want to share okay.

A

Okay, BJ I'm gonna. Stop then, and thanks for doing this by the way.

F

Sure so yeah can you guys see the screen.

A

I can can everyone else.

G

F

Okay, so uh yeah just uh just a quick recap uh from where uh from what we had discussed uh uh last time. So this is the uh new outbound packet processing pipeline, where we have the metering policy lookup coming after uh routing, and we have the metering update block, which is also uh which was already there. But this is the place where the metering buckets get updated.

F

So uh no changes here- and this is just the zoomed in view of the pipeline I- think there were a couple of comments here and uh kind of Incorporated them. So uh I guess one was this. uh There was some confusion about this: uh the TX and RX bytes, whether it represents uh uh eni or it represents how the flow is established. So I think we have some clarification on that.

F

So this is a the TX and RX is eni Centric, so just like renamed it as eni, transmit bytes and en I received bytes, so uh doesn't matter which direction the flow is established, but accounting is always eni Centric and we also have included a direction bit going into the meter table which helps us decide which uh which counter to increment uh transmit or the receive counter. So this is just to uh based on the comments from the last meeting. We just updated this diagram, no other changes, everything Remains the Same.

F

So any other comments here, then we can move on to discuss the bucket IDs.

D

um Prince had added uh three types of uh metering right uh policy based route-based, and there was a mapping table based right. um These especially mapping table base applies to the outbound pipeline because it's not applicable to inbound. So uh how are we taking care of those different types of metering here in this lookup.

F

So um uh yeah, so basically, the meter bucket ID uh is coming from three different uh tables. If you notice in this uh in this pipeline, we have the policy lookup, which gives the meter bucket ID. The routing is the meter bucket, ID and mapping also gives the bucket ID. So given the fact that there are three points where the meter bucket ID is derived, we just need a way to uh like a precedence uh policy to determine which bucket ID is the final bucket ID, which goes into Accounting in the meter table.

F

uh So the routing has a meter policy uh enable control, so routing lookup decides whether the meter policy uh should be looked up or not, and if the meter policy uh lookup is enabled, then the meter bucket ID, coming from the meter policy table, takes precedence over the meter bucket ID, coming from the routing table and going further in the pipeline.

F

uh You have a override Boolean coming from the mapping table and if this Boolean is set, then the meter bucket ID coming from the mapping lookup uh or takes precedence over the meter bucket ID coming over policy or the route. So that is what is kind of depicted in this pipeline. Of course, all this would have to be will be represented in the behavioral model. P4 changes all as well.

D

There is a decision made whether we should do the meter policy table or which lookup has to be done at a given time.

F

So the routing has the control over whether policy lookup is performed or not so uh uh yeah. So I guess this is uh this kind of uh incorporates all the requirements and the different scenarios that were put forth in the requirements. uh So basically.

D

Go ahead, please so, which means outbound routing table uh will always be uh looked up anyway, and that will make the decision of the return. Okay.

F

Yes, yeah. That's right, yeah.

D

So this is the routing table per eni right.

F

D

Not the entire routing table.

F

So this is my routing table, so you can see that there's a eni again tip going into the outbound rocket.

H

Hey this is Bud. I have a question about the inputs to the meter policy table um the uh the IP address there. The ca dip is that the same input to the outbound writing table.

F

um Yeah, so this is the packet IP uh incoming uh packet, uh uh inner destination IP. So this is the serial destination IP.

H

Okay um and so for the outbound routing table, the inputs are the E and I ID and the the ca dip. um Then at the top. Here you have the eni table um where the policy meter ID is, is taken from.

H

Isn't it true that the eni table is just a sort of a remapping of the eni ID to the meter policy ID for the input to this table like I'm, not sure how the meter policy table is actually doing something different, then the outbound routing table.

F

Oh okay, so uh I see so so the meter policy table has uh prefix and priority based lookup. So there is uh which is like the outbound routing table does like a LPM based lookup. So the lookup types is the way the lookup is done in the pipeline is uh different. uh I guess the priority is not shown here, but there is also the IP and the priority bit which goes into the policy so.

H

F

Is not a strict, the LPM lookup okay.

H

So, what's the what's the requirement for the policy I'm? Sorry, what's the requirement for having a priority.

F

Oh uh yeah I think that is because uh there was a case where, if there were multiple uh prefix overlap and there is uh multiple matches, then you needed uh uh the priority would decide which meter bucket would win. So it could be a case where there are multiple hits due to uh overlapping subnets, um and there could be in that case that you need to have a priority to decide which entry takes precedures.

H

So there's there's a a need to be able to configure non-longest prefix match Behavior I, think you're, saying.

B

Yeah so basically I think one of the requirements that uh that's captured as metering is. Let's say: if you have a.

I

B

Going to internet right so it could match any default route routing table right in that default route. Routing table. We cannot have just one metering bucket to account for all packets going to internet. So in that we can have let's say some specific IPS to be metered separately right. So then you can associate a meter policy to this default route. Lpm entry and uh and the meter policy can have different destinations to be metered differently.

H

A

Does it matter what the destination is.

B

No, this is like adding a flexibility to to have that kind of metering.

G

E

Yeah this is John, but we're sharing a microphone here so um like. Wouldn't that just mean that you just have two separate lpms like one that you use for routing and one that you use for meter policy like like I guess the the concern is that once it's not an LPM, then it's like you know it's a much more complicated. You know algorithm.

J

F

J

Sure, I, maybe I, think there's a clarification here right, so yeah, uh I I, don't think the you know the override is between the routes. You know within the within the single tables, revise the overriding. You know the parties between you know different. uh uh You know between different um matching point right, so this overriding that these you know meter policy versus routing pointing to the meter pocket right. So that is overriding there.

J

It's not within the table. You you need to do the override right. So.

F

Yeah yeah so I think physically. Also, these are like two Separate Tables one is a LPM lookup, pure LPM, based lookup, and here it's a policy with the IP plus priority based lookup.

J

I mean uh the meter policies. uh Lookup is just a party based right, so yeah yeah, so that is not LPM based.

C

J

F

I think that is yeah I mean there's no way to unify the tables. If that's what the question is, uh because these are like different types of lookups, uh which is happening.

E

Yeah so I mean uh unifying, would be great, but but I understand, maybe they can't be unified. They have to be independent tables, but the concern is more about the algorithm, uh for you know, LPM plus priority, um and why it's not just straight LPM, no.

J

No, no okay. This part I want to clarify there's no LPM past part, which are we seeing the metering policies, the LPM priorities, no I, don't think so right so.

J

Table is simply a a party-based. The table. There's no LPM on the meter policy table right so.

I

It's prefix and priority. So what about priority? Yeah.

J

No, no, what do you mean by prefix there's.

I

No LPM right, so it's not healthy I mean some I mean it has a priority and some prefixes. If that uh you just match the prefix, and if it is a higher priority, you pick it up. There's no LPM! If there is a.

I

J

Can't be no, no, no, it's not exactly right.

F

J

F

It's a prefix match.

J

Right, so no no I think no! Yes,.

E

It's higher you take this one or that one. It's.

A

So Gohan you said it's a prefix match not an LPM match.

J

No, it's not it's. It's just uh you know. It's like I, think it's very similar to the echo policy right. So you know you have a priority. You know wishing you through you, you you, you have a. uh You know like a tcam prefix match right. So you.

G

D

How big will that be? Will it be as large as the routing table.

J

Sorry say it again:.

D

How large will that be if it's a turn.

J

Oh, how large should that be I mean you know the internal implementation, I, don't think it's uh you know, uh I think people have various ways to implement just like the way they implement the echo. But do we have the skill requirement for the meter policy table? First.

B

uh I, don't have the the scale requirement, but it it is not that uh heavy.

J

Heavy, can you find out this yeah yeah.

B

I will I will update that yeah. Okay,.

D

It will not be as large as the outbound routing table.

B

No, no, it's not it's not yeah.

A

Does that help Bud.

H

uh Yeah so the the the lookup algorithm it's ternary. Basically the tcam.

A

That's what I heard.

J

Yeah yeah, but you can use a various way to simulate the t-cam right. So yeah.

K

And and this metering policy table a different table than a rules table like what? What is this yeah.

C

K

There any definition of a metering policy table.

F

Yeah, so this is different from the security uh route stable uh in the pipeline as well. So the definition itself is uh here like from the schema point of view. You have a meter policy with the priority and a prefix which gives a meter bucket ID. So you have a policy and a policy ID with the V4 V6 plus meter rules. It's kind of modeled similar to Ackles.

A

F

Okay, so I guess uh going forward, uh uh so yeah I mean uh I. Think if this part is okay, we will uh obviously the behavioral model changes with the P4 changes to represent this pipeline will also uh be coming so I guess we just wanted to make sure that everybody is in sync with this uh pipeline, so the P4 changes will uh reflect this one.

K

But I just have one question where it says override it doesn't have any algorithm.

K

How does it override is there an algorithm and which one it selects.

F

uh No, so the override is something that is uh programmed from the top uh so um of every mapping. Entry can have an override uh control to decide whether the meter bucket ID coming from the mapping is overriding or not I guess. The use case here is specifically the for private links. uh You want the private link mapping buckets always to be used for accounting, uh as opposed to anything else coming from routing. So uh that's the use case where the override would be set for private link, mappings I think.

K

Do we have this in any writing like so people understand that? Is it in the document that uh already that it says that.

F

Yeah yeah: this is like I, think, princess, uh okay, good.

I

It's also there in the rtb schema too.

F

Yeah, so there is override Boolean coming here: cool all.

C

J

D

Might help the override Boolean is coming, is sdn managed right.

F

Correct yeah, it's coming from the controller, yes,.

B

F

Yeah I guess the specific use case is the private link use case uh but uh yeah. The idea here is to keep it generic as override Boolean, rather than have any specific type checks uh so yeah in the future. If there is some other use case where override is required, you can just do that.

J

Okay, so why why is this override is over only overriding the routing table, but not the meter table meter policy table.

B

And so Gohan that one when you assign the meter policy to a routing table, you know like it is for the the policy right. Otherwise, you will not associate that meter policy to that routing table, um but you don't uh specifically have control between the routing and the mapping table. So that's where you want to separate.

J

So but the figure there's a three Arrow go to the override right right. So you know the meter policy, the meter bracket ID from the policy table and from the outbound routing table then from the c2pm mapping table. So why? Oh yeah.

F

Yeah I think the thing is okay. This is just a representational diagram. I think the uh yeah I've just like merged these two arrows going here at this point right. So the decision to pick which one is already made, because the policy enable, if policy routing, says policy enabled then the bucket ID from policy is the one which is going here to this override this.

J

Description on the on that document need to be updated right. So it's not just overriding the routing meter bucket. It could be route meter policy bucket ID as well right so yeah.

F

I think the the yeah I guess the way to look at it is the requirements is basically giving a specific uh order of priority right and this pipeline is enabling uh uh this the requirements to be met by configuring in the appropriate way right. So you.

J

Know I get that problem. Just saying the you know, the description of the overriding, the um you know in a config, DB or FDB need to be updated to reflect what this? What do we mean by our right? Okay,.

F

Yeah I guess here you mean we need to say it's override coming from policy or the metering policy or the router yeah.

L

Little blocks of pseudo could work wonderfully for precision.

F

Sure, okay, that is something we can do.

I

So I think one distinct from configuration either it will be the route itself either points to if it is pointing to uh uh pointing to the mapping uh table for the v-net, then I guess that uh that outbound, that route entry will not have meter policy enabled uh in the real deployment I guess right on the meter policy. Enable will only be there for direct routes which is pointing to the Internet. So it's kind of exclusive in that way is that right, Prince! That's the idea right.

B

Yeah, that's our deployment. Yes, yes, yeah.

C

J

A

J

Me, okay, I mean all right.

J

So the the meter back ID from the metering policy but will not even go to the override right. So.

A

It's after the override it says.

J

No no I mean that means.

B

J

No case that uh the meter policy table will have a conflict with the CO2 PM mapping right so.

B

Right right, that's right, gone.

A

So you're saying, if, if all this is good, we can put it in P4 and make a couple of updates to the documentation.

A

F

Yeah yeah, so uh yeah I think that, uh like in the P4 at least the there is a meta uh field right which carries the bucket ID so like I, guess that is only a single field. We would have to appropriate. I mean appropriately update that bucket ID in the pipeline, so I guess it'll be more clearer with the P4 changes as well. I think this diagram is just a logical representation.

A

Awesome: okay, cool! Maybe we can get through Slide Five this time, yeah.

G

Okay so I'm just jumping ahead on the P4 side. You said it might become clearer on the P4, but who would set up that meta field in the P4 for this bucket ID.

F

uh So this is like any other table uh attribute which is uh derived in the pipeline and carried in The Meta right. So uh in the pipeline, you, uh you have the table results which is carried in The Meta field in the pipeline, and then it goes forward and that could be involved in another decision. So I think like, for example, in v-net. We have a similar case where we have the destination. V-Net coming from the route and mapping also gives a v-net.

F

Then there is a similar override happening in the P4, so we would have to do something like that in the uh in the P4 logic.

G

Okay, so it's essentially it will be the result of the the match, action lookup uh and then perhaps you know one of the one of the action um ID parameters would set up this thing right.

F

Right exactly yeah.

C

F

I think we can okay so going forward. uh Yeah I mean this is just to introduce the uh just to like further clarification on the metering bucket ID concept. uh So here we have a bunch of bucket IDs, uh which is like uh you have the bucket ID one to n, and each bucket ID essentially represents a type of traffic. So in this particular example, you have bucket ID one representing peered v-net, one and bucket ID3 can represent a direct route to internet Whip and so on. Right. So now you have.

F

Each of these bucket IDs are mapped to an eni uh and uh in this example like pocket id1, then 3 is mapped to eni one which internally allocates a hardware resource uh which is doing the actual accounting. So you have like two uh actual Hardware resource two buckets so to speak in the hardware, which is doing the TX and RX bytes accounting, um so yeah, just to kind of see why this particular mapping is required right.

F

So if we look at the way the billing is done, uh the billing is done at the enite level, so the hardware resource is also at a perienna level, uh but the bucket IDs themselves are associated with mappings, which are at a v-net level right so uh and not all the uh and all the bucket IDs which are associated to the mappings are are need not be required or relevant on an eni.

F

So if we take a case like uh you have eni one v-net, a which has a peering relationship with v-net b v-net b can have a bunch of bucket IDs and not all the bucket IDs on V and v-net B is actually relevant on eni, a so uh to optimize the resources you you need to associate only the relevant bucket IDs that are used for each of the Enis and this the part where you actually do the association uh is when the hardware resource actually gets allocated.

F

So that way you avoid having to allocate all the buckets on every mapping table. So you only allocate the relevance one for that TNI so and once this Association is done, you also have a query on an eni to get all the metering buckets associated with that DNA. So, for example, I guess this is the part where, uh because the billing finally is done on a perienna basis.

F

So you want to know what are all the buckets which are associated for an eni, so you can say like for again I one give me all the buckets, and that would give you like bucket ID one. This many TX and RX buys bucket ID3 and so on right. So then uh it would give you a way to derive the final billing number on a per enite basis.

F

So this is what uh this just to clarify that concept of the bucket IDs and why that actual Association is required, and this is can.

J

We look at the I, still don't understand this part. You say the bucket ID is not associated with the year. Actually, it's a it's a vignette concept, because uh It's associated with a particular mapping table the mapping table is at the winner level right so yeah, but not all the bucket is uh derived from mapping table. There are some back ID derived from the you know, meter policy, the routing table, those are on the already on the uni level right so.

F

Yeah right yeah yeah, they are at the uni level, but I think uh we need to have like a unified view uh of the bucket IDs right. So we can't uh exclude the mappings and mappings are uh definitely at the v-net level, not at an eni level so uh to accommodate the uh bucket IDs at the mapping uh and to associate the bucket IDs at an eni level. uh We have to come up with a scheme like this, uh where you associate pocket a relevant bucket IDs to the eni.

J

And the UI.

F

Yeah, so this is the schema for all the metering related uh FTP uh schema, so yeah, like policy and meter rule we've already discussed, and this is the uh something called as dash meter that is being introduced, which is like associating the bucket ID on a buddy and I uh basis, and this bucket metadata is an optional string that the controller can use to associate uh any metadata or any semantic information associated with the bucket ID with uh when he creates this uh meter dash meter, and that is also the counters which are read only.

D

This intelligence of associating or creating the bucket IDs per eni is available only in the controller right is it okay, and then there should be like a dash API that will call that the system can make a call to and retrieve all these bucket IDs per eni and program them down right. Okay,.

F

So I think the expectation here is that when you do a dash, so the dash meter object itself will have uh Associated Credit API. So you, when you do a create on eni, comma bucket ID and you can do a a gate on eni comma star. So that would give you all the bucket IDs associated with the eni.

J

Okay, so where, where do you create a bucket idea? Along I mean this is a creating The Binding between the ying and the bucket ID right? So where do do we have a schema that creates a back ID along.

F

No, so the bucket ID is uh just a number like a un 32 number that is coming from the top, uh because uh that is something that has to be managed and passed on from the top, because the meter create itself carries that bucket ID.

J

So let me ask this question right so because you you talk about you know that is uh you know this. The back ID associated with the mapping table is on the winner level that we get it so, but the bucket it could also associate with a meter uh meter view right. So the meter rule is already Associated within the level, so so for Barclay IDs, that's supposed to be associated with the metering rule. Do we also need to create a unique dash meter table which is getting high on that one yeah, so yeah.

F

That's a good question, so basically, what you're asking is, uh since the bucket at uh routing and policy is already at the eni level. Why do we need to do the association again right so yeah I mean this is something that uh uh yeah? It is a derived information so to speak, but just to keep the API simpler right. uh We can, if the association happens, for all the bucket IDs which are associated with that eni.

F

If you, if a create, is done, then there's nothing that the lower layers have to derive right, so it is kind of uh already derived at the top, and you just associate each bucket IDs. It doesn't matter whether it's Associated at a policy route or a mapping. You just associate the relevant bucket IDs to uh the eni. So we can you keep that API simple. Rather than have some. uh You know like some logic, which is passed down to the lower layers right.

G

Are a shared resource, in other words, they are shared between um multiple Enis within the v-net.

J

No okay I mean so no, no, no, the parking ID may be shared resource, but the market is not okay, yeah.

G

So but kit ID is shared bucket is not, but but buckets are identified through bucket ID, no.

J

That's a that's a confusing I think uh yeah yeah! That's why I'm also trying to understand, but it seems like uh this is a little bit weird because uh you know normally right so I I coming from you know, honey for a point of view. I I think you know. Usually you know your bucket ideas identify a unique bucket, which is uh you know having this accounting resource of txl packet, txlx packet right, so yeah, but somehow you know what what design here is that this bucket ID is kind of a class ID.

J

So it's just simplicify. You know this. uh You know that I have this uh um class of traffic, you know their friend's name and then, when you create that the meter meter table eni plus bucket ID, you actually create a real bucket ID.

B

F

Because I think the key here is to recognize the fact that the accounting itself is that uh per eni level right, so the accounting happens. uh The way to think of a bucket is eni, and a bucket ID gives you the actual uh accounting resource, but what the bucket ID represents, or the semantic meaning of a bucket ID is what is carried with that bucket ID.

F

So, like I mean that's, why we put this example just to make it more clearer right, so the bucket id1 represents a paired v-net one traffic or it could be appeared in a true traffic and so on right. So that and this period at one traffic is uh associated with the ni, One and Two, uh because it has a peering relationship with v-net one. Hence it that bucket ID needs to be associated with eni one and two.

B

So I think the uh from a mapping perspective. We are not interested in getting um counters for all the packets, that or traffic that is going through that mapping right. So it's just based on the Enis what we need. So if.

H

B

Have bucket ready to win it, and if all the accounting happens on that, it's not something that we are interested in.

D

Okay and all the the bucket IDs, they incorporate all the three different types of metering right. Everything in this one set, meaning.

F

Yeah, so uh do you mean this from policy routing or mapping yeah? So the bucket ID itself is uh uh like the un32 number, uh which is associated with policy, routing uh or mapping.

D

J

And maybe maybe this should be.

F

J

I I think we were.

F

Like uh we're trying to uh yeah, this is something that, uh uh given the requirements right where you have uh uh bucket IDs representing the class of traffic, and you also have the requirements of uh having to account at a per eni level. uh So this seemed like an appropriate approach where the association happens from the top.

C

J

I think I feel like the um the dash pipeline. Sorry, the P4 pipeline I feel you know as a hardware level. They are really operating at this. You know the real packet ID level. So therefore you know I'm thinking like on on the slides four. You know that market ID should be the real bucket ID right, so perfect, yeah yeah.

F

J

That that back ID, you know in the mirroring table there should be no young ID there, because that is. That is the action because, because you will create the actual bucket ID at the hardware level,.

F

Right yeah, so that is more like implementation, specific right so.

J

No, no, the dash pipeline is implementation. Specifically it's a it is defined. The data plan Behavior.

I

But go ahead one this thing there, though you see for the same. For example, if we had a mapping entry with a bucket ID, some bucket idx right now that same x per eni could have different counter. So there is in the hardware resources there are multiple resources.

J

That part, but that mapping you know you so first I, think the in the number five we shouldn't add to the you know app DB level. We shouldn't call it back ID. We should call it the metering class ID.

I

That yeah, that makes.

J

That is a class right so that that is a traffic kind of traffic class. That is a class that is, that is ID is allocated by the application. So they know okay, what type of class you know they have this all all the metadata associated with the class right so and when we, when we go to the actual Hardware right, so we should really do. As uh you know this this bucket ID, then the back ID is really meaning that you know this County resource per you know. Txrx plus, is the bucket ID right.

J

So then the then the allocation. You know how to remap the class ID associated with the each eni and create a real back ID. It's managed by the site that do the translation. The reason I want to the reason, I think it's it's reasonable to do this. If we go to the slides four, if you go to the slide 4 right so then the meter table is going to be a index based Hardware table. So right now the meter table you have to okay. I need the unit. Id I need the bucket ID.

J

You know it's kind of uh I I, don't know like how do we? How do we do the search right? So it's a it's a it's a it's a becoming a hash table right. So but really the back end is the index table. You just need the you know index and each Hardware. You know because they they will know okay, which year which year I really need to create a back ID, which you know I, do not create a new packet according to the class mapping right.

J

So therefore, you know you just derive the bucket ID and then the meter table become an index table. So therefore, you know a lookup is going to be more efficient.

L

So the meter policy table I'm. Sorry, the yeah. The meter policy table depends on eni. The outbound routing table can depend on E and I, but that outbound Capa mapping table does it depend on eni its results at all, maybe only indirectly through the v-net, ID I, don't even know.

I

It's indirect because it's a v-net level uh mapping.

F

Yeah, so hey go ahead so that I guess here right in the sense that the uh so but I guess the uh the fact here is that that is more like uh the hardware uh implementation specific right. So if you're looking at the behavioral model, P4 the behavioral model, P4 can have a meter table with the eni ID and the bucket idea as keys, and you can do the accounting on a th and RX basis. But in the hardware.

F

Yes, it can be a perienna index table or it can be a hash table which would take the bucket ID and then derive a smaller bucket, ID and so on. Right. But if you're looking at the period model.

F

Correct yeah exactly so I think that part we didn't want to break it down and show this because, uh like the hair model, allows you to Define like an eni, ID and bucket ID as keys, and it allows you to drive the TX and RX bytes right so that how exactly the table is implemented in a particular Hardware pipeline can be flexible because some some vendors can implement it.

J

No actually agree with that. I disagree with that argument right. So the reason I disagree with that argument is that I think the I think you know in this way. You know it's becoming. uh uh You know the way that we we we implement the counting resources becoming very application, driven right so, and uh it's not good uh in in a reason for reasons that, for example, if someone you know want to, um you know count it uh differently right. So then it's not good right.

J

So, but if you, if you aligned with uh you know or I, mean traditionally, those uh counting how the country is done is that you know on the metadata, it's always transferring the real bucket ID in the pipeline right. So this is, you know. After the after the data plan level, I think it's more understandable. You know how this is done right. So then, in this case the you know, the the bucket, the the back of the implementation or representation in the P4 is more traditional right.

J

So people knows okay, what is uh what what is mean by packet ID- and uh you know, whatever use I- want to count the bucket I. Just you know sign the packet ID there and uh and the map to that uh meter table right so and in the middle table, I just look up to the index and find the bucket and and do it because I, you know why we create another interaction. You know between this. uh You know logical people, Pipeline and the uh and the hardware implementation yeah.

F

But I think the other way to look at it is uh from the PSI API point of view right so for the PSI API or for the meter table. You want the packet ID, which is coming from the top right. No and uh and the hardware is something that the lip side layer can uh manage. No.

J

F

Particular implementation, no.

J

Okay, actually, on the side level, I want you to create a back ID on that the um you know on the hardware level and that mapping guy you know you and I class ID to the back ID should be should be managed by the application once the application means uh means occasions.

G

One index and I believe what Vijay is basically talking about when this bucket ID is, is basically saying. You know that Tuple of eni and and the cricket class so.

J

Let me let me clarify here right, so first I think you know in terms of a terminology right, so uh you know. Currently, the back ID should be really renamed to meter class ID, which is coming from the application.

J

Then in the dash pipeline I think we should have the bucket ID that is mapping one to one to the hardware and when I, whenever in the in the following discussion, the reference when this is the back ID. It's referred to that concept, that this is one one-to-one Hardware mapping. So that should be exposed by the side that the side will create all this bucket ID and then the The Arc agent need to do that. Mapping between the uni and class ID to create a unique bucket and attach it.

F

Right, yeah I think the yeah. The intention here is exactly as you described so I guess, uh semantically, that's exactly what we were also uh thinking, uh but I guess what you're saying is uh yeah I guess the beater bucket ID in this pipeline is referring to that's.

F

Why we call it Global meter, bucket ID, but uh yeah I do agree that it uh class ID might be more uh clearer, but uh yeah I guess that meter bucket ID allocation part is something that we were thinking is uh uh the responsibility of the lips eye layer which is below the sci API, and how exactly that meter bucket ID is allocated is something that can be opaque right. So I guess you are saying, break it up into two tables: that's what in the behavioral model as well.

J

No, no! No, no! No! No! No! No I'm, not saying break up with two people, I'm saying that get rid of that. uh You know the management doesn't belong to the side that the mapping of the uni to the bucket ID does not belong to the site functionality.

J

You know size should be a simple abstraction of exposing the hardware pipeline. So why why why why? Why do we want? You know this is the resource management about how many actually had a resource. We want to create how many back you want to create. Why do we want to that? Put that the you know this resource management team to decide? Why why? Why is that match by the occasions.

F

So I guess then: uh can you just clarify on how the sign API would look in that sense for the meter table, okay,.

J

So for the side, API right, so what I? What I think? Okay! So first in the people pipeline, let's clarify that in the P4 pipeline, the meter table should be a simple index table right, so uh each index corresponding a real Hardware accounting resource right. So the PSI API would simply just expose that meter table. So, okay, so I will I when I, when I do the side. I just say: Okay create a meter uh entry and today it will.

J

It will create an entry with txrx and then you know- um and this uh um um you will um you will you you will get a side object, ID right, so it as a return. We just get a set object, ID, so uh so, and that is that that is exactly matching to a specific Hardware packet ID right, so that that is, that is the side uh side. Api I would imagine.

J

um Sorry, what's that.

G

So uh Gohan um a quick question on this one. So you know so you are suggesting a table. There is a global table, a flag table of of uh bucket indexes.

G

You have you know one two I don't know: maybe one million right, so 1 million buckets are there and then the one million indexes are there and then you can allocate one index. But then how do you further map it back to the eni yeah.

J

Yeah, let me explain it right so I'm about to expand it right. So that's a simple setup here that uh um you know that site provides okay, so they add to the application Level. You know we can still use whatever the the format you know, if you go to that, uh that hod, showing that the meter format yeah yeah yeah yeah, this meter dash meter table. We can continue to use that and instead of here just to know this back at it, we should be changed to a class ID right.

J

So so, whenever we create this, uh you know dash meter, table uh you and I flashed cash ID, the under the side. Oh sorry, in the occasion it will call that the create the meter entry, so I API it could actually the bucket ID right so.

F

Then so then it's the arc agent is managing the hardware resource. So it knows how many buckets per eni and.

J

So on yeah yeah, of course, of course, so they um you know, uh uh let me sync right so um so how does a hardware and do the do the mapping right? So then they, you know, there's there's a there's a gap here, right I think you need to be. You know, look at the pipeline that you know the occasions will associate that bucket ID with some.

J

uh You know user either this metering rules so the uh or the um um the the routing rules that will pointing directly to the harder object, ID right so that side, so I can do that. But I think the on the.

B

But Gohan these routing and meter rules are created upfront before even the snapping can happen.

J

Before which mapping happened, this.

B

Dash meter Association can happen um this meter rule shell will be created in Hardware.

J

um Sure I mean I, don't know that what does it mean? But you know you: you have to resolve that dependency right. So you know if you, if you don't have the hardware meter created, then you you create you. You create that rule that pointing to that meter table um it doesn't work right. So you know you basically have to create the meter first and then create those rules right so.

I

So there is ambiguity there. There is ambiguity too, because uh if, if you take a metering bucket, uh some a class ID or class allocated on a mapping role that has projections to different bucket IDs on different Enis right, so uh it cannot be so one. uh The this thing I would uh I'm now I'm trying to Grapple with this. So what goes in the mapping entry which, what yeah so.

J

Where's, the current mapping trip where's the current mapping through there. What is the current map being to say here this.

F

Is the direct bucket.

I

F

I

Class ID now yeah.

B

Here we cannot associate a real Hardware. We cannot yeah.

J

You cannot, you should not, and then you shouldn't create another table. You should create another table to do that map. You know to you know this. Is that yeah we real. uh You know this class ID. You know this uh uh class ID and the Umi, and then you know a map into a real uh packet ID that you have.

B

J

Before right so.

B

F

J

F

What is happening here yeah? That is that's exactly what is happening here in this meter table box right. The United meter bucket ID, is going into the meter table and the hardware implementation is either managing it as an index table, like you said, or a hash table, and so on, right, which is a more implementation, specific.

D

The hardware can only give the information of txrx count with eni ID right.

J

No Jimmy what.

D

Else can we get in the hardware expectation here.

F

Okay, yeah so I think from the hardware what we're saying. So, if you take that logically, what is happening here in the pipeline, this much can be represented in BMV too right. So this vmv2 allows you to take an ID coming from a big ID, which is a bigger number. No.

J

No, no I think no. Nobody is arguing that this cannot be represented by pmv2 right. So I think we're discussing whether this is a right to be represented by beam using the right abstraction people being provided by I think we're putting too much logic in the side to manage the hardware resource which I want to move away from that.

D

F

So uh yeah so go ahead and I. Think, uh like just few minutes back like we were doing that exercise of mapping right so I guess we realized that the ID or the class ID that is coming from is the global ID, which is the big number right which needs to go into the meter table. So uh I guess the only other way uh is to push the hardware ID allocation to the top to the arcade right.

F

So this I API itself takes the actual Hardware ID, where it takes that the big the class ID and Maps it to a per eni Hardware ID. And then you call that PSI API with both these numbers. So the hardware can directly take the hardware ID that torque agent has mapper and use it directly, but we it looked like that is pushing too much of the hardware details into our kitchen. So uh we thought that that itself can be something that the lips eye layer which sits below this I API, can do that right. No.

J

As I said right, so this is about Resource, Management I. Think if you expose as a global metering, ID to the application will be much easier for the application to do the resource matching, because you know, okay, what is the limitation you know? I can do easily do the CRM I know, okay, what is the consumption of the metering table? How should I manage it right so, instead of pushing All Those comp, you know there's the logic into the sizing. Okay, I, don't know how to how to do the crms. Now.

J

How do I know I? Actually how many, because, because the hardware they have a, they have a they, they will have a limit on. You know how many back real back ID they can create right. So they give you this one. You know you use it as a global resource. It'll be much easier for us to tracking. You know what is the resource consumption. But, however, if you do this indirect mapping, then I actually don't know at the application. Level I actually don't know how many.

F

Right so, but isn't it similar to any other table in vmv2 correctly, for example, if you take a v-net table currently right, you have v-net ID, which is indexed into every net table, but there's a separate resource available, PSI API right where you can query and then get how much resources available on the table right so I think yeah I, guess we are making the orc agent uh simpler. So he just takes the whatever is coming from the top and just puts it down and the lips eye layer is managing the actual Hardware resource.

F

So if we had an API on the meter table which, on a per eni basis, it gives you how much resources currently available, which I believe PSI already has those semantics right, uh then it would you leave the actual management of the table to the left side layer and you keep the arc agent in double layer, simply that that was our thinking.

J

But no I think you know I mean occasionally Implement once and work on every platform right. So you know if I, if I want to just write once right. So why would I write one to every side vendor to replicate the same logic in their site? Library instead of I put this logic into the lock agent and we'll have better testing stories there as well.

A

1003 I think we can resolve.

J

Maybe we will need to resolve it offline, but.

A

J

Think you know this seems, like uh you know, bring complexities I mean the interface between the between the data plan. The control plan looks, uh you know not as not as the most straightforward way to to be represented.

A

Okay, all right! Well, maybe we'll Vijay I hate to do this. Maybe we'll carve out 15 more minutes next meeting, yep sure sure. Okay, all right, um it's been a been a very informative meeting. Thanks you guys um I'm sure you have to go to a different call, but I'll stop the recording and you guys have a good day.

H

A