DASH Behavioral Model WG, 18 May 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DASH Behavioral Model WG May 18 2023

Description

PR365 - Adding support for metering (Outbound)
https://github.com/sonic-net/DASH/pull/365
Mentioned in DASH HLD 2.4.2

There was a need to introduce new annotations. Also, the ACL code in P4 has a compile flag - be careful here for bmv2 to SAI generation.

A

Thanks for coming to the dash behavioral model group on May, 18th I think today is the day. Mount St Helens blew up a million years ago or a long time ago anyway. I think it's the anniversary of that today, so yeah I'm from Washington State, so I remember that I think I was about 11 when that happened anyway. So.

B

A

Oh yeah yeah, so it used to be a big, beautiful mountain. It was one of the most beautiful mountains in the world and now it has a big hole right at the top. So if you ever come to Washington and want to take a drive, we could go. Look beautiful yeah.

A

um What I'm showing on the screen is what we talked about last time, which was I. Think we kind of closed up this conversation yesterday about the aqua tags and things like that so um anyway, and um we we did talk a little bit last week about or the week before, about the the experiment that we're working on, but we um you know it wasn't the highest priority.

A

So we have that and um then today we have these PRS in the queue and I was wondering if um I think it was VJ might have something you wanted to talk about or Clark if he joins the meeting from Alibaba, so I think that's what's on deck for today, unless Marion did you have anything you wanted to talk about or anyone else on the call.

C

A

Cool so Vijay was it this one for today, 365.

D

A

Okay, cool did you want me to present, or did you want to present.

E

uh Yeah I can quickly go the pr. uh Okay, I can start sharing the screen.

A

Okay, I'm gonna stop.

A

So everybody knows Vijay he's presented PR's before.

E

Hey, uh can you guys I.

A

Can see yeah I can.

E

Okay, so uh yeah I think this PR is basically addressing the uh the design for metering, uh outbound metering that was presented and uh discussed earlier, uh the main the metering requirements and also the uh uh the metering design is mentioned in the hld, so uh it just does a quick overview. This is the outbound traffic metering behavior that we had discussed and accepted. So uh this is what is being incorporated into the BM V2 Pipeline with this PR.

E

uh So there is basically a meter class ID coming from the policy table, outbound routing table and outbound the mapping table. There is also a metered bucket table, so there are two new tables being introduced in this pier the meter policy table and the meter bucket Table, and there are two uh three new attributes coming from the uh the routing and the mapping table. So there's a class ID there's a policy enabled Boolean and then there's an override Boolean.

E

um So now we can just look at the pr the changes in the pr so uh yeah, so these set of changes are basically for this I API generation. So um because of the way the tables are defined, there was a need to introduce some new annotations um for generating the uh table as an object, and so these changes address all the new. uh The PSI API changes for the new annotations and just going ahead.

E

Yeah, so these These are the before changes. So um so here we can see that in the outbound routing table we have the metered policy enabled and the meter class, which is coming from every uh routing action.

E

And we have the uh from the outbound mapping table, we have the same meter class and then the uh there is an override which is coming from the override Boolean, which is coming from the mapping table and going further ahead from the eni. We get the policy ID. So there is a V4 and V6 meter policy ID coming from the eni table, so this is similar to Ackles, where there's no inbound and outbound. Here it's like uh the uh V4 meter policy and V6 meter policy.

E

So but the way the meter policy is structured is similar to the Ackles, where there's a policy table and there is a Rule table. So the meter policy table uh has the meter policy ID and it just as the address family check, which is similar to the actual group table that we have in pmv2.

E

And then there is a meter Rule table which contains the actual rules. uh Where you have the meter policy ID and you have the uh uh a ternary match on the uh destination address and the meter rule action itself can give the meter.

C

Class I didn't get one thing: the emitter policy table uh same table is applied in both directions, or we have a table per direction that can be applied for the same flow.

E

