DASH Behavioral Model WG, 14 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DASH Behavioral Model WG July 14 2022

Description

Discussed PR141 - will keep a separate action
P4 fixes needed
#146 to saad-mhzr

A

Meeting for dash it's july 14th and we could get started so we're, I think, where we left off last time, um we had 137 that needed to be reviewed and approved. We closed on the white box, black box testing discussion and um I think, let me pull up the project here.

A

And share my screen.

A

Behavioral model, can you guys see? Okay, yes, yeah, okay, so great thanks and I think we had a couple of items to check back on um today today during this call um july, 14th july 14th. That's today, okay, and so um I was wondering, though um I wanted to open it up. First, I know bud had a question, and so I thought maybe, but did you want to ask your question well before we get started.

B

um I could there's there's actually um like several questions um about.

C

B

Tables in the p4 code, uh we can leave it to the end. um I'm not that picky.

A

Okay, um why don't we go ahead and then check back on these real quick? We had where you want to go ahead and check back on the ones for the 14th.

A

I'll go into the by owner view here, so I know we wanted to check back on um number seven here: connection tracking in the simulator we were dependent on p4 community.

D

Yeah this one is not dependent on p4 community anymore. However, there's still work to be done, but it is currently on hold due to uh resource allocation, so uh yeah. I cannot provide a new date until we resume this task, uh but we are not blocked anymore. uh We just need to get to it at some point.

A

Okay and are you, are you saying you have to do it yourself or are you asking for, like oh.

D

A

D

We have other person in my team doing that.

A

D

uh But he's busy with another thing so yeah.

A

Okay, all right so you're not asking for help from anyone. Okay, that's helpful thanks and then.

A

Is mario on the phone me it's hard to monitor both here.

E

Yeah yeah yeah um how's this moving on moving on, but not done yet.

A

Oh you're, moving on okay, great awesome. Well, should I put it in drafting or in progress. I.

E

Mean progress in person, okay,.

A

Great awesome check back next week then see how it's gone.

A

Someone have some music going. That's that's helpful in the morning. um I need to size down this uh window. Real, quick.

A

That's better: okay,.

A

A

I think that's all we needed to check back on. um We've had conversations about scythe thrift, we've.

D

I thought there was another pr.

A

There is wasn't it number, um let me check it here.

A

This one, um the adding the tunnel table to the pipeline.

D

A

D

Tell you the v-net direct uh route by.

A

Okay, yeah it's right here. I've got it on the screen. Number 141.

A

So do we have mukesh on the phone.

F

Yeah- and here.

A

Great okay: let's talk about this one then.

D

Yeah I saw uh in the behavioral model implementation the v-net direct route is left empty. Can you please explain? uh Why did you do it this way.

F

Yeah can uh share my yeah.

A

Are you trying to find the sharing button.

F

uh Yeah, I'm just trying to it's the permissions.

G

Careful it is next to the leave button so.

F

Yeah, okay, you will just see my screen now.

A

F

Okay, so so basically, uh this pr is about handling all these examples from the uh sonic hld right. So there are four four cases here for phase one: uh the v-net we know direct uh the direct and the drop.

F

So we have added.

F

Four cases here, uh three cases here in the route mean it was already there, so we've added the direct and the drop so and within the v-net is where we have the v-net and v-net direct both are handled here. uh So I'll first go to the direct and the drop, and then we could talk about the.

B

F

In the minute.

F

So, basically from the example, what direct means is that we don't do anything in the overlay. We just send it to the underlay uh for underlay routing the packet incoming packet from the vm is decap, the outer header is decap and the inner header is just routed in the underlay.

F

So that's how I handle the route direct.

F

This is nothing to do here, but we just need an action here so that we can configure this from the uh gnml from the uh dash containers and then the drop action is pretty obvious, so we want to drop those packets matching those prefixes.

F

You just set the drop to true so the so that leaves the route we need so in the route we net. So what we have done is so this handles, like we said here it handles both these cases. So the first case is where uh we ponder the mapping table the ca to pa mapping table.

F

The second case is where we point to the mapping table plus, but we also have a uh ipo right, meaning the lookup ip, the ip that needs to be looked up in the mapping table and needs to come from this routing table, whereas in the first case we just use the ip directly from the packet, the best ip from the packet, so so to handle both those cases. uh We have this flag now called use overlay and hyp, and we also specify an ip here in this uh in this routing entry.

