DASH Behavioral Model WG, 21 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DASH Behavioral Model WG Meeting July 21 2022

Description

PR Review: 141, 149, 152
P4 bugs/issues needing volunteers

A

Hi everyone I'm starting the recording and today's the july 21st version of the behavioral model meeting, and um unless anyone had something high priority to discuss, I thought today, maybe we could go through the um the items here in the list that are blocked or waiting for a resource uh to see how? Maybe we could make progress on these? What do you guys think.

B

Yeah, I think we have a list of pull requests spending that I would rather review.

A

Okay, do you want to present marion, or do you want me to do it.

B

um Yeah, I can do it.

A

Okay, I'll stop.

B

B

So we have one two: three pull requests from cash vj.

B

B

Yeah for now, that's it. Let's stick to those two, so I have reviewed this one. uh There is my approval. um We discussed it last time, mukesh presented it, uh it's uh direct being indirect and drop actions for a routing table. um So, from my point of view, everything was fixed. There is.

B

There are those three new actions done separately. um All the infrastructure in place uh is is more cash on the call, by the way.

C

Yeah yeah I'm here.

B

uh So what about the duplicate attribute? Was that fixed as well.

C

Yeah that is fixed uh I'll, raise one more follow-up here for the uh the comments in the side, with the generated editors right. If there is an ad condition and those kind of things where we have to just say uh both conditions, both actions uh are have to be, can be allowed for this parameter right. So those kind of things I have to fix yet, but in terms of the ipa header generation itself, it compiles, and it's fine now.

B

Yeah, okay, so I will, by the way uh there is a parallel work that needs to be done, so I will uh be doing it today. uh Based on those pull requests, I will regenerate psi apis and submit will request to cyber repository, but to finish on this one, it has my approval. So everyone else please take a look. I will.

B

uh I will give it another uh day to provide comments so yeah. If there are any change requests, please submit this. One looks good to me: I'm willing to merge it. So that's that's number one.

C

um Did you say yeah should I generate these apr and ocp repo.

B

Oh, probably I'll do it myself after we.

C

B

This merged, I will generate side api myself.

D

Okay, marianna might be missing something, but what what needs to be submitted to this psi? Repo, that's not auto generated like within our dash pipeline.

B

No, that's actually what needs to be done. The auto generated api needs to be submitted.

D

Oh, you want to actually put that in the official repo.

B

It is on the dash branch it already is there you'll go to github, github or cpsi res branch dash, which has uh apis over here, aligned with the latest master master on the dash repo like oh here, they are.

D

So, what's the purpose of submitting these to side if they're still sort of in development- and they might get some churn- is there any benefit to put them in the side? At this point? At this point,.

B

Yeah because there is sonic work going on so I understand there are changes. So that's one thing that I'm trying to keep to the minimum changes to the existing apis, but what we have already um is being used uh in sonic. It is integrated into a sonic branch in cyredis.

B

It will be used by orc agent orc agent work starts, I don't know it's microsoft, who's doing that, but it's supposed to start this week next week. So we have all the infrastructure in place.

D

So if this were suddenly in the sai repo, let's say you know tomorrow, which I know won't be how we're going to integrate that into the uh dash pipeline, build system, because right now, that's generating these and sort of appending them or inserting them into the files. What's what's your feeling that how do we reconcile those two sources of truth.

B

Well, this is, let's say a snapshot. um The behavioral model will always have the latest one. Any changes would be done. We need to take the all the behavioral model. Tests uh needs to be done based on the uh latest auto generated, because we are doing change to the behavioral model first and we get the apis. We run the tests here. It is a little bit, uh maybe a little bit behind. I try to keep them up to date.

B

um Yeah, okay, we're not yeah. So this one is there's still one source of truth. This one may be just a little bit behind in time. That's it.

D

Okay, do we want to when we submit things here, I think would be good to put in the pull request like the commit level of the dash repo that those came from, so you can always backtrack and know exactly what what its uh origin was.

B

um Yeah yeah I'm trying to do that to reference one from another and github displays. All of that. um Let me see comments. Let's go to the comments.

D

Because you're kind of manually copying it right so so there's no like automatic repo linkage. You have to put it on something.

B

Yeah so let's see comments. The last change that was done and submitted to the behavioral model was remove inbound vm table uh yeah. I don't remember which one is referencing which one but you're right. It's a good thing to do. uh Probably that's something that we will need to have like best practices on as well.