Yeah so I think this one uh right now uh I've only addressed the outbound Direction meter policy, so there was a clarification required on the inbound Direction whether the policy is really required from the requirements point of view or not. uh That is something that I need to uh check back with prints and uh get back on that because uh yeah I.

C

Think this will be addressed that yes,.

E

C

E

So a meter Rule table has the so this is uh more simple than uh the Accel Rule table. It just has the meter policy ID and then the destination address and the rule action.

F

Sorry, quick question.

E

Sorry yeah: this is uh basically priority based uh Tikka match. That's the requirements which was mentioned, there's a priority based uh uh a prefix match so for meter policy. So that's why it is ternary here.

F

As opposed to your prefix I, guess that's my point as.

E

Opposed to LPM yeah.

B

I mean if it's restricted to be prefixes, maybe a comment saying: control plane must use, prefixes might be appropriate.

E

uh Yeah I think uh yeah. Sure I can add a comment, uh but yeah I mean if you guys look at the SI API, which is generated. It becomes clear but yeah I can definitely add a comment here.

F

Well, I guess: my comment was along the same lines: if, at this IPI is supposed to be a prefix, the table can be, can have some terminology basically say use this I prefix type. That's why I'm getting up.

B

There's no P4 type, that's prefix only other than LPM.

F

But you can specify aside. There is one example right above that on the policy ID, you see that side type, that's how you basically massage the type that PSI is basically posting I I, see.

B

With The annotation sure.

F

Yeah, that's why I'm asking about this.

E

Yeah, so uh yeah I didn't really put The annotation here, because the way this IPA got generated seemed to be uh in sync, so I just thought: I'll just leave it as ternary.

F

Yeah, we'll get back to that one: okay, yeah.

E

uh Sure, okay, so um so, then we have the meter class. So then uh the finally we have the metered bucket, where the actual uh counting uh happens, uh the there's the outbound bytes counter and the inbound bytes counter. uh Now this meter bucket uh uh table itself is, uh uh is skied upon eni, ID and meter class and the meter bucket action is actually just the counter action. So there's nothing really happening here. uh So the way I've tried to model this in bmv2 is because we have two counters outbound and inbound counters.

E

We can't have like two direct counters for a table, uh so instead I added two uh dummy tables which are basically like meter bucket outbound and meter bucket inbound, and uh there are two direct counters attached here, uh which is as per bmv2 and now, depending on the uh the Direction coming in meta. We will either apply the outbound table or the inbound table, uh so this table is basically for the PSI API generation and these two tables are for bmv2.

E

So there is a ignored table, so there is no PSI apis associated with the meter bucket, outbound or inbound, but does IPS are associated only with this meter bucket table here, but in the bmv2 data path the counters will increment either in the outbound or the inbound table. But there is one TBD here is that in the bmv2 side lib we need to kind of Stitch the uh right when we do a count, counter get on inbound, bytes counter or the outbound bytes counter.

E

We need to go and fetch the actual counter from the appropriate bmv2 table. So uh that is something that uh is not yet addressed. So.

G

Bj, do you think there could be some kind of a clever annotation that gives hints to the code generator that it could automatically do certain things in the side after, in this case, yeah.

E

I think that is what I was thinking to do, uh but I thought I just uh wanted to get this ipis out there, uh because uh yeah I think yeah. That is uh one uh one possible way to do this, um that we have some kind of cyan Edition here which says that hey these two counters, uh which are actually attributes, um are tied to the uh counter here, the direct counter here in a different table.

E

Now, if we can have some kind of annotation, then uh probably in the generator we can like generate the code appropriately because unfortunately uh yeah this is yet another uh example of like PSI API generation tied to bmv2 right. So it's like some idiosyncrasy or surf bmv2 spilling over to side API generation.

E

So um yeah going ahead, so there is the so uh yeah. This is where the actually the tables are getting applied. So if you have uh the policy enabled which is coming from the route table, then you apply the meter policy and then you apply the meter Rule, and so this particular logic is uh described here.

E

