**Session Date/Time:** 22 Jul 2026 14:00

[00:00:06] **Job Snijders**: It is 4PM sharp in Vienna, and this is the global routing operations working group. Welcome, everyone. If you're not supposed to be in Vienna, come see me after the session, and we'll try and help you. With me, I'm Job Snijders. I am one of your co chairs. This is Paolo Lucenti, my fellow co chair. Paolo lost his glasses. So whoever has the best one liner joke about losing your glasses, yeah, please please do take the opportunity before making technical comments. And our secretary, Where are you today?

[00:00:49] **Paolo Lucenti**: Hey.

[00:00:49] **Job Snijders**: Yeah. Thank you. I took this photo two kilometers from here. I thought it was really funny. It's nice to be in Vienna. So today, we have a super packed agenda, which means we're gonna do very strict timekeeping. There is no room for longer than allocated discussion. So when we start waving, like, stop. Stop. You have to stop as presenter. We'll we'll go through our chair slides, and then we'll dive into the presentations. First of all, make sure you scan the QR codes that's hanging off the microphone so we can try and book a bigger room next time because the room is a little bit packed. Can see how many people online.

[00:01:49] **Shuang**: I don't.

[00:01:51] **Job Snijders**: So many. Yeah. Okay. Routing is increasingly popular. Some resources for your consideration. We have a nice mailing list, grow@ietf.org. You can view the archive here. And there's a chat room that I'll be monitoring throughout the session. So if you don't wanna walk through the microphone but do have, like, a small question or comment, feel free to use the chat room. Pierre Pierre Francois, kick help is helping us. He did not see it coming. Alright. The note well, I implore on all of you, please be excellent towards each other. We are a bit of a debate club at the IETf, and the goal is to, challenge each other's, ideas and and arguments. But that means no at hominess. No no no, specifics to to affiliation or appearance. No shouting. Yeah. Strive to be excellent towards each other. And, your your contributions at the microphone or in the chats or on the mailing list are considered IETF contributions, and that has a bit of a special connotation. If you wanna read more about that concept, click on the links. All the blue words are clickable links. So if you download the the chair slides from the data tracker, you can quite easily get to the content. Now since our last meeting, we managed to publish an RFC, RC ninety nine seventy two, one of the last ones of the vintage batch before October. Advanced BGP monitoring protocol statistic types. Thank you to the authors, and thank you to the working group for working on this document, and thank you for the patience. Then we have a Internet draft that passed working group last call and passed IASG review and is now with the RFC editor, the near real time monitoring near real time mirroring protocol to replicate IRR databases. I expect this to be published somewhere in the next few months. Then we have an agenda item, and I'm gonna pass the microphone to Paolo. It's yeah.

[00:04:32] **Paolo Lucenti**: Right. So, yeah, small, you know, agenda item around BMP. So we are very happy that there is a flourishing of contributions around the bmp. Right? So we see there is, you know, adoption among among vendors, and there is new drafts being created. Sometimes what we have recognized is that these initiatives, they are not really sticking together with, you know, the rest of the protocol, what with what has already been standardized or what is in flight at the moment. Right? So duplication of frameworks or, you know, things that really, you know, go the way. Okay. We invent 10 new message types and things like that. So we should try to be good citizens, like, when we design the protocol and try to make sure that when we make a proposal, it's sticking together with the rest. Right? So we should try to aim at a good protocol design. Right? And so because of that, with Job, we did discuss the matter, and we thought that we would like to do going forward some a little bit of gatekeeping. Right? The gatekeeping at the moment of document adoption. So the moment in which somebody says, hi. I want my document to be adopted. We would like to have a little bit not a lot of bureaucracy, but, like, a small form in which we will essentially be asking, like, so did you review the existing documents? Did you read them? Did you make sure enough did you do enough work to make sure that everything is sticking together in terms of design with the rest? Right? And this is right to try to, you know, have something more consistent. So we don't have any slides or we don't have any, you know, proposed, you know, kind of form yet. We will go through it. Of course, we will submit it to the working group. I mean, we will have a conversation. So for now, it's just something verbal. And, of course, we are also, you know, here, you know, to collect feedback, like, you know, anybody has anything to say about it or or not. Yeah.

[00:07:12] **Job Snijders**: Yeah. So so to add a little bit to this, there is some concern about the long term maintainability of the BMP protocol, and it it has grown a lot in recent years. So going forward, we would like to hear from offers, like, what specifications did you study before you came up with this idea to avoid, say, duplication of efforts, duplication of functionality. We also want offers to to really investigate, like, do you need to extend an existing type, or is a new message thing needed? Or, like, in what direction is is the extension happening, and why is that direction the the the appropriate path? And this is to to make sure that that the BMP protocol, yeah, doesn't become the DNS. Right. And no offense to my DNS friends, of course. Are there any questions on this topic of gatekeeping?

[00:08:21] **Paolo Lucenti**: Is there any support to this Good question. Gatekeeping. Okay, Jeff.

[00:08:26] **Job Snijders**: Okay. We see 34 okay. Yeah. Yeah. Okay. Thank you so much. It is good to see there is understanding and appreciation for, yeah, this initiative. Yeah. And and a likely outcome of this is that we will develop some sort of checklist or, like, a small interview form. But Paolo, as soon as he finds his glasses

[00:08:53] **Luuk Hendriks**: Got it. Got it.

[00:08:55] **Maria Matejka**: Yeah. Alright. Next

[00:09:00] **Paolo Lucenti**: up. I think next up is Camilo.

[00:09:05] **Job Snijders**: No. We're gonna show the agenda. You you that's not all my slides. Look. I spent a lot of time making these slides with FI and Pendoc and, LaTeX, so I'd feel bad if we don't look at all of them. Okay. Our agenda for today is spread over four pages because there's a lot of presenters. Camilo is first, then Paolo. Prasad, Maria Martin Pelz will be remote, I think. Luuk Hendriks, I'm really looking forward to what Luuk Hendriks slide look like. And Shuang and then Tobias, is is he in the room yet? Oh, yeah. Your icon sends you. Okay. So, Camilo, take it away. This is the holy clicker.

[00:10:06] **Camilo Cardona**: Okay. Thanks. Here because I'm always bugging this. Okay. Let's just start with pad marking. So Camilo Cardona from NTT. I'll give you the status of three documents or the three of them working group doc working working group documents. The first one is pad status. For a short overview for whoever doesn't know, this is a proposed TLV for BMP that basically marks the status on the paths. What are the status? Whether the paths have been filtered, whether they are in in the RIP, whether you can see the this here, whether it's Tails suppressed, invalid, and things like that. This is an old document. I have presented this many times. What's new on this version of the document is that we have finally an implementation. Thank you very much, Huawei and and Swisscom for leading that. I'll I'll describe this shortly. And, this is something new, and I think has been discussed also with the leaders of the group. Thanks to the to the with with the now RFC that was published for the group. They did have a few statistics that basically could did not belong so much in that document because they refer mostly about some things that we describe better here. So it was proposed that we move those statistics to this document since we already have the space to describe all these status with with more with more detail. Please take a look. I'm not going to go into much into it because I do want to focus more in that now we have an implementation of the whole path status TLB. Again, Huawei implemented in their NAIC series. Thomas and Swisscom lead the that effort. We use PMIC well, they use PMIC, are chair leads, and also Netgos WhiteShark for for validation. So I I think it works. We probably will look forward to a bit more information probably when we can get it, but you can see at least know that this thing can be implemented. So the document besides that, which is I find very important, has been more or less stable for already I will say more than a year. I, honestly, at this point, would actually start asking for a last call if it were not that. We do depend on the TLB one, which we will have to wait for it because I don't think it makes sense to last call this one if that one is not last call. So we will be waiting. I I don't know if I should talk about this one more until we get that one done. Do you guys agree on on

[00:12:59] **Paolo Lucenti**: that? Sure.

[00:13:01] **Camilo Cardona**: Okay. Questions or comments?

[00:13:08] **Tobias Fiebig**: Yep. I guess not.

[00:13:11] **Camilo Cardona**: So we can go for the next one. Yep. Can you do it, please? Okay. Fun. Yarn modules. The our BMP YANG module. Again, it's also another old document. We got last year a lot of comments from Per, who's our YANG doctor. I don't think it's here. I can only thank him for that. Oh, I have to reset my timer. Paolo, come on. I cannot do this in one. And that distracts me. So we got a lot of a lot of feedback from him, a lot of editorials. We changed all we we try to align with him on on on all the changes he proposed. I have to admit that from the YANG models, this one is big. So I can only thank him and any other reviewer for that. We also have, and I will talk about this in a second, an implementation status. So that's always that's always very exciting. No? A job? Aren't you excited? Implementation? Yeah. And I'll try to discuss a bit about some dependencies we have with TCP. So let's start with implementation status. Arcus gave us a hand, implemented this module, and only thank them for that. That's that's what we need. They did not implement some parts of the TCP the TCP, auxiliary model, mostly about the TCP-AO, which I'm going to talk in a second. But the rest, I think, has good coverage. I personally haven't seen it, but the comment so far is that the model is in good progress. So that's also a step forward in that regard. So I do have an open question for the group, which is our dependency with the TCP AO draft. So there's a I'll I'll be honest with you guys. We when we created the BMP and model, the first version, we model it a lot from the b m between the BGP model, and that one already had CCP IO for authentication. And we added it to the model even though it wasn't a standard for v for BMP. And now we have a draft, Jeff. It's there, standardizing that. And, therefore, we do have now kind of a normative reference to that one. Our the BMP model is actually in good progress, and I think now in more in the last steps than in the starting steps. So the question is what do we do? So we have a few options. The first option is to we just keep going on this. Thomas helped me with maybe we can follow this forty eight ninety seven section 3.1 to just move forward. So that's one option. And that's the one that we will take by default, except if somebody yells no. The second one is that we actually, push, so we kinda strip those parts from the model and ask Jeff and the coauthors of the draft to add them to their module. It's going to be less work from us, more work for Jeff, but that's also an option. The third option is that we wait. But, of course, implementations for the TCP-AO and publication of that model can be or that draft can take some months or years. So maybe that's why I think we can just keep going and trying to use the forty eight ninety seven if that's feasible. That's the question for the group. If anybody has an opinion, then please go ahead.

