Internet Engineering Task Force IETF 115, 10 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF115-BIER-20221110-1530

Description

BIER meeting session at IETF115
2022/11/10 1530

https://datatracker.ietf.org/meeting/115/proceedings/

A

I got the cue I got the cue you guys hear me.

B

A

B

A

B

You have to chat, then you have to queue.

A

No I've I've got the questions for the queue that can do that. The chat, I can't type I got one hand.

A

None I haven't I'm no opiates. Today, I'm going I'm going cold, turkey, yeah, really, okay, it's two days is enough.

A

um Yeah you got to put your face to the mic. I can't hear you when you're that far away we'll.

B

Check regularly with you whether you're, still conscious or.

A

You just faded out: man fell off the chair, okay, yeah, I I need a I, need a button, a release button if I pass out and drop the button. You'll know um there's just questions already about remote uh control of the slides I mean the PDFs are up there. I know, there's two different buttons on allowing either they control it or you control it.

A

uh It's not obvious which is which, but either way they don't do remote slide and screen. Sharing you've got the slides. They either hit the button or you hit the button for them. Correct.

A

Do you know which button to hit Tony we'll.

B

See what the first pretzel the apis, the tooling seems to have changed, so we figure out as we go man yeah.

A

It changes every time, I believe in you, Tony.

B

You have to dial in this chair as well.

C

B

That's just a cue.

C

C

B

All right now, I have this thing.

B

B

Okay, folks, we're about to start.

A

B

You win you're trying to begin yeah normal stuff if you're quite funny.

B

So, what's this new document, API I thought no I, just click on the press that shows up, but this looked like that at all.

A

Like if you list the materials you can just select them from there.

B

Yeah, that's what I did meeting materials right, yep.

A

B

Right so now I click on the stuff. The staff tries to download it and then what do I do from here? I can't present it.

A

uh Show offense sure you can.

B

That's what I, like it downloads it.

B

So now I do share screen or what.

A

New screen's been shared yeah there you go.

B

Except I somehow have to get the material I thought it was supposed to do all this stuff automatically. You.

A

Have to share it and you have to accept it.

A

Then you could pass the control by going the little revoke screen Icon by you, put your mouse over that, and it shows you where you can have you either slide control or you pass the slide control to them.

B

No, the only thing that allows students to share a screen. That's about it, oh man! Well all these improvements improvements every time, no.

B

Yeah, so when I do presentation view how the hell do I put material in here.

B

So, what's the tooling now.

A

Well, you had the presentation up yet there you go.

B

Okay, so welcome starting beer session. We have uh semi-conscious chair online, so Greg will be managing the queue. We have a projectile song that came back.

B

We have one: one of the fathers came back um a pretty good agenda today, a couple of interesting things: um yeah, let's start um can.

A

I add a note: I want to add a note about the queue. uh The queue is a composite of people online and in the room and to manage the queue properly. Everyone should be using the tool, so even if you're in the room get on meet Echo and as you come into the mic, hit the queue button, so we can manage the queue order based on who hit it first, both in the room and online.

B

Right so everybody has to basically dial in and mute their laptop and you know jump.

A

On correct, otherwise,.

B

You'll be standing by the mic new procedures, all right note, taker.

B

One after another don't fall over. You know, yeah, it's been promoted to note, taking hey Sandy, okay.

D

It's better than me. Thank you.

B

Much much simpler here in the room, there is a note-taking tool right. When you did you manage to Darling uh that your eyes doesn't have Wi-Fi, so that sucks, um so we only have one laptop with material. The other one has only the Q all right. How do we not taking now in this degraded environment, um old-fashioned sucks, give it another shot? What you get in that you know.

A

Yeah he could type it remote, but he won't have the notes from the people online to read if he can't get into meet Echo.

B

Right because people like to run with us while we're taking notes.

B

All right there's one which is completely open, yeah Legacy, nobody does Legacy except me and the eyes. So that's why it works all right. So, let's see what the ice gets, the note taking all right. So, let's start uh so I'll be flipping those things and then we'll see how the stuff works. uh New, tooling, fine, the usual note! Well, uh the GJ plus everybody. Please wear a mask.

B

You know it's a pretty compliant except some people. Snacking snacking is limited to 60 seconds. Okay,.

B

And if it's not, it will be next to it, if I'm sure all right. So everybody please signs in tooling, changed again. Hoorah, okay and please mute uh your microphone because otherwise you know we'll have uh looking effects.

B

uh You know the agenda agenda. Is the meat Echo uh I, don't even know whether we're running meet Echo anymore foreign willing to do the meat Echo stuff, I thought. So no so we have no taking I will have uh the recording.

A

All right, anyone in the notes should be in media Echo and composite voice. Voices at the mic as well as people are typing online. So if we do meet Echo everyone's got, anyone doing notes has got to be on it.

B

I I lost you Greg, so the the notes are automatically going on mik, Echo or not.

A

uh It will be recorded, but what's set at the mic, won't be so if someone can type them in. That's the point of having a note taker to put.

B

It all together right exactly so. The note should Encompass. Of course, you know the whole questions on the mic. All right.

A

B

uh We're not having any technical issues, otherwise you know what to report them um good, so agenda, a bunch of updates on the previous stuff, a very interesting conversation on Ephesian P4 based beer implementation looks actually fascinating on the Tofino and then tallest is showing something towards uh recursive beat masks uh which looked like a pretty crowded pressure. We see what comes out of it, then probably an frr update and T extension by Sandy. If we find time, okay, so um what's the status, so the T stuff is an RFC. Congratulations! Yeah!

B

You know, claim to fame beer bar APA passed and got an.

A

B

Room Applause room Applause. We don't get that many of those we need to know cheap wins. uh The beer bar IPA is also RFC now, so we have a clean architecture. You know either run to it igp or otherwise do our own things if necessary, Club.

A

B

Oh thanks for Jeffrey to actually hurting that one along for quite a long time. um All right now comes the public castigate. The ospv3 stuff is being uh not taken. Care of I was twice uh on people I was promised, updates. I updates not delivered one of the code that is sitting here and looked properly, bedraggled right. So, gentlemen, I give you last warning and two weeks and otherwise I start to go.

B

Look for another Shepherd, oh I'm sheparding, but the stuff as far as he's not addressed so I give you two weeks for version that takes care of the stuff. Otherwise you know you lose the opportunity for Eternal, Fame and I will go and drag another author and make him editor and basically start. You know to get the stuff delivered so once again, last call, but in a different sense um a bunch of things are uh moving forward. Nothing particular here: uh Bunch waiting for Shepherd.

B

um Yeah, nothing very interesting here unless somebody wants to come. Yeah Andrew.

B

Yeah, so that just kicked in so I have to go and look at this draft and and see whether in the state we need to actually call our review, so the early reviews will be coming no much faster than before. Right. We.