B

um Let's see, maybe it's here.

C

I'd like another label or something in reference that.

B

uh Yeah also true, okay, it's not this one. Maybe it's this one.

B

Also then, I guess I forgot to do it as well, so probably yeah. We need to come up with some way to reference. Those two because they are uh one is result of another. The uh ocp cycle request is the result of this one. They are not referenced in any way.

D

Even just a comment uh for now: um you know that has the commit of the dash repo, it would be minimum. You could always regenerate everything. You don't want to lose historical. um You know bookmarks, so to speak.

D

Yeah someday it'll catch up to us when we have to like go backwards and find out where something went wrong.

B

Yes, I agree yeah. Thank you.

D

B

um All right, so probably we'll start with this one. Sorry on this one. um Where was that? Let me go back to so we'll start this process. I guess, with this pull request uh to keep track of them. I'll reference put the references involved.

B

um Then, okay, there is another pull request. Fix duplicate fans is vijay on the call. Can we talk about it.

E

Yeah hey, uh so this was the build issue that we were seeing because some of the psy attributes from the p4 are getting appended multiple times. Basically, when you run make psi uh all of the attributes and object id and so on in the header files was getting appended every time you run make size. So if you run make side like five times, there would be repeated five times and that would lead to a compilation failure.

E

So I guess we were not seeing this earlier because when, uh when you do make all the first time we net out builds and let's say, you're starting on a clean repo, then you're only generating it one time and the c compiler doesn't complain, but there's a particular sequence where, if you do make sci, let's say two times and then try to do, make we net out, then the compilation was failing.

B

Oh sorry, uh-huh it depends duplicate. Let me see you mean that uh what files are affected.

E

This is the uh the auto generated files, uh the side size.

B

Extensions yeah.

E

Yeah there are, I think, three or four files which get affected yeah.

D

All right same thing, all the extension files I mean another.

B

D

B

Yeah, well, uh I can comment on that. This is actually really good change and forward looking because uh what you may have noticed is that the current structure is the following: we have master branch inside repo that doesn't have dash apis and we have dash branch inside repo that has right now dash apis.

B

So every time we do header auto generation, we clone master branch, which means that we have a clean psy, and then I append everything and if you'd do this trick, uh as you mentioned uh more than one time, you'd get duplicates uh the plan for sonic integration is that we will merge dash apis.

B

I believe it will be more or less stabilized. After we have the v-net routing and acl changes uh merged, we will have the dash branch merged into master branch. So we end up with the situation where, at the point that you, cloned sci-repo, you already get previous version of dash apis.

B

So we don't really want to do the um let's say the the flow will change from appending new apis to actually doing a modification where you already have those object types and you might need to clean them up beforehand. You might need to, um let's say, uh remove the duplicates that this pull request is doing. So this is partial work.

D

B

D

On this, which.

B

One second, one last sentence which we will uh take, but I think it is, it will have to be completed with uh more logic, to actually be able to regenerate dash apis based on the already existing api. So we don't leave some non, not non-existing apis that were present in the previous behavioral models.

E

Right so I guess something some people change like removing a table, then.

B

E

Okay, okay got it.

B

Yeah, but we can merge this already, the for the further changes will be done. I guess on demand. If we will run into that issue, we will face that.

D

um We can we can do one better if you want now. We can merge this as is, but we could also do a trial run of what you're talking about, because right now in the current dash, it's importing psi as a sub module and in fact the current dash repo is not using the psi main branch. It's using my dev branch because of all the fixes for psi thrift generation.

D

So we can import any branch of psi. We want into this and try this. So we could try your psy dash branch as.

C

D

And then you know change it as we need to. But if someone wanted to go to that even more forward-looking scenario, we could actually try that, on a trial basis to see if it blows up yeah, what's what where people's preference you want to do this, as is because as a workaround right now, you can just do make clean, make cycling psy and it will, you know, not have the repeated headers, it's just a workflow command, so you know we can do it any way we want.

D

Did you understand what I was saying bj about how we can we can use a different psi branch to test this out.

E

Right right, yeah um yeah- I was just thinking- uh maybe we take this in as is and then do incremental changes on top uh uh whatever enhancements. uh I'm sure, like more enhancements, would be required to this generator right going forward.

D

Yeah, I'm good with that.

D

I liked your solution. I was going to do a cluejir one that just did a clean in the make file. This is more elegant than like marion says. It's looking forward.