So, uh as you can see, the meter class can come from three different places in the pipeline uh and we need a way to pick the right meter class table which is ultimately used in the meter bucket for uh counting.

E

So this has the uh basically the Precedence logic, so uh the meter policy lookup, if it's enabled and meter policy, gives the meter class, then that gets precedence and over the routing tables meter class and the mapping can override it on believe this mapping override Boolean is set. Otherwise whatever is coming from, the policy is taken, so I mean that whatever is described here is kind of defined in this uh logic, so yeah. So.

E

Finally, you pick one meter class, which goes uh there are policy, meter, class route, meter, class and mapping meter class and finally, what goes to a metered bucket is the uh one, a meter class which is chosen based on the Precedence rules.

E

uh So- and this is the other one, so there is the meter bucket apply which actually doesn't do anything but I think the compiler didn't like it. If I didn't apply this so I I'm just doing an apply here and if the direction is outbound, then we do the outbound apply or inbound apply. Now these two things are basically just incrementing the direct counters in bmv2, and that's the thing that we need to fetch, and these are the test changes so uh just quickly. I just wanted to show the PSI apis which got generated.

E

So we have the uh here create meter bucket, and then we have the meter policy and then the meter rule. uh So the meter policy and the rule is uh yeah. Okay, before that I just wanted to show the uh yeah in the eni. These are the new attributes which got generated in this API. So there's an eni attribute V4 and V6 meter policy ID, and uh there is yeah. There is in the ca to PA mapping.

E

There is a new meter class and a meter class override and in outbound routing there is a new attribute which is an enable and then the same meter class, so I think inside API it's called meter class everywhere. Only in the bmv2 I mean that's because of the pipeline is uh defined.

F

E

uh In this sorry, in the site, API.

F

Yeah yeah just to see the attributes.

E

So this is the create meter bucket.

E

And these are the attributes, so yeah I think this was. The interesting thing is uh for the rules yeah, so the ternary match it gets. uh It becomes a dip dip mask and a priority.

H

Can I ask a question about this I so I understand why you're saying it's not an LPM, because it's got priority, but um from the perspective of The Masks The Masks will always be sort of prefix oriented and not just arbitrary masks. Right, yes, yeah, like is there any way? We can express that in the API like that that that the masks aren't allowed to be just like arbitrary random masks, but a prefix oriented.

B

And then, like always consistent with longest previous match,.

H

Well, yeah yeah I mean I, understand why it's not like an LPM from the P4 perspective and because it's got a priority, but I think it's like. um If we know that these masks are always going to be in sort of a prefix form, um I think then certain data planes could take advantage of that. And uh but if, if the mask, if the API says it can be an arbitrary mask, then that's uh uh yeah a harder thing to to do right.

E

Right yeah agreed so um yeah I think we have a precedence uh for using uh dip as uh uh ternary like in inbound routing. Also uh there is a similar, a precedence where we have uh I think there. It is Sip and it's a similar thing. Sip sip mask and priority. So I was just like kind of riding on that precedence, but yeah you're, right, I, think uh I, don't know. If there's some way uh are you saying we should generate some comment.

H

Here yeah, maybe it's a comment, or maybe it's the the API takes like a instead of a mask, takes like a length and then that, like by definition, constrains what the masks can be um I'm. Okay, if it's just a comment but- um and you know, if an arbitrary mask came, we could fail. The API I just want to make sure that it's like um at least known that the definition of this is that these aren't intended to be just like arbitrary masks but uh sort of prefix oriented masks, but.

B

It can maybe it's already clear to you John. If the intent is all the mass are all prefixes and if the priorities are always longest, prefix match wins.

H

No I think the reason is uh Andy that you could have like. um Let's say, a more specific um prefix, that's at a lower priority, and so like the covering prefix at a higher priority would be what you want to match on right.

B

So it would never match in the data plane during that time. It was configured that way, but you could remove the higher priority One at any time and it would change exactly.

H