A

Didn't hear Andrew remote can all questions go to the mic? Please.

B

Yeah to the mic, please systems uh yeah right.

E

um Yeah Andrew here um just I I, don't know whether this has been circulated to all the working groups, but we've got a policy in routing area. Now that before drafts go to the area directors after last call, they must have gone through an early review through the directorate.

E

This is just to help us speed along the pipeline, except for you know, because it's a lot easier if we get documents that have been reviewed, so I was just reminding the chairs about that with the number of documents that are looking like they're about to arrive, um yeah, okay,.

B

All right so um so we need a bunch of Shepherds, for uh you know earlier reviews, so people can clean the stuff up before we push it further uh least extensive, frr, surely interesting uh everything else. Maticus is a service. Probably interesting. Te, uh no opinion the beer.

A

You got a question with the mic: Greg Greg.

F

Okay, uh Greg mersky Erickson on Saturday the pain in the butt; no.

B

It's not just you.

F

Okay, okay, then, should I assume that everybody enjoys it.

B

Okay, all right.

F

Okay, I'm glad to uh so dear pink uh beer ping. In the last call, um we received Shepherd's review. Thank you uh for the shepherd uh worked under addressing I, submitted my proposal to the pen holder and uh never heard since um so the draft expired.

B

Who is that? Who is the pen holder editor on it? An.

F

B

Official editor or just the first author.

F

His first offer right so um I would appreciate, if chairs, can think of assigning the editor to the draft, so we can move on because the problem, the problem is not. The problem is um as additional as you uh listed BFD draft here, so that ping, uh the BFD and path MTU Discovery, depend on progress of uh BRP.

B

No problem, please send official requests to the list. The chairs were turning around, give the first Auto 20 minutes time to react, and if not, we basically sign an editor yeah.

A

We've reached out to nahendra already we got some response, but nothing really progressed. um I think is fair enough that we just move the pen yep.

F

Yeah and actually the info fairness I, send the request before the meeting yep.

A

Oh absolutely very.

B

A

Set, let's move the pen.

B

uh Yeah we'll give it some time and then we move the pan. You know we get the nature, so we move this stuff forward. Okay, uh anything else on the drop shot standing on the status.

B

A

Oh, that's Jeffrey. Sorry.

G

Yeah Jeffrey from juniper um I think there is one draft missing here, probably because it's expired and it's my fault, it's the beer proxy draft. um It's uh I! We believe it's ready for last call, but I will refresh it and then refresh.

B

We need the shepherd and so on, and then we have to call it for the last call whatever next next next next time, next guy on the mic, please no acrobatic, you know throwing around and juggling things.

B

Okay, so that's it.

B

B

You do the notes, okay, so around the slides.

H

I

Well, first thing: first ice welcome back! Thank you! uh Maybe we can get some Belgium beer now man.

I

So with that said, if, if I knew, the last call was as easy as going to the microphone I wouldn't face anybody's time with going over this draft again, uh but I think we try to do three last calls on this and I think it went to the working group too.

I

I, don't know what was I think you know they were in favor of pushing it through. So I don't know. Do you want me to go through it, or this is a question for chairs.

B

I

Quickly, sorry, what was the answer.

A

Let's see if you can step through or we have time.

I

Yeah I mean I I, don't want to waste anybody's time. If everybody knows about the draft- and you know we're going to just do a Last Call on it, uh you know get a shepherd on it. Then you know I can give 10 minutes back to the to the working group.

B

uh Show of hands people need to refresh. Then we run five minutes. Nobody gets hurt. Okay, one two yeah, please run a refresh.

I

All right sounds.

B

Good, keep it snap people at least people know what the whole.

I

Thing is about I'll, make it very Snappy, so uh the problem we are trying to solve is that some providers that they are trying to go next slide. Please actually some providers that are trying to go to the next uh to the next technology, which is beer for multicast. They want to replace some parts of their Network, so they buy brand new hardware, that is beer capable and they want to replace one portion of the network uh as an example.

I

In this case the network is being multicast, ldp, mldp and the small island within that network is going to get upgraded and to beer and with this draft basically what they can do is they can I, wouldn't use the term as Stitch. They can signal the mldp to the Beer core from one Island mldp Ireland to another mldp Island that is connected through this vehicle.

I

So next slide. Please.

I

So so, basically, the way it's done is like PM signaling. uh All that happens is that when mldp effects arrive at a beer, Edge router, uh we grabbed that mldp FEC and the mlbp signaling. If you will and we use RFC 7060 and we shoot it from the. uh Let me get my terminology right: the the down a stream B router, which is uh Ingress view, router, I, guess to the upper stream B router and the Upstream B router keeps track of all these Downstream uh routers.

I

If you will that are interested in building this multicast tree via the mldp signal, so the Upstream B router, Edge router builds a table or something similar to a table that tracks all the downstream routers that are interested in the tree. Next slide, please!

I

So, obviously, when you get into the into the other side of the mldp to the other mldp Island, then your effect just goes all the way to the source via mldp signaling. And then your uh signaling is uh fully achieved.

I

As at this point, and then your data path starts, data path starts from The Source via mldp VIA, ldp mpls in cap, and when it goes to the to the Beer domain, we have a list of the um Downstream routers that are interested into that tree and we generate a beer header that has the bits of all the downstream routers in the beer header and we shoot the packet all the way uh through the beer core to the downstream ldp Island.

I

We remove the beer header and then we go to the wild via the mpls header itself and that's how the solution works. So it's not really a stitching. It's just tunneling and yeah.

B

Okay, last call request: uh should we do show of hands or take it to the list crack.

B

Faded out uh okay, so we issue a Last Call on the list. Okay, uh unless there's any questions, we have time for a question or two.

B

Empty okay, next one thank you.

B

uh Beer Bishop Jeffrey, who is doing that.

A

G

All right, so it's this is update on this bgp extension uh for beer signaling on behalf of the co-authors. Next slide, please uh there's a bit of history on this draft. It had passed working group last call before and I was the shepherd I did the review. I had some comments, um then uh the main authors had lost Dean, um and uh so they couldn't address the comments.

G

And additionally, it was only intended to for this bgpdc scenario with bgp being the underlay, and it is assumed that uh all the routers would support beer, and if there is one router or that does not support beer, then the Ingress replication will happen all the way to the bfvrs.

G

um This is a problem that was pointed out in another draft, the markets as a service- and it has also also has a solution for that situation.

G

So after considering all the factors factors like the nobody was uh actually working on comments, and then we have this problem, so we decided to do a revamp, so I joined as the editor.

G

um We moved to move the solution from the markets as a service strapped into this this one too, so that you can handle generic situations and not just for these pgp DC and where all the routers support beer um next slide. Please.

B

Sorry, one too many yeah.

G