F

So if this is false, then it defaults to the route v-net case, and if this is true, then we specify an ip here and then it goes into the v-net directories.

F

um So the other way of doing this would be to create a separate action called route being a direct and not use a flag. So we could do that. Also. Currently, when I tried that I hit one limitation, which is that uh this dest v net vni would be a parameter that would be shared by both those actions right so uh so the psi api generation was ending up, generating two different attributes with the same name, and that was getting a compilation error.

F

We can fix that, but I was wondering whether we should create a separate action for that or just leave it like this. Here.

D

I believe it's better to create a separate action, because this way you will need to have another boolean attribute, which is um I'd rather avoid that.

F

Okay, yeah: we can fix that so I'll work on uh also fixing the uh api generation tool to just uh not create the duplicate attribute.

F

uh So once I do that, I can create a separate action and then I'll get rid of this boolean bit here and so the route being a direct will have uh the disk finite vni, the overlay nh ip and the. So these two right. No, it won't have this blank and it will directly overwrite the lookup.

F

So what we have done here is that we created a new meta variable called the lookup test ip and that's what we are going to look up in the mapping table instead of the one from the packet we're going to use this lookup desktop.

F

So by default we copy the ip from the packet into this lookup and then, if this is set, then we overwrite that lookup with the one coming from the routing table.

F

G

F

I make a comment.

G

Yeah so uh so there is obviously one of the I mean between the two choices. One of them is more memory efficient right, so essentially, you'll be adding a bit to the whole of the routing table. Whatever is the size right could go into millions in cases right. uh So adding actions also adds because you need to select a specific action, so it might depend it does depend on.

G

uh You know how many actions you have and if it is a true to the power and what not, but at least there there is more possibility of optimization right and whereas, if you just add extra parameters to actions, they all become the so called associated data, and then the maximum of of any one of the parameters of the actions is the width of the memory you need to keep so uh so we can do some math and clearly you will have one that's more memory optimal. So I think writing code.

D

I I tend to disagree with that, because this is behavioral model. You are not working on optimizing. The memory usage we're working on the clearest definition of the behavior.

D

This is not supposed to be interpreted for implementation, one to one.

G

No, I'm saying that we don't need to exclude that. I agree with you that you know we don't need to focus on exclusively memory, but somebody may use it as a real thing also, so you don't need to preclude that and you don't have.

D

So any optimization can go underneath. What we are exposing to the real implementations are um api. An api can be interpreted in many ways as long as they follow this behavior.

C

Yeah yeah, I think the api part is important, because this is going to translate into side table manipulations, ultimately, regardless of the implementation. So we have to be really conscious of the api that results from all these choices. Right.

F

Yeah, as long as the api lends itself to optimization from the underlying layer.

F

D

Yeah, so I think I have only one comment to really have two actions over here. It maps very well to gnmi defined for the controller.

F

Sure yeah yeah, because even in the jeremiah documentation I thought I saw so the we need to mean it in the other document. Here I thought I saw cases where even uh the between a direct was called venus action.

F

If you see here.

F

The routing table action type is v-net, it has overlay ip, but the type is v-net.

F

So I don't know. Maybe this is wrong here. It should be v-net direct because in this there are two.

D

Examples right, yeah, sorry, what I meant is not genomic the uh layer in between the application, the b schema. You have two different kinds of uh routes: there.

F

Correct yeah, so now what I meant is from the genome itself: the difference between this v-net and v-net direct just to be clear.

F

So the hld document says that the v-net means go to mapping without aip and v-netdirect at least the example says that there will be an oral ip, whereas here in this document the wiener to wiener document.

F

This is knotted there in the master, but I saw a pull request with this and we did purple in one of the older meeting circuits. So so here it say here in this document. uh The vnet action has both does both going to mapping without the overlay ip and uh top here. This doesn't have an overlay ip, and here you have a v-net action, but it does have overlapping both are called. The action is the same. The action is good. Maybe I don't know if this is a typo here.

A

It's very impossible, that's something we were working on and we're going to get feedback on. Yeah.

F

