Session Date/Time: 22 Jul 2026 12:00
[00:01:00] Tony Przygienda: So here I am. Greg is online. Good. You're cheering.
[00:01:08] Sandy Zhang: Uh-huh. I just You just got promoted
[00:01:11] Tony Przygienda: without any race.
[00:01:13] Sandy Zhang: I just sleep.
[00:01:16] Tony Przygienda: Double the responsibility. You know? You're qualified now, but you get no race. Welcome to the BIER session. We got room this size. We got to accommodate all the BGP sessions, all the AI side meetings easily. And I understand if you have to shout because you can't, you know, understand each other.
[00:02:05] Sandy Zhang: Yeah. It
[00:02:07] Tony Przygienda: looks like a bureaucrat. That's that's exactly my inside joke when I was in IBM. Right? I was like the absolute crazy boy doing crazy shit, but I was wearing this sleeve protectors like, you know, IV hundred years before working. You have to have a style. Oh, it's transcribing all this. Very good. Lots of politically incorrect thing. So why doesn't it, like, you know, do stars for the things that's supposed to say? Please replace in the transcription all the politically incorrect terms with stars. Beer, suspicious. Yeah. So the newest joke was Yeah. Try that today in the land of the yeah. Anyway, we're not here for political commentary. We're here for the BIER session. So let's start.
[00:04:24] Jeffrey Zhang: Alright.
[00:04:34] Sandy Zhang: So this again, our co chair, Greg, is online. Greg?
[00:04:43] Greg Shepherd: Yes. I'm here.
[00:04:44] Sandy Zhang: Okay. So will you present to the BIER working group status document? Status document. Good.
[00:04:57] Greg Shepherd: Good morning.
[00:04:59] Sandy Zhang: Good morning.
[00:05:01] Tony Przygienda: It was his alternate e o o. It's alright.
[00:05:04] Sandy Zhang: Okay.
[00:05:04] Tony Przygienda: Yeah. Go ahead. Okay.
[00:05:06] Sandy Zhang: So let's begin. Welcome to attend IETF one twenty six BIER session. And please make sure you are in the right room. And let's see. It's not a well. And every IETF meeting have this, and then you have interesting on it. You can read it. And this is meeting tips. For the in person participants, please make sure you should assign to the meeting. And for the remote participants, please make sure your audio and the video are off unless you are sharing or presenting during a session. So please join the queue and then speak in the mic. So this is a resource of this meeting, and you will find something about the BIER working group. And you will find the the meetings taking link through this, and please help us to improve the meetings.
[00:06:18] Tony Przygienda: Anybody taking notes?
[00:06:21] Sandy Zhang: We have AI now. Yes. But but we the IETF will generate the meetings at first, and we we can improve it.
[00:06:34] Tony Przygienda: End up in jail. I rather, you know, falsify the meetings myself. Alright. So I I think there's nothing to take minutes. That's good.
[00:06:42] Sandy Zhang: Okay. So we have a newly published RFC OEM requirements, and it's RFC ninety nine seventy four. And I thank you for all the works. And we have a draft seeing the attitude queue because of the pre normative documents are still in the line. And the other, we have PRP in the GitHub, and we have done the work in the GitHub, and we'd like to do more in the GitHub to improve the document. And then it will be published to FC. So mhmm. Yes. Okay. That's some documents need to be refreshed, such as the non-MPLS extensions because we'd like to move these draft to next stage. So authors such as Jeffrey, please refresh the draft non-MPLS extension so we can move it on.
[00:07:51] Tony Przygienda: Exactly. So lots of drafts are hanging on the non-MPLS extensions, please. So please, please, please refresh it so we can finally push it out. It's gating, you know, tons of other stuff behind it. Thanks.
[00:08:07] Sandy Zhang: And we have three draft that had finished the working group plus call and IPR call, and it's right to the next stage. And, also, we still need some IPR core responding from the authors such as the BGP RS BGP RS extensions, and other one is bierin6.
[00:08:37] Tony Przygienda: Yeah. So we got the OEM requirements out, and the OEM draft went up, basically, through all the reviews. And the authors are kind of, you know, cleaning up the last comments on the whole thing amongst themselves. If you want to participate, there is a GitHub with, you know, all the issues, all the pools, so on. More than welcome to jump in there. There's another couple of issues, more of the stuff editorial. But if people are more than happy and willing to help, that will be appreciated. Okay?
[00:09:16] Sandy Zhang: So this is our agenda today. And if somebody want to comment on the working group status, please speak.
[00:09:26] Tony Przygienda: Right. And for people who haven't been in this AI multicast side meetings and other subversive, you know, activities that have been going on under the agenda, there is a lot of discussion about possibly, you know, extending BIER and using BIER for it and so on. So I can recommend Mike McBride put out basically from these side meetings stream of consciousness things. He put together a pretty good draft. Outlined some of the not all, but, know, some of the problems some of the problem we didn't address, he doesn't show. But I think it's a fairly objective assessment, you know, what would be needed and consideration, you know, which direction the whole thing should go and what we do with pluses, minuses. So I recommend to read that stuff. It's called AI requirement something. Okay? Thanks.
[00:10:20] Sandy Zhang: So let's begin our presentation today. Okay. Just wait for a moment.
[00:10:44] Jeffrey Zhang: I think. Yep.
[00:10:48] Sandy Zhang: So the new one. 1414 version. Right? You send the final version.
[00:10:59] Toerless Eckert: Yep. Yep. You need to make the clicker pass the slide control to the clicker.
[00:11:04] Sandy Zhang: Yes. I had.
[00:11:05] Toerless Eckert: Yeah. Okay. Welcome, everybody. So this is BIER-FRR. We we had that fail on the ISG. And so then last time, I explained a little bit the plan of trying to help improve the quality of the document primarily, which involved a lot of trying to first read up on the technology and starting to to understand the goals and but ultimately have something that because I really think that the BIER-FRR is really cool. Right? So BIER is the best technology for multicast to apply all the benefits that we have in FRR for unicast. So I really wanted to see that the document can kind of tell that to all the customers who love FRR but have no idea what BIER or multicast are and not just kind of only do the minimum fixes to get this thing through I s g and then nobody reads it. Now if there's a lot of new text, some of the old text may become redundant. So but let's get to that problem after we think the new text is useful. And yeah. So the the changes over, you know, unicast FRR, I think, are minimal, and I think that's kind of showing that to the unicast people that everything of unicast FRR can be reused, is reused, is applied. I think that's a big benefit if we get that done right. Click. Yep. So that was what I did in IETF 125. So the first intersection was trying to explain all these unicast FRR mechanisms, LFA, remote LFA, TILFA, so that we also introduce the terminology that's defined their p case p p space, q space because the the document will need to reference to that later and and trying to minimize, you know, additional new technology that terminology that we need to introduce. So for for this IETF, I'd edit a section of trying to explain the BIER forwarding extensions that we need for FRR. And that ends up being different models, which obviously we'll have to discuss how many and which ones are useful. I think the way it's trying to show them now makes a lot of sense and gets away from the issue that they were considered to be implementation ideas. And and I'll talk about that more. And then for next I t f, it's pretty much all the control plane stuff in terms of how do you calculate the different adjacencies that you need for the backup. And so we'd already talked amongst the coauthors of that to also figure out what a minimum useful set is that lays out the land and see how easy they are to derive from existing control plane calculations done for unicast FRR. Okay. So there are a couple of things that were kind of hinted at in the draft, which I think we should be clear of maybe putting out of scope. This primarily is meant to be informational overview, and so there are lot of details that can be added, but I I don't think it's necessarily helpful at this stage. So I would, for example, say we're always assuming unicast FRR is being used. Traditionally, it's called IPFR, but it's also the same with MPLS now. You know? But we don't need to talk anymore, I think, about RSVPTE tunnels, GRE tunnels, all that other stuff that really, you know, the majority of operators or any, you know, operator that would dare to adopt BIER wouldn't have in their network. And that's just, you know, my opinion. So please feel free to chime in. I don't think we should increase the amount of routing protocol requirements that we have over those that are already established for unicast FRR. So pretty much meaning we use the SPF IGPs that we have, which are used to calculate unicast FRR adjacencies. So if somebody comes and says, well, I wanna do BIER-FRR with Babel or some other routing protocol, great. Everything can be done, but maybe those things in in different documents. Right? And then also the partial view deployment. So there is a wonderful long rant about that in RFC eighty two seventy nine section six dot nine. We can write something like that. Not a problem. Is it helpful? So I'd rather start saying no at this point. Yep.
[00:15:46] Tony Przygienda: And I think it's actually quite interesting. Nobody gave you the real careful thought, I think, I think. And the other thing, that would be possibly helpful and would make your use case very strong or a suggestion of of your special solution for the FRR is when a BIER is being programmed by a controller. Right? Because then you don't have any FRR at all unless you program it, which means the BIER somehow has to do the FRR itself.
[00:16:17] Toerless Eckert: So that that's interesting because I thought so far everybody's happy for Unicast FRR for the IGP to solve it. So I'd love to learn controller based networks if if that really exists so that that because then we also need to have the Yang model, right, and then and that stuff. So
[00:16:34] Tony Przygienda: Whether it exists or doesn't exist today, our job is to build, you know, a control plane as flexible as possible. Right? It was never intention that we glue BIER together with IGB from day one. Right? So since we have such a flexible architecture and you went down this path to consider how to do FRR without necessary IGP or better than IGP for means a logical inclusion. Sure. Sure. Okay.
[00:17:05] Toerless Eckert: Alright. So the one of the concerns about the old text was that that it kind of was perceived to be implementation example details or so that are not good generalizable. So I was trying to emphasize that what is now in in the draft, in the new text, is really forwarding models in very much the same way as it was specified as the BIER architecture forwarding model in 8279. So it's pseudocode and BIFT specification. So these actually are abstractions. There are a lot of ways on how you can optimize and change them. And then the question is why do we need different models? And this is exactly what the majority of the slides here are doing, showing how the three different proposed models are differing in the way of, you know, how packets are being replicated, starting from, you know, one that's most easy maybe to implement to one that's most efficient, having the least or no unnecessary duplicates. And operators need to have this type of specification. So they put the stuff into operation, and they wanna see is it working correctly. You know, I'm seeing duplicated packets here. Why is that? Well, that's that's part of the solution that we have. Right? As well as, you know, planning for the network capacity. Right? They need to be able to simulate, especially in FRR. Right? Where is traffic flowing? How much traffic is flowing there? So so those things are requiring us to have specifications. Even if you do a proprietary implementation, you'll have to provide to the customer a model of that so that he can validate the stuff and that he can plan the network and emulate simulate it. Okay. So here are the three models, kind of just random new terms that I came up. BIER adjacency FRR. So the idea here is we're not changing BIER forwarding at all. We're just using unicast FRR. How good will that work as kind of the adjacency in BIER? Then the second one is we are extending the BIFT with backup FBMs. How much better does that work? And then finally, removing all the issues of that second one, sorted backup FBM. And then I'm starting with the most simple example topology to make the comparison most easy. And then I'm going to one of the most complex topology example to show how in reality these these can also differ. Lick? Yes. So this is the most simple example topology. So we're having r two as the node that is trying to do FRR because one out of r three, r four, or r five may fail. So obviously, we're only talking node protection. Link protection is there as well, but it's the boring case. So that that is not something really of of interest for the high level here. And the topology setup that behind each of the three next hop neighbors, there are two BFERs. I've I've been using two BFERs because I don't want anybody stand up and say, so in the FRR case, why don't you simply use unicast? Right? So just to eliminate that that question, each of them has two. And so if you look at the BIFT without any FRR, you obviously see that to get to r six and r seven, you're going through b f r neighbor number r three. And then likewise, r eight and r nine, you go through r four. Eleven and ten, you go through r five. And so now, let's see what we can do in the f r r case. Obviously, if one of these node failed So these are all, by the way, shortest path, right? So the topology set up that this actually is a good shortest path solution. This is what you get from the I g p. If one of the three neighbors fails, obviously, r two can just go to any of the other two, most likely the adjacent one, and gets the packet down. So this is simple because we can use LFA. You just send the packets for one of the neighbor to another neighbor and it will get to the destination. That's the beauty of BIER. Right? You you don't need to tunnel back into some place in this topology. You just simply send to another neighbor. And in the f r r case, that is also the shortest path and that you can pre calculate through the normal l f a calculation. So here is the adjacency f r r, and I call it adjacency f r r because the only thing we're doing here is replacing a neighbor with an adjacency that is from unicast, which is the protected neighbor. So instead of r three, we're putting the l f a R three comma R four adjacency in there, Which means, please send this packet to R three and if that fails, then send it to R four. So the unicast forwarding code will basically try to see is the link to r three up. If not, then it sends to R four. And likewise for the others as well. And so that is basically what I would call no change to BIER forwarding because, you know, there's always some way of how the replicated BIER packet has to be forwarded. And so that could be the existing unicast code with LFA in there, remote LFA, whatever we have from unicast. And the way I've represented in our pseudo code, what really is unicast behavior, packet sent. Right? So if that b f r neighbor is an LFA, well, you check is the neighbor up, then you send it to that neighbor. If it's down, then you send it to the backup neighbor. Right? So that pseudo code we could replicate for remote l f a and for t I l f a, but it's basically just our pseudo code representation of existing unicast behavior. Click. So now what is the issue with this? The issue with this is that when let's say r three fails, we have a packet to all the six b f e r's, then we're not only going to send one packet to r four, but we are going to send two packets to r four. Right? Because the first thing that happens is we're trying to match against r six. We have r six bit set. So then we're sending for both r six and r seven to the LFA r three r four. So that basically means r three has failed. So we're going to send one packet copy with the bits for r six and r seven towards r four. That was just kind of the FRR situation to compensate for r three having failed. And then we continue in the BIFT, and we're going with normal stuff. So we're going to send a second packet to r four, which is up and is for r eight and r nine. Right? So just using the standard BIFT, LFA adjacencies works perfectly fine. We're just having the overhead of now sending double the amount of traffic, so to speak, out to that that neighbor r four. And there is no duplicate packets at the receiver, obviously, different bits. So ultimately, those duplicates will, you know, vanish away when you go further down the tree. So it's just more bandwidth utilization on the intermediate hops, which may or may not be an issue. Click. Okay. So how can we solve that? And that is basically by introducing for the backup case, a separate backup FBM, which is the bitmask for which you are going to mark out the bit string in the packet. So let's run through that. We're calling that b f r r, backup f b m. So again, we're going r six, unchanged f b m for the standard case, six and seven are behind r three. But now if r three is failed and we need to send to r four, then we're basically saying, well, now we're using a different f b m. We're using r six, r seven, r eight, and r nine, which is pretty much exactly the f b m for r three, r six, and r seven, plus the f b m that we had for r four. Right? Which was eight and nine. So we're already dealing with all the four bits, and we're only getting a single copy now out to r four because of the first BIFT line for r six. All the four bits have been dealt with. So when the forwarding proceeds to r eight, there is no bit left. So we are only sending one packet. Great. Wonderful. So that is a forwarding change we're seeing. Fewer amount of packets. Now what this does not solve is that when instead of r three, we have r five failing. Because then the BIFT entries are in the wrong order. We're still doing r four first. We're sending out a packet to r four. And only afterwards will we send out a packet because of failed r five to r four. And at that point in time, it looks as if it should be fine. Right? The backup f b m has all the four bits, but the ordering of the forwarding makes it that, you know, the two, you know, bits for r four were already sent out. So because of this ordering of the forwarding, we cannot avoid duplicates in all cases. We can only avoid the duplicates when the failed interface is has its BIFT entries before the non failed ones. So that's the limitation of this second model. So in the pseudocode, this backup FBM, that is just these three lines of code in the pseudo code that are marked, and it's basically, you know, is the primary up? No. If it's not up, then we're simply using the backup f b m and the backup b f r neighbor for the forwarding. Everything else in the forwarding code stays the same. So how do we get rid of the duplication for the last case? Well, one option that I was coming up, and that's what I called sorted backup FRR, is that we already are enumerating over the bits in the bit string. And the control plane could basically have a nice simple way to equally be informed of which interfaces are down, and then accordingly have the bits that are going to downed interfaces. That's down BFR neighbor indices. Control play needs to, in a few millisecond, update that. And then basically, we can simply return the bit positions in such a way that we first give all the bit positions of interfaces that are down, and afterwards the ones that are up. And we always have the order that the down interface bits are evaluated first, and we get rid of the duplicates. So that that is something which in the old draft was done through, let's do on a per interface BIFT. And here, the trick is simply reorder, you know, your BIFT entries, how you evaluate them. It's one model. Right? So if there are other models, you know, or if if another model would be better to express this, but this would basically be exactly the idea to get rid of any of the duplicates of the BIER-FRR approach. Click. I think I have to so right. So now we're going to the the interesting part, which is how do these compare with a real network. And so the queue space is from IPFRR, the space that can be reached from the receivers but not from the sender. So you need to tunnel. And then the interesting part that happens in the case of multicast is that it may not be good enough to just send one tunneled packet towards all the receivers because it may become partitioned. So let's show that in this picture here. We have our f r router being r one, and we have the next hop neighbor being r two, and that fails. And when you look at the topology, what you see is r one can send through r two to all the four b f e r's. But when r two fails, there is no single connection anymore on how it could tunnel to some place and still reach all the four b f e r. Right? It cannot simply send to r twelve because r twelve could theoretically reach everybody, but r twelve would still send everything back to r one in the old I g p routing table. So you need to send towards at least R 11, and that is basically here on this slide. You need to send one packet copy to r eleven and indicate, well, you can go to r five and r six, and you need to send another copy to r thirteen at least to reach r seven and R eight. Right? So so that is the cool, new, interesting challenge you have in this type of topology. Now, if we do this in a f r where we do not change anything in the forwarding table, but we just keep the existing BIFT, it kind of looks as if we could simply do this. Right? So for R 5 and R 6, we put R L F A in there and then a tunnel toward R 11 to the up for the first two routers, R 5 and R 6, and then R 7 and R 8 going into a tunnel toward R 13. Basically, exactly what we had here in this previous slide. Right? We just put this into the BIFT and hoping this will work, but it doesn't work. And it doesn't work because the f b m already eats up all the four bits. Right? So you have a packet for the four b f e r, R5, R6, R7, and R eight. And what happens in the failure case? Well, they're all going into a tunnel toward R 11. There is nothing here in this solution that helps you for r seven and R eight to be actually sent toward R 13, which is what would be needed. Right? So this does not work in the way that we would like it to if we just stick to the existing BIFT without any extensions. But we can even do a workaround. Right? So if you say, well, but I I bought a chip from a monopoly vendor of crappy chips, and it cannot do any extensions. I need to wait another ten year before that vendor brings out the next chip. What would you do here? Well, you're tweaking with the f b m. You're splitting up the f b m so that r five and r six are having the same f b m but not r seven and r eight. And what this now does is that when there is no failure, then our router would send two packets, two native BIER packets toward the neighbor r two. Right? So we take the hit, the performance hit in duplicating the amount of traffic in the normal non failure case, and the l f a case or the r l f a case now works because when there is a failure case, then you you go for r five, and that is being tunneled into r 11, catches up r five and r six, and you got the two bits for seven and eight left, and so they're processed and go to r 30. Right? So we can actually get without any changes for the BIFT FRR working at the cost of, if you have this type of topology, taking a performance hit in the normal case when no FRR is happening. And that may be perfectly fine. Right? So think it I mean, I I was trying to give to customers even ten years ago all type of great optimizations. And I said, well, you're using too much traffic now with multicast without that optimization. And then they said, wait a second. So we can finally justify the upgrade for the following links? So that's great. So no, we don't need a new feature. Right? So let's say you have 100 gigabit links. You have only five gigabits of multicast. You want a high reliability. Well, you would now need 10 gigabits instead of five gigabits. Customer may be fine with it. Right? So that's why I don't think we should discount these most simple options without any changes in the BIFT offhand. And obviously, when we go to the BIER FRR, SBFR, where we have the backup f b m, then of course the solution will work perfectly fine because now whenever there is the failure case, we will use the smaller backup f b m and then the stuff will correctly get into the right tunnels. Right? So this case is kind of the most obvious example for why we really, if we wanna be as efficient as possible, wanna have the backup FBM entries in the BIFT for good FRR. So now all of this is very abstract and doesn't take into account encapsulation, and eighty two seventy nine didn't take into account encapsulation as well. But I think it may make sense to consider also thinking about that, even though it may be getting too much into implementation. But to give you an idea, obviously, when we do send to a backup neighbor, then the BIFT I d, which is the first field in the BIER header, which is the label, that needs to be different than when you send to the primary one. Now it's not a problem to do that because that information is flooded by the IGP or the controller. But of course, we need to accordingly put it in, and that's a BIER specific function. That label is not used by unicast, so maybe better in our forwarding plane specification. That's what we're also including. And then also the idea adjacency, FRR adjacencies, maybe resources and hardware forwarding tables. So it really makes sense to think, should we not continue to reuse the ones built by Unicast as much as possible, like we defined in the AFR model? And so that's why I thought up this model which is SBFRR, but now for m p l s using f r adjacencies. Right? So this is an alternative for the SBFR that is generalized. Right? And so what we're seeing here is we're tracking the primary BIFT idea and we're tracking the backup BIFT id. So those two labels are now entered in the b in the BIFT, but we're now using just simple unicast adjacencies. Right? Unchanged. And then the forwarding plane changes here in red are exactly the changes over what were done for SBFR. So the first thing is when we're enumerating the BIFT entries, we're returning a bit that says, well, you know, this is for this BIFT entry, we're in FRR mode. The the link has failed. And then we're again overriding the FBM and the BIFT ID with a backup. And when we're sending out a packet, the only change, of course, we're adding here is we're adding the BIFT I d correctly, and that is it. And the packet sending is now just normal unicast packet sending, assuming that there is obviously the right unicast FRR adjacency. So that is kind of, I think, the most beautiful option that I can think of if it works. And I think would be the best model because it minimizes, you know, the resources we need for for BIER itself. And that's what I said here. So what I wanted to show this this time is the different forwarding models that BIER-f- r r may want to explain to show that we can start with something that doesn't change BIFT, b r forwarding at all, up to one that has hopefully, you know, very feasible changes and totally avoids any duplications. And, you know, you may pick one of them in the middle. And yeah. So those are all, you know, based on well understood Unicast, FRR mechanisms, LFA, remote LFA, TILFA. And this is just kind of the integration of those forwarding options with the BIFT. And then, yep, next time, the IGP calculations to set up those adjacencies. Alright. Was that half an hour?
[00:39:11] Tony Przygienda: So from my side, excellent. Thanks. First time I see that, like, coherently laid out which option, you know, buys you what. You didn't say anything about potential improvement over IGP FRR failover in terms of, you know, speed. There'll be
[00:39:28] Toerless Eckert: No. Same.
[00:39:29] Tony Przygienda: Considerations. Yeah. Okay. Yeah.
[00:39:31] Toerless Eckert: I mean, I I haven't seen good numbers. I I I I've sown some implementation a few milliseconds. Right? It's as fast Mhmm. As the link down indication can come. And if we go into these details, this the RFC specs are pretty bad. You need hold downs, and there are a bunch of things.
[00:39:47] Tony Przygienda: But Agree on.
[00:39:47] Toerless Eckert: I think it's all the same as unicast. It's a good starting point unless that really sucks and you say we can do better.
[00:39:59] Tony Przygienda: Now having seen the structure, it's probably just the same, let me say. Yeah. Which is a pity. Right? Because if you look at something that beats even the IGP FRR speed failovers, that will be a huge advantage.
[00:40:10] Toerless Eckert: Okay. If you if you think we should capture one of that I haven't thought about it. Right? I'm I've I've made a lot of career by just, you know, sucking up to the unicast side of things and trying to show how to make multicast as compatible with it as possible.
[00:40:26] Tony Przygienda: Mhmm. Yeah.
[00:40:33] Jeffrey Zhang: Jeffrey Zhang, HP Juniper. Both RFC eighties two seventy nine and your slides, assuming that FBM is associated with each BIFT entry. But if you consider ECNP and FBM is really as a property of a a particular BFR neighbor, not a particular BIFT entry. And if you you think of it that way, things may may become more may may become simpler.
[00:41:10] Toerless Eckert: Okay. I think I heard you say two things. The first is e c m p. Yes. I've willfully ignored it so far. Is your second point independent of e c m p?
[00:41:21] Jeffrey Zhang: So forget about e c m p for one for one moment. So in the r f c eighty two eighty two seventy nine, the FBM is associated with each BIFT entry. Correct? And your slides also assume that. But if you're now adding the ECNP consideration, then you will realize that FBM is actually a property of each BFR neighbor, not a property of BIFT entry.
[00:42:07] Toerless Eckert: Okay. May maybe a little bit need a
[00:42:09] Jeffrey Zhang: little bit
[00:42:09] Toerless Eckert: longer to Okay.
[00:42:10] Jeffrey Zhang: So so then the the basic the the the short point is that FBM is really a property of a particular BFR neighbor. And once you think of it that way Yes. It the things will may may become simpler, and the way you describe it may become may be different.
[00:42:28] Toerless Eckert: Okay. Right. So yes. Yes. That I think would mean that we would first agree that we are re re what 8279 was writing in a different form. And I didn't wanna go that additional path. If if we're fine with that, then we can try to simplify based on that. Right? So as long as we're agreeing, yes, we are re representing, it should be model wise the same and and then we we do it, that that's fine. It's just probably more work for me, but let's see if if I understand what you're trying to get to. We can exchange. And if I have to rewrite it all again
[00:43:06] Jeffrey Zhang: No. You don't you don't Yeah.
[00:43:08] Toerless Eckert: No. Completely understood. Right? And I was also thinking about other optimizations, but I was trying to push back. So this was just the format trying to suck up with existing eighty two seventy nine. Anything else?
[00:43:26] Tony Przygienda: Okay. No. Thanks a lot. So
[00:43:33] Sandy Zhang: we have still some time. So if anyone want to say something or discuss some topic here.
[00:43:54] Toerless Eckert: Just to be thrown out of the room, has anybody good war stories about AI? Because I did a lot of stuff now in terms of, you know, the graphics and everything lately with with the AI tool, so it was actually helpful. Converted my really sucky graphics into this with Gemini and so on. So in my other working group, also people were reporting happily that, you know, especially English as a second language, you know, just for spell checking. Right? Obviously, you don't wanna have the AI do any of the actual text writing, but existing text or so found even logical mistakes. Right? Oh, there's a not missing or you there is a not that shouldn't be there, so it did understand some of these things. So always love to hear more, especially positive war stories.
[00:44:45] Tony Przygienda: I was the first guy to acknowledging Claude as a contributor to my draft. Okay? Nobody got the joke. It is actually amazingly good. Alright? So you can give you the draft. Say, read the draft, read the references, catch up, then give it a implementation you have and start to argue both the reference of implementation, the draft, and ask what is the specification holes that you're seeing and what is the implementation holes that you're seeing versus the specification. It it models both in my experience. So you have to tell it, okay. Look. This is implementation specific. It does not does not go into specification. Right? But I had also very good experiences and subtle discussion where about semantics. Like, what does zero mean? Like you say, right, the logical error not that much, but basically shooting holes, like saying, look. This semantics not fully covered. What if these ranges overlap? Right? And then I could actually tell it, go look at the implementation. We have a very complex API based on these, like, ranges that overlap. How would you treat them? And there was the optimal treatment that would, however, make the AI awkward. So this thing thought through it and said, look, this will be optimal. That is not as optimal will work, but the AI will be orthogonal. I would prefer that. It was very impressive because it was the full thought process that I already had, and I was testing it whether it actually was capable of doing that. Graphics, I found it very poor. It struggles. Right? You want graphs and things overlaps and so on. With a lot of, you know, careful pushing forward, you did a reasonable SVG, which is still much simpler, much faster than you do it yourself, but it's not as helpful. In rewriting, One person told me, your style is too flowery. You should get AI on to simplify it, which you did. And the next reviewer told me, this is too dry. This is AI ish. You should rewrite. Like so you know the fable with the with the with the donkey, right, if you don't read it up. Right? So I wouldn't pay too much attention to that. The style is particular. You like it or you don't like it. But in terms of shooting holes in the spec, arguing the spec, of course, in rewriting, that's that's that goes immediately. But the imp the the impressive stuff was I have a complex reference implementation and the spec, and I'm basically letting this thing balance both against each other. The to my my experience. You know? Yep. One of many, but that was the one that was very kind of positive and very representative. Yeah. Thanks.
[00:47:36] Toerless Eckert: So the Ori, I think, was trying to you know, a couple of folks from the application area, right, getting to the point of really trying to see that specifications are complete enough that you could actually let the AI write a reference implementation as opposed to afterthought what you did. Right? So that that might also be an interesting thing to do. So Not not because you wanna use the implementation, which may be another reason, but to see if it's complete.
[00:48:06] Tony Przygienda: Well, but that doesn't give you a guarantee. A better indicator would be do you have two different AIs writing two implementations from scratch, which I had because this thing got to the point where it said, my design starts to become so complex. I need another AI to check it. So it started an empty AI and started to reason against each other. At which point in time, you know, you can become a clinical psychiatrist because you're dealing with this schizophrenic personality. Yeah. Good. No. It's a good question. So I highly encourage that. The other really positive thing is I thought this GitHub being a draft was a little bit of red tape generation. I find it works really well if the draft is advanced. Like, issues, pushes, the authors commenting onto each other, reviewing, automatically pulling in, it's actually very amenable towards working on fairly complex draft with a couple of authors. Just saying.
[00:49:12] Jeffrey Zhang: Jeffrey Zhang, HP Juniper. I just wanna quickly add something about the AI stuff. You probably have heard various discussions in the site meetings and in other working groups about use of multicast for AI, and also there seems to be a leading solution there. There are some gaps or enhancements we could do that people have pointed out. And I just want to say that we have some thoughts on those, and we can work on those extensions or enhancements in the BIER working group and for those, gaps. And there are some work ongoing, and we we will be able to to share more in the next IETF meeting.
[00:50:01] Tony Przygienda: Yeah. More than encourage people to bring that. As you see, for reasons I won't speculate except or or you pay me a beer, why the people didn't show up, actually show it how they want to hack BIER to do AI? But it's fine. We had staff working group to get something done here. Better makes sense. But, yeah, the gaps are people talk about the gaps more and more openly, what they desire, and contribution more than welcome. And, you know, we're the discussion with the charter, you know, will happen if this stuff starts to develop in this direction. But, obviously, there's need, and now there is a raising acceptance because from what I understood, some people without actually telling others started to actually hack multicast and use it. And so very, very beneficial, you know, job completion time and GPU usage effects, which is not a surprise. Correct? Yes.
[00:51:01] Toerless Eckert: Yeah. Just just a remind and so and for those who weren't in PIM. Right? So the last presentations was about how do we make failover for for PIM faster. And that that that was kind of I I can see the realities of the industry, but, obviously, you know, I'm I'm I'm happy if if we could say, well, you know, we would have a much better solution with BIER for that because it's it's also based on what Unicast does. So if if you're interested in the FRR stuff and compare with, you know, how badly we struggle with the complexity in doing the same with PIM.
[00:51:37] Tony Przygienda: We yes. But, you know, telling people who look to speed up the PIM failover do not run PIM is mostly not a productive discussion. Right? So, yeah, fully agree. Thanks.
[00:51:49] Sandy Zhang: Alright. So, Greg, are you still online?
[00:51:57] Greg Shepherd: Yes. I am.
[00:51:58] Sandy Zhang: Yes. Do you have anything to talk about?
[00:52:02] Greg Shepherd: Oh, goodness. Well, we covered a lot there. I just wanna thanks for those for picking this up.
[00:52:12] Sandy Zhang: So we're done today? Yeah. Yes. Thank you for you for attending this meeting. So in next meeting, San Francisco. Yeah.
[00:52:26] Tony Przygienda: Yes. You got some of your life back. Time for a BIER.
[00:52:31] Greg Shepherd: Hey. Can I just see hands in the room? Who is planning on attending San Francisco? Hands up? Wow. Alright. Thank you.
[00:52:50] Tony Przygienda: No. It's actually surprisingly good. Depends which side you look from. All good. Alright. Very BIER.