So this is uh is an example. What I was talking about here? We have the the fr1 on the left side. There is a noun bfr in the middle, which does not support the appear and Then followed by vfr2 and then bfvr one two three on the right side.

G

um Before this uh new revision, all the bfrs or bfvrs, they will only advertise their own beer prefixes and their encapsulation information.

G

Now, when bfr calculates, the beef entries for BF er123, the next hub in the in a bgp advertisement, is that non-bfr and it has no idea that dfr is also in the bfr2, is in the past, so it will just tunnel the traffic to be a vr123 directly.

G

If you hadn't known that bfr2 can be used, then you could have just tunnel to the bfr2 only um with the new approach, all the bfrs via router, when they re-advertise the beer prefixes, they will updates uh the beer information and they will also update a sub a next hub, sub tlv in the brtov and to themselves. So this um has two purposes.

G

The main purpose is that in this example bfr2, when the it really advertised the bfvr123 prefixes, it updates next hub to itself so now in bfr1, guess that this is the next half is bfr too, and it has the encapsulation information and associated with bfr too. So it knows that for all those bfvr one, two three they can just be reached from bfr too, so that handles the non-bf Rockets very well, and another side benefit. Is that all those prefix beer prefixes?

G

They are now reiterized by the bfr2, with the same deer tlv that allows the better PCP and Roi packing.

G

um So next next slide. Please.

G

This procedures is basically what I just talked about next slide.

G

um There is another or enhancement here we just talked about that.

G

Let's go back to that picture.

G

So here bfaer123 originated, there are an RI for their peer prefixes and then it is assumed that everyone just re-advertise them everywhere, but there may be situations where um you do not want to re-advertise the Beer prefixes everywhere. For example, bfr2 can say that I'm not going to re-read the price, those bfvr one, two three prefixes instead bfr2 will just advertise its own beer prefixes, but it uses uh um sub POV that is defined in the other draft beer prefix either.

G

Excuse me re-advertisement that um in that sub new sub gov, you will just list all the bfr IDS reachable from this bfr. So um that's what I was talking about on that uh slide later, let's go back to that slide. You know yeah so um summary of the all the changes in this revision. We extended the scope for general or applicability.

G

It also handles mpos and now mpls encapsulation handles non-bfr and we updated the signaling so that the transit bfrs do not need to advertise the beer information with their own beer prefix anymore, unless they want to use the proxy range sub POV to advertise bfrids that are reachable from them.

G

We also added a section about the fifth calculation update the text for how to handle the spear information and trvs at the dear domain. Boundary next slide.

G

um So with these changes uh we need to do another round of working group last call. We also need a new shepher. I was the chefer before, but now um I'm joined as an editor, oh by the way Cindy joined as a contributor. She helped a lot in, especially on that proxy range. Sub. Tlb is a support.

B

Questions on the queue nothing. uh In my opinion, this needs uh to be bounds of IDR as well. Very significant change of procedure. Okay and now, because you carry the stuff transitive through I- would like to have these guys look in terms of like Atomic attributes, Aggregates blah blah right, you're triggering a couple of procedures, so uh I will fire something towards the IDR, and then we see whether anything pops up on the list and then uh find Visual work, group plus call again and Shepard, please if anyone volunteers to do that stuff.

B

B

Okay done next, one I think Jeffrey. You know uh prefix, okay,.

E

G

um So this is the updates uh on that ear. Prefix redistributes traps um on behalf of the quarters next slide. Please.

G

Just a quick review, um we have three igp domains in this topology, even though they are running three uh different uh igp instances that beer subdomain itself is actually just a single one. They cover all those domains, questions. How do we registering the beer information between them? That's one question.

G

um Another question is that if we are using pgplu um because with pcpr you, the the prefix for Edge routers are typically not distributed into igp, they only advertised by pgp among those border routers. So in that case, how are going to do peer forwarding.

C

G

So the uh the approach there is the uh to have the Border routers advertise their own beer prefixes with that same proxy wrench subtlb I mentioned earlier to list the external bfr IDs that are reachable about them. So that's the basic idea on how to handle the pgplu case. That's basically the um what this draft is about. um It's been there quite for quite some time. I will not get into the details.

G

um The purpose of this presentation here is just give a quick overview and then request for working group last call.

G

Next slide, yeah.

B

Okay, so the previous redistribute.

B

Classical okay.

B

Thanks questions, no one on the Queue thanks.

A

We got uh last call show of hands in the room.

B

A

B

A

The list we do it in the room and I we have a tool that does that uh this was uh which draft again it vanished. What was the title of the draft.

B

uh That's the prefix redistribute.

A

Prefix regist, okay, yeah.

B

If you want actually all.

A

Right show a hands.

B

We do the virtual tool right.

A

Yeah, this just gets everybody remote end in the room, so we have a count. We have a record and we take a little list.

A

15 with the 16. no descent rooms up, I said we got it all right and oh 17-18 more people are coming in 19.. One person says it's not ready and they change their vote back to 19.

A

looks unanimous all right thanks room, we'll take you to the list ending session.

B

So, let's also do a show of hand for the uh the bgp last call, but I would wait until we get this IDR feedback and then I would only go for the last call. Maybe next meeting.

A

uh But we should check the room.

B

A

All right show of hands.

A

We have uh someone with the mic hope he vanished.

A

All right, unanimous, no descent, all right thanks! Everyone we'll take out the list. Oh another one came in we're at 15., we're there all right, ending count. Okay,.

B

Back to the agenda, okay, so it looks like the bgp is going last call as well, while I make the IDR basically checking with the IDR, uh um uh what you call it integrated part of the last call. Okay.

B

uh There was someone on the mic.

A

B

A

I

Dude, if you want to do the same thing for the ldp one.

B

uh True, if we're consistent, okay, let's run the mldp.

A

That was mlbp, correct, yep I just have to put a title in it.

A

All right show of hands in the tool.

A

Thanks everyone.

A

No dissent we're at 15 16., it looks like we got full support all right thanks. Everyone we'll take you to the list ending count.

B

Okay, Stefan comes on fungen presentation.

B

All right next, one.

B

So Stefan this looks actually like a very interesting presentation, a special for implementers or people pouring yourself in the Silicon or even you know very efficient software. Okay, let's go.

B

We don't hear you.

B

No, if you own the tool, you have to open the mic step.

H

H

Okay, can I start okay, perfect, um hello, everyone. My name is Stephanie I'm, a PhD student at the University of tubing and today I'm going to talk about an efficient before based beam Plantation on Tofino, and this is a joint work with my colleagues, Daniel melling and Michelle Metz Next Step, please, okay, I'm, going to start my talk with a short recap.

H

What we did before in previous work, then I'm going to talk about the problem statement and the implementation of efficient beer in P4 and, finally, I'm going to talk about optimization that can be applied to this implementation.

H