Okay, so that is the case, so then yeah so the second action, the we need direct action that we'll be creating that won't have this boolean so which means that vnetdirect always means overlay ip will be provided if it's not optional, we'll go with that assumption.

F

I'll make those changes and.

A

Yeah, I think, we're all quiet, because we're thinking so yeah.

D

No everything else looks good yeah, yeah.

F

D

F

Change I made was the make file. I just added the dependency for all the p ports. Whenever we make a change in the p4, it was not building the uh the json, then the other change was like. uh We just added the drop action at the end of the pipeline to just to make sure that when we say drop, it basically drops here.

F

C

Yeah, I saw your change on the makefile dependencies that I had something like that added in another pending pr, so we both found the same thing. That's good.

D

So maybe you can have it removed from here, because this one is not the infrastructure. This is behavioral model. Let's maybe keep infrastructure changes separate.

F

Sure yeah, if it's coming in later than that I thought yeah, the word changes will immediately start seeing this, which, whichever year goes first.

C

Yeah and by the way, thanks for following the um the issues here, both mukesh and and bj, filed some issues that we talked about. You know verbally yesterday, it's good to track those. So thanks.

A

So I'm going to go ahead and make a comment to the pr just what we just talked about. You know I was just taking notes while you're talking, if that's um okay,.

D

Guess no need, I will leave it myself.

A

Oh, I was doing a lot of typing okay I'll, take it out all right um great and then yes, if you want to get with me about what let's do it over email, um the piece you believe is wrong. In the document um I can make changes sure, yeah, okay, all right.

C

Can we talk for a minute about something that came up in this discussion about how the the psy api is generated from the p4 code and there's a lot of implications um in terms of generating the official site dash site api? How the p4 code is written? We probably need to outline some design rules or guidelines for that, because someone could make something that runs fine in their development environment and they make some innocuous choices on the table. Implementation and don't realize the impact. Let's say on the site: api: that's going to affect everything.

C

So do we need to have a talk about that at some point and lay down some guidelines, because not everyone appreciates the hidden implications of things.

D

On one hand yeah, but on the other hand, don't we have ci cd for it at least, to not break anything.

C

No, no! It's not whether or not it's broken. It's the choice. The implementation choice that someone makes is going to affect the psy api. That's going to trickle all the way up to the sonic integration right, so we have to design the table so that the resulting api is what we want. I'm not worried about the breaking that select follows, but how we define things has a lot of subtle implications, right, yeah,.

D

There are rules that can be defined. That's true,.

C

Not everyone understands psi best practices, let's say, and um I certainly don't have a grasp of all the implications hidden or otherwise. So if someone defines a p-4 table that runs great in their simulation and works and they write tests, but then um someone else says: oh gosh, that's um not a very ideal way to implement the psi interface that comes out of that. Can we do it a different way? We try to figure out what some of those rules are. If there are any.

D

Yeah definitely well, I think I can uh outline some basic ones. uh There is the there is an advanced section with regards to acls, but that was basically just the choice of implementation, so it's rather an exception.

D

um Yeah, probably we can do something like that, and there are. There is future work as well like, for instance, it's not very clear how to write p4 program in a way that it will properly uh generate apis for counters. For instance, it's not yet clear to me, but I think definitely we can do stuff like uh describe.

D

What what goes into those attributes, how the names of keys and action parameters affect them and actions themselves so yeah? You can describe those rules.

G

Yeah, that is great, and that is great guys. I think this is you know thanks chris, for bringing this one up, because, as we just reviewed this pr, you know that that was pretty evident, that somebody made a mistake, but not made a mistake, but you know what what they chose really resulted in some sort of like compilation right. So I think, as we define the rules, one thing will be important is how how are we going to enforce them as part of the cicd?

G

That should also be uh you know. Besides, just basically, you know somewhere and pointing it out. Let's make this one as part of an automatic process of how we enforce.

C

It right yeah, so I see two action items here: one is start creating a set of rules, design, rules um or principles, and even if it starts out as a readme with quick bullets to get the most important ones. That are right on top of mind, because we don't want to make this having to write a novel that never gets written because you know so, let's least jot down the most important ones.

C

And then the second action item would be create some tooling to do some style checking or something just like you know, when you do psi metadata generation, there's just tons of checks that are done like did someone change the value of an enum from the last revision of psi, etc. There's all these scripts in there that do that. We can possibly do a similar thing for the p4.