And in a from a P4 like modeling perspective, like you know, modeling it as Turner, he gives you this behavior from an actual vendor implementation. There's lots of flexibility on how you might implement this.

D

B

Right so you'd like to document it that it's I'd.

H

Like to constrain it, but.

B

But priorities are arbitrary on previous.

H

Yeah I'd like to constrain it so that the masks can't be arbitrary, that they have to be prefix oriented. um Because that's that's really. The requirement.

E

Okay, yeah yeah I, think uh yeah I mean given the fact that this is iip address. uh Hopefully it's uh yeah the mask is uh uh it should not be given as arbitrary, so uh yeah. We can look into that. But uh just uh one point is that we do have other instances which were introduced before uh which kind of follow the I'm just following the same path but yeah. We should.

B

Apply to all then.

E

H

Absolutely I think we, if there's an if the requirement is constrained in that way, then we should express it somehow yeah.

E

F

Okay, can you go to this IP uh the attributes that, when you fetch the buy account.

E

Right so that does.

E

Yeah, so there is a so. This is the meter bucket, so basically uh yeah when we create the meter bucket. We give the eni in the class which is attributes and then what you get is the metered bucket ID. So uh yeah I mean like in.

F

E

F

How do you retrieve the bike comp yeah.

E

So, okay, so this for the byte count, yeah, that's a good question, so I just uh so. This is also something which is uh kind of unique to this meter bucket. So, basically, there are two attributes uh which are meter bucket attributes which are generated as read-only attributes. So the idea is that when we do a get on these attributes, we get the counter um now yeah. We need to somehow tie this to the BMV to direct counter. That's the silib part that I was talking about, which is not yet done.

F

So two comments here: it's also me a little wasteful to have both an inbound and another counter in the same meter, because a lot of flows are unidirectional right, that's the first command and second is: how do you do if it's read only? How do you clear a counter.

E

So um yeah so I guess the inbound and outbound, because it's tied to a flow right so anytime uh a flow is created. You have the bi-directional flow created, uh in other words, in the data path.

E

You are provisioning, uh both the counters, whether it increments or not, uh is dependent on how the actual uh packet path is, but uh I think the byte counters itself uh are like actually provisioned uh in the hardware and as to the clearing part, so I believe uh create uh because it's tied to a meter class and it's tied to like accounting traffic. When you create a new meter class- and you are instantiating a new bucket, it is, it starts off as a zero counter, and it's pretty much increments for the lifetime of that.

E

uh That meter class.

C

E

F

That's I mean yeah any kind of platform. Typically, when you have counter at least at the Seattle level, you got to show player that kind of stuff right. So do we even care to implement a clear here or that's going to be taken care of by uh by the airport layer, especially since, if those are only 32 bits, They're Gonna Roll, if they were 64-bit, that'd, be different but 30 to bit They're Gonna Roll.

E

Right so I think we can make this 64-bit, that's something that I can check so um yeah I think it should probably be a 64 okay, 64-bit counter here right, so you can change that part.

E

uh As far as the clearing is concerned, uh I, don't think uh that was part of the requirement, because once a bucket and class which is associated with the bucket is instantiated, it's pretty much exists till that class goes away and probably a new class can use the same bucket area at which time it is anyway, it's a new create and then it starts off as zero. So that's what I understand. So that's. Why there's no like a clear API here.

F

I mean I: guess if you make them right, read and write, then the set on that counter attribute will just work right. If need be,.

I

So what is the requirement uh is? Is it like the same pocket for both inbound and outbound traffic, for the same flow uh is the way currently yeah.

E

I

E

A single meter class is associated with outbound and inbound.

I

And and as a result same bucket same bucket,.

E

Yes, that's right. Yeah one bucket has both the inbound and outbound counters yeah.

E

Yeah I guess this set is one thing that you can potentially use to clear its uh here.

E

F

I guess about the requirements: it's fine, but yeah yeah definitely make it 64-bit.

E

Okay: okay, I'll, look into that yeah.

E