Next slide, please! Okay! So at ITF 108 we already presented the first implementation of beer and bfr0 in before for the Intel Tofino, and there we used an iterative processing approach where in each iteration one next top was served. So we received a beer packet in the first pipeline iteration. We forward the packet to the first next top of the pack of the gear package. Then we cloned the packet recirculated in the second iteration, the second Next Top is served and so on next slide. Please!

H

This approach has one huge drawback, because we make heavy use of recirculation and recirculation requires capacity on the switch. So, for example, when we get 100 gigabit per second multicast traffic with tires and desktops, then this results in 400 400, Giga per second recirculation traffic. That needs to be processed on the switch and when we look at the chart here um on the left side and when we get 100, gigabit per second traffic have only a singular, select, recirculation port and want to send the packet to three Next Tops This Is, the green bar.

H

Then we only achieve around 40 gigabit per second, because the pipeline is overloaded due to recirculation, so we have heavy packet loss. We were able to solve this issue by adding dedicated recirculation parts to increase the recirculation capacity, so with three recirculation Parts on the right side of the plot, we are able to serve up to four Next Tops at line rate with 100 gigaby per second. However, these dedicated recirculation parts are physical parts of the device, so these cannot be used for any other traffic than recirculated beer traffic. Next slide, please.

H

So our goal is, was to reduce the recirculations, to improve the efficiency and to save capacity on the switch for other traffic and a simple idea that one can up come up with is that we want to determine all Max types of the beer, packets and possibly one shot and then use, for example, a static internal multicast group to replicate the packets to the required next talks in one shot, so that we do not decrease the collection.

H

Well, this idea has some challenges in P4 and on the internet Tofino, because with beer bit strings with at least 256 bits, it's quite difficult to map this bit string to the set of a packet's. Next stop in a single table like look up when we do not have specialized Hardware as when we just have an Intel Tofino, and a second challenge is that we only have a limited number of configurable static, multicast groups.

H

So we cannot simply have any combination of possible next stops as multicast group, because it's just too much so the question is now: how can we do this more efficiently next time? Please next slide, please um just as a very small recap: P4 is a highlighted programming language to describe data planes and there we have a compiler that Maps the P4 program onto programmable pipelines of targets, for example. In our case, the inter tufino next slide, please.

H

So our approach for more efficient B implementation is now the following. We have a switch with a certain number of ports, for example 32, and now we divide all parts of that switch in case so-called configured Port clusters, for example, the first 10 parts are the first configure Port cluster here with the yellow border. Another 10 parts are the second here with the blue border and the remaining 12 ports are another configure Port cluster.

H

These configure Port clusters can be overlapping, so they do not have to be disjoint and, of course, ports within a configured podcast that do not have to be physically next to each other. This is just for Simplicity and all configured part classes together have to cover all parts of the switch, and now we want to determine which configure Port clusters require a packet copy. So we get a b, a packet that, for example, should be sent through the first part of the switch and through the last one.

H

So we need the first configured part cluster and the third configure part cluster, and this may be done again, possibly iteratively. However, only with a few iterations like one to four and not like 1 to 32, as in our previous implementation, and when we now know that, for example, C1 needs a packet copy. We can use a suitable static, multicast group to replicate the packet to all required Next Tops within this a configure Port cluster, but only towards the required Next Tops.

H

And with this approach we need a maximum number of K minus 1 recirculations for K configure plot clusters. So, for example, with the 32 Port switch and three configured Port clusters for size, 11, 11 and 10, then we need at most two recirculations independent on the number of next stops and in our last implementation this was next house minus one. So this is a drastic reduction in the number of risk conditions. Next slide.

H

Please, and the question is now okay: how can we determine which configure Port clusters need a package and to that end we look at all combinations of these configure Port clusters here called SI with our example, with three configure Port clusters. We have seven combinations, a single configured, part clusters, all combinations of two and all combinations of three, and then we look at the so-called combined fbm, which indicates all beef ERS that are reachable through the subset.

H

When we look at a part of the switch, then this part is used to reach certain DVRs, so this part has an fbm. Likewise, when we look at the configure Port cluster, it contains ports.

H

So all parts together build also the fbm of the configure Port cluster and when we now have a subset of configured Port cluster, we just bitwise or the individual fpms of the configure plug testers and when we now receive a b, a bit string and which is here shown in the example um with beef ERS that are reachable through the first configured Port cluster. Here in Orange and, for example, the second configure Port cluster here in blue, then we apply a ternary match.

H

Operation ternary match is simply a bit wise and operation, um and we do it with the complement of the combined fbm and we Define a match when the result is zero. What does this mean? This means that the complement of the cspn has a zero at every bit position where the BRB string has has an activated bit, and this means that the combined fpm has a one at every bit position where the build string has bought an activated bit, which simply means that the cfbm serves all pvrs of video package.

H

In this example. um This would be the case for S4 and S7, because these two contain the first and second configure part cluster. However, S7 also contains the third. We do not want to send super application to the third content import cluster because it does need a packet.

H

um Luckily, when we order this table according to the size of the subset, then we get as first match the smallest combination that is required, and then, in this case this is S4, and then we can simply select the first configure Port cluster for further processing.

H

Then we recirculate and the second step we can work with the remaining control clusters that need a packet copy. Next slide, please, and now that we know which configure thought clusters need a packet copy. We only have to determine an appropriate multicast group so that we can replicate the packet to all Next Tops within this configure Port cluster in one shot without research collection. How do we do that? First, we configure all combinations of paths within configure Port clusters as static multicast groups.

H

We do that to gain some robustness against changes in the magic history, for example, when in DVR joins police, and then we apply the same logic as before. We have a combined fbm of the static multicast Group, which indicates all the vrs that are reachable through this group, or rather through the parts that are part of this static. Multicast group. Again we apply the ternary match operation on the pivot string and the complement of the csvm when the match is zero.

H

We know that the multicast group contains all parts that are required to serve the beer packets.

H

We again order the table according to the size of the static multicast group, so we get the most precise multicast group, so we do not send replication to parts that do not need a package and when we now have configured multicast groups and configure ports clusters of size M and we need 2 to the power of n-static biology class groups, because we have all combinations and for our previous example with 32 ports and our three part clusters of size, 11, 11 and 10.

H

We need around 5120 static, multicast groups, and this is well feasible on a device like the Intel Tofino. We implemented this approach. It runs at 100, Cubit per second per part on the Intel toofino next slide. Please, this approach can be further optimized as follows: next slide, please um we have certain assumptions about multicast traffic. We believe that multicast traffic is not completely random. We mean by that that there is some correlation on eager spots.

H

So there are certain Port combinations that tend to occur together and other product combinations are less likely to be used for single gear package.

H