[00:16:42] **Jeff Haas**: I'll keep it short. You're going to get pushed back from the ISG if you don't actually have something talking about this. The nice thing about Yang is you can have this is a requirement of the document. We have, you know, work at the working group to say that we do want to support this. And anybody who does not support it can, you know, do a deviation statement in their YANG implementation. So there nobody is blocked from using this and enables everybody to use it when it's there.

[00:17:07] **Camilo Cardona**: Yep. And that makes that makes good sense. That makes sense. And and and we actually talk about this in in in the document already. So that's good. Thanks for that feedback, Jeff. Besides resolving this, I'm I I I don't know whether we need a new draft a new reviews from the I don't I don't know how how that works. I don't know if we need another review from the young doctors or if we need a shepherd, but I think we are more in that position of moving this forward than just waiting. So, you know, Thomas now is a YANG doctor. Maybe he can also take a look at at at his own draft.

[00:17:47] **Thomas Graf**: I just wanted to double down what Jeff said. So deviation would be wrong in this case. I think what we want is a feature.

[00:17:58] **Tobias Fiebig**: Okay.

[00:18:02] **Camilo Cardona**: Well, we can we can think about about that. Well, the point is that TCP-AO is is an op is also not a choice that you can ignore. And, I mean, there there there are a lot of caveats here that we can we can discuss. I don't know if we need a feature to add a choice. That will be that that could look a bit weird, even though it's feasible, of course, above above all. Okay. So I don't know if takeaway well, because, really, takeaway for you guys maybe, sorry, about that is whether we have to I because I don't know how how it works.

[00:18:37] **Job Snijders**: To respond to Jeff, I think if if a bmp-yang model is is created without TCP-AO, we we can make a strong argument to to pass it because we are documenting the current state of the art. So I'm not the the the arguments, I'm I reject. Okay. So in that sense, if TCP-AO is not yet implemented for bmp, And if it's if the document is not ready, remove it as a hard dependency, refer to it as work in progress, and yeah. It's

[00:19:14] **Jeff Haas**: fine. Maybe I'll speak with our Sorry?

[00:19:20] **Job Snijders**: Or the bribes or yeah.

[00:19:22] **Camilo Cardona**: How how do we do that concretely?

[00:19:24] **Jeff Haas**: Delete it.

[00:19:25] **Camilo Cardona**: We delete it.

[00:19:26] **Job Snijders**: You polish the

[00:19:27] **Alexander Azimov**: d button a little bit.

[00:19:29] **Camilo Cardona**: Okay. No. That that's fine. We can answer we can answer that. Okay. That's it. Well, anymore I don't know if anybody has more questions about this. We ask for if if anybody can look I mean, if anybody's excited about BMP, please read the the model. I mean, it it is probably, should be part of the no. Actually, and I'm serious with this. It should be part of the since this is a working group document, whoever does a draft of BMP should say whether that model should be extended from now on. Feedback. Yep. And because if it's not, then that means the model well, all models are wrong, but it means that we need to rethink about this. And this is a working group document now is the way. So I think for now on, please add that into your list of and then we can have more reviewers, which is my final goal. Okay. Okay. Thank you. Talking a bit more about BMP, this is the attribute about filtering flag. Do you ever presented this, Paolo, in other

[00:20:32] **Paolo Lucenti**: Quite some time ago.

[00:20:34] **Camilo Cardona**: Okay. So just to give a review of this, since it's my first time also, vanilla VMP, it was always considered that the streams from VMP were, let's say, complete. The the router was sending all the information of what you that what it had in their in their rips. When LogRip came, I honestly don't know what the line of thought was, but they discovered that some feeds will be filtered, so they will not be complete. And they added a marker as a flag in the in the protocol. However, attribute and a rebout do not have that flag, but it's very it's very feasible that rebat attribute and reroute are also filtered. For instance, in the BMP YANG model that I just described well, I didn't describe, but I I I gave up a date of, it does have the option to filter to filter those those kind of streams. So by the by the same reasoning, the idea is that we also add that filter flag into Azure b natural rebout. It makes the whole implementation a bit more, more more more uniform if it's already in the local RIP. An Azure Binary Bout can also be filtered, then it makes sense to have that filter flag. The filter flag is not going to tell the collector whether what is filtered or not. For that, I will recommend to you for for the collector to do to do to follow the YAN module and and get the filter path, but at least gives information to apps to the upstream that something is not complete and that something that is already on the local RIB. So it just makes sense to make all of these on uniform. We can try to implement this. I mean, I I could take a copy and add the flag and then maybe ask Paolo to to to in PMHGTT to output it in the JSON file that is full. But but at the end, this doesn't really need a big implementation. It's just that it's just formalization. So, honestly, I don't know how much we have to wait because to me, it just makes sense to continue if the group allows, maybe in the mailing list. So I don't know what what to follow here, but I will propose we just follow with last call. I'm I'm not I'm normally not super aggressive on this, but this one, I don't know what what else to do.

[00:22:58] **Job Snijders**: So working group last call for filtering Adj-RIB-In and Adj-RIB-Out. Yep. We will push the button.

[00:23:05] **Luuk Hendriks**: Thank you.

[00:23:12] **Camilo Cardona**: I don't know how to turn it off. I will just put it here. Hope that's helpful. Thank

[00:23:18] **Jeff Haas**: you very much.

[00:23:21] **Job Snijders**: Next up, I think, is Paulo. Yep. You want me to help you?

[00:23:27] **Maxime**: What do you?

[00:23:34] **Paolo Lucenti**: And the timer.

[00:23:36] **Job Snijders**: Yeah. The the mic, it's right in front

[00:23:38] **Alexander Azimov**: of you.

[00:23:41] **Paolo Lucenti**: Alright. So How long did you want? Five minutes? Yeah. Five minutes. I will cut short the the slides because in the end, it's, you know okay. We talk BMP version four, so the TLV support. I have my typical slide that recaps a little bit, you know, what is the the draft. It is true that this slide is slowly becoming a little bit, you know, outdated because it started with having, you know, TLVing, a route monitoring, and peer down, but things are, you know, a little bit evolving over time. We have the enterprise bit right now, and we are bumping the version. And we have some new TLVs that actually apply to all the messages, like the sequence, the timestamp, and the flags. What happened since the last ITF? I mean, there were quite some changes to not quite some changes, quite some edits to the document, but mostly, it was smoothing out the the fact that we merged the the SNTS document in. And the main thing is that the SNTS document was really related to route monitoring. And then the moment in which we analyze things, we said, like, okay. But some of the content actually applies to all the BMP messages, like the TLB like, the sequence or the timestamp TLB and things like that. So we had to reward, you know, a few things. Then there was quite some consistent review from my YANG-er. It was fantastic. So also that, you know, took some time. But where I want to draw your attention is what's next. So I had a couple of very interesting conversation this week with Prasad and with Luuk. So Prasad was saying, like, dude, I mean, you are having a lot of TLVs and things like that here. But then we have this very rigid peer header. And, you know, this being rigid, it will, you know, fire back at some point. Right? And especially, we have some documents in flight, like the multi peer header document that, you know, it will, you know, clash with the the current rigidity. So, essentially, what Prasad was saying, I mean, we need something more flexible there. What it means more flexible? It means making the peer header TLVed. Right? So take all the static structure and you make TLV out of all the fields. This could be just one basic idea. We can work on that better. So Prasad was right. And then Luuk came and said, hey, dude. Like, now we are doing all this TLV. The now the peer header, it's also not rigid anymore and things like that. But now we have peer up and peer down, and we have quite some static structures there. The we have the BGP PDU, the notification, or the open, and they are not contained into a TLV and things like that. I mean, this is looking quite ugly, you know, for a protocol that is going into the TLV direction. Maybe we want to change that. And also, Luca is right. Right? So it was quite interesting conversation. So my take was like, okay. We should try to wrap up this document. Right? So this BMP version four. But it's true that we have quite a good opportunity to make to improve the design of the protocol. And when I was talking, this was a point that was mentioned by Prasad. Right? So it was like, you you know, we are not doing anything new, no rocket science, no reinventing anything, not introducing any news or whatever. This is just encoding and decoding. And encoding and decoding, probably, it's the easiest thing that you can fix, especially, you know, with LLMs and and things like that. So, like, we can fix the encoding and decoding and, on the other hand, have a a better design of the protocol. Right? And it come I mean, it's a valid point. I mean, it's I, you know, I kind of accepted it. But I'm very curious if there is any opinion on all of this from the audience. Thomas.