A

B

Okay, so everyone else please review this one um again, probably like in a day it will be merged. If you have any comments, um all right, thanks, yeah, sorry and this one, there is a problem with this pull request. I haven't gotten to it yet uh like to the full review.

B

The problem is that I have a very, very similar pull request and uh let me explain why we need it. So uh previously we had a behavioral model of acls.

B

That was simply like we defined stages and we put eni as a key in the acl which, in terms of like static configuration, will work.

B

The problem is um changes to the configuration, because uh acls are really a security table security group that needs to be bound to eni and unbound atomically, which neither the uh before runtime nor the psy apis allow to do in a way that the behavioral model is defined today. So, instead of having uh let me show that.

B

So this is mukesh did exactly what I have in my pull request. However, I still haven't compared them, uh but if we go to the, let me just jump to dash acl.

B

So if we go here, you see that instead of having this match on eni, which requires us to in case of any configuration updates to do the updates rules, one by one. What we have instead is the acl group id, which we can populate rules ahead of time and then with a single action of uh appending.

B

B

A new group id as a parameter of vni, like your set in I attributes, just set a different acl group id. We can switch atomically from one group to another group of the of the acls, so we won't end up in a situation where one packet matches on a bunch of rules from previous table and then on a bunch of rules from the new table, because we are still updated still in progress, so this change allows for the um or the for the atomic switch of the acl groups.

B

This is why we need it so as a side effect, it will change site apis, which I wouldn't want to do, but this is a very good reason to do that. So that's why I guess we both decided to do this change.

B

The only comment I have like right off the top is that I saw there is.

B

There are other changes so mukesh. If you can comment on them as well. Why do we have changes in the test and in the psy api? Oh sorry, implementation generation.

B

So what we're doing there.

C

C

So I was also like trying to uh make a test for this fight, just populating the active tables and so on. So while I was doing that, I found some uh other issues so try to fix them. So here what I've done is uh so when I tried to test it, what I found was that the p4 was complaining. Basically, the for psi objects psi apis of type object of the type where it returns an object id.

C

So the implementation currently doesn't populate the table key the p4 table key. So basically, what we are saying is the p4 table. Key is also the object id right. This I object id, so the psi object. Id is just a incrementing number that we are returning from the implementation today in the generated code right, but it never goes into the p4 itself. So so this changes to generate that id and also push it to the p4 as a table key.

C

uh So that's what this is. Basically, it just adds the uh adds that generated number as a key to the people without which the test was failing. Uh-Huh.

C

B

So can we split this into two pull requests? First, one is the behavioral model and all necessary to uh to generate site apis and second is uh test and site implementation. Can we do that? Because it's it's a lot of things to to review. Maybe we could do it faster having those two pull requests like if we have the behavioral model inside api, I can then again uh generate side.

B

Api changes, move it to the side repo and have that ready for integration, and then you can follow up on the tests and all the rest afterwards.

C

Okay, okay, so yeah yeah. My thinking was that uh with the test, then it's also validated like whatever is in the p4 and just validate the entire end to end but yeah. We just.

B

Yeah, I understand your point, but we didn't have test before. So it's not like anything will be broken.

C

B

Yeah right now the criteria is the correct api and the test uh it's a great bonus, but we can. We can have it done separately.

C

E

Want to break all the prs in the future, also, just as I api, plus p4 changes and then anything related to test separate, pia.

B

Oh, I I think it's hard to answer. You know if, if there is some substantial change in the behavior that really affects tests, especially tests that we might have in the future- and you cannot re- you cannot change one without changing the other and I believe it will go as one pull request. But here we, my point, is that we didn't have a test. So, let's, let's keep it as small as possible.

B

D

Yeah, um it's interesting timing, because I'm also working on the code generator and the v-net out cpp and uh just started finding some issues which I was going to file and do some fixes for um so yeah. If we separate out some of the infrastop from from the code changes, it might be a good thing also, we did merge. I did merge the um pull request that night and so you'll want to sync to that.

C

Yeah yeah there's.

D

C

Another thing yeah.

D

You you can also, I restructured the dash pipeline tests a little bit so that you can add more directories with more source files and we'll find them all so like. If you were to look under dash pipeline tests, the structure is a little different. Now um you can add like another separate test date, you don't have to mix it in the existing file. If you want and the make file we'll just find them through wild cards and just add the tests.