And the meter policy itself, the meter policy and the meter rule is similar to our uh Akil. um This iaps is also pretty much uh similar, so you have the meter policy. You have the IP address, attribute to create the meter policy and meter rule. Just has the policy and destination IP and.

F

E

F

Be careful with this statement because the the alcohol code in P4 has a compound flag and what gets generated out of the box is not what it's supposed to be we're supposed to have list of prefixes, whereas out of the box, it generates just an IP address.

F

E

F

About this, oh.

E

Yeah yeah right so I think we don't have that list. uh At least here per meter rule there's only one IP address yeah yeah I understand what you're saying so. I think that there's a there's, a discrepancy right between what bmv2 says and what the API is generated for ankle rules.

F

What they're supposed to be right? There's no, the Christmas tree out of the box, it's the same, but it's not complete. It's not Dash compliant.

E

Okay, yeah I, think here it's just one single IP address so I think here this there is no uh real discriminant, because it's much more simpler right. It's just one IP address that you want to match on there.

C

E

uh Yeah I guess: that's it and I think yeah I was having some trouble just uh with, uh because the new attributes were added I was having some trouble getting their tests to pass the existing test to pass so working with Chris uh on that one uh thanks Chris for helping the uh with that and uh Chris and Andre. Also um so I think Andrew is looking at making some size. C changes to make these tests pass.

G

uh Very comprehensive PR well done. That's.

A

B

Quick question: following up on something you should talk to you about earlier. uh You said that there should be counters that can be updated for a mix of some outbound and some inbound packets.

B

C

Should be possible.

B

To configure some some meters.

E

B

E

Do you mean in the BMV.

B

Too uh so in the BMV too, it sounds like you made it, so that's impossible to do. Oh.

E

Yeah so I think the BMV to the problem I faced was this the direct counter, uh the specification here. This is something that bmv2 uh already supports so, but you can only support one type of counter like what I really needed here was like a way to give like two direct counters and in this statement, if I could say, like counters, equals outbound, comma in bond, or something like that. So.

B

So you can, if you don't there's another extern called a counter without the word direct underscore in front of it. Oh.

E

That is a table counter uh that yeah I looked at that. That was just the thing I.

B

Mean you give it's an array number from zero to size minus one. Then you can specify an index that you want to update in that array. Okay,.

E

So I guess, but there was uh the other problem uh here- is that we have actually we are. There is some logic involved right to uh like to increment the right counter table. uh We have to look at the direction in the uh meta and then increment either outbound or inbound so yeah. It was kind of hard to take and.

B

Yeah, because what are the keys that those help on an inbound tables match on imagine they mentioned the same things right, correct? Yes, so so you're saying that the set of meter, class values and eni ID values will be different for outbound and inbound, potentially no.

E

B

No, no it'll be the same. It'll be the same. Well this so so, then I would say why not. It would be actually closer to the desired effect if there weren't such an, if condition with an outbounded in one table, there's just one regardless of Direction. Isn't that closer to what the PSI intention is.

E

uh But then we need to increment the right uh counter right because based on uh the direction which is coming in The, Meta,.

B

Did you decide decide what to specify an index to update update.

E

Yeah so I guess that is the meter uh bucket ID that we're talking about so I mean this is basically a hash table uh of eni and writer class right. So.

B

I I'm just saying that there is a if you don't use direct counter. You can have two counter indexes updated by the same table two counter externs, that they do the same table. If you want, or one.

C

B

I think the restrictions you're hitting are because of the direct counter, and if you replace it with counter, maybe it's closer to the behavior. You actually want basically.

G

Calling uh extern in an action right, Andy.

B

The actual action you would say, update index 17 in this array or where 17 would be a parameter, probably an action parameter. The.

G

Control movement- and you can do several.

B

Of those in one and you can update more than one in a single action.

E

I see so this is you're saying we can have the two counters defined uh in bmv2 and then have some extern, which has the logic of actually looking at what I have here right, looking at the direction and it.