[00:28:30] **Thomas Graf**: Yes. Hi, Paulo. I think you already said in the beginning, it's time to wrap up. I looked in the data tracker. We are now seven years into the document. Mhmm. We have dependencies on that document. We have implementations out in the file. I'm an operator

[00:28:48] **Camilo Cardona**: Mhmm.

[00:28:49] **Thomas Graf**: Looking very forward on actually being able to validate or verify redundancy in the network. Without path marking, this is not possible.

[00:28:57] **Camilo Cardona**: Mhmm.

[00:28:57] **Thomas Graf**: I'm looking at all the individual documents with all the different proposals. Normally, if I would go into another working group, like, people would say, I think it's now time for the design team. Yep. My suggestion here is I think we should stay as it is.

[00:29:16] **Camilo Cardona**: Mhmm.

[00:29:16] **Thomas Graf**: Wrap up as p m p v four. And then, basically, all these different proposals we have now, these different ideas we have now, let's form a design team on it and start working on b m p v five.

[00:29:30] **Paolo Lucenti**: Okay. That's a good input. Thank you. Talks.

[00:29:37] **Luuk Hendriks**: Luke and Ricks in LNetlv. I'm all for somewhat more flexibility, maybe in the prepare header, but it's still a header. I would like to have stuff in a position that I know where I can find it. Making this a complete arbitrary thing is, of course, super flexible, but I it I don't think we should go there for that part of

[00:30:00] **Tobias Fiebig**: Mhmm.

[00:30:00] **Luuk Hendriks**: Of the messages. Thank you, Luke. I mean, I agree what Thomas said. I mean, he's on that journey. But on the other hand, if somebody know if I know that v five book is coming, I might wait and not go to v four immediately. So that's the balance.

[00:30:20] **Paolo Lucenti**: Exactly. Exactly. The this is always the problem when you start doing the next version and the next next version and the next version is not completed yet. Yeah. That's

[00:30:30] **Job Snijders**: Yeah. But to be clear, v five is for 2036. So

[00:30:34] **Tobias Fiebig**: Yep. Yeah.

[00:30:37] **Paolo Lucenti**: Alright. Thank you.

[00:30:40] **Tobias Fiebig**: Thank you, Paulo.

[00:30:45] **Job Snijders**: Next up, Narashima Prasanth, please.

[00:30:58] **Jeff Haas**: Hello.

[00:31:05] **Narasimha Prasad**: I'm Prasad from Cisco. Today, I'll be giving an update on three or four of our drafts. We've actually made edits to two of them, which is number two and number three. And on number four and five, we've had discussions. We've agreed on a certain direction to take, but we have not updated the drafts yet. So I'll be sharing the direction with all of you. And then while chatting with Paulo and few others, everybody felt that, especially for number two and three, it'll be good to recap the use cases, especially if you can find some references in the public domain. So I'll kick start the presentation with that. So the first one is the route reflector deployment use case. This was co presented by Netflix and Cisco recently this year at Ripe ninety two. This is the network diagram is from their slide, but, essentially, what I'm trying to cover here is, especially for RR use cases, people want to use BMP. Netflix is keen on using it. They shared that in their presentation. And two other things which are important for us for these drafts is the scale of the routes. You can see it goes all the way up to 40,000,000 routes slash parts, and the number of clients which they wanna monitor is around 300 the max. So the two drafts which we have, which is the aggregated route mount draft and the common update stuff kind of fit this use case. So, mainly, I wanna just call out the scale signal here and the motivation. The next one is the edge deployment use case. This was shared at NANOG ninety seven. It was g course fast Netmon who presented this. So, essentially, what they called out in that deck is I think they use. Maybe, Luke, you know about this. What they were sharing is they had 300 3,000 BGP sessions, and then across the network, they had close to 200,000,000 routes. But what matters for us is per router, they're close to 70,000,000 routes. And then their intention was to use a live service provider network, which had multi vendor deployment. So in that presentation, they share that it was across Arista, Cisco, and Juniper. And then main two callouts here is, again, the route scale and also the peer scale. You see that the total number of peers is very high. It's close to 3,000. This is where the multi peer header draft and the aggregated route monitoring draft kind of help in addressing some of these scale deployment use case. Outside of this, I've also seen similar use cases from other operators. So but this is what I could find publicly from this year. Just to summarize those two slides, one is the edge use case, other one is the route reflector use case. So many sessions, lot of routes, and then how do we optimize BMP to help boost the router and the collector to have better performance and convergence. So if we help BMP with with the convergence, the side effect of that is it'll help BGP as well because on the router, both BGP and BMP cannot share the CPU. So in the route monitoring draft so this is the last sort of setup slide I have. After this, I have draft update presentations. So we are just leveraging the already well proven BGP group packing technology where the it's it's called peer group. It's called update groups. But, essentially, the concept is you do the table walk once per peer group, and then you send all the updates out, and then you're packing things across the peers. So that is the essential building block from BGP, which is getting leveraged in BMP. So there's nothing new. It's a well proven thing which is established in BGP. So, yeah, I'll let you guys read this offline. Couple of callouts is fewer table works. There is less work for the router, less data on the network. So, hopefully, it'll also help the collector side of things. I had a chat with Luke yesterday, and he did mention to me that it would help. Because we were thinking if on the collector side, because there's so much CPU, if they would worry about this at all, or is this a very specific problem for the vendors where the router CPU is kind of not as lavish as what the collectors run on? And then he did say that some of this would help on the collector side as well. Yeah. So this side is calling out the best case scenario for both of these drafts. How much will the optimizations help with? So the two takeaways for you is with the aggregation route one draft, if you had end peers, if, let's say, we can share things across all those end peers, instead of sending end different messages, there'll be just one message wherein you would bulk all of them and send them out. This is exactly how the BGP packing works across the peers. And then so that is within a review, and then the common update drafts kinda goes across reviews and says that if you're able to share anything across reviews, then let's say you're you have two reviews where you can share stuff, then there is a two n is to one reduction. So this is the best case numbers, but the actual gain would depend on the commonality. Okay. Maybe I'll pause after I give an update on the drafts, and then you can ask me questions. So on the multi peer header draft, this is where we made updates to the latest version, zero two version. So we kind of now are positioning the multi head header draft as a framework wherein you can use this not just for route one messages, but also for other use cases like peer down, route mirroring, peer up, and statistics. So we added those use cases in the recent update to the draft. But I do wanna call out on the table on the right that the strongest fit I see is for OutMon. VC is for OutMon, and maybe the next one in the list is for peer down, where if there's a common failure, all the peers are going down. We can use the multi peer header to sort of use this particular framework to group things and then send one big message with with with all the peer downs. And then would be route mirroring. I mean, this is where it I think it just depends because somebody may be using route mirroring because they wanna see every small blip in the network. And if we start grouping things, maybe that is not to everybody's liking. And then there is and statistics where maybe what can be shared across different peers will start becoming less and less. So that's why we are marked it as conditional. But, yeah, maybe here, I'll pause and then get some feedback on what you guys think about the broader use cases and the, you know, the stuff I presented before this. Any questions on that? Any comments? You think it's okay for us to extend it to other message types beyond Route one? Any thoughts?

[00:39:19] **Luuk Hendriks**: Luke and Ricks, we also discussed this already offline, but maybe for the group. On the case of the pair up, and this might also apply to other message types, you know, I can see that working for an iBGP scenario, but as soon as you start thinking of this in an eBGP scenario and you have your 32 bit ASN and the capabilities, every every message will be different from the other. Right? Yeah. In the in the route monitoring draft, you say you don't wanna mix aggregated messages and non aggregated messages, so you will need to use two streams. Long story short, it might need some text on operational considerations. Right? I guess that's something to keep in mind when making overviews like this. I guess, in general, it it sounds like a beneficial thing, but we might have to study it on a per message type basis.

[00:40:10] **Narasimha Prasad**: Thank you, Luke.

[00:40:17] **Shuang**: Okay.

[00:40:25] **Thomas Graf**: Hey, Pasa and Thomas. I would like to understand what are the implications in terms of group TLV. Is there anything to be considered between the two?

[00:40:35] **Narasimha Prasad**: Yeah. I'll update you on that, Antero. Next.

[00:40:37] **Thomas Graf**: Okay. Good. Thanks. Thank you.

[00:40:44] **Narasimha Prasad**: So this one provides the framework. Our thought process was anything which is specific to the message types itself, like what Thomas was asking in the case of Route one, that can go into their own drafts so that way we use this as a framework draft. And then if anybody's interested, then we can evolve the individual drafts for other message types. So this is where this draft update you answers bit of what Thomas was asking. So this is the aggregated route one draft, which we modified to build on top of the multiplayer header draft. So in the earlier version, it was all v three. So we didn't have any option for TLVs and such. So in the latest update, Thomas, to answer your question, we've added the TLV way of doing things. So right now, both the options are there for both v three and v four, but maybe as the draft matures, we would have to pick one. But for now, we have listed both, and we have listed how we can use the route one aggregation across both v three and v four. That is pretty much the update we did in this version. She thanks to Luke. He also was asking us about this in the last ITF on can we use the aggregation route one draft for with people? Yeah. I mean, main feedback I wanted here was if you guys have any thoughts from the collector side, will it complicate things? Kinda goes back to what Paulo was asking from a codec decodec perspective. Okay. I'm not kind of calling out the proposed working group direction whether we want that option or not. Maybe I'll wait for the template, and then then maybe we will take a call if we tick all the boxes.

[00:42:41] **Paolo Lucenti**: Okay.