C

Make sure that you know the p4 info doesn't have certain things in it. That would be unfortunate for the side generation, for example,.

H

Martin, do you have any idea of how that might be done? You know. um Well, if it comes to like consistency.

D

Across different versions of psy, there is, I believe, um as long as dash api is still in the experimental.

D

We have a waiver on that, so we don't need to keep the order, everything else like uh style checks and all that uh it is enforced by the api generation itself. So uh there isn't.

D

I don't believe there is a way to define uh some kind of name of the key or parameter that will result in invalid name in psy, except for those cases like uh what was found with this pr, where the same parameter is is found in more than one action. But that's that's where we need to actually do improvements inside api generation, not to write p4 program in a different way, and that's why I'm insisting on doing it the right way to actually change the api generation, make it smarter generally. What I'm trying to do is.

D

To not need to think about how you write your p4 program that it will affect psi api, because people don't think about how they write a program and how the p4 runtime apis will look like it's just a different look and feel.

D

But if we find something like that, usually it will be a signal that we need to improve site api generation, not to write the p4 uh program in a different way. And that's why I'm insisting on that. We don't need to make workarounds in p4. We need to define two different actions: no additional booleans, nothing like that and.

D

Just fix the api generation, I think that's the right place to to do that.

C

You don't think the p4 code should just have a valid validator after it's compiled, not really okay, but we agree that we need something to catch things, that uh you know discourage practices that don't fit our conventions of some sort.

D

uh Yeah, if we will find a real example of such thing for now, uh what I saw it was that psy, api generator is not working as expected. Okay,.

C

Good discussion.

A

Anyone else before we move on to bud.

A

Okay, let's do it.

B

All right, uh hey, christina.

C

B

um A few questions about some of the small tables that um are looked up at the start of the p4 processing. uh Let me try to share my screen.

B

Right can folks see this yeah all right, so um I had some questions on the vip table, the ethernet address map and the pa validation table. Let me just go through these one at a time, so the the vip table. So my first question is um so I think I know what this is for um it's to ensure that the destination ip address on the outer header matches one of the vips that we advertised.

B

So my first question is: what is the scale of this table? Is it just those two ip addresses.

D

Roughly yeah like for now, I think the common use case will be one ipv4 or one ipv6. Okay,.

B

Okay, um okay, uh so I just actually I'm looking at this now, there's only an ipv4 address in the table as a key. Oh.

D

Yeah uh right uh site api generates, uh like the ip address that you can pick from it's a it's. A bug should support, as we have in other places, um a boolean flag that indicates if it's before or b6. Basically, the family okay um needs to be improved, but that's the meaning.

B

Okay, sure, okay, my second question is that um I noticed here after the table apply is invoked.

B

We check to see if the packet was flagged to be dropped and it and the function returns for the control returns immediately and there are other times where a packet is marked to be dropped, and we don't do this. I don't know if this is um just.

D

Sort of an accidental.

B

Inconsistency or if there's uh some rules.

D

It's a bug uh because this behavioral model wasn't tested thoroughly, especially for the cases where you for the negative cases where you need to drop it back for some reason and you'll find stuff like that, when we will have negative test cases that want to ensure that, with this specific field, uh meaning that something is not really.

D

Done properly like, for instance, we don't have this, uh as you mentioned web programmed or maybe I don't know eni programmed uh for this mac address package should be dropped. uh We don't have these negative use cases, so you will find these inconsistencies till then. Probably there will be like a major task of revamping all of the drop logic in the pipeline.

B

Okay, okay and the last question on the vip table was: should the deny action be marked as default? Only um so I think this means in p4 that um you can't actually.

C

B

Cable entry with deny it's like a miss is a deny.

D

B

D

B

D

Yeah here it's interesting because uh I really would want to have, as you said, only accept action and deny is default only.

D

However, there is an implication on this psy api, because what we have in here is that this entry will generate like an empty attribute list which say doesn't like if we don't have any any parameters to choose from and having only one action results in an empty attribute list. So there is like more to that. That needs to be solved how we properly model that with site apis. Maybe this would be the object where the attribute is the ip address, because right now it's an entry.

D