B

Sounds like look at the direction. This is exactly what you don't want it from the verbal description that you answered to talk to you earlier. You don't want to have different entries depending on the direction I thought you want, the same, eni, keys and other key.

E

So yeah, but there are two different uh like attributes here right like. If you look at the side, the meter bucket table itself has two different uh counter values there: two uh you win 32s or 64s here right, so we have to go and increment the right uh counter attribute. So that's what I'm trying to model here so.

B

So you want a single key and then you want it depending on the direction of the packet to update an outbound cutter or an inbound. Yes, exactly single.

E

Key yeah, depending on that yeah, okay,.

B

Right so I mean you could have a single counter. I mean yeah. I mean there's different ways to do this, but you could have two counter arrays and have an if statement, interaction, saying if the direction is this update on this counter. Otherwise update that counter, okay, single table I.

E

See so, but then uh for what I understood from the documentation is that when you use a counter, it's not a per entry counter. It's a table counter, maybe yeah I'm wrong. I.

B

Mean the direct counter is one to one with table entries the if you take off the direct underscore, it's just an array from zero to size, minus one not associated with any table, not fixed to be Associated any table. Well, you can update it from a table action, I.

E

See: okay, okay, yeah, perhaps uh yeah I wasn't aware of that! Maybe uh yeah! If you can just send me an example uh because I'm also like pretty new to BMV too so yeah for.

B

Sure sure no I understood yeah. No, it's there's no reason. You'd already know it without the key I'm just I'm, just trying I'm just noticing a small potential difference and wondering if a small change would make it more closely.

E

Sure, yeah, yeah I think uh yeah I agree like if we can just collapse these two tables, because yeah these These are basically just uh just because to accommodate that BMV to uh direct counter I introduced like there are three tables. So if you can just collapse it into one and then have some logic, perhaps it's more intuitive right, yep.

B

E

Okay yeah, maybe if you can provide an example, offline I can try to look at that right. Yeah thanks thanks.

G

Hey uh BJ, you know when we were discussing this one-on-one last week you had to modify a ton of test cases to add some new attributes right right and uh I'm, just wondering in general. Is there anyone in this group who can respond? Is it necessary to pass all attributes or can some of them just default because it seemed like it makes test case maintenance, a real chore? If we had 10 times as many test cases, it would be horrible.

G

Can't attributes just be optional in the site API and are we may be making more work for ourselves.

C

They are not the key uh if they are actually attributes, they are optional.

F

Within the meter, be an optional.

G

Well, yeah, and how come the API was testing for the number of attributes was that an artifact of our implementation? No.

C

It's not the API, I think yeah. It's the.

E

One question there was that uh uh yeah we have that match params and uh uh actual params check assert right. I was hitting that uh if the test cases are missing the attributes, but.

D

E

Is there any way to make it like an optional attribute and not do the uh magical incremental uh match params.

C

Yes, so again, uh if you look at the API alone, it says clearly which uh which attributes are mandatory on Create and which are not and are provided with the default value. Implementation may not follow that, and this is about.

G

Yeah that so PJ we might want to look into that, because this sets a precedent. It's uh great, that you update all those test cases but I feel bad for you, because it was so much work. Yeah.

J

E

uh Yeah I couldn't find that, where is the, uh what makes the attribute mandatory or not mandatory? Is it this one? Okay,.

C

Yeah, the mandatory one create means.

E

Yeah, this is uh we're talking about this attribute right, creatives.

C

Sorry, so it's not mandatory it, uh it can be passed and create, or it can be. You see there is a default value. No.

E

Okay, so okay, just the presence of this means that it's not mandatory, yeah I guess we need to then update the generator, because the generator is like blindly doing that to match.

K

E

G

Fix that in this PR, so we um set it straight or you want to do that as after the fact.

E

uh No I can look into that, so we can get the cicd going right.

G

And if that's the case, you're welcome to revert those test cases. You know just.

C

G