[00:42:45] **Narasimha Prasad**: So on the common updates draft, which was across RIBs, so this is a directional update. We have not modified the draft. So all of our scores discussed, and then we felt it's better to merge the common updates draft into the route one aggregation draft. So that way, we have one draft which covers the sort of the scale enhancement, so to say, in the b m p messages. So you will see us sort of taking this step if everybody seems to be okay with this. The plan is to merge the common update draft into the route one aggregation draft, and maybe we will call it something else. But the idea is within a review across RIBs, we just have one draft which does the scale optimization. If there's no sort of opposition to this, we will go ahead and of do this. Okay. I don't see anybody objecting. This was another thing wherein just to recap, the generic event notification draft was kind of covering the systemic events in BMP. So these were things like, did some review get unmonitored on the box, or was some PR configured but has been down for, you know, longer than a certain threshold? So there are a lot of things which were not route specific, but they were systemic or PR specific. So for that, we had a generic event notification draft. And before that, Paulo and Camilo already had the route event notification draft, which kind of covered all the route specific event logging. So we kind of discussed amongst us, and then we felt it's better to have one draft for BMP, which can provide the event notification framework. So it covers, you know, all kinds of things, not just routes, not just systemic stuff. So having one draft would be good. But what we have kind of discussed and decided on is it's good to merge them, but what exactly to merge, I think we are still trying to figure out. Should it be just the framework, which is there in the Rel draft, and then the gen draft, you know, calls out the specific use cases, or we merge the entire gen draft into Rel. I think that we are still discussing. So if you guys have any

[00:45:15] **Job Snijders**: feedback Sorry. You have one minute left.

[00:45:17] **Camilo Cardona**: Okay. Sure.

[00:45:19] **Narasimha Prasad**: If you have any feedback on that, please let us know on if we just should have one framework and one in the Rell draft, or we should just merge everything into one. Similar to statistics, we will start with the framework, and then we will have a few use cases defined for the events. And then as we go, if people have more use cases to add just like statistics, they can create other drafts for this. I think that was my last slide. Yeah.

[00:45:50] **Job Snijders**: Oh, because in the lower right button, it says page 13 of 17, and I was like, oh, you're you're still at 30% to go.

[00:45:58] **Narasimha Prasad**: Well, that was because I have some backup slides. Oh, I see. Wants to read it offline. Yeah. Yeah. I'll just Nice. Yeah. All these additional

[00:46:04] **Job Snijders**: Perfect timing. Yeah. Good job. Alright. Question from the audience.

[00:46:11] **Nanning**: Hello. From Huawei. Okay. Common. I think it's reasonable that we can have a common BGP event reporting framework. And maybe we can have some coordinations because the generic event notification draft shares, and one of my drafts share some similar ideas. Maybe we can have offline discussion. Thank you.

[00:46:42] **Maria Matejka**: Maria from BIRD, I have a quick question. Should I review all your drafts now to check whether it's implementable in BIRD, or should I wait until it's until it's inside the group?

[00:46:56] **Narasimha Prasad**: What's preferred? I mean, I would prefer some early feedback so that we are more prepared before the working group or option. So if it's okay with you, I would request you

[00:47:04] **Maria Matejka**: to Okay. You're gonna put it higher on my queue. Thank you. Thank you.

[00:47:11] **Job Snijders**: Alright. Thank you. Thank you so much. Next up is Maria with RouteSurfer NextHop translation. And Let's get away from BMP for

[00:47:26] **Maria Matejka**: a while. From

[00:47:27] **Job Snijders**: Dutch to English or what kind of translation?

[00:47:31] **Maria Matejka**: Hello. Holy holy clicker. Yeah. Okay. This is a a follow-up on RFC eight nine fifty, which if you if you are deploying on a single on a single link, it's completely okay. You can just unnumber the unnumber the IP for just from the link. But whenever you happen to to run it on route server, you find out that whenever you wanna unnumber one client, you have a problem because nobody else who is not who is not supporting RFC eight nine fifty can ever see can ever see the route. They will never get it, and they will never reach you. So unless you do a quick one shot one shot translate transition from from nothing to everybody, you are stuck and you have no motivation for actually for actually running running RFC eighty nine fifty in a on a route server at all. I summarized here that you can have legacy speakers who have no support for RFC eighty nine fifty, and then you have supporting speakers. You actually have it and who could actually receive and send legacy prefixes with I p v six next hops. But the problem begins when you get the the prefixes and you wanna send them to somebody who doesn't support them. You have a problem. They will you will you won't even send them. And if you send them, it's malformed. So no easy way from that. So we need a transitional mechanism if we wanna if we wanna go for route servers, which eventually lose all the IPv4 addresses and go IPv6 only. There is one the the easiest way is the physical proxy way. You just set set up completely different complete separate two domains. One domain has legacy addresses with legacy legacy next hops. The other domain has also legacy prefixes, but with with I p v six net hops. And then you have to set up a middle a middleware, a a middle node, actually does BGP to both route servers and behaves as a proxy. This has some problems, like you have to send the data to the proxy as is as can be seen here. There is one part doing the the legacy routing. The the other parts doing the same thing, but with r RFC eighty nine fifty. And then you set set at pass through the through the BGP proxy. You scrub the you scrub the next hops to itself, and the traffic runs through the BGP proxy. And if you have one switch, that link to this between the proxy and switch gets the traffic twice. Well, it's already deployed in some route servers, and it's allegedly working. But with the other authors, we decided that this doesn't scale. So another way is a virtual proxy. Instead of doing, like, a real proxy for the traffic, instead of it, you do you do, like, the same, but you set up a spoofer. And the spoofer is replying for to the ARPS and the NDs. Because if you look at the if you look at the schema, the clients which are called here BG and B, these clients actually don't need an IPv four address. They can have only an IPv six one, and it's enough to, like, virtually allocate them to to them. And everything else is done by by the BGP proxy, which spoofs the the ARP and sends the sends the actual information, sends the ARP reply instead of doing ND. This is all whole mess as as well because you are you are spoofing spoofing MAC addresses of different clients on your own network. This is kind of stupid, but it's all also working. There were some there were some experiments with this, but it it has some drawbacks as well. So what we are oh, I have closed the queue. We are we we have written the most part most of this draft is actually the mini proxy, which is the approach useful for for networks running EVPN under the under the under the peering network, peering wheel peering VLAN. And they are actually replying to ARPs and NDs on edges. As long as soon as you start doing this, you have our free and ND free network. And access switch can reply to all of to the legitimate questions, to legitimate r queries or n d queries on the on the to the to those machines. And they can actually choose whether whether they will have the the table or not. So the only thing the only thing remains, and it's that you have to translate the BGP next hop, which you receive between the I p v four and I p v six, which is what this draft is about. You are already registering the MAC address of every client. And, yes, you'll still need an I p v four address assigned to every client. But with this technique, you can actually renumber your if you as long as your your IPv four addresses are enough, you you are okay. You can you can stick with them. And when you are running away of running out of IPv four addresses, instead of asking for bigger allocation or buying new buying new bulk, you can you can go and decide with each which with each client into which block this is going to be re renumbered. And then if they don't like eighty nine fifty if they if they do eighty nine fifty, you are okay. You can you can gradually gradually renumber everybody to not renumber. Convert everybody to r p RFC eighty nine fifty, and those remaining five networks who need the IPV for next hops can get IPV for next hops from, let's say, 10 slash eight or one twin one ninety two, one sixty eight, whatever, from RFC nineteen eighteen or from the shared space, whatever you decide with them. And this draft specifies that you can you can do it actually for each each client separately because the translation is happening on the site which is facing the client. So you can do it, like, individually for each client, and you can do you can do gradual gradual remembering. Originally, in this draft, there was a request to create to to allocate a piece of class in class e addresses for for this purpose. I dropped this with my with my colleagues from this one because we found out that it was it was not crucial for this draft. And we are going to resubmit this probably into into the into the into area working group because it's more like general and it doesn't it doesn't necessarily apply all network servers. And, yeah, this is how the how the Edge Mini Proxy actually works. The the red part, there is no legend. Why? The red part is traffic. The blue part is is BGP, and the BGP is translated translated when it comes from the I p v four from the legacy part. It's translated to I p v six next hops and then back to I p v four next hops whenever it's sent to somebody who doesn't like I p v six in the next hops. And that's basically all of this. We think that the draft is basically done from ours from our perspective. We think it's it fits the working group purpose. We have we are we already can configure this with BIRD, so that is technically an implementation. We are going to look into other implementations whether they are capable of doing this. And we'd like to ask you whether this is something which is which is worth the working group. We'd like to request the working group option mostly because there is already an RFC which says which says that you should not no. You you must not rewrite the next hop. This is technically an update to that RFC, which says you must not rewrite it. And this says, well, you can actually rewrite it if you wanna do I p v four to I p v six and back. And that's it from my from my side. Questions, please.

[00:56:48] **Job Snijders**: How do I get in the queue?

[00:56:52] **Tobias Fiebig**: So to be a serious to you, Vin. I just wanted to express my motivation for this draft and to work on this. So I would be very happy if the working group would decide to adopt this. And I believe that this is a good path forward to get v four out of IXs where it can be annoying, especially for remembering. Thank you.

[00:57:22] **Job Snijders**: Job Snyder's, are you sure grow is the best working group for this? Because the the the route server specification was done in IDR. This seems like you're fiddling with with some protocol internals. I mean, I I I'm let me let me first say, like, this is interesting work. Let's find a good place for it to progress it. That that is where I'm coming from. So, Jeff yeah.