And if you look at this entry inside api, there is entry itself that has the ip value and then attribute list allows you to choose from accept or deny action. If we would say that deny is default only then there is only accept, which is only one, and this attribute is redundant. We are left with the empty list, which is a little bit ugly, like both ways is ugly. So I'm trying to think how these kind of uh um let's say almost atomic checks need to be properly expressed inside as well.

B

Okay: okay, that's.

A

Fine but logically.

B

um We won't really program an entry that says deny.

F

B

Just be a misdemeanor okay,.

F

Right right, one question: so the the default only tag is not today, honored by the side, the side tool right, yeah.

D

That's what the market default.

F

Only it doesn't remove, I mean the size api still.

D

Yeah, because I cannot leave it empty, otherwise, I won't compile. I still need to leave that choice.

F

No, not it's not just that, even if you want to remove it from the side, let's say some other case right, where we have three actions or more than one action. You still can't leave it, because the json tag doesn't have the default only anywhere express right.

D

Oh you're saying the p4 runtime file doesn't have this information.

F

Yeah, the default only tag is not.

D

F

It's not coming into the json file, so I I don't know how. How can we leave it out of the sign.

D

Yeah right, I don't have an answer right now. That's something for the future improvements.

B

Okay, uh so the next table I had a question on, is the ether address map table and I think you've addressed this uh with what you said before about negative testing. um So we look up the mac address and determine the eni from it.

B

D

That's that's for sure. We just don't do it in a lot of places properly.

B

Okay, okay and the last table is the pa table, the pa, sorry validation table, and this one I I wasn't. I I understand the the idea of like a validation, but um I was not really clear on um how this table would be used.

B

um So it sounds like this is um an um inbound table inbound only table, so it sounds like it's used to say that hey these packets from these source addresses source ip addresses are allowed to send packets to this eni.

B

And it seems like a like- I I'm not, I have to admit I'm not super familiar with the whole like uh the way data centers are constructed and everything, but that seems like a possibly a large number of um um uh entries in this in this table if you have to enumerate every valid possible source, um so I wasn't sure if that's that was the purpose of the table or if it was really trying to so.

D

The scale is equal to the scale of c, a to p a mapping. Basically um it's a it's a two-way.

D

uh Let's, let's say it's two-way communication: you have the outbound, where you map from ca to p8, so you're saying, if I'm sending a packet to if I uh was programmed to be able to communicate with that other eni, meaning I have an entry in ca to pa table, then I should be able to accept packets from them as well. So what happens in reality is that controller. Only programs, the mapping table and inbound validation table is programmed as a result of it as a side effect.

D

Basically, I'm saying that I want to go to that pa, so I need to be able to receive from it as well. Okay and the scale is on par. So if it's like 10 million on dpu in one direction, it will be 10 million in the opposite direction. On the pa, validation.

B

Okay, all right great, that that explains a lot.

F

Thanks, uh I have the same question as well, but how do we? How is this table going to get populated uh so from each uh so just trying to see how the gnmi model data would be converted to this one.

D

Yeah so, as I said, gnmi or sonic schema exposes ca to pa mapping table right. We have a mapping table.

D

F

D

F

Eni and ca combination: we would be having an entry here.

D

Yeah yeah, it's like it has to be done automatically by uh sonic software by the york agent. So this.

B

C

D

C

Is this going to be a like an orchestration function where one entry gets expanded into two yeah? Okay? So it's not exactly a one-to-one mapping of the app db.

D

And that's why we have the orchestration agent, because it's not one-to-one map reasons so.

F

Just to go ahead so just to just to clarify so whenever, whenever the, uh whenever we provision a ca to pa entry via gnmi, um the arc agent should loop through every ni in the system and then uh our every ni in that particular v-net and create an entry here for each of those c entries.

F

And whenever an eni gets created. We have to look through.

D

F

To pa entries and create entry here is that.

D

No, no that's too much uh the ca to pa mapping. Entry already has eni as a key, so we know for which eni we need to program that we don't need to do.

F

D

Oh okay, so it should be the same thing in here. It's for for v-net.

F

It should be okay, so the ni is not a key here. It should not be a key here. It should be the.

D

um Maybe that's true: yeah could be a bug as well.

F

Okay, I think that's the source of the confusion for even for yeah, I think yeah. So if it's vni commercials, then it makes a little bit more sense.