D

And you know if this is unclear feel free to contact me offline too, but definitely want to sync your repo, because it did some things last night, but we're all heading in the same direction. Good.

C

D

C

Into just the p4 changes and then the intro part I'll keep that so one other thing I did here. I.

B

Think before and the api p4 and api, if anything is needed in the api generation.

C

Yeah yeah, so one other thing I did here is to change the match type to optional. um You know if you can go back.

C

The one thing this allows us to uh it will treat the table as a ternary table right and then in terms of generation. This generates that uh sciatica priority attribute.

B

Yeah yeah, okay. I agree.

C

And another thing is making it optional means that while we are testing also, we can like leave out certain parameters. I mean now. We are um required to manually pass every single match key here, which is not the case with the regular record. So until.

A

We get the range.

C

And the range list, and all that that optional would be a better match.

B

Right, it's the same thing as with um list that we really want to achieve at the end, which may be empty, which is the same meaning is optional.

C

B

Okay yeah. I agree.

C

Okay and uh as a follow-up to this another thing I wanted to do, this is more from the implementation side, so we just have one uh api right to populate the actual group, whereas we have five stages in p4, so I was wondering how the actual population is going to happen right. It is not going to populate all the five stage tables.

B

Yeah, but that, for that reason you need to have when the site api is generated, there should be an attribute pointing to a group. So every rule belongs to a group.

C

Yeah, so the problem is uh it's not just the group because the in the p4, it's also there is also a stage right, so it's actually five different.

C

So the way now it will look is uh each p4 table is a collection of actual groups right, not just one alkyl group. It will be more than one equal group, the one p4 table equal to multiple apple groups, and there are five such p4 tables.

C

So now the question is which cycle group will go into which p4 table right, because we have five stages and each active group belongs in one of those stages.

B

Right, okay, I'll need to look at it offline. I guess I solved for it in my patch yeah, probably I'll, just compare what I did in mine uh to yours and um I can leave a comment. How.

C

So this has nothing to do with the api itself. Besides,.

A

C

B

Previously, on.

C

The stage correct yeah, so the stage id was there previously, so this used to identify which table which p4 table it went to. But I don't think this is the correct uh thing to do in this api, and this is should not have a stage for the apple itself.

B

C

Yeah, so one solution I was thinking was to just for the behavioral model, so this is just a reference implementation right. This is not the actual thing, so one solution I was thinking was to copy uh the same content onto all five tables right. So that way, uh anyway, it's going to be looked up based on the group, so the auto generation will still work.

C

We just copy the same content onto all tables and the way we copy it is determined based on what is the tag name tag given to the table, so the style name tag given to the table is the same then. From that psi, api implementation, we copied onto all the tables uh all the p4 tables associated with that one side, api.

B

Yeah, you are right, but this is the control, plane issue or psi implementation issue.

C

B

C

B

I agree with you, so what needs to happen is that this is actually defined in the p4 spec. Is that when you apply the same table more than once, it really generates?

B

uh The compiler generates uh multiple instances of those tables, and this is responsibility of a control plane to populate them all at once. So this is what psi implementation needs to do. I agree with that. Yeah.

C

So so yeah I can make that change as well in this high implementation for the implementation generation.

A

F

So why why do we call these this journal? Why are we calling these acls as opposed to rules, because rules are defined differently than acls.

B

um You're, probably right we're talking about so this is the acl table, but when you but api is per one entry, so that's really. When you call the api you create one rule, you don't create a table.

F

Yeah, you create a rule which is very like lists of things, and it's not.

C

F

It's not a firewall filter, it's a rule.

B

Yeah, it's a rule right. We can rename it to rule as well.

F

Because I really so.

C

What we call yeah, what we call axle here, is actually the room.

B

C

An actual group is a collection of groups. Yes,.

F

Well, it's not it's a game, it's I don't know. Maybe it's a p4 thing, but it's actually uh it's a group of rules and uh yeah, but I don't know if you call it an echo group. um The rule group.

F

Is that just a p4 nomenclature thing, because.

B

um No not really. This is.

F

Actually, how it is named.

B

In the sonic schema, so it's really aligned with the sonic schema. It's called acl group and sonic as well.

F

Okay, but they don't have a notion of rules, though, do they.

B

Yeah there is an acl group, an acl rule and the acl rule is pointing to a group.

F