um The second assumption is that we only have a limited number of static multicast groups, so we have to comply to yourself maximum number that we want to use, and our optimization idea is now the following: we sample beer, packets, locally and based on the beer bit string. We know which parts have to be used locally on the device to forward the package. This information is stored in a graph structure, and then we can apply clustering methods to choose appropriate configured.

H

Port clusters, such you know in a way such that all of them together cover all parts of the switch and that part that's statistically and occur um more likely to get them via package have to be used together, are in the same configured part cluster, so that we can use a single multicast group to serve all of them and in the end, this means that we need less configure Port clusters per via packet on average, and this reduces the required number of recirculations next slide.

H

Please um here's a small example and when we get via traffic with around 4.5 Next Tops on average, in our old implementation, this required 3.5 recirculation leverage, which is the Red Bar in the graphic here and in our new approach with the optimization.

H

When we have highly correlated multicast traffic, which means that there's a high correlation between equals parts and beer packets, then we need almost zero rest circulations with around 1000 static, multicast groups, that's the bar on the right and when we have less correlated multicast traffic, which means that there's some Randomness within the use of eager spots for beer packets, then we still need around a scenery circulation with 1000 static, multicast groups instead of the 3.5 recirculations. Now about approach next slide, please!

H

So to conclude this talk. We presented the mechanism to forward beer traffic with only a few iterations instead of the number of next talks, and to that end we choose so-called configure podcasters and then apply an iterative processing where, in each iteration we select the configure Port class that it needs a packet copy, and then we send a packet to all required Parts within this configure Port cluster in one shot, the Second Step may be achieved through predefined internal multicast groups, as in the case with Intel Tofino. However, these multicast groups are static.

H

They are not Dynamic, so we do not need any Dynamic state, and this may also be done differently depending on the technology. So when there's another replication mechanism, that's more efficient, then multicast groups. This can be also used with this mechanism. We have a maximum number of iterations, which is bounded by the maximum number of block clusters, for example three instead of 32, and we can even further optimize this approach by packet, sampling and then applying machine learning and to get appropriate configured podcasters.

H

We implemented this at line rate at Intel, Tofino and more details can be found in our paper here at the pre-print, which is currently under review, and we are happy to discuss any questions. However, we have to see how this will work when I don't need you. Thank you.

B

Okay, so Stefan, can you hear us? Oh no, oh okay, so excellent questions, nothing on the queue.

B

A

Right so I.

B

Would have uh yeah Greg.

A

I said nothing remote and nothing in the room.

B

So I have one question. The rest was pretty clear uh when I look at the picture.

B

Why is the orange and the blue overlapping here? Is there any Rhyme or Reason to that stuff?.

H

um Because maybe there are certain multicast groups or certain number of peer packets that have um a subset in the yellow cluster configurable part cluster. But there are also some beer packets that need parts of the second one and, as we configure all possible configuration combinations of Parts, when we have disjoint um configure Park clusters, we need at least one recirculation when we need to have a packet that needs parts of both clusters and when we can do overlapping clusters, then there's the chance that we need no rest circulation at all.

B

Okay, so basically you had enough ports and you chose the sizes that were by they do not have to overlap right. You have both possibilities.

A

Exactly okay: okay, yeah! We got one question.

A

So is that Sandy, no, it's it's Jeffrey.

G

The mic go ahead, Jeffrey from juniper, um so if I understand this correctly, the each cluster is kind of like a line card. It's on some routers.

G

um Another thing is the so inside each cluster. It seems that your you may be doing uh like a string, P string, lookup on the entirety or just on these bits for that cluster. Only and both uh ideas uh have been documented or in some in some scenarios.

G

In some companies uh internal implementations, um we can discuss uh further offline and additionally, I guess it's really depending on the implementation. I know. There's some implementation do not require a recirculation for each iteration of that lookup that that bit in the bit string, so indeed I guess for for some Hardware each iteration. What that does require re-segration- and in that case this optimization will help.

H

Yeah definitely so we are a bit Limited in the number of table, lookups that we can do before and on the Tofino, and so we do not have a way to make 30 lookups in one iteration, for example. So we have to do these recirculations, and um this is a way to optimize how we do these three circulations, but I'm really interested in more information about the line card, capabilities of existing B implementations.

H

A

J

Yes, can you hear me.

A

J

um Yeah I just had a quick question. You know on the uh so P4 I think one of the major advantages of P4 does help with the pipeline programming and staging um the ability to eliminate recirculation that happens on the um on the Asic.

J

um You know by doing just the recirculate, uh you know the uh programming with P4. Are you able to eliminate the uh pipelining or eliminate recirculation I think have you have you tried without having to um uh deal with the randomness I? Think like you had to um in in your one of your last slides, you mentioned that you're working on how to uh the optimization.

J

So if you, without the optimization and if you just strictly did everything just with P4 and and and with the pipeline programming, were you able to get to a point where you can eliminate uh recirculation without having the optimization I.

H

Think um well, yeah. Thank you. Thank you for the question. um Of course, you could do it all without recirculation by just copying the packet to each egress Port that has a potential receiver and then dropping the packet in the egress when the receiver is not needed. But in this way you will block the response. So when you get 100 Gig and each Port has a receiver at the end and we make a packet copy to each Port, then the whole switch is full and we cannot have any other traffic.

H

um That's why we need a way to determine before we put the packet in egress spots, which Ingress Sports needs a copy, and this is quite difficult and prefer based on the header length of the beer bit string, and at least we did not find a more efficient way, as we just presented here.

J

B

Okay, one more question from me because I'm thinking about the stuff more and more so when you were did the static, multi cost group calculation, um it seems low to me. So is the static multicast group per cluster?

B

So can you assign basically the same multicast group in terms of an address twice for each cluster and that's how you're counting it so you reuse, basically multicast addresses or are they all unique across all the Clusters.

H

um It's not a multicast address, it's an internal way of telling the Tofino to do a packet replication to certain parts, and basically we tell it. The control plane give us a multicast group for these parts. Then we get a number and, based on this number, we can later tell the Tofino to replicate the packet to this port and we have up to 2 to the power of 16 multicast groups available on the Tofino and on our example on one of the slides. With these three configurable podcasters, we used five thousand of them so.

B

That's why, but what you're showing here is really that is the identifier is unique across the clusters right, okay,.

H

Yeah yeah across the whole across all clusters, so.

B

Yeah, um okay,.

H

A

uh I have a question so uh when you say internal multicast group, these are actually group addresses, like ipv4 multicast addressing is built into the structure of Tofino. Or what do you mean? No.

H

This is a 16-bit number, which is called multicast group from the Tofino because it behaves like a magikas group as it replicates packets.

A

Of an index table pointing to a group of output, ports yeah. Thank you.

B

Okay, so, basically, when you try to do two clusters, you ran out of those identifiers size.

H

This is for our clusters, but oh yeah, when it all went on the 32 Port switch. We cannot have only two clusters with each 16 Parts because we only have two policies next time: okay,.