[00:57:55] **Maria Matejka**: I was sorry. Okay. I was living in a I I was thinking that this was some parts of the route servers were done here. But if I am if I am wrong that parts of our route servers were done here, I may have read wrong.

[00:58:08] **Jeff Haas**: No. And so that your memory is correct. The route server document was finalized here. It was from a long series of work that had been done before. So in terms of where it goes, it can go here perfectly fine. The thing that I would maybe challenge you for is thinking is you have a very specific use case towards route servers. This is a good thing. You had mentioned as examples of the VPN type work. If you find that this ends up being, you know, consultation with other people, this is more generic. Let's move it to, you know, a different group than grow since it's outside route server at that point.

[00:58:40] **Job Snijders**: So so you're saying the route server spec started as an IDR document, became a grow document?

[00:58:46] **Jeff Haas**: It started here, and the document actually started at nineteen ninety something as route servers were used what you act as part of building the Internet. Alright.

[00:58:55] **Job Snijders**: Well, we'll we'll confirm where this should go, and then yeah. Yep. And any other so aside from the procedures, any other feedback on the substance of this draft?

[00:59:12] **Jeff Haas**: So for route servers, this is obviously a useful thing for some specific edge circumstances as you're saying. So, you know, for what route servers are being deployed for, this is great. For other circumstances, my personal experiences, you know, things like EVPN and other things already have the other related features tied in. So this is more of an edge type scenario for that. The place that this might be a interesting scenario for is, honestly, for the service provider crowd, you know, so getting some grow feedback on that respect about, well, what if your remote device doesn't support that? My gut feel from this is that at the service provider edge, this is typically done through static configuration and tunneling. So this is not a general problem for them. So I think I think we're sort of grind grinding the edge cases down to, you know, the route service is really the only place that this is important.

[01:00:05] **Maria Matejka**: Yeah. I was like, I don't I don't have any other use case for this, but the route servers I are hit by this. So so it's specified for route servers. Anybody finds anything else that's useful for that it's that this is useful for, please come to me. Tell me. Thank you.

[01:00:23] **Job Snijders**: Thank you so much, Maria. Next up, Martin Pels dialing in remotely from The Netherlands.

[01:00:34] **Martin Pels**: Hello. Am I audible?

[01:00:42] **Job Snijders**: Martin, I have the clicker here.

[01:00:49] **Martin Pels**: Just throw it.

[01:00:51] **Job Snijders**: You sound a little bit muffled. I don't know which microphone can you repeat the sentence?

[01:01:04] **Paolo Lucenti**: Please be patient.

[01:01:07] **Job Snijders**: I am very patient.

[01:01:08] **Martin Pels**: Is this better?

[01:01:10] **Thomas Graf**: Yes. Thank you.

[01:01:13] **Paolo Lucenti**: And, Martin, you have the control of the slides. So

[01:01:16] **Martin Pels**: Yes. But I do not see my own slides.

[01:01:26] **Paolo Lucenti**: Network.

[01:01:27] **Martin Pels**: I still have Maria's slides here.

[01:01:29] **Job Snijders**: Yeah. I think you need to launch Martin's slides and then hand the control to him.

[01:01:34] **Martin Pels**: Oh, wait. Maybe I can do that here.

[01:01:37] **Job Snijders**: Yeah. And let me click harder.

[01:01:40] **Martin Pels**: There we go. Yes. So sorry for not being, in the room with you. This is a young data model for BGP communities updates. So very quickly, what we're trying to do is operators want to publish how they are using a BGP communities in their network and the local defined fields in them, they can publish that in JSON or CBOR, and, then parsers and looking glasses, for example, can download these JSON files and, look at communities on the wire and derive meaning from them based on what's in the JSON. So the changes since the last time I was up here, the model has been restructured a bit to support augmenting, other Yang modules. I'll go into that in a bit. And, we've added an RPKI based discovery mechanism. So first, the augmentation. So the module has been restructured so that each BGP community description is a separate grouping, and that way you can attach it to, BGP communities in other modules. For example, IETf BGP module. And there's an augmentation to that module. An example augmentation module is in the draft to demonstrate this. And the next point is RPKI based discovery. So the purpose of that is you want to know if a certain network publishes, community definitions for their, communities. For that, Job Snijders helped out with defining a new RPKI object type, a community definition reference, CDR. Ayana has provided early registration of, code points for this, and, Job wrote a proof of concept for publishing an object and, validating it in RPKI client. So the RPKI object looks like this. We have a a version which defaults to zero. We have an AS ID, which is the autonomous system ID of the network that is publishing the community definition. Then we have the yang revision of the yang model that the JSON is using. And then we have a location, which, is an HTTPS URI pointing to a JSON file on a web server somewhere that the operator chooses. Then parsers can, download this object, download to JSON, and they, match the autonomous system ID in the JSON to the ASID in this object to make sure that they're looking at the right thing, and then they can use these definitions from the JSON file. So there are a few more open issues. So currently, the descriptions for a BGP community subfields can be either a simple string or the value of the, actual fields. And now Maria is working on a draft in IDR to standardize how to display communities and, other BGP attributes, And she's looking into using this module as well for that work, and she identified a few improvements. So for displaying, the the important one was, one bit flags. So if you have a community with many different flags, that are just a simple, one bit things, then it's a bit convoluted to, to handle that in the current module. And, the second improvement she, came up with was mapping tables. The idea of that is, is, first of all, within a JSON, you could have a mapping table for, for example, country codes, and you refer to that one mapping table from multiple community definitions. That would help be helpful to save some memory. And another idea is, to have a a mapping pointing to, some IANA registered values, so that we can have mapping tables that are shared between community definitions from different ASNs. So that's still ongoing. And then the other open thing is that I would really welcome, more implementations, especially on the partner side, either standalone or as part of, something like IATf-bgp or other Yang modules, and other open implementations, RPKI publishing and validation, because we only have the one implementation by Job at the moment, so, more interoperability testing would be useful there. And that is all I had to share. Any questions? I see Luke in the queue.

[01:08:00] **Luuk Hendriks**: Luke Henrichs. Hi, Martin. A question. Maybe I missed it, from the last version of the document, but about the CDR. So we're now able to get this all the way into the RP software. Right? Now how do I get it from the RP software into my software, so to speak? So far, this was an RTR thing. Right? If I ever needed something something from RP, I'm not sure whether this will be a thing that we should put in RTR. Maybe this is out of scope for this draft to begin with, but do you have any thoughts on this?

[01:08:39] **Martin Pels**: Yop, you wanted to comment on that?

[01:08:42] **Job Snijders**: Yes, sir. There is more in the universe than RTR. And what I envision for RPKI clients is it it discovers the CDRs in the global repositories. RPI clients spits out validated payloads in adjacent formats. And this JSON format contains ROA information, ASPA, speech, Psec keys, and will contain CDRs. So the likes of pmacct and Rotonda slurp in the CDR sorry, slurp in this RPKI client generated JSON and and can do post processing. Maybe in some future version, an RTR extension makes sense if routers can use the the information in some way, but but that is not this draft. So no RCR extension. Just just do it in the your any any API endpoints you feel comfortable with. So I hear a second implementation is coming. No commitments?

[01:10:02] **Paolo Lucenti**: Right. Thanks, Martin. And next up, I think, is Luke. We are a little bit behind time. So, Luke, we are going to Yeah. Allocate you eight minutes. Okay.