D

Yeah, I don't remember if the atp has vni yeah. It has to be the same here.

B

Okay, that ties into my last question um about the the keys to the this table, um because in the p4 code the eni id is not determined at the time the table lookup happens.

B

um So I didn't know if that that there was something funky with the table keys or if the table, if or if the lookup needed to be moved, but.

I

D

Like maybe the e.

B

Id shouldn't be one of the keys, then.

D

Right looks like above.

D

A

So all right, all right that was.

B

A

Does somebody fix the bug or how does do we do it later? Sorry, I'm not a software developer.

C

Well, I would even change the question a little bit saying: we've identified at least three or four or five loose ends in the p4 code that are acknowledged, but we don't have we're not tracking them we're just keeping them in mind. Do we want to transition to where we make a list or file issues, because pretty soon we'll have 20 things um keeping track of in our minds and not written? What do you think? Martin?

C

Are we at that crossover point, or do we want to do a bunch of house cleaning and then start fresh list.

D

um Yeah, I think issues has have to be opened. I I think one major can be opened like to do proper.

D

Well, I'm not sure uh do we need to have an issue per uh table that doesn't do drop properly on miss. uh That's one thing yeah also about the pa, validation. That's another one.

D

C

Do we have well these key lookups right, okay,.

F

B

If you want, I can open issues and try to open as few as possible yeah. You can check that the context of the the the stuff inside each issue.

C

Similarly, yeah and um michael miele documented how to um make checklists inside issues, so you don't have to have an issue per item. You can just have an issue like handle drop cases. Then you put a little square bracket with an x in it. It populates like a checklist item in the in the issue and you can track them like that way. It's in the github rules document.

C

So it's a handy way of not blowing up the issues list.

A

Can I can try and find that for you bud and um send it to you an email uh sure if you want or or you can try and find it, I mean.

C

I think I can I'll just look it up here. Yeah, let's see here, we go.

C

Okay, yeah, I I I'm just thinking I mean I have a list of um to do's in the p4 code as well, but in my mind and um pretty soon you know we're all going to have a little mental list. We may as well start getting in writing.

C

A

Do you see that in the chat window, but.

B

B

A

A

F

Had one question about the drop one follow-up question: um so when there is a drop, should we drop it immediately I mean, should we do that return immediately, or should we wait until the I mean go to the end of the pipeline, because there is a eni meter with a drop, so that's the correct way of handling the drums.

D

Yeah, probably that ties into another question of how do we properly do? Statistics and this is still open.

D

So maybe if, if we can do all the needed statistics in place- and we don't need to go to the end of the pipeline, if we cannot do that, we need to still gather on all information at the end. Probably we do. I also don't know which way is the best to go.

I

Should we carry like a drop bit in the meta field and then uh yeah count it somewhere and then finally drop it.

C

Yeah and we need a mark to drop instruction at the end of that. um If the metadata is marked drop, that's not in the code either.

F

So that's mean my peer has that to have the mark to drop, but uh yeah we have scenarios where it's drop even before uh it's returned before, so we should handle it in a common way by just setting the bit and letting it fall to the end of the pipeline. Then get dropped there.

F

But then I don't know what would happen if say, for example, this big case where we're saying it's already wrong, but we still allow all the table lookups and then drop it in. Is that an acceptable behavior.

D

Yeah, so again, there should be a common way. I just I'm not sure at this point which, uh which one is it.

F

Yeah yeah just do this yeah.

A

Right um so number 142 came in marion just um asking for a review here yesterday. This is the tunnel table in the pipeline. So fyi did you want to talk about this pj.

I

Hey sure yeah um yeah, if you can quickly go over.

I

Can I share my screen, of course.

A

It's the up arrow button in the white box, yeah.

I

Yeah I'm having some issue with that, but uh that's fine um yeah. I just uh wanted to just uh go over these changes. So basically uh this pr. What it's uh trying to propose is uh uh segregating all the tunnel attributes into uh the tunnel table which is part of the pipeline, because right now, tunnel attributes are driven from multiple tables in the pipeline.

I