Mandatory or put them in I mean because you've done the work and it's another regression test.

E

K

Enjoy this override, is it sorry Chris? You were saying something: oh.

G

Oh no go ahead.

K

The override is this also part of the meter policy table.

E

This is only part of the mapping, because uh the mapping comes uh later in.

K

The pipeline yeah yeah, so I'm just wondering where it comes from.

E

So the I think the requirement was like. If you have private link mappings, then you want the meter class to be uh taken from the private link mappings as opposed to what is coming from the routing. So, for example, in a v-net you can have a route which has a metered class and it points to a mapping table which can have regular mappings and it can also have private link mappings.

E

So for the regular mappings, you want the meter class, which is coming from the outbound routing table, but for the private link mappings, because they are built differently. You want a meter class coming from the mapping entry, so that is the use case for this override.

K

Okay, the controller has to write.

K

Oh okay, so you're saying this override is constant.

E

Yeah, it's a Boolean yeah pictures, yeah.

K

Okay, so it doesn't need to be written from the controller point of view.

E

uh No, this has to come from the top. So if it's a private link mapping, then uh his uh the controller will set this uh particular meter class override.

K

E

K

I was thinking so where does this come from in our implementation? It's not part of the policy table. Will this be a separate table or an eye table? Where is it coming from? No.

E

It comes from the outbound CA to mapping CA to PM mapping so like in the gnmi V8.

E

Yeah here we added this one: the output override meter, this one.

F

Then this be redundant with the fact that the military class has been around like I, don't see a case where you would you would program a media class which you don't override.

E

uh You don't override uh I, think the yeah I think the Boolean here is to make sure so. The case here is like: uh if you have a non-pl mapping, it can have its own meter class, but it can still hit. It can come from a route where which does not have any meter class specified right? So.

J

It might be absorbed because of uh availability zone or something there could be a meter class, which is only valid if it is written. The Venus or not.

K

D

Hey DJ I have a question about the meter table.

D

um There are two keys in it. There's a the policy ID and the IP address um see the IP address, allow for IPv6 as well. So.

E

uh Yeah I think it BMV to. uh There was an issue. This API itself allows for the IPv6 address uh because it is PSI IP address type, but in bmv2 uh it is V4.

E

um Yeah I think there was some issue with when I tried to use the IP SI, um just the prefix type, the generic V4 or V6 there's one field called V4 or V6 and bmv2. uh When we try to use that in a ternary match, it doesn't like it um and there's also inbound routing table which is kind of doing a similar thing.

E

um Yeah, but I think this is uh probably another thing which we need to fix in uh here and in other places. Also. Okay,.

I

This is the default action deny. uh uh Is that what the intention uh I.

A

See the default only deny.

I

Okay, so so I thought okay. This was metering uh mainly to for the accounting purpose,.

B

So maybe you want to you're wondering if it should be like a no-op action instead, all right or increment some default counter index or something.

E

Yeah I think so too. So I think this is probably um yeah an artifact from the actual Rule table. So yeah I, don't.

I

J

A

Be denying packets.

E

If winter rule doesn't match yeah, okay, yeah, okay, let me look at that as well. Okay,.

A

It's a big PR. It's tough to look at all the lines.

A

E

uh Yeah I think it's pretty much done so. Okay just talked about everything that I haven't I've, also taken uh notes on a few of the comments and.

A

E

Don't understand: okay,.

A

All right and I um and I've connected you uh with Andy there and uh guys do you think this was enough time to go over this, or do you want to have 10 minutes in the next call for this or the next bmv2 call for this? What do you think.

A

Well, if you have comments on it, I guess put a suggestion in the pr or um ping PJ to to take a look at something. If there's a question um we're at one up we're at 11 16. did you have something reshma, no.

K

I think for now we it looks good and then, if there are any comments, as you mentioned, we've added here.

A

Yeah, yep, okay and so I think we're at time. If you guys don't have anything else.

A

And today's Thursday so day before Friday I'll go ahead and stop the recording.