[01:10:26] **Luuk Hendriks**: Yep. Yes. Okay. Back to BMP. During the hackathon, Colin and I tried to write some codes for documents we've been working on, namely the one where we try to put BMP stuff into MRT. And the stuff that we then want to put in, that should be BNP snapshots, another draft we've been working on. I will do a short recap of that in a few slides. Because this should be doable in, like, one and a half day, but, you know, then we realized, oh, yeah. Then we also have to actually do, you know, this full BMP version four stuff. But, you know, let's get cracking. So short recap, BMP snapshots, that's basically a mechanism to tie together a bunch of existing bmp messages, preceded by a new message type, namely a snapshot message and a TLV with an ID that ties all these messages together so we have a grouping of messages. Now, we reuse existing BMP messages so you can use this on the wire, from a router to a station, from a station to another station. But, you know, for this hackathon, we focus on the storing this to persistent storage. Okay. Start coding. MRT, let's open up the draft. Look at look at the common header wire formats, 32 bit time stamps. Oh, no. Scroll a bit further down. So this is basically your twenty thirty eight's problem. We did the math. We can't retire before then, so we somehow have to fix this. And, basically, the text also says, yeah, we know we know this is a problem, but this is a problem for future you. So here we are. We started thinking about how can we then actually fix this in a somewhat nice way. MRT is extensible, extendable. We can define new record types, but how are we gonna do this? Are we gonna come up with a, like, an extended time stamp records that we then put in front of every other MRT record that then contains our messages? Yeah. Sure. That, you know, that might work. But what if you split the file? Because then you have to split on, like, you know, an an an even record number or whatever. And and and what's next? Because there will be another thing. Right? So are we gonna make a generic extended TLV kind of thing? I mean I mean, it fits in the working group, but this is a rabbit hole. We don't wanna go there. Right? In typical hackathon fashion, we were doing more talking than coding. And shout out to. He he joined our table, and we started chatting about this pcap NG thing. I guess we all know pcap. Pcap NG is a very much more generic way of storing messages or basically whatever blocks of information. This is IETf work. The registration of link types is also will also become an process. So this nicely fits into, our basic ITF way of working. And if we could actually put the BMP messages in there, Wireshark has proper p cap NG support. I mean, it basically came from the Wireshark people. So if this works, we can leverage things in Wireshark like they're the sectors and they're filtering. All good stuff. So we decided to divert from the original plan. We need a custom data link type. If you know pcap, you're typically thinking of the ethernet link type, right, where there is your Ethernet frame, and then there is some IP, and there is some layer four, yada yada. Maybe you have used it for eight zero two dot eleven Wi Fi stuff, but you can define your own custom stuff. So you only have to put in your, in our case, BMP message. You don't have to worry about any other layers. And then, basically, you follow the p cap n g structure. You have to write out a small section header block, a description about the interface where you can put in some extra information, and then you can start writing message after message after message. And then it's really close to how we know MRT in their update style file. It's just messages in very simple MRT records one after another. So, again, this is really not a pcap as we, you know, usually know it for Ethernet type stuff. So visualized, what we did is we took a a bay BMP feed from route views, and we started hacking on Rotonda. Two, for every stream, start writing out this section header block, the interface description block with our chosen data link layer type. And then for every message that comes in, we oh, nope. First, of course, we write this snapshot message that's from one of these new drafts in an enhanced packet block, and we start converting all the BMP version three messages that come in, and we write them out with our snapshot TLV in these EPB blocks. You add the extension dot pcap n g, and for once, this actually worked. So this is a screenshot of Wireshark where we opened up our generated file, and now we have our BMP messages altogether in this dot pcap n g. So these are some details on the on the actual data. I guess the most important thing here is that we put this stuff on the Wiki to share in different variations. So there is the pcap n g version. There's also just the the bare binary version if you don't wanna, you know, fool around with with with Wireshark, but just want to soak up this towards your collector. And for both of these file types, we have the one with the snapshot and also the one without the snapshot. So if you are not interested in pKeptNG and you are not interested in snapshots, there is one which is basically a BMP v four test data file. So that's on that on that wiki entry that still needs some love, but I hope that, you know, people start sharing other test data there as well because I think we can do with a bit more sharing of test data within the working group. So what's next? I think that we are more in favor of pursuing this dot pcap n g route for storing BMP messages than bolting it on to MRT. So, you know, we might even though we just revived the thing to sessions ago, meetings ago, we will come up with something new. And for the BMP offline draft, which is basically the BMP snapshot draft, we'll continue experimenting with now the running codes and the test data and update the documents accordingly. And who knows for in the future? We already have some ideas where we can maybe fix this problem in a a more broader sense and start to store MRT records in a pKeep-NG fashion that is useful for, say, the the larger collector projects like without breaking all their historical collected data. But that's for another day. And with thirty nine seconds left, I hope I made up some time. Thank you.

[01:18:20] **Tobias Fiebig**: Thank you. Please.

[01:18:24] **Alexander Azimov**: Alexander. Remember the old days when I was having a lot of fun trying to convert MAT format to something readable. I wonder why you are trying to convert the MP data that's normally is readable to back to MIT format. Okay. This slide makes me less anxious, of course. But, anyway, so what was the foundation of your approach? So why do you want MIT back?

[01:19:02] **Luuk Hendriks**: I never said I want MIT back. MIT was given to me. I I mean, I was I I was I was the first, you know, to say a couple years back when we started the new code base, like, you know, let's do something different slash better than than MRT. But MRT is here, and it's, I guess, here to stay for a few more years. So this is an attempt to, you know, slowly make things better. For some context, what we were trying to do is is get a better variant of the MRT update style of files. Right? So this is not the, like, the b view or the full dump kind of thing. For the BMP snapshot draft, we envisioned we could leverage what's in that snapshot draft, and then we have enough information in the messages itself to use the update style MRT files to get some state in there. I mean, this is a hard sentence also to, you know, to say out loud. But so we could do with an MRT updates style file. But because the MRT record type is is is not optimal, the closest thing would be the pcap NG file. We get some tooling for free around it, but it's not replacing MRT altogether because for that, I agree, we need we need something that is radically different. Right? Jason Zip. Jason?

[01:20:33] **Alexander Azimov**: Okay. Thank you.

[01:20:39] **Paolo Lucenti**: Thank you, Luke. And we want. Sure. You also have eight minutes.

[01:20:54] **Camilo Cardona**: Okay. Sorry.

[01:20:55] **Shuang**: So hello, everyone. I'm from laboratory. So today, I'll be talking about the our first version of the drafts, the requirements for monitoring API related processes on routers using BMP. A little recap of our previous drafts. We have divided all the processes on the routers into four stages, and the namely, first is to acquire a particular data, and second is how the router configure a particular policy. And for the third stage is how each route is validated, and force is to observe routing impacts. And for all the four stages, they have one correlated view is that the BMP should correlate what our data and policy existed with what happened to each PGP route. So in this in this version, I have mainly made four design changes. The first the first changes that I have for previous concern, I proposed to proposed the five new BMP messages types. And, actually, each each each stage has one dedicated message type. And now in this new version, I have reduced them to three. And the following three the following three changes just come from the previous previous talk and advises in the mailing in the mailing list. And for the first one is the slam become a first class source and and policy item. And second, in this draft, optional CCR based data dataset identification is supported. And third, we have explicitly clarified the boundary between the BMP and the young telemetry telemetry boundary. So the main direction for this updates in in this version is we try to narrow down the responsibility and a smaller protocol service for BMP. So for the first chain for the first change, it's actually there is twofold. For the fur first one is we have I have combined the RPKI sauce and RPKI policy message type into a uniform RPKI config message type. And second, for the RPKI state message type, I have seen that there is already a newly published RFC that already defines the ROV states in the BMP rip state status, so we can just reuse this message type. And for our API config, the the data imports can be multiple, like, including the RTR, DGP, and static configurations. However, the SLAM may also change the validation dataset. So, we propose that BMP should also report the addition and removals from from the slums. So the RPKI config should report not only the source type, availability, report counts, but also the up at the time arrows, data center identity, and for the dataset identity because there may be multiple versions of dataset. The CCR could be used to identify the dataset. And here, I want clarify the the difference between the BMP and the YAM's streaming telemetry. They are at the same stage but different observation levels. For the streaming telemetry, it is it operates at the device level to to report the troubleshooting information, including the RDR session information and cache synchronizations. And for b m and for BMP alone, it should focus on the routing routing context, which means what what data was actually available and used for validation. And here's an example for if the if there are two in this example, there are two I think that caches that are used and primary cache is fail fails. So for the young telemetry, it will mainly focus on the failure details. And for BMP alone, it will for for BMP, it will look at when the failure happens, what what remains to be important for the validation process, which means the active source now, the effective data set, and the routing correlation. And here, I want additionally discuss another another problem, which is not strictly in the scope of the requirements, but is highly related, which is the implement the engineering implementation of of the of each b BMP message in at each stage. And here, I picked the API validation. For API validation, the BMP message should report not only the validation state, but also how the state how we finally come to the state. So here, we propose three tiers to our data model. For the first tier, it should report the the overall validation information. And for the second tier is the validation rule records, which corresponds to the summary of each course contributing rule. And for the third tier is just the the detailed context of each contributing rule. And for to realize such TLV model, there could be two options. For the for the for the first option, we can reuse the validation TLV in raw manners, and this could be easier to to prototype but may require duplicate reports whenever the dataset is whenever the eval validation dataset is changed. And another option is to just use a dedicated API validation message type. And finally, I want emphasize the last stage. It is not frequently discussed in previous talk, but this stage is also important because even if the very validate the the validation results are the same, it could the routes could be handled differently. It may be dropped, deep referenced, or only adjust tagged. So the API impact should report the policy action as well as the routing outcomes based on the validation results. So for for our next plan, we plan to further stabilize the requirements, and I plan to raise a new companion solution draft, specifically focus on the engineering implementation of the message type. And that's all. So Thank you.

[01:28:17] **Maria Matejka**: This is Maria from BERT. I'd like to note that this gathering all of this data would require to speculatively speculatively execute parts of the parts of the policies after the after the decision is taken because the RPKI the RPKI decision is not necessarily the last decision to be made before dropping the route or whatever. Yeah. Yeah. So what you are basically imposing here is doing speculative execution on multiple multiple ways in the code all the way through after the best route selection, which happens possibly asynchronously after the after the route is after the route is received. So I would like to see either a lot of consideration of this or, better, a little bit of reduction of the scope because the amount of information you are requiring is, I would not say impossible together, but expensive.

[01:29:25] **Shuang**: Yeah. Okay. Thank you.

[01:29:32] **Nanning**: Hello. From Huawei. Personally, I think the reported information in your draft may belong to a kind of reported events. So, you know, there are some other proposals in the working group that to propose some new BMP messages to report routing events or some configuration events and some other events. So my opinion is that the wider we can consider the event reporting designs or VMP extensions together. In the draft, maybe three new messages will be dis defined, and the other drafts are more some other types of messages are defined. So maybe we can consider the designs together. That's my opinion. Thank you. Okay. Thank you.

[01:30:32] **Paolo Lucenti**: Makes sense. I echo his comment and comment. Okay. Thank you so much. Tobias. Tobias, you are going to have fifteen minutes. One five. One five.

[01:30:51] **Tobias Fiebig**: I'll get cut by a quarter and then 20%.