So the idea is to bring all the different tunnel related attributes into a single tunnel table and derive tunnel ids from different tables in the pipeline like the route and then the ca to pa mapping and then the eni, which are all driving a tunnel table which comes to a single point of a single point of indirection, which is the tunnel table where all the tunnel attributes are segregated.

I

So this allows us to kind of manage the tunnel programming more easily because if uh any uh tunnel, only tunnel related attributes can go just in this tunnel table, for example, and cap type, and then the depo or the outer headers can all go uh in the tunnel table and there's only a single touch point uh from the api point of view. If any uh tunnel attribute changes.

I

uh So uh this is the just a high level overview of the change, so I just wanted to kind of get thoughts from everyone on if this kind of syncs, with what we want to do.

D

So what are the attributes of the tunnel table?.

I

uh Yeah, you can go into the pr so right now the.

I

Yeah, if you can just scroll down so one thing is currently there is the uh we've added like two end cap types, vxlan and nvgre, although the uh only vxlan is being driven from the tunnel table right now, and the tunnel table itself has the attributes which are the underlay, dmacc and underlay depend in the end cap type.

D

Yeah but those are not really um so: underlay dip, okay, uh let's stick to underlay the so end. Cap type, you mean vxlan versus nvgre.

D

That's right, yeah, okay, um underlay, but there is other. There are other things there is vni or gre key. Whatever one depends, depending on the tunnel type.

I

Right so uh yeah, I think the vni is something that we have uh currently. We are not yet moving it into the tunnel table. That is something that we are leaving it as is, but that is one potential option that we can move into the tunnel table uh the gre uh keys itself. That is something uh right now. If you see the way the only vxlan is handled so the gre keys is not something that is part of the tunnel attributes, but that is something that we can add as well.

I

If we need to do encap type, gre.

D

Not sure if it will work for every so the problem with this is that.

D

That's not really how uh the encapsulation for uh for all of the v-net routes is happening right now, because this information is taken from different places and you don't necessarily have them all at once.

D

If it was the case that you can actually build the whole channel all at once, but what happens in reality is that some of the values are determined uh when there is a routing, lookup and some other values are determined when there is a c8pa lookup.

D

So still there, there is some indirection there, so I am afraid of grouping all of them into one tunnel id because I may not have all of them together and I need to carry this tunnel id over somehow.

F

They all should either come from say to part, or they really come from one place. Yeah and.

D

Really demand a different story: it should be part of the tunnel. Actually, uh it should be part of the underlay uh which is not yet complete, but uh underway dip and vni.

F

So the vni- I I think that's why vienna is left out of this one, because vni can come from the because there could be multiple routing entries or ca2p entries sharing the same tunnel, so the vmi is left outside this. This has only the actual underlay tunnel, specific properties like the ip and the type like you said. The mac is probably going to come from the underlay, so we can leave that out as well.

D

Yeah, so what's the use of this table really, we are just collapsing two values into one or actually, assuming we have only one channel really used on one dpu, we're just switching underlay ip for um for a tunnel led so that underlay ip will be determined later.

I

Yeah, I think the idea is, to just add a level of indirection, because you don't want to go and touch multiple entries if some tunnel property changes- and this is also a place where you can stash any tunnel related attributes in a single table.

I

So, for example, something like an admin state on a tunnel can go into this place uh rather than go and touch multiple entries.

D

But but there is no right, but probably here I will go back to what uh chris mentioned. uh What are the rules? For? Probably this is the case where we need some guidelines for uh why we do implementation this way and not the other is because there is no tunnel and there is no tunnel admin state. There is no notion of the tunnel in uh sonic schema and we are trying to be close to sonic schema.

D

So if there is nothing like that, it means that uh sonic will need to now keep some cache of the tunnels and keep all those in directions and every time we want to to just program a new mapping entry. Probably what sonic will need to do is to look up tunnel id put the tunnel id in the right place or create a new one, which is additional work on the york agent, which doesn't really need to be there.

I

Right right, yeah yeah. I agree besides uh one level of psi api and additional side tunnel api, uh but the question is: uh does it yeah? The question is: does it make life easier uh from managing tunnels, point of view uh rather than because even for the arc agent, there are multiple touch points. If some tunnel attribute changes like an end cap type or even a dip changes uh having to touch multiple entries or program call multiple psi. Api sports is calling a single api right.

I