Okay, well at least use the word rule because it is a rule it's different than it's ever been. It's never been defined like that before, so we got to differentiate it to make sure people don't think of it as being a firewall filter which it's not right. It would be easy if it were, but it's not okay and it's also a prior. So that group, it's a prioritized, it's a prioritized list of rules right. So it's not just a list of rules. It's a prioritized list. Yes, so just make that clear.

A

Yeah, this is new in sonic for sure it's not there at the moment.

F

He's in the background, bro yeah.

A

Oh sorry, I have connected a different, monitor and whatnot. No, I was just uh agreeing with you that you know today it's not there in sonic and this concept is not there. So if we start to use the word rule, it will be much better yeah. In this context,.

C

I mean might be.

B

Yeah, probably.

A

B

Let's do it all at once, so yeah, so to summarize two pull requests that I already put an approval on. They were there for a week. So if anyone wants to make any comments, please do you have another day uh and this one is still under review. It's quite big, so I really am asking for splitting in it into two yeah and that's it.

B

There are no more changes to the behavioral model. At this point.

A

Is it okay with you? If I go over a few items in the list, then marion or did anyone have questions.

E

Hey uh yeah, I think uh mukesh and I we wanted to bring up another uh just a question about the uh v-net uh table. um So mukesh, do you want to just discover that the proposed change to the outbound pipeline, what we were thinking, whether it makes sense.

C

Yeah, so we had some questions about where the vni is derived from in the pipeline and how it matches to the gnmi approach. I mean gma model and we wanted to see if we can uh bring in the wiener table also into the psi api. I know we talked about this marine. I think vijay had mail and we have applied, but we just wanted to go over that possible in this meeting.

B

Yeah, you can present that as well.

C

Okay, I'll just share.

C

Able to see my screen.

A

C

Okay, so I've just tried to show the current model here and the proposed model below so the current model. uh What we have is uh the dust mat in the packet, uh so this is the outbound direction.

C

This mic in the packet is uh matched in the ni either table and it provides an eni id right and that we look up in the ni table to get the cpsps flows and all those things uh also. We we match it in the there's another eni to vni table which gets us the uh end cap, pnr in in parallel, the eni also is used to look up the lpm table with the test ip and then from there we get a dust vnet vni uh which so we need to see if this overrides.

F

C

Connect so this this does vn v-net vienna is used to look up the ca to pm mapping, but it also could overwrite the final encap pni that goes out in the packet, but that decision is based on whether the uh there is a boolean coming out of the ca to pm mapping, which is whether to override this or not.

C

So this is the current uh pipeline in uh in the dash p4 code now, uh so we think the gnmi is this way, so we were wondering if we should change the p4 also to this way right. So the pipeline seems to be like this part is the same. So we apply the dust mag and then we figure out the eni id and from the eni id we actually can derive a v net id from the en table and the v-net id is looked up in a v-net table to get the end cap piano right.

C

So this is the gnmi model and at the same time, the eni id is also looked up in the lpm table to get a v-net id, and so this v-net id could be different from the v-net id coming from the eni, because the lpm in case of v-net peering cases, the lpm, could give a different v-net id.

C

So finally, we need to look up the v-net id coming from either from the ni or if the lpm has overridden the unit id, then we use that minute id to look up the vena table and get the end cap piano, and then there is also a possibility that and obviously the v-net id coming from this is also used to look up the ca to pa mapping right and then. Finally, we uh there is, there might be a case where the ca to pa mapping can also override the fincap pnf required.

C

So this part, I'm not sure if it's really needed, because the gnma examples never covered this uh so either the encorpion is only coming from the venus table or from the yeah. So that's that's the question that I have for the gnm itself. But overall the question is uh to us: this looked uh like a more clear way of representing the gnmi model in this iap as well, and it will be a straightforward mapping from gmail to size what people and this. uh So we are here.

C

We are making some assumptions that the v-net and the vni are the same. So we are overloading the concept of the vna. I thought so.

B

C

And the vni is.

B

Actually, it is the same. One thing that I can add to the second diagram is that uh you have actually two venus there, one that is determined from eni, and hence you have two two vni's in the first diagram, uh the v-net that is looked up from the eni is the source unit or the v-net that this dna belongs to, and the v and the unit that you get from the route. Lookup is the destination vni or the a destination v-net or the v-net that this packet is going to be forwarded to so yeah.

C

B

Actually yeah same.

C