[01:30:56] **Job Snijders**: Inflation. Well, let's see how it goes.

[01:30:59] **Tobias Fiebig**: Yeah. Getting mixed messages from the chairs there. I saw that looking glasses were in scope of the working group, but one is missing them.

[01:31:12] **Job Snijders**: So

[01:31:15] **Tobias Fiebig**: welcome, everyone. We're gonna do what we are doing every single time when we do grow at an ITF meeting except for last time. We're gonna talk about draft-, -itf- grow-, -bgp-, -upsec update and the accompanying drafts. So good news is that the first document has already passed working group last call, but we have two more to go, which roughly have 10 times as many pages. So overview of the document status. The main one, the replacement for b c P 194, has passed working group last call, but it is waiting for the two other documents to also do so, which the chairs informed me about at the beginning of this meeting. The second one, which is informal collection of options, methods, and things you can do to actually keep your routing secure, hope being that if we make this an informational document and not a BCP, it's easier to update in the future and doesn't go stale as quickly. It's making good progress, relatively complete. I see this go towards a working group last call in the next couple of months. And then there's also a terms document, which is thought to be something like what the DNS people are doing, but not as authoritative as what the DNS people are doing, kind of trying to find our common language that that has some more progress but still has some larger major organizational needs which have to be implemented. And as I see the room being way more full than in previous meetings, PRs are very much welcome. So as I said, for the OpsEC update document, the working group last call has been closed. We are technically waiting for the Shepard write up, and I assume that that will be a bit out because the chairs are currently waiting to start the IETf last call until the other two documents are also going through working group last call, which kind of makes sense because one of the first feedbacks one usually gets for the first document is we would like to have all the things that are purposefully in the other documents in this document as well. At the hackathon, I don't know whether you noticed. Sometimes rooms in this hotel tend to get a bit full. We were facing something similar. So we sat together with Jeff on Saturday, not in the hackathon room, but in a room next door. Still hope that the hackathon chairs are not unhappy that we didn't take a presentation slot. We had one further contributor at the hackathon who made a pass over the terms document and added a couple of terms and a spell check. And I believe, overall, we are looking forward to kind of okay progress there over that weekend. We still need feedback though, because what we essentially started is Jeff, who I could also motivate to become a co author, based on the amount of feedback and lines he has contributed so far, has started his full pass, which got over the course of the hackathon until section seven. And keep in mind, this is a roughly 50 page document. We need more people to do the very same thing. I don't know whether you remember the first document that had, I think, five pages or six, and I have been asking for, like, three ITFs in a row whether anyone hasn't read it. I would like to avoid that with that one, especially during working group last call. So if you have the time, go through that document, find things which need improvement, and send PRs. The draft ITF CIDR ops avoid RPKI state in BGP is no longer expired. This was solved by it now being in the editor queue, which also is helpful, we could just update the reference there. And what we still also have to do is align the terminology we're using in the informational document with the, terms document. So terms, for the terms document, we got one PR with a lot of spell checking because, apparently, I was talking about a lot of divers which were involved with BGP, like the snorkeling type. But I learned that the Great Barrier Reef is not in Austria. Anyway, that document needs further additions, and I'm kind of hoping on all of you to contribute these. Like, every single term counts. And if anyone feels particularly interested in having opinions on the sorting of this, especially what we do with the three letter acronyms and the definitions. Do we leave them mixed up or do we clearly separate them? I want to hear opinions on that. So let's quickly recall the original plan for these documents. What we wanted is we wanted to update slash replace hundred ninety four, so r c, 07/04/1954, if I recall that correctly. It should be short enough for policymakers to be able to read it. It should be generic enough to be resilient to specific terminology changing, So a little bit like policy documents in our IRs. It should be testable independent of the implementation and it should be published quick enough to prevent harm. So we wanted to get this out in months, not years. I think that was at hundred seventeen?

[01:36:51] **Job Snijders**: It was a few years ago.

[01:36:52] **Tobias Fiebig**: Good. Good. Just just wanted to make sure because my memory with age gets worse. So what we managed to do is we split out the individual x from that rather big basket. We have the one document which does policy. We have one document which, provides, well, kind of informal guidance and one on terminology. What we did not accomplish is be quick. So discussion points for now because as you might have noticed, I did not really use that much time because usually, there's not a lot of input over the course between ITFs. So I always try to get the people to, provide input when they can't run away. You might see people blocking the doors. That's what we're gonna do the remaining nine minutes of this. So for the informational document, read it. You can start now if you want, but ideally within the next week. This needs more eyes and more PRs. For the terms document, pull requests are very much welcome. If there's something missing which you want to see in there, either drop a line like, please add this, then I'm happy to add that, or if you want to make me especially happy, send a PR where you have added that term. And, for the last one, so I heard about the plan of the chairs to wait for these other two documents. I can kind of see that going forward, but I would like to hear what the working group thinks about that as well. So thank you. And, please, before we leave, let's talk about this. And if nobody wants to talk about this, can also just replace BGP with an alternate method of Internet communication. I mean, that's that that's also on the table. We have

[01:38:53] **Jeff Haas**: EGP. We have EGP.

[01:38:56] **Tobias Fiebig**: We can go back to EGP. That's a good idea. And there are the MyQ fields.

[01:39:03] **Alexander Azimov**: Yeah. Alexander. Small comment related to the first no. Not first. I think first document. Yeah. The last one. It says industry options. It's speaks about altering BGP routes in one of its sections, and it mentions origin. And during this meeting, it was already discussed that origin it looks like we we should respitify what we are doing with origin. So I suggest to synchronize with people who are eager to put their hands in all these old attribute and its use cases.

[01:39:45] **Tobias Fiebig**: Yeah. That that that's why we added Jeff as a co author. Okay. So I think we stick with the agreement that everyone who doesn't walk to the mic volunteers as a core editor. Yep. Yep. Yep. Yep. Good. I'm I'm I'm happy to see that much enthusiasm. And I think your time is then back in what it should be. Right?

[01:40:10] **Camilo Cardona**: Almost. Almost. Thank you.

[01:40:12] **Paolo Lucenti**: Thank you.

[01:40:13] **Camilo Cardona**: Thank you, Bob. And

[01:40:18] **Paolo Lucenti**: we have. And

[01:40:28] **Job Snijders**: the holy clicker is missing.

[01:40:30] **Tobias Fiebig**: Oh.

[01:40:32] **Job Snijders**: You would have download a clicker.

[01:40:42] **Paolo Lucenti**: And, Nani, you will also have eight minutes.

[01:40:44] **Nanning**: Okay. That's fine.

[01:40:46] **Paolo Lucenti**: Thank you.

[01:40:46] **Shuang**: Thank you.

[01:40:49] **Nanning**: Good afternoon. Hello, everyone. I'm from Huawei. I will present the main updates to the draft on behalf of the. In the draft, we propose to report some routine events of BGP flow spec and BGP SR policies to the monitors. Okay. In the last IETf meeting, I presented this draft and the received some comments from the working group. Thanks for the people who gave our comments. And the first is from Jeff. It's about UTF-eight text strings. In the draft, in the our older version of the draft, we use local action to carry the reported routing events. And one bad code point is followed with UTF-eight string. This string can be used to provide additional information for the to the operator operators. And I had a offline chat with last weekend and confirmed the comment. And finally, in the latest version of the draft, the UTF-eight string has been removed from the log action so that to avoid the difficulty to of passing and interpreting this field. And, we will also consider whether we need to add some other structured data in the. And now another comment is is about selecting routing events. Thanks for the comment. We've already noticed that it's left in the minis of grow working group meeting. In the draft, we reported the routing events, and that it's events are related to next hops. But when the network is unstable, the next hops may change dynamically, and there may need many routing events need to be reported to the station. So we have added some taxes in the operational section. Particularly, mitigation measures should be deployed for both the device side and the monitoring side. We also expanded the BGP SR policy routing events extensions. In the worst draft of version zero, there is only one routing event of ASR policy reported that is invalid candidate pass. And in the latest version, two more routing events are defend that is invalid segment list, and the other is exceeded spec limit. We so so section of operational considerations was rewritten. We'll provide more details regarding to both the device side and the collector side or the monitoring side. Particularly, the device should need to report the routing events upon the corresponding routing events occur. And the devices can also selectively to route repository routine events when the network is unstable, and that this is curse corresponding to the second comment mentioned earlier. And some other details can be found in the draft. We added a request allocation request in the last version. This section is to be done. And in this this version of the draft, we have explicitly point all that. We have INR requests. We also added Yu Jiago as one of the co authors. She comes from laboratory. We added this draft together. Okay. That's all. Thank you. Comments are welcome.

[01:45:17] **Paolo Lucenti**: I I have myself one comment. I've read draft. It makes sense, like, also how it is, you know, nested in inside the RAN framework. So my comment was just about the title of the draft. Like,

[01:45:32] **Luuk Hendriks**: it seems Okay.

[01:45:33] **Paolo Lucenti**: You know, it seems very generic, like log more routing events in BGP monitoring protocol, whereas you focus on SR and flow spec. I wanted to see maybe a more fitting title for the document. And

[01:45:49] **Nanning**: yeah. Okay. Thank you. Yep. We will fix that in the next version of the draft.

[01:45:55] **Maxime**: Thank you.

[01:45:55] **Tobias Fiebig**: Thank you. Thank you.

[01:46:01] **Luuk Hendriks**: Thank you.

[01:46:03] **Job Snijders**: Thank you for not stealing the clicker like Tobias does.