B

Cool yeah, that was what I was kind of aiming at. Thank you yeah, very clear.

B

Any more questions, observations, yeah super work, thanks.

B

K

All right so uh I had this uh earlier version. I think two years ago, so be back here now next slide coming.

K

L

So we continue to think that traffic engineering is really very important right. So we've got brt out um and um we're getting back at that net uh to all the good things where we could actually for for multicast use, brte um and I'm not going to to read through the long list, I I think most people, uh hopefully should know them um and then through um working through brte I, think we got to the point where I was happy.

L

If it was working in in small scale, and then everybody was asking me about large scale and to make it larger and everything. And so then you know the ideas it came around on uh how what the root cause of the problem is, and it's really what I would call now the flat bit strings right.

L

So brt was designed to be as much as possible um using the same hardware for wooding as beer, which means one single flat bit string, and now we think that we can do better when we are taking into account that we're 10 years after the original redesign, our Hardware forwarding planes hopefully can do better, um and we think that we can encode trees more efficient than brte, um make larger headers easier to process and make it easier to Auto configure next slide, and this is by the way, highly experimental right.

L

So this is by far not hey. Here is a new great solution. Everything is done, but we're at the end of a longer road. So, on the right hand, side.

L

What you're seeing is the multicast tree that we want to send a packet over and instead of having a flat bit string, we're now encoding into the address field of the packet for each forwarding router a separate bit string, and then we are ultimately setting up the tree that way, and what we're doing is that the serialized encoding is updated on every hop so that the Hop that is processing it only needs to look at its own bit string and then for every copy that it does.

L

It is simply updating the offset and the links to point to the downstream neighbors um what we call recursive unit, which is the bit string and then, of course, all the downstream neighbors um bit strings themselves next slide. This is, of course, very high level.

L

um Here's the encoding um and the processing on every hop. So you see on the upper row, you see the processing on router a which would be the root, and the root, of course sees the whole tree. The first bit string on the left BSA is the bit string for the root. In this case it is making two copies.

L

One two router B one for router c, um and um to do that it examines only its own bit string then for the serialization we need to have the length of the subtrees for um B and C. um One is actually derived from reading the ru links.

B

Very quickly before you kind of lose everyone, everyone in the room, possibly me as well, but you describe only trees which have maximum fan out of two right. No.

L

No, this is, this is arbitrarily many, so um in this case we're just showing two bits, so it can be many bits and the the AF field is an array. Okay,.

F

L

Example with two so uh two AF entries.

B

All clear thanks so.

L

This is an area and we're saving one area element, because we can calculate the length of the last recursive unit um because we can take the global Ru links field and do the calculation that is in that field. So obviously you know this. This takes longer than the the first slide deck.

L

Hopefully, the visuals are somewhat helpful, but yeah um I think uh we'll take more time to breathe in, um but the the main point is: every router only needs to look at its own bit string and that bit string only needs as many bits as that router has interfaces so to speak or host neighbors next slide right. So this is a little bit different, a view of the same thing right. Obviously, this could replace the bitstring field of an RFC 8296 packet header um and then the cost of the serialization right.

L

We love the fact that we only got every router's bit string that we need not the bit strings from any router where the tree doesn't go through, but the cost, of course, are exactly these addressing fields that are telling us the length of the subtrees and then the global Ru links, and are you offset? So this is kind of the overhead for the savings that we get next slide, and so we did some simulation some calculation for large-scale Network.

L

So this is uh I, think uh um uh Beijing Mobile in in China uh with a couple of uh hops right, so every hop is individually in there and then this comparison actually not even against brt, but against beer and the total number of replication needed to reach a certain uh random subset of receivers and then going through all possible random subset of receivers, starting from a small number going to a very large number.

L

So and of course, these type of simulation, these type of analysis we need more from to to actually vet than the scalability benefit of this mechanism. Next slide.

B

So there's a lot of very small writing, but I see that you basically achieved it even with a very small bit mask size of 256 bits, the whole simulation correct. That's.

L

That's yeah, so I I haven't been able to validate this. This is.

B

L

Colleagues and Beijing have done right, so obviously the more we get into that assessment. uh The more we'll we'll have to revisit these numbers and and look for different topologies as well. Yeah next slide.

B

L

Okay, so the three big things right, so replication, efficiency for small trees and large networks right so and it's easier to make the comparison with beer, because brte with all these different optimizations is it's very difficult right. Imagine you have a network with 10 000, bfer and you've just got a bit string length of 256 right so even um replication to a small set of 10, 20, 30 or 40 random destinations.

L

A large Network right across that Network may require up to 40 uh packet, copies in BR and brte, because they're all in different bits drinks right. So you have 20 256 bits, so that's 40 different bit strings. So even for small trees, you may need a large number of copies right, and so why do we care about small trees and large networks? Well, that's what we did started in 1994 right, which we called it Pim sparse mode right.

L

We want to have efficient delivery, small trees in large networks, and that hasn't changed just because we want to go stateless. So that's why small trees are actually quite interesting next slide. So then we had this fun discussion with Dino. He isn't even here so that was basically I was trying to be really provocative and that's the red warning offensive technology, Right.

B

Congratulations: nothing new! Keep on right.

L

So um consider really why don't we have bit strings that? Are you know, 10 000 bits long right, what's bad about it, so and then go through the reason why it does or does not work right. So in the first place, I think it would work perfectly fine from the benefit side. Okay, it's one kilobyte worth of bit strings, one kilobyte worth of data, but we still only have an overhead of 50 we're sending it to a large number of bits, 10 000 receivers, and we have an overhead of two times right.

L

If we do Ingress replication, it's an overhead of ten thousand or right. So if we go Pim sparse mode sure we only have an overhead of one, but then all you know the stateful operation. So why didn't we like large headers up so far? I, don't think the MTU is the issue right, one thousand byte, more MTU! If we start with data center, I've I've worked with so many uh crazy networks with really uh you know gigantic packet sizes right I, don't even think it is long-term.

L

The accessibility of the header right we've started with header from 128 byte. Now we're at 512 byte would say we can access one kilobyte of of header in the forwarding plane in 10 years, but the problem that we have is we don't want to process 10 000 bits worth of you know stuff when we only need to replicate to 10 outgoing interfaces right.

L

If we only want to replicate to 10 outgoing interfaces, we should only have to look and process something that is proportional to the number of replications we really can do, and that is exactly what RBS gives us right. We're only looking always at a local bit string and all the other header is just payload that you know some other router down. The tree will look into next slide.

B

B

I think we jammed okay.

L