Thing so we could bring another wiener table, look up uh here, just after the vni required, but at this point it looked like. uh We only need one lookup in the peanut table and whichever uh v-net I mean, if the lpm overrides the v-net id, then we can use that p-net id to look up the unit double because we're only getting the end cap vni in future. If we actually need two lookups, then we can actually bring in another v-net lookup in the behavior p4 code here as well.

B

No, but you have this lookup, you look up eni and you get v-net as an attribute of dni.

E

Right in the there's, currently only a single vni, uh which is coming from the v-net table, uh irrespective of the direction.

C

Yeah, so the green id could come from the eni or the lpm right, uh so the v, but.

B

Those are different again.

C

It may be the same or may be different right, so we don't.

B

Do the same as.

C

B

I mean the meaning not really like, if you're not crossing the v-net boundaries, it's the same unit, but I'm talking about uh semantic meaning uh in iv. Unit is the source unit where you're going from and lpm v-net is the destination unit where you're going to it may or may not be the same.

C

You know yeah, that's true so, but uh in the model, ultimately we're just using it to derive the vni. Yes,.

B

C

Gma model what we are using, it is to just look up and get the vni so for now.

C

You're thinking just use the deskt v-net id, whichever wherever that is coming from and look up the v-net and uh so the source v-net lookup uh is not yet there, but we could bring it later if we want as well.

B

Yeah, so that that's right, that's a good thing that you are pointing out, and I already issued a question or request for clarification to um to the guys that are defining gnmi for the controller, because to my understanding, by default source.

B

Source vni should be used. Overriding vni to destination. Vni is rather an exception, not the rule.

E

Right, but it's also an optional thing right, because lpm, if it doesn't drive a v-net id, we are just going to use whatever is the v-net id coming from eni and that will be uh that will drive the encapriani right. So the.

B

E

Is an optional thing.

B

No, no! It's not because it's used for ca to pa lookup, it's not an optional. Is it mentioned as optional.

E

uh Yeah, I think the way that the proposal is, I think.

A

It depends on the action when it is optional and when it is not optional, so for these v-net direct to init uh actions, it will be v-net is required.

C

And it could be the same as the eni or it could be definitely.

A

It could be same, it could be. I mean that that value can be same, but, like marian mentioned, the semantics are different right and I think mukesh I will add examples for the one that are missing, um but I think overall I it looks like the proposed outbound is a little bit cleaner, right or clearer.

B

So do so prince. Do you want to introduce the concept of a v-net.

A

That is, uh that is a little bit more straightforward right.

B

Okay, so well, actually what will effectively change um is that we won't have dni to be an ilookup. What we will have is um the v-net table, and then um it will be also used. Oh, but let me think so: there's only one v-net table so um not sure how that will work in the p4 model. I will need to think about it, because we have two units as it points out, and we need to have vni resolved for both of them. So yeah.

C

So so today we only get the vni from the dust venus right, so I think we could use it from the lpn one stuff.

A

We also have the other.

C

Concept of could also have the other thing of uh like we could see once we have the tackle solution where uh I was saying like we could copy the contents right, so we can have as many lookups of the same table as we want in the p4. Oh yeah,.

B

C

With the singles type here so that way, we could still have uh source v net lookup and a desktop unit lookup in p4, but it's populated with a single control, plane, side, api.

B

Yeah, that's also true yeah.

C

Yeah so for now uh we could do it this way and then, if you want, we can introduce another unit table lookup in the source. Also, if you need it.

B

Well, we do need it in this source. I believe I'm still waiting for the answer from the author of the gnmi schema, but right now, I'm assuming that we will need it.

C

So that's a question to print right.

C

Where the vna, the basically the v-net id from the are eni asking whether the v-net should be looked up from there. But what is the question I didn't get it.

A

C

A

To vienna yield, uh you know exactly.

B

Source vni or source v-net.

A

That's the mapping for from a vm to an actual bni, and that comes from the controller right. The source vni.

B

Yeah we we do have.

C

B

In the schema, however, we don't have a knob to choose for aca to pay mapping either we are using source, vni or destination.

A

Yeah, I think, merit that's the boolean part right yeah that we can clarify. I think the the other question is. uh I believe what mukesh is asking from eni to veenat right. Is that what mukesh.

C

Yeah my is uh so. There is a v-net id coming from the eni. Yes,.

A

C