So uh that was the idea behind this, uh but yeah it does add another psi api to the behavioral model, and so that's the question. I guess in terms of whether this makes sense to add this indirection or yeah. It does add some work to the arc agent.

F

Also, today uh uh thai is the the concept of a tunnel is: is there in this ip and the science? uh Even sonic orchestra does do configure tunnels and all that this is not a new concept. So this is a pretty well-known concept of creating tunnels and it's the responsibility.

D

Of planning to.

F

Manage tunnels and so on.

D

So why aren't we using the site api for the tunnel that we have today.

D

Yeah, probably the tunnel that psy has today it actually behaves slightly different. That's my point. uh The underlay tunnel is what you're trying to model in here. You have a tunnel id and from there you derive attributes, and here again we don't derive.

D

And actually, if you look at the tunnel, there are uh cyto uh the one that we have today. It has stuff like uh vni, mappings, uh other things which we cannot bring in here. So the question is: how do we uh derive and dash all of these attributes? And it's not done in one place?

D

So that's why I believe it will be less beneficial to have the tunnel id, because we are trying to impose this kind of entity that doesn't really exist.

D

We are taking different values from different places from from the routing table from the ca to pa table, maybe from other places as well.

D

And having them collapsed into one.

D

Doesn't really make sense and if we will reduce this this tunnel uh table to just basically what it is today, I believe underlay dmacc shouldn't be there. Underlay dmacc has nothing to do with the tunnel, uh but underlay is the only thing that we can put there and I don't see a reason to have this in direction.

I

Yeah, I think, underlying type uh those are yeah. Underlay dmac can definitely be uh removed from here, because it's strictly not a tunnel property, so underlay dip right now is pretty much uh the only thing and, of course, the type of the tunnel.

D

Yeah, so we're just switching one for another.

I

So I mean uh just trying to understand in terms of just the switzer api uh tunnel. uh We don't see how this maps to the dash tunnel right because dash uh itself needs. The concept of the dash pipeline needs a concept of the tunnel right. So um yeah.

D

Then that's my exactly. I guess.

D

I think it doesn't need that it's a different concept.

I

Okay, okay, so I guess what you're saying is: there is no benefit to adding an indirection at the dash level and leave the you know: leave the orchestrator to go and program multiple entries or call multiples apis and leave the work to the implementation layer.

D

Yeah, actually there will be less api calls if we keep them separate, because that's how sonic schema looks like.

I

Yeah: okay, okay,.

F

So is that one of the goals like uh keeping it as close to the gnmi as possible.

D

F

D

Everything that we can.

C

D

Like the gnmi schema, that's why we have the orc agent, as I mentioned before, uh like one c, a to p mapping results in um two entries in psi, because we need to program the opposite direction for pa validation, but other than that.

D

If there is a choice to have it exactly like what controller expect, then, why not.

I

Okay, so I think yeah, I guess fundamentally, it boils down to that if we are having that as a thumb rule- and we don't want to introduce any new indirections to make the behavioral models api life easier, then what we are saying is we want to avoid doing such things in the behavior model, to keep it as close to the gnmi model as possible, while it might not seem efficient from a pipeline point of view, but because it maps to the gnmi model, it makes more sense right.

I

I

Sure yeah uh sounds good, I think uh yeah. We just wanted to understand uh like what is the just the general motivations, but uh I guess uh uh now we have a more uh clear picture uh of the general motivation that we want to keep the psi apis as close to gnma apis as possible right and anything else is not encouraged.

D

Yeah, that's definitely a goal. It will make life of sonic easier, less bugs.

D

Okay: okay, less things so.

I

One other thing is.

D

I

D

Sorry, but I am three minutes overdue for another call, so if it does not uh consider me please continue, but I will need to drop thanks. Everyone.

A

Thanks, um do you want and with marion leaving, do you want to save your question for next time or try to cover it in email.

I

uh No, I think, uh that's fine, I can uh yeah shoot an inventor and, uh if required, otherwise, I could.

A

Okay, okay, so and and bud, did you want to file those two um items on the p4 or did you want me to do it or I can do it? Okay, all right.

A

um If anything and then action items for next time would be to, I guess, maybe cover cover any other code in the pipeline and um maybe bug coverage um all right, I'll, stop the recording and post it hello, yeah, yeah,.