No here so Auto configuration right so I mean I started, brte I'm, not really a fan of centralized controllers right, I, love, traffic engineering, but I would love to have you know as lightweight as possible traffic engineering um in the source router in the first top router doing explicit Source route and I don't want to have to configure new address basis on every node and with this mechanism RBS we really only need to have every router locally assigning a number from 1 to 20 for all the 20 bits of its interfaces and don't have to have global address space like the bif-t ID that we need to do sorry, bfr, ID, that we need to do now in beer and beer to e to basically split up.

L

um You know the identifiers of routers across the different SI right, so that problem goes away and I think we could, with this mechanism, also get back to something. That is a lot more, if not fully auto configuring. So next slide yeah so um scale right. That primarily comes because we're not doing this hard subdivision into fixed 256, uh bit streaks or larger right. So we are not wasting any bits that we're having in the bit strings.

L

Just you know the overhead of this tying together, the auto configuration and then I'm starting to become a big fan of really looking into strict hop-by-hop Source routing, because that eliminates all my igp problems that I may have along the path like igp micro, loops and others right I can basically take all the updates out of the hardware forwarding table on the midpoints.

L

The only stuff I need to do is my big Ingress router, with a big CPU is creating my you know, hop by hopsource routing header in the data center and the hardware routers doing the replication along the path never need to update the hardware, forwarding tables next slide.

B

So reflect to something else: yeah.

L

Right so we're looking for interest feedback collaboration right. Is this easy enough packet processing? Obviously you know we have the plus. We have the minus. um We want to continue evaluating and improving the approach.

L

Scalability comparison, implementation, feasibility, such as MP4, you saw one of the co-authors being Michael right, so we're working on that together um and then, of course, there may be other proposals that are looking beyond the flat bit strings that we've done and that hopefully we're starting to successfully deploy for the Next Generation beyond that right and then, ultimately, you know when we feel that we have something that enough people feel um could work um right. What are the criteria that would make any such non-flat bit-free Solutions acceptable as beer working group right? Obviously rechargering.

L

We had to do that all the time, but what are the criteria right? What are the bounds of what beer ultimately would want to do? I'm not asking to answer that question now, but I think it would be really good to have an answer. You know within the next half a year or a year so that we know where to put what works, um because the more we get working group support and people interested I think uh the better. The result will be.

A

Okay, we got uh queue filled up here. I'm just going to give you comments. First from the chat uh from Edward V saying MTU is I, think is he meant smaller problem? Much bigger problem is how big header A6 May process it may be as low as 128 bytes.

L

Mm-Hmm right, if, if that is as low as it's get on those type of devices, then we have to see what's the best use in that right, so I'm not sure if we could claim that this is better than a flat bit string.

L

um You've seen we've done the comparison for 256 bits, which is by itself less than 128 byte. But of course we also have other uh header overhead, so um yeah. Let's do the comparison there as well. Of course,.

A

All right next participant, Zhang.

G

So, if you're down from juniper, um so when PRT was first brought up, I I was not believing and I was in doubts because I didn't see it would scale. But when this RBS was brought up, I liked it and I I can clearly see the advantage compared to brt. So this is a good thing.

G

um There are some benefits on the slide you claimed. I will need to understand it better, but the basic idea of using the recursive structure and to save the the overhead using local bits a bit Precision that that's the key I I. It does work and I like it and once a suggestion in the name itself is to me it's really just beer RBS, don't call it cgm2. Oh.

L

L

So that's already gone yep.

A

All right, Tony.

B

Okay, so speaking uh purely as participant, okay, um I, like that I'm surprised by this 256 bits that result is so good. So you know uh trust is good. I.

E

B

See that verified independently, because the gains are impressive. um It looks simple enough to process in the hardware. There are, of course, open things like how do you make sure that everybody computes the same tree? What will happen while the tree is converging like Loop prevention right, the the usual discussions? What will happen there? Nothing, because each node has to kind of see the same tree and know the offset? Who is the next note?

B

Maybe a missing stuff, but it's just this thing that I'm thinking like network has to become Verge State for the whole thing to work me things, um I, wouldn't even call it te2.

B

um This will be a fundamentally different way to process the bit mask. um uh Yeah me likes, okay, that's what I can say. It's I think it's a great proposal. If, if the numbers- and then you know these little things- that we don't see to work out and we yeah.

L

Okay, my biggest challenge, of course, is so we've done. You know an evaluation of course in actual Hardware, which is you know, like everybody else here, vendor proprietary Hardware, that researchers can't verify. So that's why Michael is doing it on P4 and P4. Has problems I'm, not sure how much that is going to tell us right, so the decisions of what is actually feasible everywhere, I think in our space is really a difficult one to do, and I hope that we can all try to do that. You know as good as possible.

B

Yeah but the number of replication can be actually and against the number of replication can be simulated here. I mean you, don't really need the hardware implementation here. No.

L

I think it is about the complexity of the calculation that you need to do to update the two fields and extract the information.

B

I would kind of abstract that looked like a fairly simple Hardware operation, comparatively speaking, not as simple as ending bitmask and so on, but it doesn't look like excessive TLD processing tool.

L

For disclosure, this is the you know. Upstream marketing presentation read the draft. There are details right. So, let's.

B

See yeah I will I, will it triggered it? I mean I. I didn't have time to read the draft, but you triggered my interest.

C

No I say so: yeah I also find it a very Nifty approach. So uh it's uh quite nice, uh although so I saw my comments to the.

L

List, oh yeah, sure very valid I just didn't have the time I need to do next breath with with those feedback.

C

Yeah because I think there's some design choices made to not put the more uh state in the packet, but put it in the control plane where it doesn't belong so in my I do expect actually the the header size to increase. If you want to solve that problem. So the data that you're showing here for this 256 bits might not be as good as it slips two days. Yes, definitely foreign.

A

L

The part, what are the overall benefits and does the total header size really as as opposed to the processing cost right? So let's distinguish those maybe yeah.

C

How about, but if we support uh looking into this more for sure, yeah.

J

Yes, uh just a few comments, so I I really like the idea, you know it's, uh it seems like an optimization. It kind of takes some of uh what exists today, I guess in Optimus ideas of optimization and um it seems like a really a good Improvement and works with. uh As you said, small trees are important, Universal Big Trees, but it really uh is a is a real nice optimization to um severe.

J

You know one One initial idea: I guess a comment could this since it does use the architecture or an idea of using a bit string? Could this actually be like an extension or possibly an optimization to existing beer architecture?

J

L

I mean I described how it would fit into an 80 296 header right. So obviously we only have power of two length of the bit string right now, so we would need to do some padding and ultimately we could use all the different lengths depending if, if the hardware does it right so yeah it could be fit in there. Is it the best header but I, don't think we can save a lot by by trying to optimize that header just for you know, saving every single bit.

B

Well, I mean so there was a strong, architectural and practical consideration to put the Beet mask at the very end. Right so hence I mean the power of two is artifact, because the algorithms to look up look up so good, but there is nothing that will you know, put a crimp into our whole thing. It would make the big mess different length, so you know we'll have to think how to record it in terms of the beer and coating that we have today, we have a version on it.