There is the wiener tidy coming from the lpm right. Yes, now, which vni should be in the encapped package. I.

A

Don't know that is, that is what is determined by the the boolean.

B

Which is missing from this schema right, yeah.

A

Which is missing from the schema which I like I mentioned it will be, it will add, like we'll, have to have some discussions with the with michael and uh the sdn team, and- and I think that's what marian mentioned about the.

C

Jnmi folks.

A

C

A

C

That was the uncareful, so we were thinking always the one from the lpm will overwrite, but you're saying there is a boolean coming from mapping which will decide whether to use the vni from the eni, yes or the source vnet or the this unit. Yes,.

A

And how that is uh determined is what is the miss? The gap in the in the current schema like whether it is through a boolean or the capm mapping itself will provide the vni or the source when I I'm like, which is not clear. So I I think uh that that part will be clarified and I'll put some examples. All they need is the destination vni right and just.

D

The destination is from.

A

C

A

Both vnis are available here. I think so. The only pro problem is which one to choose right, and it is the same I mean sometimes it would be the same. Sometimes it would be different whether based on it is in vinnette or intervene at right. Yes, um so it is, uh we just need the lpm lookup. I I I feel you know we.

C

A

C

Understanding, but I think the what they're suggesting is there should be a boolean in the mapping to decide whether it's the source or the best. We even if it's different.

A

C

Might still be sending with the source, we know things. Oh.

A

B

Yeah because look at it from um basically from the inbound direction, I believe, on the inbound you will be receiving if the packet comes from a different v-net. You are receiving usually vni of that v-net not of yours unit, but of the other.

A

B

It originated from.

A

E

So prince in that sense, in that the schema we are thinking of adding some boolean in the v-net mapping table right.

A

E

Something similar okay.

A

Yeah in the cap table yeah.

C

So we had one more question about the inbound case as well.

A

So I think I think mukesh before we go, so what is our plan for this like? If is it? uh I think it looks like some. Some changes is happening here right with the proposed.

C

Yeah we can actually change the change to introduce the wiener table, okay and make it v-net id based right and then based on your final confirmation, we can add a source v net id lookup and we can have the.

A

C

In the mapping, which is already there, but we can just convert it to instead of directly specifying uh yeah, we can use that to drive whether the v-net, when vni from the source unit or the bni from the dust unit should be used.

C

A

C

Can change it to a v-net id and the v-net based lookup, as given in the lower part of the picture.

E

And also we'll remove the eni to vna table.

C

Yeah, we'll change that to like kind of the wiener table, as it's shown.

B

I'm okay with that, but I'm almost certain that there is also a source v-net. So you need to take into account that you'll need to do like two v-net lookups in the behavioral model.

C

Sure, yeah yeah. Why.

A

Do we need the capa mapping before the v-net on the top.

A

The v-net table the eni to vni was a bit more clearer. I felt the the current outbound you know in the proposed outbound. Why do we need the capa mapping to happen before the v-net on the top.

C

uh It's not before it's just the same. This thing right, there's no, there's no sequencing there! Okay yeah! I just moved the v-net id v-net lookup after the lpm, because it can come, it can be driven the vnet id to look up. The avenue table could come either from lpm or from the eni, whereas in the top case the ni to vna is always coming from, but in case we are going to make two v net. Lookups then uh yeah, similar to the united way.

C

There will be v net lookup, also in the bottom source, v net lookup, and then there will also be address v network based on the lpm's lpn's phenotype.

E

Yeah, I think, in the diagram the table placement is just shown parallel, but actually it happens.

C

So one other thing I wanted to bring up was: uh the v-net also gives the inbound vni right. The same vni is also used for the inbound case. Also in the gnmi model, the source mac will be used. Sorry for the inbound direction.

C

Okay, I think I've given it wrong here, so in the outbound direction, with the source map that determines dna and the inbound direction, we use the dust mac to look up the ena and then get the v-net id and the v-net table would provide the vni for the inbound case.

C

So it's the same vmi right, whereas I think in the current p4 model there is separate uh vm vni in the eni table.

E

Table yeah, so that also yeah I mean that will also yeah.

B

I'm sorry I didn't get that. Can you please repeat so.

C

B

Are you talking about that? Has bni.

C

So the eni table here that has a vm vienna attribute in the current pipeline.

B

C

B

I see it that's next in the inbound case after we receive the packet and we verify that it is allowed. What we need to do is to end up to the vm's real va.