[01:46:09] **Paolo Lucenti**: Did you see that? I saw I saw that. I saw that. I saw that. It it was close. It was close enough.

[01:46:18] **Martin Pels**: There you go.

[01:46:27] **China Unicom Representative**: K. Hi, everyone. From China Unicom. Today, on behalf of my team to introduce the draft BMP extension for configuration monitoring TLV. First, I will introduce the this document to find two types of bmp extension TLVs. The first is configuration message TLV, carries configuration information associated with BGP routing changes. And the the second is time tab TLP, which includes the configuration summation, time tab, and the configuration activity activation timestamp. This extension enable BGP monitoring platforms to correlate BGP events with configuration changes, improving fault localization and troubleshooting for configuration induced routine issues. And here, we gave two simple use cases. The first is a survive configuration conflict with existing network configuration. A new VPN binding was aided to the base station management to look back interface. It conflicted with the existing settings causing preview router to be withdraw through BGP and all base station to go offline. Without BGP configuration change data, operators had to test the course of the fail fail. And the the second case is IB overflow failed caused by relaxed import router failed policy. A relaxed import policy caused continued RIB groups. Months later, the numbers of user exceeded the device capacity causing FIB programming failures, unstable BGP seasons, and the surprise outage. With the configuration data in BNB, the monitoring platform could link the route in inquiries to the earlier policy change and identify the course more quickly. And the next is show the BMP extended TLVs. The first is a configuration message TLV in the including type configuration ID, configuration source, and the reserved field. And the the second is temp tab TLV. It's including configuration sum summation timestamp and configure effective timestamp. And next is a scope of application of BMP message type. The BMP TLVs defined in this document can be included in the following BMP message type. The first is appear up notification. The second is tear down note notification, and the third is route monitoring message, and the the fourth is route event loading message. And next, we welcome your comment and suggestion to help improve the draft. Thank you.

[01:50:16] **Narasimha Prasad**: Hi. This is Prasadj from Cisco. I just had a quick comment that maybe we should look at the generic event draft and maybe the RHEL draft, see if the they have the framework for you Okay. To sort of build on that for your use case.

[01:50:35] **China Unicom Representative**: Okay.

[01:50:35] **Narasimha Prasad**: I think otherwise, it's gonna explode. We will have so many different use cases, everybody defining their own TLVs. Okay. So maybe we should look at helping improving RHEL and GEN as a framework and then build your use cases on top of that, perhaps.

[01:50:52] **China Unicom Representative**: Okay. Okay. Thank you. I'll copy it.

[01:50:55] **Luuk Hendriks**: Yeah.

[01:50:57] **Paolo Lucenti**: And similarly to Prasad comment, I had also the comment that the timestamp TLV is already defined in the d m p v four draft. So I was just not clear if you were extending that with some other code points or whether you were redefining it. Right? Because that also, that one applies to all the BMP messages. So

[01:51:24] **China Unicom Representative**: Okay. We will consider about it.

[01:51:27] **Camilo Cardona**: Mhmm. Okay.

[01:51:28] **Tobias Fiebig**: You. Thank you. Thank

[01:51:31] **Job Snijders**: you so much. Alright. We're at the last presentation. By Maxine.

[01:51:47] **Maxime**: Is that Maxine's.

[01:51:49] **Job Snijders**: Oh, good. That's pretty pretty close.

[01:51:51] **Camilo Cardona**: Almost almost.

[01:51:55] **Job Snijders**: Yeah. Request to the working group to keep an open mind to this presentation. Okay.

[01:52:04] **Maxime**: Thank you for the advertisement. I'm gonna add that I know that grow- not be the best booking group for the this work, but it technically fits the charter. And we can take it offline if you want to discuss somewhere else. So motivations. The idea is to do path validation in a different way. And why a new protocol when a spy is nearing adoption in the side drop swagging group? Because we in PAVA, we do some things with prefix dependent other validations, which means that we can do fine tuning of relationships, especially non Gau-rexfos compliant relationships that are complex relationships. Also, this it's an independent system from the RPKI for doing I'm gonna explain after. So for doing the the the querying, so we keep the information close closer to the AIS. There's no need to constantly go through I r IRRRLs to update information and or to have your own repository. And we catch all past forgeries contrary to ASPA in the way that Astra does it. So the idea is that we have two parts, a DNS querying to get the information and path verifications. The highlights. SURPARVA

[01:53:45] **Tobias Fiebig**: is

[01:53:45] **Maxime**: meant to be run on the dedicated server and not on the routers, not to add load on it. It's done asynchronously, so DNS operations are not directly affected by the protocol. It is complementary to ASPA, so both can be used. And it's even we even get more information when both are used. So it's interesting in that sense. And it should not take precedence over ASPA because it's like a a different way of doing things. And also, and just as a note, the querying uses DNS, but it could be added to a different or similar system that is to be questioned or commented in the future. So the querying goes by cutting the AS path that we received here at a a s six received the BGP update from AES-one for the prefix 1.1 and slash 16. And so the AES path would be here five thousand seven twenty one, and we cut it into segments that overlap of three ASs, which each AS in the path at the middle of the segment. And this can form DNS query that is sent to the DNS server operated by HAS that will ask for this specific prefix and this specific segment if it is it seems valid from the point of view of the AS. The AS then are re will I mean, DNS server will answer one status among up, down, submit, or error. I'm gonna describe right after. And the servers are not giving an answer. Then we give them an unknown status, which will be skipped in verification. And so, like, here, we get a few the answers corresponding previously to the past segments given. I'm going okay. So the different statuses are summit, which is like when we have, like, a customer to provider and peer to peer then link and our customer to provider and provider to customer. So like the up of a of a link. The up status is when the segment was customer to provider, then customer to provider. Down is provider to customer, then provider to customer, or with the provider to customer after a peer to peer segment, an error in any other configuration or if the AES path just doesn't exist from the point of view of the AES. Then after getting the list of of status, we can run the verification. So through the finite stage machine that in the end results in a similar idea to what is done in ASPA. So going up the list of providers and then going down, and and that's basically it. But like unlike, as far, we can verify small chain parts in the middle of the path and adjust from the extremities of it. Also, so as I said before, covers Astra concerns and past forgeries that are covered in Astra. So it does like both the work of ASPA and Astra. And information doesn't have to be print downloaded because it's done off off-site. And we have DNS SEC on the on the queries to guarantee that authenticity. And what's next? So, like, the idea is to see if it sparks any community interest and then to compete to keep refining the draft as there are still stuff to do and lot of precisions to be made. Welcome contributions if anyone's interested in the work and maybe implementations down the line. If you have any question, comments.

[01:58:35] **Job Snijders**: Yeah. We have some a few minutes left for questions or comments.

[01:58:44] **China Unicom Representative**: Oh.

[01:58:46] **Job Snijders**: Did it run out of juice?

[01:58:48] **Nanning**: No battery.

[01:58:48] **Job Snijders**: No battery. Yeah. Yep.

[01:58:54] **Jeff Haas**: Thanks. Making sure you're right. So, Jeff has thanks for the presentation. So I added a little bit of context into the chat. Back when we were doing this original cider work, you know, discussion about using DNS for this was one of the things. So I'd recommend looking at the archives. A thing that has changed since then is DNSSEC is deployable. That was not the case at the time. One way to characterize this is this is very similar to DNS black hole listing that you use for email. So I understand where you're getting some of the idea from. And having, been running a mail server for twenty years and knowing how painful that fails, I'd be worried about putting routing security stuff into BGP. Okay. That said, there's also a proposal, that is partially deployed for email called Dane, which is a generic mechanism. I realized that Dane's about the certificates, but it's also giving an idea about how to actually correlate services back. Maybe as part of your discussion into the next version, you know, talk about how that's comparable.

[01:59:56] **Maxime**: Yes. It could be a very I mean, I I looked at Dane and also it couldn't be, like, put into the draft and all. So

[02:00:04] **Jeff Haas**: yeah. Exactly.

[02:00:05] **Nanning**: Thank you. Yeah. From lab. Just a brief question. So does this draft assume this is a online DNS querying method? It means when receiving a BGP updates, it will always trigger DNS queries towards every triplet on the ES path. Have have you considered using some cache mechanisms such like DNS cache or validation result cache?

[02:00:35] **Maxime**: Or There can be DNS caching on the on the on the thing, especially if, like, a route is propagated. I mean, there are, like, probably a lot of ASs will ask about the same I mean, exactly the same question. So DNS caching can be done in that regard. And

[02:00:52] **Nanning**: Yeah. Yeah. I think there are some space to optimization, so we can have talk later maybe.

[02:00:58] **Maxime**: Yeah. Okay. Thank you.

[02:01:07] **Job Snijders**: Alright. The big shuffle of microphones. Thank you so much for your presentation. I suggest if people have other comments or questions, send an email. This brings us to the end of our

[02:01:21] **Paolo Lucenti**: On time.

[02:01:22] **Job Snijders**: Of ours yeah. We're we're on time. It's good. I would love to see all of you in San Francisco, if not there, Kuala Lumpur or online. Thank you so much for your time and interest in the global routing operations working group. See you soon.

[02:01:43] **Maria Matejka**: See you soon.

[02:01:46] **Maxime**: Kind of.

[02:01:47] **Luuk Hendriks**: Kind of. What happened? You you left them somewhere. You don't have to

[02:01:53] **Paolo Lucenti**: I I I sit on them.