B

We can always bump it to version two or we can think of. You know how we semantically distinguish just like with the brke. How do we semantically interpret the bit mask differently, so I? Don't think or it actually anything would prevent us to go and have yet another semantic interpretation of the bead mask and all the existing Hardware right, yeah yeah.

L

The the simple way to do it is have different different subdomain semantics, like we also defined for beauty. That's what I.

B

Have in this slightly whatever I mean the control plane, we can go wild right so that we can synchronize who assigns which semantics you know to to what kind of bitmaps is long in the hardware. We don't start to pile stuff up, so yeah, I, fundamentally I, don't see like architect, actually that wouldn't feed and then Coatings we have and the architectural degrees of freedoms that we provided yeah.

J

Makes sense I like it? Thank you.

B

All right, so we weigh over time I think the other things are not earth-shattering pretty much. This updates all right, I have to find my window again.

H

Yeah yeah yeah, yeah yeah.

B

Here we are so what else is on the tank? um We still have to be a frr update, yeah, we can run through it quickly, I mean otherwise. People can just you know, Fade Out, foreign.

M

I'm going to talk about a bfr, it will be very quick.

M

Please suggestions.

M

Which I think we address our comments and accept all the suggestions, for example, suggests that we should have one okay forward table and then for bfr and the lawnmower forwarding. So we added the one extended forward table for normal 14 and forever.

M

So in addition to that, and then uh there's some people mentioned that also the relationship between bfr and ipfr. So we just we dressed next page.

M

So this is the structure of one folding table for all, so basically the contains primary entry and then backup entry, and then we have Flags indicate whether this is a bicarbon. Entry will be used next page.

M

Ipfr, so one question is that we already have an ipfri: why do we need a bfr? This is because beer package is a forward without IB header I mean outside header. So in this case, ipfr cannot apply to the Beer package because it don't have to be a Target that doesn't have a IP out headers. So in this case, when one beer, that's hot, failed or unreachable and then be a package will be dropped and then lost. So that's why we need bfr so regarding to beer, LFA and the IPL fa.

M

So basically we a BFF LFA, will use IPL a as much as possible.

M

So when we have whatever.

M

So if that one, the LFA is also the pfr label node, and then we can directly use that IPL.

M

So for for IPL, we have different types and we have basic IPL Alpha and we have remote one and we have a property independent LFA. So those are three types will also reused, because we have a architecture to support normal action, which is just forwarding the package to the laptop and then we also have a tunnel, and then we have also you first. So what is a covered? So next page.

M

So we just want to uh welcome work comments and the suggestions.

I

Yeah, who made me goalie Nokia um I, mean yeah great idea, but I'm still scratching my head. Usually the deployments that we're seeing with beer unicast is enabled so uh most of the deployments they want to follow unicast, so I'm still kind of scratching my head. Why do I want to separate my beer faster you're out from unigas.

M

So be ah so. What are the questions that you mean you? Don't we don't need this one? Don't let any of the bfr no.

I

Sorry so going back to your slide, you had three different of fast rerouting. So if you have basic LFA, oh.

M

I

Don't need the.

M

Remote on that.

I

Yeah, if you have basic LFA and and your.

M

I

Can be resolved via basically LFA without remote or TI LFA, then you just use the beer header right. You push it to the to the fast reroute next up and then the beer header just follows the igp. My only Point here is that beer advertisement is via igp anyway. So.

D

I

Is in the mercy of the igp and uh what what we have realized I mean our implementation. Is you just turn on LFA in the network and beer just follows it, there's nothing special about it that that's how the input like, even from implementation point of view. We didn't have to do marriage. We just turned on the LFA under your igp, and you just follows it.

M

As long as, if you have one but that's I, think the yeah normally is okay, but sometimes because some notes from the support appear. In that case, we may have a issue if we ever know the support that one, it's okay, yeah every ID, every IP LFA is also p l of a and then we'll watch that go forward right.

I

Yeah again, maybe you want to bring up the cases. I mean again. We haven't seen any case that the igp LFA cannot resolve but maybe bring on the cases, and we can. We can discuss.

M

It yeah yeah, you've all support them, then that's okay, foreign, so.

B

Jumping quickly, I mean we had kind of this discussion, not ongoing discussion, but to keep everybody open-minded right. Yes, today we deploy the right, GPS or unicast or works like a charm but fundamentally or it actually were not slave to igp right, we can run completely different computation run, build completely forwarding table installed via controllers if we're not slave to igp and igpfrr is not good enough.

B

You know this has the architectural degree of Freedom, which arguably we don't need today in deployment okay, but there's nothing fundamentally wrong with the work that is completely useless, because we assume we always have an igp awards for follow. Unicast, okay,.

I

Well, that okay, again I just want to be very careful here, even with the controller like if you have Sr policy or anything that comes down with the controller again from what we see from the implementation. It just follows: what is installed in the data path? Right I mean we don't see anything as specific, but yeah I mean I'll.

I

Take it back if there is something specific that we are trying to solve here, which we haven't thought about, it yeah for sure, I'm, just giving feedback to the working group that you know based on the live implementation and live deployment. This is what we're saying.

B

Okay I mean this discussion has been going. You know that was the first comment given to the draft okay. So thanks for the update right, uh something else chasing me, but it's okay and we come to the very last one and we weigh over time. Okay,.

D

Okay, can you hear me.

B

Yeah Sandy loud and clear.

D

Okay, I'd like to say this is a very simple draft- is used for prte VP, a beefed ID at what husband uh in in brt in calculate circulation. Sorry because the previous slides, the previous structure is no are not opting optimal, so we, you would like to use a new advertisement for the gift ID advertisement.

D

So uh the only change for the new uh draft is that we move the Deep ID advertisement from the DP to the prefix. So we just only Edward has the gift. Id was so. This can reduce the advertisement and bytes consume consumption, greatly yeah. So that's very simple! Oh sorry, please next.

D

So we know that the pure- this is for the brte, which is defining up C 9262, so it's used for the beef.it advertisement. Next.

D

So we know that we must advertise the gift idea for the beer tea table routing table lookup, so we need to advertisement advertisement next. Please.

D

So we have the the previous structure is the word highest, the uh the proof, the Edward husband in previous structure is and what has the gift ID under BP the POV? So we just moved the operation to the prefix, so the Edward husband may be more efficient, so um the if the ID is located per SD BSL.

B

Ladies and gentlemen, heart stop we're being kicked out of the room justifyingly, so we overrun mercilessly all right. Well, Sandy. Sorry, we pushed the stuff to.

D

The next session, thank you. Everyone.

B

Interesting session.

D

A

One uh Tony's got to pay for beer for everybody tonight.

B