C

So dark vmware is also the same as the venus vienna is our understanding.

B

A

It's not uh guaranteed um okay. Sometimes it will be some reserve to be a nice. No.

C

No so princess this is not the packet coming from the thing right, like vm, it's the packet sent to the vm. This is.

E

The inbound case.

C

Right so the internet is the package.

B

This symmetrical right if a packet comes from host to the dpu with a reserved vni, so the expectation is that the dpu will send it to the host with also a reserved bni, not the vienna dna.

C

uh So in the gnmi model, where is this uh reserve vn? We didn't see any vna in the eni table in the gnmi.

C

Is it in that plane? Yes,.

B

Yeah, I believe it's still uh needs to be closed.

A

Yeah, I think that list is not true, it is, it is just single vni.

C

So there is a single reserved vna in the plane and so.

B

C

Do we have to put that in the eni table in the p4 pipeline right? Even then, it can come from that place right. Why do we need it in the eni table.

A

Why do we need it in the eni table? Because there is, I don't think we have a p4 for appliance right before model for appliance.

C

We do have a planes also.

B

No, not really, I think it is redundant, especially with the attributes that it has right now, so the appliance actually models all the missing things from the underlay like the neighbors and stuff. It has to be actually refined in a way it doesn't really model the appliance.

B

So we can agree on having one vni for talking between the appliance and the host. That's.

D

B

Way to do or another way, which is which it is modeled right now, is that there is really an option to have different vnis between a host and an appliance so that on the uh when the packet comes from the host you have you have a table. I forgot its name. ah Actually it's a direction lookup table right that all this special vnis it tells you to do to go outbound, but it may be more than one right. It does not make an assumption that all foster will send the same.

B

Vni could be more than one so same thing in here. The same assumption is made in the opposite direction. When we are sending from appliance to uh to the host, we are not making assumption that it will be uh the same value, although it could be like it is defined in the schema, but we just didn't make this assumption. We have vni value towards each host individually.

B

It doesn't really break anything, it's just more granularity on behavioral model level, um and that's it. You can make assumption that for now it's just one value.

C

Okay, so can we confirm this with the wiener thing that always the packet going back to the vm would be the drizzle and.

B

C

Think, rather than the actual vni.

A

So basically, you want the inbound, the lookup.

A

Yeah, I I will add that as well in the in the example yeah.

C

Yeah, so that makes sense. So if it is the reserve bni, then marion, what you're saying is we'll drive it from the ni table as a reserve vni. That user will configure.

B

C

B

You can imagine a flow where you get the reserved vni from the controller and you program it in two places in the direction and for each dna for each dna.

E

Yeah, I think, because it has implication on the behavior model- change that vmvni, whether we retain it right.

C

So one question is uh so from the controller. The vni is a global thing right, uh it's in the appliance table, so it's not specific to any eni. It's a vmware, multiple.

C

Yeah, so what's the case you're saying like there could be more than one uh bni right so, but today.

B

Behavioral model allows for that: it's not necessarily yeah, uh I'm not sure. If we would want to stay with that or remove it.

B

Maybe we can generalize it to be like in the um like in the controller, just one value, but I don't really see a benefit and that you can just stay with um with the assumption that psy provides like for more flexibility and that's it doesn't have to be one-to-one.

B

A

B

Really, a drawback: if you agree.

A

The eni vm to vni is always reserved and always uh special right. The only vni that is not reserved is in the other direction to the after that comes after the ca to pm mapping, but from vni sorry, the eni, the bni is always uh reserved and comes from. The controller is what I thought.

C

Yeah, so that's the question like this: are we supposed to send with the same reserved vni back to the vmware.

B

Clarify that maybe for next time sure.

C

E

uh No, so I think uh yeah I mean if this at least the concept of introducing a v-net table uh looks okay. We can actually start looking at their model. Related changes.

B

C

A

Okay, so is it um I'm just gonna end the meeting I'll in the call and uh just share my screen real quick on the I did create um the items we talked about last time, the p4 issues here at the bottom. um If someone wanted to pick up, egressport should equal the ingress port. um We bud, went ahead and created these two mukesh picked this one up and there's this one remove the eni id from the pa validation table keys. So this is where I put these for now.

A

If you'd like to work on them, I put them in the chat window and I'll stop the recording anything else. Marion.

C

A

Thanks everybody sounds like there's a lot to work on for next time.