Session Date/Time: 20 Jul 2026 14:30
[00:00:06] Susan Hares: You think there might be one. And Xiaohu Who did that even though we may find out that it's not really there. It's important to let us tell it about it. So I really appreciate him going that extra mile. Okay, guys. Come in. Close the door. The agenda's tight. Love to have you here. Just come in. We'll start. I think I'm at one. Okay. The agenda is really tight. Everybody look at Ketan and say, thank you, Ketan, because he got us three sessions, but we've managed to filAS Chem to the brim. Okay? And be very tight on this schedule. This schedule, as we walk through with so before we started, I went to the note well. I went to the importance of disclosing IPR. If you're coming in late, read the note well in the slides. If you are participating, you must disclose IPR. If you're discussing with someone, must disclose IPR. You must treat everyone else courteously. That's the basic read the note well. Okay. Our charter is approved. It was a really good charter and discussion. We have started grouping drafts and running drafts through the adoption and the pre adoption review process, the adoption, the working group and the working group last called by four groups core SR, SRT, BGPLS and FSP-two. I guess that's actually five groups. Today, we're going mostly core presentations. Friday first session is SR, SRTE and BGPLS. If you don't know what those things mean, SR means segment routing, SRTE means segment routing for traffic engineering, and BGPLS, you should know from the document. Okay. The second session is on flow spec V2. That was what we set in our agenda, but we had to do a little bit of arranging for people who asked us to squeeze them in in one place. The full status is at status. Is at the GitHub. We have not gone to a Wiki status. We've gone to GitHub, the chairs use daily to update status. So if you want to see it, there's the URL. You can review it. Okay. I'm going to go through a very brief status. There's more on the web. We go in the web through working group last call, adoption, early allocation, pending stuff. On the wiki, there are Shepard reports. Okay. Who's at the RFC editor? We added next draft- ITF-idr-nhc. We added VPN ORF and RFC 4760bis. Half of the 20 extension, the draft- first from SR policy on NRP and the draft- itf- bgp-ls-sr- EPE over L2vPN, and we have two in active AD review. Ketan is doing a really good job of keeping up or handing it off to Gunter. Gunter is also very effective in his reviews. Now, I am behind on Shepard's review, expect reviews in alAS Che non core areas during the week. So if your draft is a working group draft or a pending draft, I will send you a shepherd review that says, here's how you get to the next step. We are trying to run things as quickly as possible. Please pay attention to the list or to my email directly. Okay. Past working group call. BGP model. Jeff has a discussion. I won't go through that. SD WAN, there's just a few less tweaks on the Shepard report, but it's the documents done draft- ITF-idr- ts- flow spec SR policy. The authors sent in the revision just before the meeting, the Shepard- will go on. And then I have one you'll find a number of these drafts. I've got to go and see where Spring's current status is. And Alvaro and Joel and who's the third chair, guys? Bruno, right? Spring?
[00:05:34] Jeff Haas: Yes?
[00:05:34] Susan Hares: Yeah. Good. I didn't my brain didn't stop. That I'm reviewing that for the last CT draft. The BGP DMZ was one that had was in the IPR. There is if you have an empty seat next to you, raise your hand. Okay. There are still plenty of places. This is going to get tight, folks. So grab a seat soon. So good news is that Touhou went back and helped his lawyers find the right stuff. There's no IPR on the DMZ, I think, on that one as well. Yeah. So that's good news. I hope the best chairs are here. And derived community is a discussion. Should I do that at the end so we have plenty of time? We could save it. Now?
[00:06:26] Jeff Haas: SAVe it for later.
[00:06:27] Susan Hares: We'll do this. I sent out a message to the draft-idr- derived community. We're gonna do this last unless you wanted to do it now.
[00:06:36] Ketan Talaulikar: No. It was on the IPR thing. I would appreciate if Xiaohu sends an email on the IDR and best list confirming That that there is no
[00:06:46] Susan Hares: would be super. Do that. We miss anything else? Ketan's been very helpfuAS Co us. Okay. Link local. Okay, guys. If you're in the queue for draft, we really raise your hand if you have an empty seat, folks, next to you. There's a couple there. There's a couple there. Please. And there's one up here at front. I really do not like. The link local capabilities could still use a did you have something?
[00:07:19] Ketan Talaulikar: Sorry. I just just sorry to interrupt because this is IPR, and it's important. Can you clarify whether you have it on the best DMZ draft as well?
[00:07:30] Susan Hares: No. Yes. No. Not on the
[00:07:32] Ketan Talaulikar: do that on that email as well. Thank you.
[00:07:34] Susan Hares: Yes. So the draft idea or link local capability, it was finished a month ago, but we still could use some more comments. If you're interested in this, please comment because we get into these stuck modes. Draft utero was extending the adoption because I don't have an IPR statement from Binwin. Unless I get IPR statements, I can't close a working group adoption. Lutostanski inter-as-rtc inter AC is a very small draft. It's easy to read. Do us a favor. Take a look at it. We think it's something that's out there and we should standardize, but it needs more. The same is Varun's bgp-bestpath-selection-next-hop path selection, next-hop selection, and Bruno's draft on MRI handling. They're going to be discussed today. Please make comments. There were technically closing today, but we'lAS Cake comments all week. Okay. Core pending. Next, next-hop nodes, rtc-hierarchical-rr right r r which Jie is going to show some additional comments on that and draft RTC, no RT. And we deprecated a whole bunch of drafts. I'm running a little bit behind, guys. There are adoptions in process. We adopted one SR draft and I ran into a procedural error where I realized that we adopted draft-ali-idr-bgp-ls-sr-policy-path-segment-distribution. Love these names. We adopted it as a unique draft and then merged it with the other one, but I hadn't called an adoption for lin-idr-bgp-ls-sr-policy-admin-flags admin policy. If you get a chance, please comment. And we will start this week on an SR. Does it sound like we're doing a lot of work? I think we're doing okay. And then there are upcoming assignments. Now, this is important for everyone. Even I'm saying it now, even though we'll cover this in detail on the Friday sessions. Look, to help everybody get their code points effectively, even though the BGPLS is first come, first served. And I'm trying to work it through the working group to make sure we don't have any problems and then working with IANA to track down your code points. So if you've got a code point you want for your BGPLS draft, let me know and I'lAS Cry to help you. The same is true of SR drafts. Those I have to review and send forward. But we've been able to close last ITF's gap. We had four that were sitting out there that had sort of pseudo squatting on it, we've closed those. If you're looking for an SR draft code point and you've been a working group draft for a while, send me a note so I can try to help you go through that quickly. I've already gone through the rest, guys. I think I'm done. Okay. Did I miss anything you know of?
[00:11:03] Jeff Haas: Nope. I wilAS Cake the slide back. Okay. Then move. And index for the next two. If you could chat right here.
[00:11:13] Susan Hares: Oh, questions. Yep. It's so
[00:11:18] Jeff Haas: Put in
[00:11:19] Susan Hares: the chat.
[00:11:22] Jeff Haas: Okay. I will need you to swap this bites over for a bit in a second. Hi. I'm Jeff, and I'm gonna try to recover some of our time for the next two slides. So this will go very quick. So I'm here for this first set of things to present on, you know, two pieces, the b f d strict mode feature that I'm doing with Marissa, AC, and Albert Fu. And overlapping that is work that we've had to do about, you know, exposing the finite state machine points code points out to INF for maintenance. So very simple statement about what the problem is. You know, b f d and RFC fifty eight eighty says we do b f d. We have multi and single hop b f d if no formats, and we have a generic document fifty eight eighty two that now says, when you take things down, you know, we want the session to go down with it. It's less good about saying what to do when you bring the session up. And the side effect is we have interop problems across the vendors based on where they start BFT versus the BGP state machine. This has caused wedged sessions, so it's a real problem. So why does BGP care about up? Well, we depend on exactly where we start things. And very specifically, some implementations were not even starting BGP until BFT went up, some started b BGP first and then waited for BFT to go up. This is a recipe for deadlocks. You know, it's not a happy thing. We tend to see this in the field, when, a hold down mode is configured when, you know, we wanna actually make sure BFT is up for a stable period of time before you allow BGP to come up. You know, very simple problem description. Dev box, what do you do about that? Hell, the answer is pick one side. And, you know, once we actually do that, we want to make sure that we both agree what we do. We do this through a capability. Easy? Yeah. It was like the the actual answer for this on the wire is just simply, you know, wait for b b f d to come up before you send your keep alive to make BGP say I'm established. The problem is if you do anything in the BGP finite state machine, thank you, Alex Zinin, so many years ago, keeps on being pain that you keep on giving us, the amount of text that you need to do to say this one sentence is gigantic. You know, John Scudder is going through similar fun now for, you know, 42 71 BISS. I'm sure he'lAS Cell us about that later. This means that we need new events. We had a send hold timer, RFC that went out that also needed new events. What this meant is how do you actually track this stuff in the state machine? Our choice was to go with substates. And it was part of this. We also had to figure out how do we actually, you know, latch this into the state machine. The first round, when we did the expanded state machine work, we thought this was open sent. We did an audit as part of the work that we did for BGP over QUIC, where we spent a huge amount of no work with, Ying镇, trying
[00:14:12] Luuk Hendriks: to figure out
[00:14:13] Jeff Haas: what the fizzing looked like. We figured out that this was really open confirm, Did a huge amount of document update that changed zero on the wire. This was sort of a point about how bad the FSM actually is in many respects. Exactly how we maintain the FSM is going to be a longer discussion. And, you know, past that point, we still have a re a reason to document these things and take these code points because we're gonna expose them eventually through things like YANG modules. So we have to put together a registry for it. Very boring. That said, both pieces of work have completed. We are now ready to actually take both the documents to last call. As, you know, we've made the request down the list. This is your chance to actually pay attention and ask questions. There are at least three implementations, so we're good to go. You know, let's get things moving. Quick questions before we move off to the next presentation. Excellent. Carrie, could you switch me over? My goodness. You have to unshare this the ticker.
[00:15:15] Camille Braat: Where is it? I don't have click.
[00:15:26] Keyur Patel: One sec.
[00:15:51] Jeff Haas: That's here. And then get back to share again. Confirm. And then you can click share again. Click. Okay. It makes sense. So one of our bits of joys as a chair is they added a, you know, bot to controAS Che clicker here, but it also means that you get to argue with the machine before you switch things. So a very brief update on the, you know, the b h p model, work that we're doing with Mahesh. And basically, the chairs up front, this makes review of the model a little bit interesting. So document history, we promise there are gonna be no yang trees, you know, during this presentation. You've had enough of them. Previously, we last called this in 2024, you know, but we left it waiting for implementation because our tradition is two interoperable implementations. Since then, we've had pressure to ship the document anyway. So this has been a conversation not only with AD, but also the broadband forum who sent a formal liaison statement saying, we would like to use this IETf stuff. Fun detail in other presentations, you know, like the NMAP presentation earlier this week. We have other people making use of the model for things like BGP streaming telemetry. So success, people are using the stuff. So we're moving this stuff forward. What does that actually mean? Well, we had to do the last tiny bits cleanup, you know, as part of this. The most impactfuAS Ching, you know, thanks to the discussion with Maria, is we have implementations that, you know, wanted to actually key on things other than the IP address of the neighbor. And we had to add a little bit of flexibility for that. We got some help modeling, that sort of thing. A lot of the rest of the work is two years was enough for us to actually have to make changes into how Yang has actually done in IETF. Semantic versioning is now a thing. You know, people there are familiar with OpenConfig and other projects. You've been there for a while. IETf is now actually doing it. We did a little bit of rearrangement and cleanup, and, you know, as part of these efforts, we had cross correlation versus the OpenConfig modeAS Chat provides parallel functionality in a different organization. This gave us a small number of changes. We did ask the dynamic peers. We created a, you know, a b n f, you know, format for the s path regular expression language and its statistics. You know, and you know, also got some feedback as part of a updated Yang doctor's review from Andy Bierman. Thanks, Andy. The biggest thing that actually changed in terms of, you know, churn in the model was caused by updating the I n a considerations. This is another piece of procedure that has, you know, been updated since 2024. Things that are maintained by IANA require clear instructions to do so. This caused us to move some stuff around. You know? Things moved. We didn't actually change contents, you know, but, you know, this made a lot of churn in the document itself. Biggest thing that I actually like to do is clean up the, you know, extended community encodings. We found a better format to allow us to do this for maintenance purposes. And one of the nice presentations we have queued up later is we were talking about a similar problem of how do we canonically modeAS Chese sorts of things both in a, you know, independent reason and a human readable one. So our steps are here. We're going to have, you a bit of a review on this, addressing the last bit of the Yang doctor stuff. We will be communicating with Ayanna about the last pieces of the procedures, and then hopefully send this to ISG. Have I a quick question for Weiqiang.
[00:19:15] Weiqiang Song: Yeah. Weiqiang Song from the team. How's the b b f liaison officer hat? Yeah. Thank you very much for the presentation of the draft. You know, it has the draft status update. Actually, BBF has expressed their you know, they use this draft as reference for their work w t for some some issue two. And their work is progressing to the completion, but they would not be able to publish it unless until ITF published the BGP data model draft. So I think BBF certainly is about to progress this draft to ISG to publication. K.
[00:20:07] Jeff Haas: And as part of ITF processes, and we have talked about this amongst ourselves, we'd appreciate if the BBF and other organizations that have interest participate in the last call and review, you know, that way they can make sure that we don't ship something that they can't use.
[00:20:22] Weiqiang Song: Yes. I can. And actually, we can also send the liaison to BBF, you know, telAS CelAS Chem how to do that.
[00:20:30] Jeff Haas: Exactly. Okay. Thank you very much. And hopefully, I've recovered a few minutes. Just oh.
[00:20:38] Ketan Talaulikar: So this draft, the chairs have been carrying it or maintaining it and improving it for a long, long, long time. The fourth author is the current management AD. This probably may be the largest ever Yang model 240 document in of the ITF. So and I've I've been asked to call consensus on it for that reason. I would really appreciate people voicing their opinions on the mailing list. It doesn't need to be perfect. There is parallel work with the Yang versioning and all of that happening, which hopefully makes some of these things easier to maintain, fix, improve. That's this thing. So but, please, I need some responses on the list.
[00:21:32] Jeff Haas: Thank you. Thank you, Kevin. Xiaohu?
[00:21:56] Susan Hares: You want the other one
[00:21:57] Xiaohu Xu: first? Yeah.
[00:21:59] Jeff Haas: Oh, you wanted the idea? Present. Yes. Okay. Let me switch it first.
[00:22:08] Xiaohu Xu: Hello, everyone. I'm Xiaohu from China Mobile Cloud. Let's talk about how to use FARE in multi-plane scale-out networks. Currently, more and more large scale AI training cluster are considering to use multi-plane scale-up networks in order to reduce the usage of switches and optical links. In such scenario, there are no interplan links within the fabric. So the rNIC, RDMA NIC, need to detect reachability and even the past bandwidth of each plan in order to perform eCMP or even weighted eCMP across those plans. The FARE draft proposed to extend the BGP FAR protocol from switches to GPUs for multi-plane scale-out networks, the same technology could be applied to the multi-plane scale-up networks. There are two major difference. One is the protocol extended from switches to the The other is this multi-plane scale-up up networks will require much larger routing tables than the multi-plane scale-up networks. Assume there are scale-up networks consisting of 100K GPUs and four planes. It will require about 100K host routes to be propagated across each plane. The rNIC shouldn't install more than 400K host routes. That's not possible from the perspective of rNIC. Inundation is not optimal for switches to instalAS Chose host routes. So we need some routing table reduction mechanism. There are two options. One, to use route aggregation with unreachability notification. The other is to leverage the prefix ORF mechanism. In the formal approach, route will be the host routes would be aggregated when advertising them from leaf switches to spy switches. However, if there are no other mechanisms for unreachability advertisement enabled,
[00:25:49] Olivier Dugeon Dugeon: there
[00:25:49] Xiaohu Xu: will be black hole issue. So we offer two options. One is to use a normal route advertisement with the past bandwidth attended, and the value is set to zero. Another approach here to reduce the UPA mechanism defined in those two draft. Upon receiving reachability advertisement, need to update its foreign table as follows. First is locate the best match subnet route, current unreachability host route. Then from those next hop next hop set next hops of the aggregated route, remove the next hop of the next hop of the affected plan. Then the rNIC will install specific host routes with the remaining next hop, the aggregate route. Another approach is very straightforward. It's just to leverage the ORF mechanism. In addition, since there are no need for switches to install all host route in its FIB, we can use some FIB suppression trick. For example, when receiving host route from onyx, leaf switches could tag FIB suppressed extended community attribute to indicate those household don't need to be FIB installed. Oh, that's all. Any comments or suggestions?
[00:28:01] Krishna Swamy: Hey. Krishna Swamy, Cisco Systems. Can I go back to the previous slide? Yeah. What happens if, you know, we advertise only a default route is being used on the NIC?
[00:28:15] Xiaohu Xu: You mean the NIC only use default route? In our approach, I prefer to advertise the aggregated route instead of default route to our NICs.
[00:28:33] Krishna Swamy: Yeah. I mean, on one angle, you know, you're trying to reduce the host routes. Why don't even reduce the subnet routes too? Because Nick has only a certain way of going out, only to the Leaf, right? Why do you even need an aggregated route? I mean, think about it. Okay. Okay. Right? So that's that's something to consider. Yeah. And, you know, I'm also a contributor to the draft-ietf-idr-fsv2-ip-basic. Okay. There are new newer versions coming with lot more things getting handled as a part of UPA, and we can discuss and see that, you know, how Yeah. This is overlapping. The UPA work is getting overlapped.
[00:29:11] Xiaohu Xu: Yeah. I have considered this, the pros and cons of those two options. In my opinion, the use of a past bandwidth value setting to is more helpful in special use case. For example, if some, lens or series were given transceiver, then work, but the remaining, series could still be used. In that case, the route's advertisements with past bandwidth could still advertise the the the remaining batteries. In that case, the pros can advertise three status, reachability, unreachability, and passive reachability. Okay. That's the main pros.
[00:30:18] Jeff Haas: You're in the next session. Okay. Thanks. Oh. Jeff, did you want to keep it very brief?
[00:30:27] Yingzhen Wang: Just to ensure Nvidia, just quick ones where you can't have default because network are rail-optimized. You need to exit the raiAS Chat goes to the destination. Otherwise, rails will break down.
[00:30:38] Xiaohu Xu: And I thought you're gonna ask to ORF. You know, but I think it's not the solution. Thank you.
[00:30:45] Keyur Patel: Hey. I'll be real quick, I I think that's what I was gonna comment what Jeff said. You can't do this with default route because there's an east west traffic going on. So you need to have subnets.
[00:30:58] Xiaohu Xu: Okay. I just, give a quick update of the changes, this draft. Uh-oh. We end a new call, sir, since the last version, And we also end some clarifications about the two scenario. One is the use of multiple BGP sessions between switch pair. Another is packet forwarding over tunnels. Okay. For the first scenario, when multiple BGP sessions are used between switch pairing, the path bandwidth calculation must be performed on the node granularity rather than the session granularity. When the packet are forwarded over tunnels, we can attach the past battery's value to the route of the, look back addresses, which use that tunnel at a point. So in this case, the logic of the fare could still be valid. Currently, we have more implementations, including multiple vendors and multiple chips. I think it's this draft is ready for working group adoption since I have declared there are no IPR. Okay. I think it's
[00:32:49] Jeff Haas: So thank you for clearing up the IPR issue. That makes things easier. A thing that you will also have to do before we will start a, you adoption when we're ready to is there is a five author limit on the drafts, you know, to go Okay.
[00:33:03] Xiaohu Xu: I see.
[00:33:04] Jeff Haas: So, you know, the fact that you can fit so many authors onto one page is impressive.
[00:33:09] Xiaohu Xu: Okay. Just remain five or six. Okay.
[00:33:15] Jeff Haas: So I I think the FARE base proposal has been well understood. You know, so we'll see what we can do about getting into the adoption queue. For the other document, you know, more discussion obviously would be good.
[00:33:29] Xiaohu Xu: Yes. Yes. Thank you.
[00:33:30] Jeff Haas: K. Thank you, Sean. Our next presentation will be the ORF YANG model.
[00:33:59] Weiqiang Song: Okay.
[00:34:01] Weiqiang Cheng: Hi, everyone. I'm from china. And I'm presenting a new draft, YANG data model for BGP Outbound Route Filtering on behalf of the other authors. And first is the overview, and this draft was triggered by the review of the VPN perfect draft and which set the needs for YANG model. And during the design, we find the current ITF BGP, and it's related to YANG module. Do not cover the ORF functionalities. So we extend the existing modeAS Co support the old. And this document defines the YANG data models for the configuration and management for the BGP including, like, the generic outbound route filtering capability defined in fifty two ninety one and the address prefix of defined in fifty two ninety two and covering prefix of defined it in seventy five forty three and the VPN Prefix ORF we've mentioned in the as as the draft we mentioned. And we've defined in, like, two YANG modules in this document. One is the ITF BGP or of YANG. The other one is the ITF BGP VPN perfects of. Yeah. So first is the module or, yeah, ITF BGP or it's basically contains of, like it contains, like, three main components. First is the generic of capability. We defined it a grouping for the of capability advertisement with a list that with the supported of types and whether it is the the speaker support the send or receive or both in for each RF types. And second one is the address perfects off. We defined it a grouping for address perfect of entries, and we're using for the configuration of the entries advertised by the local speaker and and also the operational stage for the interest they received from the peers. And this part was augment to the IETf-bgp model and is applicable to the IPV four unit cast, IPV six unit cast, both neighbors and peer groups. The third part of it is the CPU or and we defined it defining separate groupings for the CP-ORF entry list, like for VPN v four, VPN v six, and VPN since they were different in their constraints about the route types and host address. And and and also they were, like, you were used to for the configuration of the entries and the receive entries that generated by the speaker and received from the peers like the former one. And also augment also augment to the I t f b g p model and is applicable to the AS Chree v p n, m p v six v four unicast, AS Chree v p n, r p v six unicast, and the AS Cwo v p n, e v p n neighbors, and peer groups. So the second module is the IETf- b g p VPN Prefix ORF, and we defined it as grouping for the quarter policy, which contains its the quotas, like, with the RDs, source b, quota, overload VPN routes, process method, and the and and we reuse it to augment on the different address families for their to define their to configure their quotas. And, also, we define a groupings for group grouping for the VPN Prefix ORF entry and to for the operational states of the generated VPN entries and send it by the speakers and also the received from peers. And it's applicable to the address family that's listing there here. And, yeah, that's it. Any comments?
[00:39:14] Jeff Haas: K. While we're waiting for comments in the queue, so channeling Ketan from the chat, he's requesting that the authors for the ORF Yang module please comment on the BGP Yang module last call.
[00:39:29] Weiqiang Song: It's seven day channel or
[00:39:31] Jeff Haas: In the checklist. My second piece of comment is that thank you for taking on the work to document and build Yang for all ORF, not just one. We one of the discussions that we have not started yet, which will probably be IDR chairs, Ketan, and other, you know, routing working groups, is now that the base PGP model is done, as we have people augmenting it like yourselves, we will have to have a review process for how things integrate. So, you know, we will supply feedback.
[00:40:07] Susan Hares: Thank you.
[00:40:09] Jeff Haas: Any other questions? Okay. Thank you for the presentation. K. David Smith, you don't need to share your screen. The slides are up. We'll just pass you the slide control in a second. Would you please test your audio while we're doing that?
[00:40:49] David Smith Smith: Hi, everyone.
[00:40:51] Jeff Haas: We can hear you loud and clear. You should have slide control. Go ahead, please.
[00:40:54] David Smith Smith: Okay. Thank you. Good day, everyone. My name is David Smith Smith, and I'm a coauthor of a new draft entitled BGP route reflector deployment considerations. And in this slot, I'm gonna walk through the motivations, topics, and objectives of this new draft. To begin, we intend for this draft to be an informational draft only because it's not proposing any new protocol changes or extensions. The primary purpose of the draft is first to examine the common route reflector deployment models and the distinct trade offs of each, and secondly, provide best practice recommendations to help operators maximize the performance, scale, and avaiChina Telecomility of route reflector infrastructure. Now we believe there's a need for such a draft because improper deployment of route reflector infrastructure could introduce risks to overall network performance. And just to give the working group a sense of, you know, the types of things that could go wrong if route reflectors are not deployed correctly, you know, we've provided a list here. So, for example, if, you know, if the limits of a route reflector hardware platform are exceeded, it can put an entire cluster at risk. If route reflector if if excessive route reflector redundancy is deployed, then clients are forced to process more I b g p sessions, more updates, and more paths, we could which could be detrimentaAS Co clients. Obviously, you know, larger cluster sizes increase the blast radius. And if multiple address families are coupled together, either on a single session or on a single route reflector, then a failure within a single address family can potentially affect other address families. A slow client, for example, within a cluster or within an update group could degrade the performance of the whole cluster or update group. If a route reflector is hiding paths, then that could result in suboptimaAS Craffic forwarding. And, of course, you know, poor TCP transport performance could degrade both BGP performance as well as overall network performance. And session resets introduced by session prefix limits, know, those could affect network avaiChina Telecomility. And then lastly, packet loss or packet BGP packet drops due to aggressive control plane policing, could also affect network avaiChina Telecomility and overall network performance. Okay? So now these are just a subset of example issues. Note, there are others which we cover in the draft. But for all of these reasons, you know, we think there's significant value in in such a such a draft. Okay? And that it's important to document these issues because to date, we don't believe these are all well understood or well documented. Okay? Okay. So here's the list of topics that are currently included in version zero of the draft. There are other topics which we intend to add to future versions of the draft. And, again, we think these are important and interesting topics that that should be documented. Okay? Now we're obviously not gonna be able to go through, you know, all of these topics in in this slot, but we will go through several just to give the working group a sense of a sense of the draft. K? So, for example, in large scale BGP networks, there are three common, route reflector deployment models, specifically multi cluster, route reflector deployment models. The first being a full mesh amongst amongst clusters. Right? This is, you know, a very simple design that scales very well and provides efficient path delivery across the topology. The only limiting factors are the full mesh between clusters. And, you know, when adding a new cluster to the topology, it requires reconfiguration of alAS Che existing route reflectors. Okay? The second multicluster design option involves multiple tiers of route reflectors. Right? So at the lowest level, you know, the border routers, you know, they peer they they serve or act as clients of, say, tier two route reflectors as was the case in the previous multi full mesh design. But instead of the tier two route reflectors having a a full mesh, they act with clients to tier one route reflectors. And the tier one reflect route reflectors have a a full mesh amongst themselves. Right? So this multi tier design enables massive scaling because it avoids the full mesh between the tier two route reflectors. However, because it introduces this additional layer of route reflection, it could, you know, it could degrade BGP convergence. Right? And then, of course, because, you know, tier one clusters and and secondly, tier one clusters, could have a very large blast radius.
[00:47:45] Keyur Patel: K?
[00:47:47] David Smith Smith: The third design option, multicluster design option, involves multiple planes. Right? So in this slide, we illustrate a dual plane design with red and blue planes. The clients or border routers peer with both planes, peer with the route reflectors of each plane, and then the route reflectors can either use the full mesh amongst themselves as described in the the first design option or a multi tiered design as described in the the second. Right? So a multiplane design provides two benefits or use cases above and beyond the previous two designs. One is increased redundancy, and second is horizontal scaling of the BGP control
[00:48:40] Camille Braat: plane. K?
[00:48:44] David Smith Smith: Another topic we review in the draft is path selection. And this is because by default by default, route reflectors compute and advertise a single best path only, and they also use their own IGP metric to the next-hop to the IGP next-hop during best its best path selection. And so these default behaviors could result in path hiding, which could lead to lead to suboptimaAS Craffic forwarding. K? Now there are a number of techniques to mitigate this as listed here. And so but but each of these techniques have distinct trade offs. Right? And we review those trade offs in the draft. As I mentioned earlier, there are some additionaAS Copics that we plan to include in future versions of the draft. Multihop BFD, BGP graceful restart are two examples. Multihop BFD is a good example because, you know, we've, we know people who are strong multi hop b f d proponents. Right? Running multi hop b f d between border routers and the route reflectors, for example. And we also know people who are strong opponents of of multi hop b f d. So regardless, you know, if the working group can't gain consensus on this specific topic, then at a minimum, we think the the pros and cons of this option, the use of multi hub EFT should be documented so that operators can then, decide for themselves. OperationaAS Copics, are outside the scope of the draft. Okay? And for for that reason, we are considering, you know, if the working group decides to adopt the draft, to renaming the draft from route reflector deployment considerations to route reflector design considerations.
[00:50:56] Keyur Patel: In
[00:51:01] David Smith Smith: terms of next steps, the authors welcome feedback, from the working group and colChina Telecomoration. And secondly, we request adoption of this draft as an informational draft because, again, we believe it would provide significant value to the operator community.
[00:51:23] Jeff Haas: K. Yeah.
[00:51:26] Keyur Patel: K. This is good work. I think if you're gonna do this and if working group is gonna take this work, then you should look at alAS Che old, RR documents, that people had written, what happens? Maybe, refer them at least minimally or talk about them. One is about hot potato routing and route reflectors. Second is, full mesh versus, just the route reflector, meaning clients full mesh together versus non full mesh. What happens typically, these route reflectors, they are deployed with IGPs. So how do you set up IGPs so that you only attract the traffic that you want, but it's not used for transit forwarding? And last but not the least, think about what can you do with GR because these things carry with full Internet table. They go down. They come up. Same table has been seen again. How do you optimize that? In short, make it more holistic.
[00:52:26] David Smith Smith: Okay. Agreed. Thank you for the feedback.
[00:52:30] John Scudder Scudder: Hi. John Scudder Scutter. Thanks for the presentation. I you know, if I wasn't persuaded before that it's a reasonable thing to write down operational considerations for route reflection, am now. My question is, why are we placing this in IDR and not in GROW, since, you know, we we have three sessions that are completely packed in IDR, and GROW is less overtaxed, and this seems more in charter for GRO than it does for IDR. Have you considered that and decided not to, or you just didn't think about it?
[00:53:14] David Smith Smith: Honestly, we didn't think about that to date, but that's that's a valid point. Thank you.
[00:53:21] John Scudder Scudder: Thanks. You might wanna take it up with the chairs, coauthors, ADs.
[00:53:24] Jeff Haas: Thank you. And, Jeff Haas, so John Scudder's speaking to the point I was going to make for you. So GROW has this within Charter within many respects. Although, as you're sort of pointing out, this is a little bit hybrid in terms of know what its goals are. I did paste into chat that GROW does already have a operational security considerations document that there's let's call it about a 15% overlap with this stuff inside of your own document. So, minimally, we wanna make sure those two pieces, you know, like transport security advice, you know, is, you know, made harmonious between the two. I think the answer that we're looking for for where we adopt, we'll have to have a conversation with our AD and see, you know, what they think. And the one thing that's to our benefit is the rechartering process did give us, you some latitude towards informational documents of this type. So we'll chat amongst ourselves, and, you know, please keep working on this and take it to the list for further discussion.
[00:54:29] Keyur Patel: Okay. Thank you. And quick comment to what John Scudder and Jeff said. Looks like skimming through the draft, there may not be guidance for implementers. Should there be a guidance for implementer implementers, then we wilAS Cake a look at it and see whether it belongs here or in.
[00:54:52] Jeff Haas: Okay. Well, thanks for the presentation, David Smith. We're gonna move on to John Scudder. No talking about forty two seventy one biz. I'd gotten slightly out of order earlier. Take a click in. And you have control.
[00:55:10] John Scudder Scudder: Thanks. Hi, everybody. Yeah. It's been a while since we talked about this last. Sorry it took so long. Hopefully, things will proceed faster from here on out. So a little bit before this meeting, I got around to publishing draft o one. I'm not gonna try to come up with a cute subtitle for every version of the draft, but I think this was the low hanging fruit edition where I think just about everything that I merged in is stuff that at least I thought was relatively noncontroversial. There were a few things that people came back to me later and said, hey. Can we talk about this in the group? And those, we reopen the issues, and they're covered in the slides to come. Other than that, I'm not gonna talk about what's in o one. You know, please do go and review it if you have the time because otherwise, when we come to working group last call, you are gonna have a very large review. So now that the low hanging fruit has been plucked, most of the remaining GitHub issue list is either big rocks, by which I just mean well, some of them are ones that are complicated to solve, but some of them are just things that are big. And but some of them are also issues where I felt like we really needed more working group discussion. And the correct answer wasn't just obvious. So what I want to do with the remaining of my twelve minutes and twenty nine seconds is I have, I think, 11 or something different issues on the following slides. That doesn't cover all of the issues. That covers the issues that I wanted your help with. Please feel free to, you know, hit me with a clue bat about other issues as well. So before I jump into that, just a quick thing at IETf-one hundred twenty four. I projected this slide. Having now gone through one iteration, I propose to make this little change, which is instead of for every PR that I merge, that we do a mailing list confirmation before that. That just seemed too ponderous, And I didn't end up doing it. I did end up mailing the list about a few things, but not most. So I propose an interest of not spamming the list and also an interest of getting things done that we adopt this instead, which is just that one issue corresponds to one PR. And that hopefully makes your review easier and hopefully makes unwinding anything that I did wrong easier. If anyone has any issues, to pawn about this, you know, you can either run to the mic or emaiAS Che list or whatever. Okay. On to the issues. And I'm just taking these in numerical order. So first one, graceful restart. RFC forty seven twenty four hacks the FSM a FARE amount. I think that for all of our RFCs that hack the FSM, is desirable. And assuming that we keep the FSM in the base spec, which I think we're going to, unless somebody wants to convince us not to, which would be awesome. But I think it's probably not really the smart thing to do, though it might be the brave one. Anyway, I think that we should try to bring the base spec FSM into as much alignment with what we actually have running on our routers as we can. That means pulling the graceful restart changes into the base spec. And it's difficult for me to see a way to do that cleanly without pulling all of graceful restart into the base spec. Because otherwise, you're kind of pointing back and forth between an already published RFC, which is over there, and a base spec, which is over there and is newer. And it just seems really weird. If anybody has any brilliant ideas about how to finesse that, cool. Please tell me. I'll be here all week. We don't necessarily have to do it at the mic. But right now, I'm kind of thinking that even though I really don't want to, that for this and a number of other RFCs that that touch the phism, we maybe just need to pulAS Chem into the base. My my assumption is, though, that for things like graceful restart, which not everybody implements, not everybody should want to implement necessarily. I don't insist that everybody have it in their implementation, that we make it clear in the base spec that it's an optional feature. We didn't so much have a concept of optional features in 04/1971, so we're going to need to invent some consistent way of doing that. And now we're gonna have something that looks like a PIX pro form a to even figure out whether it you know, which bits of forty two seventy one bis you comply with, which makes me sad. I see Sue in the queue, and I think it's probably better if we just take questions live because each issue is a different issue. Sue. Unless you'd like to do it differently, but I this makes sense to me.
[01:01:12] Susan Hares: In some sense, some of the parameters for FISM were already optional features. So
[01:01:23] John Scudder Scudder: So you think we have a pattern we can follow?
[01:01:24] Susan Hares: We have we have a pattern you can follow. The work done for the quick stuff has also probably got some informative we'll hack on that in the in the GitHub when you can. But I think I know a way path forward having done it. But I think in saying and the the standard, group of
[01:01:50] John Scudder Scudder: Usual suspects.
[01:01:51] Susan Hares: Sinners. Yeah.
[01:01:51] John Scudder Scudder: Okay. Thank you. All right. Next issue is extended message sizes. I like extended messages. I don't know how widely fielded they are. I do know that if you go and look at RFCs that normatively reference eighty six fifty four, there's two BGPLS ones that say it's recommended that you should support extended messages if you're using BGP LS. And I see that BGP sec says something that's not quite as strong as that, but it pretty much says, please do extended messages, guys. So extended messages is written in such a way that we don't have to pull it in. We can leave it alone. I think that it would be responsible to at least include a pointer, you know, in the part of the text that talks about max message size and say, there is this extended messages thing. Or we could roll it into the base spec. I would be interested in the working group's sense of whether we should just make it part of the base spec or not. Again, you know, put it in the chat. Although the chat's kind of ephemeral. Talk to me later. Send it to the mailing list. Run to the mic. Whatever. But please think about this question. I see another person in the queue. I see Sue in the queue. I don't know if you're in again or okay. You're off.
[01:03:36] Keyur Patel: That's that's me. I just have a quick comment. I love the fact that you are keeping things out. The doc has already reached 100 pages. I don't think anybody is going to implement BGP from scratch. But if they do, it's gonna be super painfuAS Co read 100 pages and implement it. I'm I'm sure there are geniuses out here.
[01:03:54] John Scudder Scudder: Yeah. The question is whether it's more painfuAS Co read the 100 pages or whether it's more painfuAS Co read a 105 page. You know, do I wanna read a 100 pages plus a whole bunch of other docs, or do I wanna read a 120 pages?
[01:04:06] Keyur Patel: Yeah. But I think that's why keeping it out makes it good for time being because as you as you increase I don't know. I am probably the answer to that lies in IDRP back in the days when you implemented it, so you'd probably know.
[01:04:23] John Scudder Scudder: Yeah. I don't wanna go back there. So,
[01:04:25] Susan Hares: John Scudder, how much of that is FISM text? Of extended message size? No. No. Oh,
[01:04:35] John Scudder Scudder: how many is that the page count?
[01:04:37] Susan Hares: Size of the this.
[01:04:39] John Scudder Scudder: Oh, I I'm not something like half.
[01:04:42] Susan Hares: They're they're in might be our only other way to do it as well.
[01:04:46] John Scudder Scudder: Yeah. The right. We can talk about that later. I don't have that in this slide deck.
[01:04:51] Keyur Patel: But it's good you're keeping things out.
[01:04:53] John Scudder Scudder: Okay. Right.
[01:04:58] Ketan Talaulikar: Oh, Ketan. Ketan, as a working group participant, I just wanted to clarify on this extended message for BGP LS. And that was really required because the BGP LS attribute has been becoming a larger and larger something that I will not say, and there was no way to do this without the extended messages. So that pointer was really required, but I just want to call out for all BGPLS implementers to be careful about it. But Got it. That's the thing. I'm not sure if it applies for BGP so much in the Internet routing, though. But
[01:05:40] John Scudder Scudder: Yeah. Although it I'm not sure what our key sizes are in BGP sec these days. But if we ever get BGP sec out in the field, it may be really important all of a sudden. I see that I've got three minutes and thirty five seconds left, and I've covered like not very much of my slides. So what I'm going to do is instead of trying to speak to alAS Che slides, I'm just going to fly down them, give you, you know, a quick overview of what's in here. People can look at the deck later. I'm going to be around all week. We can talk about it. You know, find me, send me an email, something. Sorry. Yeah. So TTL security. There was a suggestion made that we mandate TTL two fifty five as a default. A lot of implementations do TTL one. It's not actually required in the spec as far as I was able to tell. Although alAS Che implementations I've worked on have done it. The words mandatory and discretionary are in my or were in my opinion a well intentioned mistake. And I think we should get rid of them and just say what we mean. The legacy NLRI encoding. Okay. I do want to talk to this slide. Four thousand two and seventy one talks about an encoding that only covers Effie Saffie 1.1. I wilAS Cell you for certain we will not get this document progressed unless we cover IPv6. We can do it as a cluster with the BIS 4,760 plus whatever the other one is for IPv6. We can do it by rolling alAS Chis stuff in. We maybe are not actually doing any favors to our readers if we continue just describing the legacy encoding in the base spec even though it's the easiest thing to do. So I you know, there's I I laid out four options. I crossed out the ones I think are not the best options. I'm I'm okay with either saying, here's the document. It has the legacy encoding, but for god's sake, don't use it. Go look at forty seven sixty instead, or we could roll in forty seven sixty and just describe what we mean in terms of the encoding we prefer. One is less work. One is probably the right thing. Tiebreakers. Somebody opened an issue saying, please add shortest cluster list. Jeff added, by the way, we need to be able to talk about how we augment tiebreakers in the future. I think that sounds great. I don't know how to do it. Please send text or at least a clue. Remove private. It was proposed that we should document remove private AS, which pretty much everybody does. It's not in any spec that we've got as far as I know. I'm not sure what to do. What do we document? One required mode, somebody's going to win, somebody's going to lose. I guess we could pick a required mode that nobody implements there. That way nobody loses. Or nobody wins, rather. Everybody loses. We could document the union of every single thing that exists. I'm not sure. Please send ideas. We have a I added a registry for attribute flags. The big question here is, are attribute flags ever going to be useful? If there's any chance they're going to be useful, we should have a registry. If we just think that they're toxic waste, we should say they're toxic waste. This is a FAREly involved three slide set. Maybe I'm the only one that it makes sense to. I'm not sure. The kind of bottom line is it's in the slides. Please read them. Somebody review it. Better advice about the origin attribute. There's an issue saying, can we please say something clearer about how IGP versus incomplete gets used because the RFC is not very clear and different vendors implement different things? Robert suggested in the email around that proposaAS Chat the should not in the quoted text should be changed to a must not. The should not is from the base spec. I think, personally, I think this ship has sailed, but we need to have some working group consensus whether we try to prevent people from changing the origin in flight. I don't think we can. But again, it's open for discussion. Almost done. This came in last week from AYANA. They said, you do guys want zero and two fifty five in the ASPATH seg types to be, you know, some form of reserved or what? Yeah. So I'm out of time. Thank you to those who have contributed PRs and who have contributed issues and comments. All of you who haven't done it yet are welcome to do it. I will say that working in this mode, I was a little skeptical, but I was completely wrong. I feel like this is allowing me to be productive and colChina Telecomorative with you guys in a way that wouldn't have worked very well just in a email workflow. I'm around all week. Please, let's work on this. Thank you.
[01:11:21] Keyur Patel: Hey. One real quick comment. I'll follow-up catch up with you. But when this document becomes a standard, do we have to worry about interoperability?
[01:11:32] John Scudder Scudder: Do we have to worry about interoperability?
[01:11:34] Keyur Patel: 4271bis documents. Should we change the language in a way that it changes the old text?
[01:11:41] John Scudder Scudder: I do not. I I think that in the in the you know, when I was pitching this as a working group document, I think I said the goal is not to have normative changes. The goal is to document what exists. I think that's stilAS Che goal. If we wanna make any normative changes, I think that's a really big deal and the working group has to be very, very clear that that's what we're doing.
[01:12:02] Keyur Patel: Perfect. Thank you. And feel free
[01:12:04] Jeff Haas: to keep going. There's two trailing comments. Trailing comment number one, see the IEPG meeting earlier this week where they talked about the use of the origin attribute. You know, people are absolutely using it in the field, it makes some people very uncomfortable. And the next piece covers our next presentation. We do have a discussion about what we do about cost installation and everything else. So just as a prelude for the talk, we have had at least three, and I think we're now starting to find evidence of a fourth, you proposal from over the years covering how we actually do resolution, costs, and how this actually may differ on a forwarding basis. So Olivier Dugeon, I'm gonna pass you slide control in a second.
[01:12:53] Olivier Dugeon Dugeon: Thank you. So hello. I'm Olivier Dugeon from Cisco. So I will present you the update on the BGP best path next-hop selection draft. So on behalf of The US quota, so we have Kamel from Bell Canada, NG from Huawei, and Israel from AT and T, which have joined us quota on this draft. So let me just recap the problem statement. So RFC forty two seventy one is considering that the next stop is actually used for forwarding. So meaning that the probability condition is based on next stop, and iBgp pass daybreaker is based also on the next step metric coming from from RIV. So with the new data plane, like a SRv6, MPLS, and that exist, this assumption is not true anymore, which lead to two main issue, which is traffic drop of suboptimal forwarding. So most of the implementation already address those issues. So the goal of the draft is really to standardize those behaviors. So for the traffic drop issue, so let's consider this topology of MPLS VPN. So we have two PE, a p one, p two, which are advertising p slash m prefixes to p three. So if we are looking at p3 routing table, so we have reachability to NH1, next stop two from p1 and p2. So the resolverability condition is okay based on the RFC-four thousand two and seventy one. But we don't have any valid MPLS LSP toward p3 to P1. So that will lead to a traffic drop because PGP will select the path to P1 as the metric cost is lower than the path of p two. So that's the first issue. The suboptimal issue, so same topology, but now we are at the intent of low delay metrics, so the green metrics of the low delay one. We materialize those low delay paths via SR policies. So now we have both the next-hop reachability with their own metrics and also the SR policy with their delay metrics. So based on RFC-four thousand two and seventy one, the matrix that will be used for the past comparison will be the past from the next-hop reachability and IGP. So we'll compare two versus six. And the intent that we have here, it's to compare the delay metrics, which should be 12 versus four. So here, based on the RFC, we will select path to our p one, which is not the optimal path that we would like to do, which should be the path of our PE2. So with those metric considerations, so we have also now the consistency of the cost type when we do the comparison. So we've we're taking the same topology as the previous example, but we just have here the SF policy, which is down to p one. In that case, we will do the comparison between the IGP metric versus the SR policy metric, which are a delay one. So it's different type of metric, and the comparison will not have many sense to do the comparison between IGP metric versus a delay metric. So by the way, here's just a mistake in the slide. It's not the cost six. It's a cost of four that should input to BGP. So in the draft, we introduced the resolution preference for this. So we we will operator will add some configuration to set the preference. So let's take the assumption that here we set the preference of 110 to IGP and the preference of 20 to policies. Then based on that preference, we will remove alAS Che paths that have a higher preference than 20. So here, only the path two will be left as a candidate path. So we will select the path with the correct intent. So we also add a section to the draft about the relationship with BGP best path selection criteria. So that draft was mainly focused on the reachability checks, and it's MPL centric, so it doesn't really fit with the other underlay technologies like SRv6 and tunnel encapsulation. It does not address how to accurately determine the internal cost and also like a solution for the comparison inconsistency cost types. So the example that we just showed before, IGP metric versus delay. So based on the feedback and the command that we received on the mailing list, so we replaced the previous forwarding address and context model with a formalized past resolution tuple. So the the key of that tuple will be the address of the forwarding. So it could be the next step, the tunnel egress endpoint, or the SRv6 SID. And, optionally, we can have also the context that will help for the resolution. So that could be something that define which table to look at or any attribute that we can have in those channel encapsulation attribute or the color extended community or any specific field in the SRv6 SID Sub-TLV and Sub-Sub-TLV other than the SID, of course. So we also add a section about the routing loops and endpoint clarification. So that's mainly highlight that with the tunneAS Cechnology, the resolve endpoint is the egress of the tunnel, which let us know that the intermediate nodes will not have any PGP lookup in that case, so minimizing the risk of any routing loop. We also had some example of the intent aware transport. So we had implementation example with BGP CT resolution schema and BGP CAR. So as next steps, we are preparing for the working group call adoption. We already received some interest from multiple operators on the mailing list. Based on the feedback that we received from other vendor, we need to do some reworking on the resolution preference mechanism to be more generic to better align with the existing implementation. And we also need to take other draft as a consideration like multi next step attributes. Thank you.
[01:19:33] Jeff Haas: You. And we have a question in the room, John Scudder Chung?
[01:19:39] Chen Changli: Chen Changli from China Mobile. Thank you very much for your presentation and your work. I think this work is very useful for for the operators' product networks, especially when they deploy and set routing policies like China Mobile. But this document has overlaps with one of my graphs. In this morning, I sent one mail in the working group mail list. And also to the authors of this one, please read it and check the others of my draft. Appreciate your response. Thank you.
[01:20:24] Jeff Haas: Okay. Xiaohu?
[01:20:30] Xiaohu Xu: Xiaohu from China Mobile Cloud. I have question about the information on page five and six. In this scenario, could we just use any custom next hop? And then you then establish direct BGP sessions between two egress p routers. In that case, maybe the issue could be solved without any new purchase.
[01:21:14] Olivier Dugeon Dugeon: I'm not sure to see how the Anycast will resolve the different metrics types.
[01:21:18] Xiaohu Xu: Use Anycast endpoint as the asset policy. No. There are two egress p routers, p one, p two.
[01:21:34] Olivier Dugeon Dugeon: P one and p two?
[01:21:35] Xiaohu Xu: Those two p routers will be used as the endpoint of the two SR policies. Right? One is IGP cost based. Another is latency based. Right? Okay. So if you prefer to use low latency as a policy as a transport layer, you just you just map the VPN service over the low latency ASR policy because both SR policies use the same endpoint, which is the which is any cost address.
[01:22:28] Jeff Haas: I apologize, So we're running shy of time. Would you please send the example to the mailing list so it could be discussed?
[01:22:35] Xiaohu Xu: Okay. Thank you.
[01:22:36] Jeff Haas: And, John Scudder, you have note fifteen seconds.
[01:22:43] John Scudder Scudder: Your talk come John Scudder Scutter, your talk comes well right after mine. You may have noticed that I was also talking about the resolvability condition. We're probably not gonna get around to standardizing your thing before we publish forty two seventy one bis, I hope. Not because I want you to be slow because I want to be fast. But it might be worth thinking about how we could modify forty two seventy one bis to be pluggable so that you have like a cleaner way of inserting your thing once it's ready to insert. So maybe we should talk about that or think about that. Point being, please think about something that could if it changed in the base spec, would make it easier for you to spec what you need. See what I mean?
[01:23:31] Olivier Dugeon Dugeon: Okay. Yeah. Let's discuss.
[01:23:33] Jeff Haas: So just a couple procedural notes. So we are going to be starting the adoption for this, you know, pretty much after ATF. Part of the shared discussion is figure out exactly what adoption we're running. And as you've noted, we have, you know, more than one draft that has touched this over time. And as John Scudder is pointing out as well, you know, we have, you forty two seventy one disc considerations. This also overlaps in strange ways versus the cost community, which has been out for a while and, you know, is incompletely supported across vendors. So this is a interesting problem and, you know, the generaAS Ching that the chairs are looking at is that we have energy to actually do something right now. So the likely outcome is that the work itself is the thing that's put out for adoption, and the actual form of the draft of the author set will be part of the discussion a little bit later. So please look for that coming up after IETf, and we look forward to taking this work forward. So thank you for the presentation. Next one is gonna be on source selective BGP.
[01:24:44] Camille Braat: Hello, everyone? Oh, close to the mic.
[01:24:46] Luuk Hendriks: Close to the
[01:24:46] Jeff Haas: the Close Raise it 05:30, please.
[01:24:53] John Scudder Scudder: Raise the mic or just handhold it.
[01:25:05] Camille Braat: Hello, everyone.
[01:25:09] Jeff Haas: Shout. Hello,
[01:25:12] Camille Braat: everyone. I'm Camille Braat, and I'm going to talk about source selective BGP. There are two there are two Internet drafts that I wrote, and the first one is source selective BGP framework, and that's an informational draft that describes that provides an overview of source select source selected BGP. It it describes some use cases, and it also includes some considerations. And the second Internet draft is about source is is a standard space to Internet draft, and it describes the new proposed BGP attribute called source selected. So before I go into the solution, first, I would like to discuss the problem statement. So in order to explain that, I upgraded this Internet this network diagram with on on the left hand side and hand side a, and that connects to the Internet with an access link, so one gig access link to ISP a, and ISP a connects to ISP b and actually the Internet. And on the Internet, there are some end side b that sends traffic to end side a and all is running fine. There's no overloads in the links, so the communication is fine. But then a DDoS attack is launched at end site a. And it's a four k DDoS attacks attacks that causes an overload of the access link, and that's also need a site a to become unreachable for end site b on the Internet. So how do we solve this? Well, the first approach is inside a tries to filter out the DDoS.
[01:27:07] Jeff Haas: Come in. My my apologies. The remote side is having trouble hearing you. Try rotating the microphone slightly. It's not. Oh. He wants that. So Switched off. That way, it's a run out. You would have to shout a lot harder for them to hear you.
[01:27:36] Camille Braat: Okay. Can you hear me now? Yeah. That's very better. Much better. Okay. Great. So yeah. Okay. Let's yeah. So n site a is puts a firewall in place and then filters out the DDoS traffic. And that's that works very well for the internal IT systems of n site a, but stilAS Che access link towards the Internet is overloaded. So n site b on the Internet can still not reach n site a. So in order to solve this, n site a has to contact its ISP a provider. And I've if ISP a puts a filter in there, then it can absorb the four gig DDoS attack and and deliver the connectivity to n side, a again from n side b on the Internet. So always fixed. But what if the attacker decides to increase the volume to 100 gig? Then ISP a will have an overloaded uplink to ISP b and, n side a is not reachable again. So the only solution here is that an ISP a contacts ISP b and asks to mitigate the DDoS attack on behalf of n site a. Yeah. Working from tier one, we have we experience on a weekly basis terabit level DDoS attacks, and we can successfully mitigate that because we have a massive uplink capacity of tens of terabits. And here's with that, my problem statement. So terabit level volumetric details attacks can only be absorbed by massive transit networks, surfing tens of millions of subscribers. So how can we use these large networks and their massive ads capacity to protect hundreds of thousands of individual customer services? And with that in mind, we also have to consider the engineering constraints. First of all, on the data plane. And these these large networks, they have existing routing hardware, and they they are not going to do a massive ASIC upgrade all around the network. So it must work on existing routing hardware, then on the control plane side. So in order to scale, to 100 thou 100 thousands of precise rules, we need to also be carefuAS Chat we don't destabilize BGP or exhaust TCAM resources in line cards. And then we also need to think about the feasibility, meaning the architectural openness and the standard routing feasibility to facilitate cross domain troubleshooting. And with that problem statement, here's the, proposed solution. Source selective BGP. So what are the two main components for source selective BGP? First, there is a BGP attribute called source selective, and that attribute contains a list of references to RPKI objects. And this BGP attribute can be used in combination with the BGP Unicast IP version four and IP version six. And the second main component is a new RPKI profile called source prefix authorization, and that's the type of RPKI object that is going to be referred to by the source selective BGP attributes. And this RPKI profile contains a a protected prefix, which is a small IP version six or IP versions four IP address block. And then along with that, there's a list of authorized source prefixes. And these authorized source prefixes, they are authorized to send traffic to the protected prefix as the destination. And this whole object is, signed and published by the IP address holder, of the IP addresses in the protected prefix. So how does source selective BGP get applied into the network? So in order to illustrate that, I have included here a network topology. It has networks one to five, one to four have RPKI activated, and five is there as well. And then you have the rest of the Internet. And inside network one, there's a firewall, and that firewall has been assigned to IP address hundred ninety two zero two ten. And it's assigned out of a slash 24 block that is assigned to network one. And network one would like to make sure that alAS Che traffic that is sent to the firewall is sourced from two prefixes. The two prefixes you see on on this presentation. And this is applied as following using source selective BGP. So network one first creates an RPKI object of type source prefix authorization. And in that RPKI object, there's a protected prefix that lists the firewall, and then you have a list of source prefixes with the two slash 20 fours. And once that is, validated and published by network one and it's fully distributed, then network one can augment or adjust the BGP unicast IP version four advertisement for the slash 24 with a new path attributes being source selective. And that source selective path attribute then refers back to the RPKI object, and as this BGP information propagates across the network, source selective BGP supporting routers that are configured to implement source authorization policies for network one can activate this source authorization in the data plane. And one example of how that looks like is included under point four. There you have a route table for router four, and you can see there that there's a new entry for the firewall IP address. And that's new entry points to an allow list, and that allow list includes two the two slash 20 fours. And when a router hits that specific route entry, it will have to perform a second lookup, a long as prefix match lookup for the source IP address and the traffic that is being routed by the router. And if it hits it, it will allow the traffic. If it doesn't hit it, it will just drop the traffic. So that's how source selective BGP gets applied to the network. Just to be clear, source selective BGP is not a mechanism to to achieve source address validation. Instead, it's building on top of source as the address validation. It requires source address validation, but it adds source authorization on top of it. Source selective BGP is also not going to change the way BGP does route selection, and it also is not mandating any packet filtering behaviors. The the source authorization policies are can be implemented, but it's not mandatory. And also the way it's implemented is also not specified. Then some feedback that was received on the mailing list, based on the Internet drafts. So the first, one is path m t u discovery because source selective BGP is filtering out packets. The MTU discovery needs to happen on the on the packetization layer end to end. And then it's very important to realize that source selective BGP is designed specifically for tier one networks or for high capacity networks that have the ability to mitigate DDoS attacks at terabit level. And therefore, source selective BGP must be extremely scaChina Telecomle, and it must be able to serve hundreds of thousands of protected prefix with potentially millions of source prefixes. And that must all be implementable in standard routing forwarding hardware. And a dense source selective BGP is leveraging standard BGP unit cost update stability, also something that a large network, would like to see. And then there's, the dependency on source address validation. So, yeah, in order to implement source authorization, you need to have source address validation applied for the authorized prefixes along the full forwarding path. Otherwise, you're just exposing, an integer Internet user. So therefore, my suggestion is to start with implementing source selective BGP only for IP prefixes in your own customer cone. And as multiple customer cones start adopting source selective BGP, you can also interconnect these customer cones, exchange prefix sets that have this stuff applied and then deploy source selective BGP across multiple customer cones. And then there is, the the, challenge with source selective BGP that Internet users will have to send their allow list via RPKI publicly, and that isn't can be considered a security concern on its own. But I believe that if an Internet user wants to put a permanent allow list right on the Internet, it must be done with open feasibility because it you need to facilitate the cross domain troubleshooting and route validation. So this presentation is just to trigger your interest, and I'm requesting feedback on this proposal. I'm going to look at the feedback. And, yeah, my my next step is basically to to incorporate alAS Che feedback into a new version of these Internet drafts.
[01:38:39] Jeff Haas: We are at time. Alexander, if you have a short question, please go ahead.
[01:38:45] Alexander Azimov: I wilAS Cry to be short. Alexander, I assume. So I have an impression that you believe that layer three firewall can be a solution for volumetric DDoS attacks.
[01:38:57] Camille Braat: Yeah. Source selective BGP can be considered as an extension. So you have the firewall, but it cannot protect its upstream. So it's another tooAS Co make sure that the It
[01:39:09] Alexander Azimov: still works on a layer three.
[01:39:12] Camille Braat: Yeah. It's it's it's doing source and validation. Yes.
[01:39:15] Alexander Azimov: And what will you will do with volumetric attacks on layer four? Is it it's it's unfortunately, I think you should consider a scene flat with spoofed address space.
[01:39:32] Jeff Haas: Right.
[01:39:32] Camille Braat: Yeah. So indeed, a source address a source IP spoofing is a problem, but the assumption is that source address validation is in place for the source prefixes that have source other authorization. Without source address validation, don't use source like a VGP.
[01:39:50] Jeff Haas: So we have to cut the the mic at this point. I will leave you with two quick comments. The first one is some of the scaling considerations that you're looking for have actually gotten discussed as deployment considerations for SAV. I think you're going to find the level of dynamic behavior you're asking will not interact well with the use cases SAV has actually analyzed. So this is good for discussion. The second one is a number of people are going to be uncomfortable with this feature much like UPA because this is allowing for selective blocking to be generally put into Internet no scope. So you're gonna find that there's the security considerations around that as well. All good considerations to talk about on the list.
[01:40:30] Olivier Dugeon Dugeon: Thank you.
[01:40:31] Jeff Haas: Thank you for the time.
[01:40:39] Maria Matejka: Okay. Hello. Prepare your favorite paint. We are going to bike shed because this is the bike shedding talk. Yeah. Nice. So I can see Let's let's cope with that. So almost every every every attribute in BGP has some structure, but there are communities which are like lists of whatever it it went in. So it sets of u n 32. It sets of it sets of triplets of u n 32 if it's large community. And then it's extended community, which is like total mess, nobody knows what's there. And if somebody knows what's in all extended communities, please raise a hand now. Nice. I mean, neither. So if we wanna put it into the into the YANG, we can do it systematically. We can send a structure, which looks horrible. But it's it's systematic, and you can parse it. You can parse it by machine. You can parse you cannot parse it by by person. Or you can send the raw data. You can parse it by machine. You cannot parse it by person, which well, it should work. It's an API, but the problem is that people of they sometimes wanna need wanna reach the the API API output by hand by eye. So this doesn't work either. So there is a compromise. Let's let's send render. But the problem is in the end that this must be parsed whenever it's used by the machine. But it looks like the consensus around the b g p yang is that this is better idea than having to parse things whenever looking at it by humans. So whatever, let's go with this. So this draft is going to define the standard render of whatever whatever attributes needed. Because, well, hello, Bert. We are using a completely different and different display of extended communities, communities than everybody else. So everybody is using something delimited by columns. Bert is using something in parentheses delimited by commas. Well, why not? Let's go to the to the columns. We don't have problem with that, but we have problem with finding out what actually should we should we separate by the columns because everybody does it differently. And let's say, make it not ambiguous so that nobody has to guess whether r t colon one colon one is a s four or a s two. So we'd like to also require a standard render in future future definitions so that we don't have this kind of problem anymore. There are extended communities doing various things like defining 84 flags. And there are others which are just zero. And there is no consensus on how to how to show this. Actually, we have more attributes. We have communities. We have extended. We have I p v six specific. We have large communities. And all of these deserve some kind of specification. And then we have a s path which came in just because, basically, everybody wants to display it and showing it showing it in different way is kind of clumsy, but it can be omitted if people if people don't like it. So the state of the work is I have outlined what I'd like to see in it. I walked over a bunch of of ECs or I have read more RFCs than I have ever wanted to read. And that's not even not even half of what I would have to eat what I would have to read. So there is much more extended communities to just check how they actually look like inside, which is also quite hard considering some RFCs don't even say what should what should be there specifically or what should happen if the if the value is different than specific specified. I may need some co coauter because this is a lot of work. So don't raise your your head, everybody. I don't expect more than the more than one volunteer. It would be still still even too much to expect one volunteer. My my thoughts just just shortly before this meeting, I I came across that draft draft in grow in the YANG of YANG BGP communities, which actually defines a a JSON structure in which one can publish how the how the EC or or communities should should be displayed or how it's structured. So I I am in contact with Martin Bells, and we are going to find out whether this can be connected so that, in the end, the the new drafts, new RFCs would have to would have to contain a piece of JSON, which would define this and then could be loaded into existing existing implementations without having to change the code every time a new RFC comes comes out. So there is also another plan on my side that I wanna create an open source library so that everybody can can see and check, even for the new JSONs, whether whether this actually works the than this way. So these are the discussion points points, whether this is actually a concept we want or whether we want to keep keep the whatever how people display it and and let it let it be. I like to ask whether it's a good idea to adopt this now or wait whether it's done and then adopt because I think it's it's would be nice to at least express the intent that we actually wanna do it by adoption. And how to actually do do the bike shedding. How how to gather people and say, well, we want r t r t r t dot dot a s for I t dash a s for I t whatever, r t whatever. How to how to display flags, how to display this and that. And I am happy
[01:47:09] Keyur Patel: to look at you when you are going
[01:47:10] Maria Matejka: to bike shed. I don't care.
[01:47:12] Susan Hares: Mhmm. And
[01:47:15] Maria Matejka: in the end, the question is how to incorporate this with the actual YANG model because I am not I don't like blocking the YANG model. On the other hand, it's a little bit bad to to have a YANG model with one specification and then say it's gonna be else. So it's gonna be something else. So that's it. I'd like to, as I said, request working group adoption.
[01:47:42] Jeff Haas: Luca, you have the mic.
[01:47:43] Luuk Hendriks: Hi. Luca and Rex in NLnet Labs. Yes. This is this is this is worth our time. I guess this is one of the things that I can't believe we did not have yet. Right? So thank you for this. I'll happily take this and see how, you know, well scores my implementation, so to speak.
[01:48:04] Maria Matejka: I intended this to not score well at any implementation.
[01:48:09] Luuk Hendriks: Well well, we can just discuss this course offline. Two things. You mentioned an open source library. Is that is that is the idea to also come up with, like, this minimaAS Cest case with alAS Che dirty edge cases and and, you know, for implementers to validate their stuff? Or because that that would be if this is possible, let's go for this, yet I need contributors for this because otherwise, I'm gonna drown in it. Yeah. Yeah. That makes sense. Yeah. I shouldn't make promises, but let's talk. Maybe the most important thing, if you haven't done so already, the maintainer of b g p dump is here this week. Colin, he has probably printed more attributes than is healthy for any human being, so make sure that you pick his brain on this as well.
[01:48:59] Maria Matejka: Yeah. I will I will calAS Co to you later because I'm going to to lose my your you lose that person's name from my memory in two seconds.
[01:49:08] Luuk Hendriks: We'll make it work. Perfect.
[01:49:10] Jeff Haas: Thank you. So I'lAS Chrow my comments in. Comment number one, this this is worthy work. We should do this. Okay. Comment two, Yang gives us some extra tools here. So this is not, you know, only one way. SNMP used to have something called the display hint, you know, so that you can have the canonical format and how it can be formatted. The yang module made the choice that we have for extended communities, which is the only big mess to have a raw format so you can have a machine parsable piece as well along with this. And my expectation, if I were to implement, you know, the b h b yang module for, you know, for my stack, now we would have, you a, you know, Juniper display format along with the IETf ones. This is meant to be a everybody can use the same thing, but, you know, as an example, Bird would like to use its other format that's allowable. You just need to have a standard way to transport it. So this is very good. And My last comment is that part of the headache here is their use cases are, you know, forked a couple of different directions. The yang module represents the regular expression because it's expected to be able to take something as a configuration as well. Designing it that direction is wrong. You know, we should start with a template of how things go. Martin's format also covers mostly parsing of things, but there's absolutely overlapping work there for having a format as well. And as Sue has pointed out on the side here, we have a consideration of you know, once we have our procedures for this, you know, registering these things in IANA and also updating the, you know, Yang module, which is intended to be extended, and we don't have to get it right perfectly now is a good direction.
[01:50:53] Alexander Azimov: Yep. Okay.
[01:50:55] Jeff Haas: Thank you. And I'm willing to help just as long as I'm
[01:50:58] Chen Changli: not the author.
[01:51:02] Susan Hares: I just mentioned registered. Okay. Okay.
[01:51:12] Jeff Haas: Slides. Next one. It's been CCMP. Share.
[01:51:24] Yingzhen Wang: This is from new. Draft is about the enhancement for ECMP EBGP scenario. So the background, common architectures for data center or AI network or PCI connect network is often used on multiple EBGP sessions for ECP. I've say 5004 has defined mode of persistence algorithm to provide provide the unnecessary best to pass transition. And I've say 5,004 state letter law. The operations should not be applied to the when both pass from the parallel EBGP sessions. Also, I've say fourteen two seven one early state letter. If the AS_PATH attribute for BGP routers would create an AS loop, the BGP routers should be accrued from decision. So the problem statement the first problem in this topology, when best can be changed across the parallel sessions, The the sample effect is received by SPY over multiple parallel EBGP sessions, and I've saved 5,004 persistence is is bypassed due to a different EBGP PR addressed and the prefect receives orders. For example, if the prefect receive orders on SPICE, P r three, p r two, and p r one, first, we received this prefix from p R three, and we select PR three for the best pass. Then we received p R two, and we we select best pass as p r two. And we we have two ECP pass. Now we received traffic from p r one. We we have three ECP pass, but the best pass is changed to p r one. So the best path change is to continue as as the traffic is received due to the low lowest tier change p r just changing. The the second problem is the reductant advertised to the same AS parallel e b b p s. A prefix is learned from an e b b p s is unnecessary to re advertise to to another parallel e b p s in the same AS. For example, if the spine receive prefix from EBGP PR1, PR2, and p r three, the best path is p r one, and then the prefix will will be advertised to p r two and p r three. And then p r two and p r three will include this perfect from load selection. The proposed solution to enhance two mechanisms. The first is to keep a load of persistent precedence extension for parallel EBGP sessions. We provide an option to extend the f c 5,004 persistence logical across all parallel EPP sessions. The new rules, if a new motor is equaAS Co the current best pass, and both are from peers in the same identified parallel EPP peers. Then we retain the current best pass select best pass so it can prevent unnecessary best pass selection. The second, we so so suppression of redactant advertised to the same AS parallel peers. We if the first AS equaAS Co the PS AS number, then we the the prefix will not be advertised to the same AS. For example, in listing pictures, we the prefix will not be advertised. When we receive the list prefix from p r one, we will not advertise the list prefix to p r two and p r three. We can reduce the unnecessary load update in this parallel EBGP top. So we proposed some changes to for BGP path selection modification. The new step will be added before the BGP identity comparison in pass selection. These steps informs the the new persistence rules for parallel EBGP peers locking the calendar best pass when the condition are met. The second, we add what we add the advertised field team rules. A simple AS pass checker prevent sending a route back into the AS when which it come from different parallel EBGP sessions. Both features can be configured. Any question? Come welcome. So I
[01:57:59] Jeff Haas: apologize. We're out of time, so we won't be able to take questions here, but we do encourage mailing this discussion. And we're going to need careful discussion about this because any changes to path selection, especially for something that is time based, tends to cause a lot of bugs. So we'll have to be very careful about how this works.
[01:58:19] Yingzhen Wang: Yeah. Thanks.
[01:58:21] Jeff Haas: Thank you for the presentation. We are to our final presentation of the day. Go on, John Scudder. Nope. Yes. Go ahead and take the controller. You will have control now.
[01:58:49] Yuan Zhang Zhang: Hello, everyone. My name is Yuan Zhang from China Telecom. Our draft is a strict model for BGP Color extended community. What is our motivation and background? So BGP Color extended community. Careers are searching to build user defined value. And the color value is locally configured, and it is designed to express forwarding intent with a pseudo administrative domain. And nowadays, technologies use color to influence forwarding across s border is such as SR policy, BGP CAR, and BGP CPR. As for s r policy, the role of b j p color select candidate pass for steering and b j p car. They they find procedures for color based routing and BGP CPR. The rule as associates color with IPv6 prefix on your local poll policy value become an inter domain for wording input. Next slide. The code gap, lack of attribution. The routine protocol doesn't provide information to verify where a color was attached or altered. AS A has legitimate origin. So the color value is 100, and AS B, transit, the color value, and AS C in transit. Now the color value is 200, and AS D is a res receiver. Heat maps the color value 200 to local policy. We found that no color orange information is carried and no bounding between color and the AS_PATH. The color value is implicitly trusted and received. This created a gap in cross domain real routine decisions. So the threat characterization can be concluded as follows. Because color is an ordinary pass attribute, any entity that originates all forward or road can manipulate it. We can send our consider the following three actors. As for network operators, they can attach, change, or strip strip color, motivity to steer traffic onto a common highly advantageous pass or off complaints pass and hackers, hackers. They compromise routers on controllers to enter as a rush operator. As for criminal nations, say, can torture operator or use wire tapping to divert traffic for extortion, monitoring, or consume it.
[02:02:03] Camille Braat: And
[02:02:03] Yuan Zhang Zhang: we we introduced the classes of attacks on BGP color. So attacks of interest violates its integrity and, authenticity of color value. As for color injection, this attaches on authorized color. And the consequence is that traffic steered onto an intent, bypassed, or constrained pass. As color re-coloring, it can transit speaker modifies the color in transit. The consequence is that multiplied effect across downstream ASes acting on intent. As for color stripping, they will remove transit color and controller attacks. They will compromise management system, define color mapping. Our our draft scope to and follows to prevent the scope from expanding. We have strictly limited scope in the draft. First, color integrity and authority, and the ability of receiving AS to attribute color to an authorized orange. And the last, an authorized injection, recurring and stripping of cross domain color. And next, residual vulnerabilities. Why existing security practice are insufficient for cross AS color. Boldering filter is intention with transitive use, and BGPsec protects the path knowledge attribute and the distinguishability from local policy. As AI stripping, a color mess surely looks in identicaAS Co an AI stripping due to large main local configuration. And last trusted mounting development. Even within a transcript configuration, there is no technical miss for a receiver to verify origin authorization. Future work. While this draft doesn't pose a solution, the threat analysis points to two potential direction for future work. One is building mechanism. Building a color value to a source orange AS, This could be assigned object or in extension to BGPsec covering extended communities. And another fresh freshness mechanism such as such as age of information, AOI, is so associate a validity interval, sequence number, and time stamp with a color value to make still and replay color values detectable. Thank you. Any question?
[02:05:12] Susan Hares: Quickly, you may, in the future, want to consider also the community container as a way to bind it. That does not handle the security issues which may be better done in the RPKI. Thank you.
[02:05:27] Keyur Patel: Okay. Okay. Thank you.
[02:05:31] Jeff Haas: One final comment. So this work is, think, new and early. You are covering good security considerations. Another place for you to work and coordinate is the GROW Working Group does have a operational security document that I've mentioned before. Part of that document is trying to update community scrubbing, which overlaps the problem you're trying to solve. I think the best solution for you is to continue working on the document, coordinate both with IDR and GROW. And as we figure out is this an operational document or is this a protocol changes, we'll figure out where the work belongs. Okay. Thank you. Thank you for the presentation and this concludes the IDR session for today. Thank you, everyone, and we'll see you for two sessions at the end on Friday. Thank you. What is
Session Date/Time: 24 Jul 2026 12:00
[00:00:08] Susan Hares: Hi. We'll start in about two to three minutes. This is the note well. We've got a packed agenda. This is the room we're gonna be in for two sessions. So you get the first session, you get a break, then you come back. So be aware, we're here till the end of the two sessions.
[00:00:32] John Scutter: To
[00:00:36] Susan Hares: the as John says, to the bitter end. Okay. Well, everyone looks like they're settled. Guess I'll go ahead early. This is the note well. If you've been here for any period of time, you will know that this is the place where I say this is an ITF working group. It has all the ITF rules regarding behavior and IPR. And if you have any question, read all these wonderful documents. Any questions? I'm also glad to repeat various portions of the IPR policy for your enjoyment. Okay. We're at two o'clock. We just to recap, we had our charter approved, and we have three sessions. Today, and part of what we did with our AD is we started to have subgroupings of drafts. One is on BGP core functions, another is on SR, SRTE, BGPLS, and flow spec. Okay. The first session today is from two until 03:30. You get a half an hour break, then we go for the last session of the day with flow spec v two. If we need to move a presentation and have it sort of languish, we either take up our breaks or we take into the next time. Statuses was given on Monday and the full status is at GitHub. It is always at GitHub as the chairs try to use that. So today, what are we talking about? Alvaro, your first stop with the mask tunnel encapsulation, then Jacob, you'll be next with the BGP Unreachable Prefix Announcement (UPA) v2. We'll have BGP point/port EC for AIDC for June and extensions to RT constraint from June. Then we're gonna go through a series of SR and SRTE drafts. These are the ones who asked for presentation. You'll notice I did an s r call on the list. S r meaning BGP SID attribute. The we have four presentations in the s r and s r t e, two in the BGP LS, and then the second session will go into little adoption. Please note that if you're doing the SR, SRTE, and BGPLS as well as the flow spec, we are running those in parallel to the core sessions. So if you had a core draft and you saw it was in line to be adopted, how are we taking SR, SRT, and BGP-LS drafts ahead of it? We're running parallel queues. So there are essentially four parallel queues that we're running this. That's the short form of that. And then we'll pick up on flow spec v two. And Jeff and I will go through one more take on the fsv2-ip-basic. And then we have other drafts. We will be doing an adoption of post spec fee to individual drafts. So these drafts are part of them. But for all of these drafts that are non core, you see a shepherd's page on the wiki. I think I've stayed within my time or less than it, Jeff. I think we'll need it. Come on in. If you there's plenty of seats up at the front. It will get more crowded as it comes. If you want a terminal, John's friendly. He really wants other people. Okay. Our next steps I've noted here are for flow spec, looking at filters and then extended communities. K. Alvaro, you should come up here next.
[00:05:07] Jiandong Jin: Hello.
[00:05:11] Alvaro Retana: Hello. Hello. Good afternoon. I'm not gonna stand between you and going home, so I'm gonna do this relatively quickly. Take my time? Okay. Great. Tony said save my time, so I'm gonna go into a lot of background on this. So we make it, you know, exciting and interesting if I get the slides. So I'm going to do this job with this work with Yaroslav. And, basically, all this is is a tone encapsulation RFC 9012 for mask. Now if you wonder what mask is, mask is basically encapsulation where you put everything over HTTP. You encapsulate over HTTP. It helps you obfuscate your traffic. It does a really good job in hiding. There's a lot of privacy around it. It's becoming relatively popular in SD WAN type applications, VPN, zero trust, network access type of things in enterprises and things like that. So we believe it's a good it would be a good candidate to put in total encapsulation, attribute in there. So this is what the stacks sort of look like. We can do or not we. Mask can do HTTP one, two, or three. And depending on what you choose, basically, up in the capsules up there is where you would put the traffic that you're encapsulating. So, obviously, everything when you look at it in the network looks like HTTP, but it is, you know, whatever tunnel you are putting in there. If you want to know anything else about mask, this is all I know. David's standing here sitting there. He's one of the main contributors to the work in the mask working group. So, basically, what this looks like is like any other tunnel. Right? You have a client. You have a proxy, which are the names of the, you know, in the mask architecture, and it gets encapsulated in there, whatever this is, IP, Ethernet, you know, anything like that. As you if you notice, there's the little locks there. All that means is that you're probably encapsulated into it or not encapsulated encrypted into it. In BGP, what this would look like is basically the same thing, but we have between the two routers, of course, a mask tunnel, which is what we would be signaling through BGP, just like we do with all the other tunnels we signal in 9012. Normally, this is configured at a client, and you have a couple of things. You have a URI template in the form of HTTPS something that explain, you know, what the target is, what the protocol, etcetera, that you're gonna use. And you have the information about the ALPN, which is usually learned from a DNS service type of of query. The LPN tells you if this is HTTP one, two, or three, and if there are priorities as well. And then there's the authentication mechanism that you use as well, mutual TLS or whatever this is, depending on the transport that you're having. So what are we proposing? Now to be clear, all this that I've mentioned before is just so that we all know kinda where we're standing. This is not in the draft. Right? The draft is not about mask. The draft is about signaling the tunnel encapsulation. So the proposal is very simple. It's basically this, the one page, which is we're posting four new tunnel types, one for each of the four mask connect mechanisms. So they're named connect to p, UDP, IP, and Ethernet. As the names say, basically, you do connect IP, you tunnel IP through the mask tunnel. Connect Ethernet, you tunnel Ethernet through the mask tunnel. Right? So, you know, nothing too too hard there. And we're proposing two news subtleties. One that is going to carry the ALPN, and it's going to indicate whether the proxy supports, basically, one, two, or three, and potential priorities. Right? So they can try the the client. The other side can try, basically, if you want or two or three. And it's gonna include the UI template. So the same thing that I just mentioned that how the client is configured in mass normally is what we're going to signal here so that the router can now instantiate the tunnel. Right? That's it. That's what the proposal is. Nothing, you know, rocket science or anything else. We do have one question that I want to discuss here, especially from an implementation point of view. If you read 9012, John and I okay. Two people. Okay. Yeah. Okay. Kevin says he read it. I don't know. Okay. So 9012, You noticed that, of course, there's a lot of detail for all the other tunnels, and the GRE and well, I don't
[00:10:01] Hooman Bidgoli: know what
[00:10:01] Alvaro Retana: the other stuff is. In here, the details of where you connect are in the URI. Right? So right. Comment was yeah. So what that means is that, usually, the client is going to go to your solution of this. Right? It's gonna go to a DNS resolution. In RFC 9012, there is a TLB called the the tunnel egress endpoint, sub TLB, which includes an IP address to indicate the tunnel egress endpoint, of course. So there's a check-in RFC 9012 that you look at the IP address to make sure that the IP address belongs to where the tunnel signaling was originated, right, to make sure that you're not signaling tunnels that go somewhere else. So right now, in the zero zero of the draft, it says that when you receive the tunnel encapsulation attribute, what you look at is you look at the URI to validate. Right? So what this means is that you need to do a DNS query and resolve the name of the proxy and figure out the IP address and, you know, and do the check. So that's what it says now. I realized that from an implementation point of view, you know, you may not want to do DNS resolutions. We can add the tunnel egress endpoints of TLB so that we also have an IP address in there. And then we make the resolution the the validation the same way that I think all of the other tunnels in 9012
[00:11:43] Jiandong Jin: do it.
[00:11:45] Alvaro Retana: So there's someone with an opinion. Oh, David, you have an opinion? Okay.
[00:11:53] David Schinazi: Hi. David Skenazi, mask enthusiast. And in true ITF tradition, I am not gonna follow the instructions because I am most definitely not a BGP expert. Sorry. I know close to nothing about BGP, but I knew a a thing or two about mask and HTTP. I noticed that you specify the LPN, which to help for the room mask works over every single version of HTTP, and that allows you to know which one of those to use. And now I'm hearing that you also want a way to get the IP address to save things. One of the things that we designed for HTTP is a DNS resource record called HTTPS, and that includes, I think, everything you need. It has all the supported ALPNs. It has the I p v four. We call them address hints because, like, it's similar to this. I think this is a hint. It doesn't say, like, that's all the answers of DNS, and it covers other things that might be useful in the establishment of your HTTPS connection. So my recommendation here would be to instead include an HTTPS DNS resource record, and that gives you, I think, all of those things. And on top of that, it gives you a future extensibility because that's one of the properties of that resource record.
[00:13:09] Alvaro Retana: Instead of the ALPN sub TLV or instead of the you said instead.
[00:13:14] David Schinazi: Instead of the ALPN sub TLV and the IP address of TLV because this resource record contains both and more. I think that would solve all your problems and be future extensible because that way, anytime someone does something to improve how to set up that's the goal of the HTTPS resource record is to tell you everything you need to know to create an HTTPS connection. And that's exactly what you're doing here is creating a HTTPS connection. So that that's, I think, would be the simplest thing to do, and you would have to reinvent as little as possible.
[00:13:45] Alvaro Retana: Right. So from the BGP point of view, that's equivalent to including the subtitle, the tunnel endpoint, tunneling your standpoint subtlety.
[00:13:53] Ketan Talaulikar: Gotcha.
[00:13:54] Alvaro Retana: John?
[00:14:05] John Scutter: John Scutter. So, normally, my reaction to saying, let's have the routing rely on the DNS would be that is a fantastic idea. I've always thought that routing should rely on DNS, and the DNS should rely on routing. That seems good. So
[00:14:25] Alvaro Retana: The RPKI does that already. So yeah.
[00:14:27] John Scutter: The the the only thing that makes me think this is okay is that as far as I can tell, the only real use case for this thing is for overlays, which maybe we can stretch a point. I still kind of like the fact that you were offering to just give me IP addresses in there, but, quick that that is my quick reaction. I will go and review the document and provide more substantive comments later. Thank you.
[00:14:50] Alvaro Retana: Thanks, John.
[00:14:51] Jeff Tantsura: So speaking from here to save shuffling time, I'm gonna overlap a little bit of John's problem, which is the BGP next hop should have some relationship to the endpoint now that we're trying to tunnel to. So it might be good to talk about that. It's simply how 9012 tries to do such a thing. DNS sec doesn't seem to be mandated in here, so that's an interesting conversation point. I don't know if the best group is generally talking about. And as somebody who's, you know, looked at a little bit of this stuff, have you guys thought about using Dane for this?
[00:15:25] David Schinazi: Are you asking me or him?
[00:15:27] Jeff Tantsura: You would count as well?
[00:15:28] Alvaro Retana: I don't know the answer, so you better ask.
[00:15:31] David Schinazi: If you're asking, have masked people thought about using Dane? The answer is absolutely not. Okay. We mask is built on top of HTTP, and HTTP has accepted our world reality that the web has the WebPKI and that DNSSEC is not implemented by any browser. And so we rely on that. And I'm not saying you should query the DNS for that record, to be clear. I'm saying you could just include it, and all you would need to include is that record format. But all those things in the DNS land, we do not use in a HTTP context.
[00:16:08] Jeff Tantsura: Okay. My follow-up with that is that even the SMTP groups have thought about that sort of thing, and they are barely a service with protection.
[00:16:18] Warren Kumari: David. You've kind of preempted me because I was about to ask whether you were suggesting pointing at DNS versus just including the record data, and the latter seems like it actually may be a good idea for this.
[00:16:33] Alvaro Retana: You wanna go again or not?
[00:16:37] David Schinazi: Sorry. That was the preview. But, yeah, I was absolutely not suggesting that you query that from the DNS in the same way that you were suggesting putting the IP address in there that is conceptually conceptually an an a record or a record. I was just suggesting you put in an HTTPS record because that's an extensible format that includes all the information you need.
[00:16:56] Alvaro Retana: Okay. Great. So we're all going into put an IP address somewhere in the DNS record, in the TLB somewhere. So we'll take that, update the draft. And in the meantime, please go read. Tell us if you have questions, comments, suggestions. Thank you.
[00:17:22] Jeff Tantsura: And UPA is next. G is telling us we're still having fun, so let's make sure we have the right deck. Sue, once we load it, could you skip to the last slide, please?
[00:17:36] Yannick Voyer: Mhmm. I'll
[00:17:37] Susan Hares: click the last one. Hopefully, that's
[00:17:40] Jeff Tantsura: right one. Yeah. Yeah. Once you proceed the last slide, make sure.
[00:17:46] Yannick Voyer: Yes. Got the last one. All set. Hello. Good afternoon. Sergeant here's ecosystem. So I'm here to present an update to the BGP UPA draft on behalf of my quarters. So this is an update from the position made by Jacob in ITF-one hundred twenty three in Madrid. So quick recap first on the prime statement, which was explained in version zero. So what's the route summarization and aggregation is basically essential to scale large networks, whether the underlay is the statistics, v x lan, or even plain IP. Also, in DC fabric, there's a need although the raw scale is lower, there's a need for raw summarization. So the problem is that the raw aggregation hides the failure of a specific covered prefix being a next stop or a route itself from the ingress point of view. So the consequence are that we would see slow conversions on the overlay or even a silent traffic drop. So the goal here is actually to signal the loss of reachability to the remote next stop or prefix and signal it to the ingress without losing the benefit of the aggregation. So this is actually related to the companion IGP mechanism, RFC 9522 with IGP UPA. So quick recap again of what was explained in the first version of the draft. So we have this simple topology of receiving VPN prefixes for CE with two next stop, p one and p two. So p one being the primary next stop, p two being the the secondary next stop. So we have an IGP between the aggression router and the the p one and two where we can have IGP UPA in place. So the aggression router would do a summarization of the p one, p two loopbacks or locator slash 64 and and would aggregate them as a slash 48 towards I b g towards the IP, the ingress PE. So a prerequisite for PIC to work in this case on ingress PE, if the ingress p one, let's say, would go down, is that we signal we are able to signal loss of reachability towards the p one. So with aggregation in place, this is not possible because the slash 48 would hide this failure. The slash 64 or the latest rollback from p one would never be visible to the ingress p. So the goal here with UPA is that the aggregator router would signal this loss of reachability towards the ingress p so that it can trigger a PIC and and trigger fast conversions without without waiting for overlay to converge. So what's changed since the update in in Madrid? So the scope initially was focused on s r v six and VPN. We did extend it to basically any any other family. So in Madrid, we did present one option, which was using MP Unreach, LRI plus UPX and Trinity. It was one of the few options that we had considered based on feedback offline from the mailing list, also our own experimentation, it turns out that the best option was not to use MP enrich, but MP enrich. So that makes things way simpler when we try to implement it. And that was, yeah, an interesting discovery. So we changed the to opaque and added more bits I mean, more flags and bits. I'll I'll show you where later on. Based on the the additional bit, we now will allow as well-to-do explicit drop. Initially, we had two triggers from IGP, UPA, and BGP aggregation. We added a third figure as a drain operation. So we dropped the UPA timer, and we get the I n assignment as well, which was not there in the first version of the draft. And we get the FRR merge using the draft version two implementation. We currently have work development in progress for I o six r and and XOS in Cisco. So the signaling decision to switch from unreach to to reach. Well, MPR reach better fits the goal that we want to achieve here. I mean, an attribute attached to, like, attached to a withdrawal is, well, non natural, very non natural. So it was a lot of gluing needed to be done, so it's more natural to do attach it to a MP reach. So you'll see later on when we start using the dBit, it makes sense also to keep it as an MP reach and also for the c drain, the scenario c with the drain scenario. So point here. So although it's now looks like a using MPA reach, it looks like a reachable prefix. We clearly mentioned that the scope here is to send this only to UPA capable peers. And we don't want I mean, a UPA route should never be used for forwarding. By default, we want this to be off and scoped at the neighbor level. Again, because I was in the description of our mailing list, the goal is not to send this over the wide Internet. And as per the b c p one nine four, I mean, all specific all and most specific two specific routes should never be announced anyway to the Internet. So that shouldn't be a concern. UP access community. So this is the the new one we we have been allocated. Subtype nine, we include the router ID, the router with this which originated the the aggregate sorry, the UP route where the aggregation happened, which is also used to do to do the duplication. So the triggers and workflow. So the first trigger was already mentioned in the first version of the draft. So IGP, UPA, we do we distribute, and then BGP takes care of synonym this. Our case b is the BGP doing integration directly. So we have a more specific in BGP, which are hidden behind the BGP aggregate. The new figure here, case c, is when we wanna do a operator driven graceful drain. So this is going to be covered in the next few slides. So once we originate the UPA, it's not a valid reachable route in the semantic, but we advertise it as MP reach NRI with the UPA extent community and a d bit on or off based on the policy. Propagation, we send this only to BGP capable peers. On the reseller side, well, this UP route will not be used for forwarding. So it it's it can be a figure for PIC. If there are there's an equivalent route, which is not UPA for the same mask, well, the reachable route without UPA should be preferred. If the d b d is set, we should do an explicit drop in the forwarding. Yeah. And as per the initial goal, the goal of UPA is trigger to peak on the ingresspe to fast conversions. So as we develop this, a new use case became evident, and it's all outlined here in a DC Spine Leaf scenario where we do BGP summarization. So imagine this is all eBGP. Each tier is a distinct AS. So you consider the case of Leaf two going down Because of the aggregate summary only on spine one, this could not be propagated to super spine one, and so the traffic will still be affected. So if we use a UPA here with the debit set, we can actually force the instantiation of a slash a more specific slash 24 to drop the traffic sooner. Or if there's an alternate pass, use it. A person driven restaurant drain. So this is the make before break plan by instance. The idea here is to announce u EPA, not because of lack of reachability, but just to announce that the reachability will be going down. So we can select alternative paths if they are available. So as I said, we have implementation in FR. We have Aina component allocated. And so the open items, next steps. So we welcomed Huawei on the on this draft who joined us. So they had another draft, one idea BGP PA. So we received feedback from the mailing list. So these are the the open items that we need to improve the security consideration, especially in case of sensitivity stripping, so the U UPAC and the PPI. Also, we need to improve the error earning section. So the use case needs to be more need to be expanded and be more made explicit into the appendix. So the SP use case, which was explained first, and then DC use case as well. So we have current implementation in progress as well, but it's still in progress. So there is very strong operator interest. So we're looking and and we are running close, so we are looking for work group adoption.
[00:29:36] Jeff Tantsura: Thank you. Okay. So we do have a very busy queue, so please be brief. Hi, Bo. You are first.
[00:29:43] Bo Wu: Hello. Hi, Bo from Huawei. Thanks for your pre presentation. And, also, we think that user IP reaching is a good idea to implement to for to implement this so it's in the future. And not and and also I see that in your slides, you also you just introduced a new data center center. Yeah. This perhaps, we can Xiaopo has shown the presentation at the first session. Probably, it may have some difference difference from the provider scenario. So we think we may have we may have some more discussion about that, how to to let the detail information about how to impriment it. Okay.
[00:30:28] Yannick Voyer: Thank you. So we'll discuss yes. We'll discuss. Maria?
[00:30:32] Jeff Tantsura: Maria from BERT, have you thought about how this is going to to work with all the best route selection and route reflectors? Because I can't see anything in there. And I'm a little bit afraid that if you are if you start mixing announcements with with this set and with without this set, especially on on devices which then if you start with partial with partial deployment and some of your devices don't understand it and some others do, what's actually expected to happen?
[00:31:03] Yannick Voyer: Yes. We did consider this, and maybe we need to add more text to make it more actually, it's not mentioned at all in the draft currently. So we need to add more text there. For I would say that if, let's say, the error doesn't support for now, I mean, you're supposed to send only if the p l is enabled by config to support the p l. Let's say this end up some work factor, but at least you need to I mean, I mean, to a bad path.
[00:31:33] Jeff Tantsura: Yeah. My only only concern is how is how it's gonna work with implementations that don't know it because it's basically exporting it's it's sending a route which is an entire route, so that's why. Thank
[00:31:46] Yannick Voyer: you.
[00:31:48] John Scutter: John, you're next. John Scutter. So this is much better than zero zero. Thank you. The I noticed that you have a BGP identifier in your community. I believe these communities cross EBGP boundaries. BGP identifier isn't unique past the AS boundary. You probably should think about what that means for you. I'm not sure what the implications are, but I thought I'd point it out.
[00:32:13] Yannick Voyer: Thank you. We'll consider it. Action?
[00:32:17] Jie Dong: Yeah. I want to tell you. You I see you you use the NP reach to advertise the unreachable UMS. So I think if the receiver understand the attend a newly added attender, is there any effect on the receivers?
[00:32:39] Yannick Voyer: Yes. If the receiver does not support UPA, there might be some side effect, but the goal here, again, is to limit the scope to only speaker supporting UPA. So, ideally, we should not be linking this to non supporting UPA peers.
[00:32:55] Liuyan Han: No.
[00:32:58] Jie Dong: My question is, you know, if the if the receiver of your new on the ROI cannot understand the the semantic of the newly added attend attend the community, so it will it it may it may install a new detail route to the prefix and will control degree your aim for the unreachable information.
[00:33:27] Yannick Voyer: I'm not sure I fully get the question. The thing is that, even without this slash, this more specific Yeah. You would still have reachability to the aggregate. So, you're not doing something worse somehow.
[00:33:43] Jie Dong: No. Maybe, you know, we we sort of think because there may be some several to advertise the summary route. And if one to advertise the detailed prefix, it will be attract the traffic to to it, but the but the traffic will be broken from there. You know, we we have discussed the such situation in the IGP scenario details. I think you have you may not consider such situations. I can decide with you later.
[00:34:17] Yannick Voyer: Yes. So Yeah. Discuss offline.
[00:34:18] Jeff Tantsura: Yes. So please list this call. Jeff, very quickly.
[00:34:22] Jeff Apcar: Very quickly. That's extremely useful work. Represent NVIDIA, we will have interworking implementation. Hopefully, San Francisco, we should be able to report that we interwork. I'll also provide in San Francisco some analysis. They're extremely it's great usability for some use cases. Less feasible from some other use cases. So probably around San Francisco, I'll discuss kind of why do one versus another.
[00:34:48] Jeff Tantsura: Yes. And the cost of damping the fire a little bit. No. My comments are, this feature is terrifying. There is a huge amount of security considerations around this because if the community is stripped, it leaks out its reachability and attracts the traffic as a more specific, which you don't wanna do. This feature I will be curious to see why you chose to go with transitive rather than non transitive for community. That would be an interesting relay piece of conversation. But as John said, this is much better than the first version. You're not trying to inject state by taking it away. So, no, thank you. This was much better. The commentary that's been left in the chat is that in normal circumstances, this would be a normal a new AFI SAVI to inject this type of state. Maybe consider that anyway even as a meta AFI SAVI because we're not trying to actually attract those state and generate state. We're just simply trying to say for this address family, please inject the black hole. And you could then scope that to the clients that actually understood that AFI is AFI. Jeff, if you have ten seconds at most.
[00:35:52] Jeff Apcar: Ten seconds. There's unreachability staff that does exactly that.
[00:35:56] Jeff Tantsura: Yep. So in that case, the the the current proposal, please don't try to ship code for this. You know, you're gonna have it malfunction, and you're gonna have a very public outages.
[00:36:07] Yannick Voyer: Again Go
[00:36:09] Jiandong Jin: ahead. We'll respond.
[00:36:10] Yannick Voyer: Yeah. Again, the goal is not for this to go all from the wide. It's limited deployment in very specific scenarios.
[00:36:16] Jeff Tantsura: I I have dealt with four different security advisories from limited deployment features, so I am less sympathetic about that right now. But we understand the proposal. I agree the use case needs to be solved. Let's work on that. Thank you. Thank you. Who could spell prefix id?
[00:37:06] Jungha Zhao: Hello, everyone. Could you hear me?
[00:37:10] Warren Kumari: We can hear you.
[00:37:11] Jungha Zhao: Oh, yes. Thank you.
[00:37:16] Susan Hares: Hello, everyone.
[00:37:18] Jungha Zhao: I'm from China Mobile, and I will present our key points and updates of our drafts, BGP points, extended communities for data centers. And then let's let's record the backgrounds in data centers highly at sensitive to network congestion and the packet loss in the only network side as showing in the gray area of the figure. And the various methods have been utilized to to use utilize multiple passes such as packet screens and the the the can to achieve the load balancing and minimize the network congestion, but the air workload has a strong strong increase when the multiple AI flows, like, security is simultaneous as a lots of hopes from the destinations that if switched to the destination servers. The packet loss occurs due to the maybe occurs due to the network congestions. And in some implementations to avoid the last congestions, the sending sides can negotiate bandwidth, bandwidth with the receiving sides. But before to do some bandwidth negotiations, the the the source the source is leaves or the source and server need to know its points. So the BCP is need to be attended to to include the past information on the destination switch, and this can be implemented by averaging BTP extended community communities attributes. And so and we as a two deployment scenarios to the drafts in terms of the intra-pod and the inter-pod. As the the in intra-pod scenario, say, it's the same as the background page, and then I've taken the CPU once and connect it to the one to one to sense air traffic to the GPU same pins that connect it to the three switches as examples. For the control pins, The first, the rules of the GPU sending will be generated by the the leaf 3 and the advertiser to the spine switch. And the task management also carries the port IDs between the list three and the GPU 17, and the spine devices will then advertise to another list switch suite device list devices, including the one. And lastly, if the one servers are route of the CPU sending and then advertise the devices, the accessory, and it's a corresponding port ID information. So to to after the control plans, the steps, the forwarding plans, the steps that can be can be achieved. And then the another third deployment scenario is expanded to see multiple pause and the as taking the GPU ones connected to the one wanting to send their traffics to the GPU x in another port as examples. For the control plans, the first, the route advertisements from the remote ports, such as the route from GPU x. Advertisement to SuperSpine's devices through the multiple course devices. And then when SuperSpine's devices advertisement DPUX routes, it carries a list of the point IDs connecting the to its core devices, and Spines aggregates the routing information from DPUX, including the multiple super Spines devices and the release of the port ID is connected to the cores. And lastly, the list alerts the root and can it goes can get the advertisement SuperSpine devices as their port ID is connected to the cores. And the forwarding plans steps is similar to the scenario ones, but the difference is that there is multiple super spans and options, and then there's ports there are some multiple support that's available. And to to achieve the port advertisements, and so we can use can implement by the BCP advertisements. And while announcing the route to the connected to servers or to another port, the BCP protocols kick on the is switch towards the response switches, carries switches, address, and the port IDs informations. And by arranging BDP's standards, the community attributes, and the new substeps, the route port IDs is is defined. And the global administrations is set to the IPv4 or the IPv6 address of the switch that's advertisements and rules. This address can be the loopback address for the establishing the PCP connections. And for the local administrations, it decide to see port ID of support connecting to a switch and the servers. And that's and they so also problems is how to to implement the BCP at the time as the port IDs in the inter port port scenarios. It's actually to achieve to carry information of the multiple devices and their port size within a single route advertisement and the voice attributes losses caused by BZP route selections when there are some multiple surpasses. So there are the two options solutions. The one is made to enable to add passive functions as it may cause routine storms, and another is it to aggregate attendees from the attributes to the ensures that no no no information is allowed. And then thank you, and welcome, sir, suggestions and comments.
[00:44:15] Jeff Tantsura: I see no comments in the room. Thank you for the presentation. I've left a comment, for you, Junghi, in the chat. There is part of standard community, functionality aggregation procedures that are not consistently implemented by vendors. This allows you to take more than one route and aggregate the list of communities into the same route. This procedure would be similar for this circumstance where you have at a local router more than one route for the same destination, and you could send out the aggregated community list from that. And you can take inspiration from that from the DMZ, no procedures for link bandwidth.
[00:45:02] Jungha Zhao: Oh, thank you for your suggestions.
[00:45:09] Jeff Tantsura: K. We have no further questions. Thank you.
[00:45:18] Jie Dong: Okay. Good afternoon, everyone. This is Jedong. I'm going to give an update about this draft on extensions to the RTC mechanism in the hierarchical RR scenario on behalf of my coauthors. So firstly, we want to give a recap of this work. Basically, this document analyze the issues with RTC in the hierarchical RR scenarios. And based on we found that with the current RTC route selection rules, the routers may fail to build a route distribution graph correctly. And we also provide candidate solutions for fixing this issue in the hierarchy of our scenario. Basically, this work has been here for a while. It was initiated in 2014 and adopted in 2015. It's almost more than ten years ago. So recently, think the working group chairs, whole working group about the implementation status of the previous version, we give an update to reflect some of this information. And, also, we give some changes to the description of the one of the optional solutions. And based on the information collected about the implementations, we also add another optional solution to the draft. So here is a problem scenario. Basically, it's a topology with hierarchical hours deployed. And, here, we can see that, if we base on the current RTC route distribution or selection rules, the r one, we will select one of the RTC routes received from the level-1 RRs, and we'll change the originator ID and also prepare the cluster ID, then advertise it to its clients level-1 RRs. But since this route is received from one of the hierarchical r r's level one RRs, some of them will see the same cluster ID as their own in the RTC routes. So this RTC routes will be discarded, which means that the routers connected to these RRs will not advertise VPN routes to these RRs, and there will be no, correct or complete, VPN route distribution graph. So here are the proposed solutions. The first one is we can use add pass for this RTC routes between the hierarchical Rs so that we can ensure that the sufficient RTC routes can be advertised to the level-1 RR and to pass BGP loop detection. The recommended number of the add pass is the maximum number of the BGP client sessions in one cluster and plus one. The benefit is there's no change to the BGP path selection rules. And based on the information from the working group chairs collection, there are multiple implementations of this approach already. And the second approach is to add it in this version, which is to we can introduce a knob to allow the cluster ID loop for the RTC routes. So this knob can be enabled on the level-1 RRs for the purine session to the level two hour. And the number of the allowed duplication of the cluster ID can be configurable. This also does not require any change to the BGP route path selection rules. And so far, there's at least one implementation of this approach. The third option is, which was in the previous version, but we made some changes in this version, which is to advertise the most disjoint route to the peers. The most disjoint pass, in this case, means that the the cluster list and the originator ID attributes are diverse from those received from this peer. So for each peer, it is suggest to advertise pass which is most disjoint from the RTC routes received received from this peer. So this will require some change to the route selection rule for the RTC address family. So far, we haven't seen implementations of this kind of approach. So for the next steps, we would like to check the working group's opinion on which option should be kept in this document so that it can be be published and to guide the implementation or deployment. And I would like to consider working for last call after this.
[00:50:16] Jeff Tantsura: Thank you. K. We have time for questions. And while we're waiting in the queue, thank you for moving this work forward again. Yeah. This is a legitimate problem. We have at least two deployed solutions, so we're ready to actually move this last call and towards RFC without being held up. To offer at least one opinion, an option is to take the third method that has no implementations and move that to the appendix as a discussion point.
[00:50:44] Jie Dong: Yeah. That's a good up choice. Thank you.
[00:50:47] Jeff Tantsura: And I've abbreviated John's point.
[00:50:53] Warren Kumari: K.
[00:51:04] Jeff Tantsura: BGP-LS only fabric. I'm guessing maybe Ketan? We have a Ketan.
[00:51:11] Marvin d'Souza: Hi. Hi, Jeff. I'll be doing that.
[00:51:13] Jeff Tantsura: I'm already Yeah. Okay.
[00:51:15] Warren Kumari: Ready to go?
[00:51:16] Marvin d'Souza: Yeah. Hello, all. Marvin from Cisco Systems. Today, I'll be presenting updates of BGP LS for BGP only networks on behalf of my coauthors. Yeah. As part of agenda, what we have is changes since the last division zero four, which was presented in 01/25. And then I will briefly cover the additional use cases included in the latest revision, and I'll finally cover the implementation status followed by our next steps.
[00:51:55] Susan Hares: Okay.
[00:51:57] Marvin d'Souza: There are two revisions after one two five. Revision five was more of a refresh with some minor corrections, notably the name of relevant IANA registry. Revision six has some considerable changes. The attribute tables have been substantially reduced to recommended baseline. For node advertisements, the node name should be included and IPv4/IPv6 router IDs may be included. Link advertisements and prefix advertisements also have limited TLVs listed. The lists are intentionally not exhaustive. Other applicable BGPLS attributes may be advertised when they are required by a particular deployment or a use case. The separate SR policy and SR v six six sections have been consolidated Instead of repeating the formats as well as detailed procedures, there is no reference to the corresponding RFCs. Also, the procedures procedures sections have been updated. There are some redundant procedures which were mentioned in section five point four and five, which are removed. The remaining procedures right now mainly focus on core node link and prefix relations. There is a specific mention of protocol ID, which is seven to be used for BGP, as well as the identifier should be zero as specified in RFC nine zero eight six. So for TI-LFA in b g p only networks, we have already covered this use case in the previous session. Latest revision now includes this use case in the document and explains how topology collected through BGPLS can be can support LFA, TLFA, and efficient remote protection computations in a BGP only fabric. We have also added references to two s r v six deployment scenario. The first covers end to end s r v six domain across DC front end and the band. The second use case covers deterministic part placement for a back end traffic. The common point between these deployments is that both scenarios need an accurate view of the BGP only fabric. The topology advertised through BGPLS provides the node and link information required by the controller application or the local SRT process. The deployment details and part computation mechanisms are covered in the reference doc drafts and remain outside the scope of this document. We currently have an implementation in Sonic FRR. The corresponding pull request has been added in the slide. We would appreciate hearing about other existing or planned implementations from the working group as well. And we already requested for IANA code point allocation for the BGP route type TLV, which is added in this document. So, yeah, looking for a king group review and feedback. Thank you. Open open for questions.
[00:55:28] Jeff Tantsura: Thank you for being efficient. We have time for questions. And while we're waiting to see if there are any other so I see you're requesting further feedback. What is your sense about how soon till this is done?
[00:55:41] Marvin d'Souza: We are almost we have almost covered everything we wanted to cover. So yeah. Based on the feedback, we'll we'll try to add anything if that's needed.
[00:55:53] Jeff Tantsura: Excellent. So we're not seeing any questions in room here. Thanks for the presentation. Maybe I had a suggestion if you're, you know, thinking you're close to done, maybe we can do that at next IETf in San Francisco.
[00:56:06] Marvin d'Souza: Sure. Thanks, Jeff.
[00:56:07] Warren Kumari: Thank you.
[00:56:18] Susan Hares: I think I jumped something.
[00:56:20] Jeff Tantsura: Yeah. You jumped a few slides. The next on the agenda was p two m p policy. Mhmm. You. Mhmm.
[00:56:40] Hooman Bidgoli: From Nokia. We thought we should bring some fun into IDR with multicast, so we're gonna present this draft. Hopefully, I can explain it correctly. So the draft is actually adopted. So the draft HP is a mistake by myself, and I'm gonna present it on behalf of my coworkers. From very high level point of view, just to give you an idea what this draft is all about, you can read the first three RFCs. So the first thing is the replication segment. Basically, all it is is a data path programming of a incoming seat. That seat can be a MPLS seat or it can be a SRV six seat. And then you have you have a bunch of OIFs, outgoing interfaces that they can push down a stream replication seat on top of that packet that has been that has been replicated. One thing that you gotta keep in mind with the replication seat is that it's like any other MPLS or SRV six seat. So you can push adjacency seats, node seat. And the beauty of it is that it can actually marry unicast and multicast together. We've been having a lot of issues throughout the service providers where the service providers, they wanna send multicast from one end of their network to the other end of the network. And then there is a unicast space in the middle, which does not do multicast. Usually, they do tunneling, multicast over LDP or SVPTE, you name it. But now with this technology, you can actually start having a seed list, and you can shoot the packet through the unicast domain, s r v six or s r MPLS. And by the time that the packet gets to the other end, you have get rid of all the node seed, adjacency seed, and you're back to the multicast seed, and you start replicating again downstream. So when it comes to multicast, another point is that you need to somehow bind that multicast through tree to a VPRN or to a certain route, SG. And that's where as our point, the multipoint policy, RFC ninety nine sixty comes into play. So, basically, you need a policy or, if you will, a binding seat to actually push the multicast traffic from the source into this tunnel, and eventually, it comes out, on the other end by removing all the seat. So that's, ninety nine sixty. And, obviously, as all the good things go, you need to have OEM tools, which is the ninety nine sixty one, which tests your tree end to end. And right now, it's only for MPLS, but eventually, we're gonna bring in a draft for s r v six as well. So the next draft, which is the best draft, is the overlay. So there is a BGP overlay that you can actually signal the multicast routes between two PEs, and that's RFC to be 10,018. So that job is almost done as well. And then there is a piece of draft. One point I wanna put on the table right now is that when it comes to this technology, there is no underlay. There is overlay, which I explained, which is the BGP. But when it comes to the underlay, it's either p set. You can nail it down with p set, or a controller, I should say. I shouldn't say p set. With the controller, you can nail it down, or you can nail it down via CLI or Yang model. So you can actually go into the, into the router and build that data state, the replication state through the router via some Yang model. And last but not least, obviously, when it comes to a controller, you can download the state via two different protocol, PCE being one, and then, obviously, BGP as our policy is the next one, which is what we are presenting here. So let me jump into a little bit of eye candy with the picture to kind of explain what this is all about. So I already talked about point to multipoint policy, which you can see at the router a. And under the point to multipoint point policy, like unicast, you're gonna create candidate paths. So all the goodies in the candidate path, how you go between one or the other is exactly like unicast. So I'm not gonna explain that. But when it comes to the multicast, when it comes to a tree, usually, trees, they get optimized a lot, and it needs to be a fast optimization. So that's why make before break is very important when it comes to a tree optimization. This is why we added what we call the path instance under the candidate path. All it is is that if you traffic engineer through the network, point to multipoint tree, and you want to optimize that tree somehow rather going to the next candidate path, you can do the optimization under the same candidate path by creating two point to multipoint instances. All point to multipoint instance is is the tree, replication, state. So that's all it is. And then you can do make before break, and you go from one instance to the next instance. So that's one of the things that is different between unicast and multicast. The next part is, obviously, you need to go into the data path, and you need to nail down the multicast state incoming interface, incoming seat with a bunch of outgoing interfaces and outgoing seats, and that's where the replication segment comes in. There's gotta be a way to actually correlate between the candidate paths or the path instances and the replication seat that you see at the bottom. And that correlation comes via the, tree identifier, which is the route ID, tree ID, path instance ID. So it's kind of important to understand that these are two different object when it comes to the programming onto the router. So you program the point to multipoint policy, and underneath the point to multipoint policy, you go, you nail down a second object that is a replication. That's important to understand when I go into the route types that we actually chose. So I already talked about most of this stuff. You can go through it and read it. I don't think there's anything here that I have not touched on this slide. I'm gonna go to the next slide. So the only thing I wanna touch here is that, as I said, there are multiple ways of nailing down, this three VI controller. So there is no underlay. The controller is the way to go, or you can use, actually the yang to build these point multiple policies or the replication seed. But there's two way of doing it with controller. You can do PCC-initiated or PCE-initiated. If you do PCC initiated, the overlay, which is the BGP with NG-MVPN routes, if anybody knows draft sixty five fourteen, I do apologize. It's a wonderful draft with a lot of route types. That was beyond my time, but it is what it is. So if you read that draft, you see how different routers, they discover the multicast routes. So you discover the multicast routes via the overlay, and then the PCC or or the router sends all that information up to the controller, and the controller does calculate the the tree between the root and all the receivers and nails down that information. Another way of doing it is that the PC just wakes up, you go on the PC or the controller. Sorry. You go on the controller and you say, I wanna nail down the tree from root x to a set of leaves, and you manually configure it and goes and and it actually nails it down. So now the funnest stuff, what we were requesting in this draft in IDR is that we're gonna have a brand new NLRI, and we're gonna have three different route types. Having a lot of route types apparently is a multicast legacy. So the reason that we have three different route types is that as I explained, you need to have a binding seat, which is the point to multipoint policy route. So you download that binding seat and that policy that actually connects to the VPRN, next generation VPRN, and then you have the route type of the replication segment. So the binding seat is the incoming seat that identifies your multicast route. And then you have a bound bunch of outgoing interfaces, And that's where the third route comes in, the OIF route. And the reason we separated the binding seed from the OIF route is because the list of, leaves, they can fluctuate during the life of the tree. One leaf can go away. And if it goes away, you need to modify the OIF list to remove that outgoing interface. So we just thought it is more efficient to separate the incoming packet, incoming information from the outgoing information by having two different routes. So that's why you see the three different routes. I'm not gonna go through the details. We can actually go through the details and and read all about it. So these are all the details. I I think we can skip all this stuff. Yeah. But this is what the draft is all about. We wanna make sure that, you know, it's the same draft and, you know, it's in part with your expectation, and we are looking for comments. That's all I got.
[01:06:06] Jeff Tantsura: Sue, did you wanna comment on Jeffrey's tracking into Pardon? Jeffrey's point point multi point document. Did you wanna comment about the
[01:06:12] Susan Hares: I I played it in a previous session with him. Okay. So
[01:06:19] Yannick Voyer: do we have do we
[01:06:20] Jeff Tantsura: have any further questions? The the point Sue and I were mentioning while we're waiting on that was, you know, the overlap with the point to multipoint BGP state injection draft that Jeffrey Zhang and others have worked on. My my question is not about that document, but the existing MVP and procedures. As you notice, it has plenty of NRI. Did you have any plans on doing any interrupt with that, or is this intended to be ships in the night?
[01:06:45] Hooman Bidgoli: No. This is gonna be ships in the night. Basically, we wanted to make this very close to the unicast, the way that the unicast stuff are done. We didn't wanna deviate from that. As I said, this technology marries multicast and unicast together.
[01:07:01] Jeff Tantsura: Mhmm. That's why
[01:07:01] Hooman Bidgoli: it makes sense to us to do this draft. You know, there's always multiple ways of skinning the cats. So
[01:07:07] Jeff Tantsura: Understood. And much like that other draft, we'll want to coordinate with best to make sure that we do the multicast stuff right.
[01:07:12] Alvaro Retana: Sure. Alright.
[01:07:14] Jeff Tantsura: K. There are no questions. Thank you.
[01:07:15] Warren Kumari: Thank you.
[01:07:43] Susan Hares: I got the right one. Just a minute. Yes. I think so. You want the right one?
[01:07:52] Jeff Tantsura: This is no. This is the SBFD one. Pardon? SBFD.
[01:07:56] Jiandong Jin: No. Not this one.
[01:07:58] Susan Hares: Previous one. Hold on.
[01:07:59] Jiandong Jin: Not this one.
[01:08:00] Jungha Zhao: Thank you.
[01:08:25] Jeff Tantsura: Yes. Yes. I'm ready. Yes. May I begin? It does now. It works.
[01:08:38] Jiandong Jin: It works?
[01:08:39] Jeff Tantsura: No. Click again. No. This one. So did you delegate? Pardon?
[01:08:50] Susan Hares: I've done it.
[01:08:53] Jeff Tantsura: You have it backwards. This one? Yes. Okay.
[01:09:01] Jiandong Jin: Hello, everyone. This is from Mobile. Today, I have five minutes to briefly present the updates for policy intentions for BFT configuration. This draft was first presented by my at Shenzhen meeting. So, currently, as our policy are typically distributed by SDN controller to the heading nodes using BGP SR policy or PCP protocol. However, the associated SVFD sessions from for the SR policies are provisions through NetConf or manual configuration. Provisioning ASR policies and SPF decisions using different methods increases operational complexity and it tends provisioning time. There's already one working group draft in PCE working group. It extends PCEP protocol to carry SPFD parameters during SR policy provisioning. So this document, it has BGP SR policy protocol to provide the same capability. So what's new in this version? We made major revisions. First, we removed the intentions for BFT configuration. BFT requires configuration on both the header node and the endpoint node. Since the ASR policy is only distributed to the header node, provisioning PFD together with the ASR policy is not appropriate. Second, we optimized the SBLP parameters and their encoding format. Then we revised the error handling behavior. An operational considerations section is added in this version, And we added Jeff as a contributor. Thank you very much for your help and contribution. This is the optimized encoding format for SBFD sub-TLV. It's dramatically simplified. Only your only your discriminator is in the fixed field since only this parameter is required or mandatory for for the s b SBFD sessions. We provide nested nested optional TLVs to carry the optional parameters, such as the desired minimal transmit interval and the detection multiplier. So this is the the encoding formats for the option TLVs. We also revised the behavior and hand handling. Malformed sub TLV is no longer treat as withdraw. The receive the receiver must ignore the sub-TLV, continue processing of the tunnel encapsulation attribute. Why? We want to align with other optional sub-TLV in the tunnel encapsulation attribute to avoid taking down the whole asset policy for a b f d product error. So we will skip this. For for next steps, questions and comments are appreciated, and we will revise the document based on the received input. And we'll be this document will be ready for the working group adoption before next meeting. Thank you.
[01:13:09] Jeff Tantsura: We have time for some questions. And while we're waiting, have you taken this document to present to Spring? To Spring? Have you presented this to the
[01:13:21] Jiandong Jin: Spring working group? No. Not yet.
[01:13:23] Jeff Tantsura: Okay. I would suggest also bringing it to Spring's attention since this use case covers the SR for BFD.
[01:13:31] Jiandong Jin: Okay. I can but there's already one working group doc in the p c p to do the same? Yes. This thing
[01:13:38] Jeff Tantsura: this this is just to make sure that they know that we're also doing it for BGP. I'm not saying to adopt it in spring. Just let them know know as part of the work.
[01:13:46] Jiandong Jin: Okay. I can do this.
[01:13:48] Jeff Tantsura: Yes. Coordination is what we're looking for.
[01:13:51] Jiandong Jin: Okay. Okay. I'll do it.
[01:13:53] Jeff Tantsura: Okay. And we have no questions. Thank you for the presentation. Thank you.
[01:14:07] Liuyan Han: Hello, everyone. Could you hear me?
[01:14:09] Warren Kumari: We can hear you.
[01:14:11] Liuyan Han: Okay. Thank you. This is Leanne from China Mobile. And sorry. I cannot see. Okay. It's okay now. But not this one.
[01:14:30] Susan Hares: Not this. Yes.
[01:14:31] Liuyan Han: But the slice is not to the right one.
[01:14:38] Jeff Tantsura: It's flex algo one.
[01:15:25] Liuyan Han: Okay. It's right. Thank you.
[01:15:30] Yannick Voyer: K. Please begin.
[01:15:32] Liuyan Han: Okay. Okay. Thank you. And I will go through the draft updates quickly. And this draft is about the BGP extensions for intra domain flex algo with s r v six. Sorry. It's a little slow. Give a second.
[01:16:02] Jeff Tantsura: Can see slide two remotely.
[01:16:04] Liuyan Han: Okay. Okay. I can see two. And this draft was presented at the last meeting, and so here, I would like to briefly introduce the background information. The typical scenario is for the multiple natural domains that managed it by the same operator. The same flex elbow is defined with the specific constraints such as the low latency in each domain, and the and the low latency passes are required across the domains. The problem is that when the s r v six locator is advertised to another AI through BGP, the associated algorithm ID is not carried together. So the receiving AIs only sees regular IPv6 prefix and computes the default shorted pass. So as a result, the cross domain flex algo pass does not work here. The goal of this draft is to carry the algorithm information along with the IPv6 prefix in BCP across domain advertisement. And this draft defines a new flexible extended community to carry the algorithm ID associated with the IPv6 prefix. And this allows the algorithm algorithm ID to be automatically carried over when BGP rules are redistributed into IGP. And specific way definition is shown in this figure. We received valuable feedbacks at the last meeting, and I really appreciate it. And we update a new version first. We add some text to describe the relationship with BGP CAR approach in this introduction section. We obtained that the CPR provides a more general solution. At the same time, we had no data for deployments where the same FlexEco is used across domains. Our approach is more simple and straightforward. It no need for manual local policy matching from the Flex-Algo ID to the Color value. So this slides, the distributed device can learn the information automatically. As mentioned about, we'll also update section two according to the further highlight of the application scenarios of this draft. The same flags are go is used in multi domain to represent the same constraints for past computation. And the last one, we ID that the RFC 9723 as a normal reference. Next step for we would really appreciate any commands or feedbacks, and we start we'd like to ask the working group to consider adoption. And thank you very much for your time, and thank you again for the valuable feedback. That's all for the presentation. Yeah.
[01:19:50] Ketan Talaulikar: Hey. So this is. Shouldn't this information be a little more this seems like a very critical piece of information to carry in extended community. What happens if the community is filtered? And then, again, the IGP FlexAl goes to sort of provide a constrained way of computing SPFs. So, what happens if you have same prefix carry different flex algos or IDs? The BGP best part will probably pick one which is not what you want also. So you probably wanna think through this carefully.
[01:20:33] Liuyan Han: Okay. Thank you very much. I I think last meeting, we also received the similar feedback. So this version, we have highlighted the scenario. The scenario we want to use this approach is for the same operator and different domains. So the flex ID can be arranged by the operator. So if the flex ID is different, we think that we can migrate from the configuration better. Maybe on this scenario, the BGP CAR approach will be very similar, not too much difference. So we we want to constrain the scenario with the same FlexEagle ID. Do you think it's suitable?
[01:21:48] Jeff Tantsura: This is Jeff. So following up on what Kay are saying, in the we have two circumstances. The first one is, you know, as a community, this has all sorts of security considerations. You know, this is overlapping the same feedback we gave the authors of the UPA draft. You know, this is a generic, no problem. We have also, as Carrie pointing out, many use cases trying to carry a flex algo, you know, have the same destination over more than one topology. And if you're going to have disjoint forwarding, it's important to be able to send more than one route for the same destination with the different flexagos. What you're proposing is acceptable for some scenarios, but maybe not others. So our collective suggestion, I think, is to spend some time thinking about those different scenarios and whether that impacts your proposal.
[01:22:47] Liuyan Han: Okay. The last words I want to say that it's just for simple and exact scenario to deployment to provide a solution. So we we don't want to cover all the scenarios.
[01:23:13] Jeff Tantsura: So while I understand your reluctance to want to cover every single scenario because this is a very generic feature, it is a very generic feature, and we'll probably need some of that discussion. And, you know, this is a good time for, you know, discussion on the mailing list to help refine that.
[01:23:32] Liuyan Han: Okay. Okay. Thank you. We can continue on the mailing list. Thank you very much.
[01:23:37] Jeff Tantsura: Thank you. Yes. NRP is next now.
[01:23:56] Jiandong Jin: Excuse me.
[01:23:57] Jeff Tantsura: Not that yet. He should look at it.
[01:24:01] Susan Hares: No. But just minute. We've got it.
[01:24:04] Marvin d'Souza: There you go.
[01:24:05] Jeff Tantsura: There you have it.
[01:24:09] Jiandong Jin: Good afternoon. From China Mobile again. This time, I'd like to present this draft BGP extensions for network resource partition on behalf of my coauthors. This draft was first presented by me at Shenzhen meeting. First of all, let's recap the core concepts. What is NRP? NRP is network resource partition. It is a logical subset of network resources assigned to a specific purpose. It is under a network resources used to deliver network services network slash services to our customers. NRP is resource concept. It is also to past concepts like as our policy of color. Let's think of an RP at the lane on on a highway while SR policy is the route taken. There are there are control play and data based solutions for NLP. For data play solutions, as stated in in draft-ietf-spring-sr-service-programming, A dedicated NRP select ID must be carried in data packets to identify this associated NRP that is used to enable the packet to be processed and forwarded over the network resources allocated to that NRP. A control plane mechanism is needed to inform the ingress p node of the NRP ID that it must encapsulate in data packet to serve as the NRP selector ID. IDR as our policy NLP draft defense one such control plan approach and it tends BGP as our policy to associate it as a policy candidate path with a specific NLP ID. This approach bans as a policy to NLP on one to one basis, which limits limits the flexibility and introduces significant operational overhead as the number of NRPs increases, especially when multiple NRPs share the same SR policy path. Furthermore, this approach cannot be used in scenarios without as our policy deployment, such as SRB or FlexAlgo. To address the limitations, this document proposed an alternative control solution. We extend BGP to carry the NRP ID via the extended community attribute. When e egresspe node advertise the customer private route to to to to the ingress PE. The corresponding NRP ID is carried in the in the community introduced in this document. This document does not change any existing data plan encapsulation and processing mechanisms. Existing existing data plan solutions are act are applicable. So why a new NRP ID if candidate community? Why not reuse the caller extended community? This is the frequently asked question. Caller extended community is to identify a path that is used to steer traffic to a specific route. It cannot distinguish between different resource partitions that share the same path, which will lead to one to one by the so an IP ID color-like is introduced in this document. It is used to identify a resource partition. It is used for resource isolation and quality of service enforcement based on customers' requirements. It enables many to one mapping. Multiple NRPs can share one as a policy path. It is clearly separated from past steering from resource assignment. It can be used in scenarios without as a policy deployment. This is a concrete illustration. The red line from the head end node to the endpoint represents the path of as a policy with low latency and abundant reservable bandwidth for NRPs. This is the the the the route with that. NRP is provisioned at each hub along this route act as the lanes allocated based on customer requirements. There are four NRPs illustrated in this diagram. NRP one is for customer a. NRP two is for customer b. And NRP three with eight megabits per second is for customer c. SDN controller can distribute the SR policy and configure the NRPs along the SR policy path. We deploy one single SR policy path while numerous network slash services can be carried over it as long as sufficient reservable bandwidth is available for new customers. For route out advertisement following the set setup, network slash services can be offered to customers when advertising the customer service route from the endpoint to the head end, attach the address policy color and NRP ID for each customer. See, this operation can also be performed manually or through an SDN controller. For traffic forwarding, when the head end nodes received packet matching the route with color and ARPID, it encapsulates the packet with the corresponding ARPID and SRP policy pass, then then it forwards the packet to the first segment of the SRP policy where the packet is tree treated and forwarded using the network resources allocated to this NLP. Every segment along the ASR policy needs the NLP IP in the packet to
[01:31:12] Jeff Tantsura: Using data in your mic.
[01:31:14] Jiandong Jin: To handle it.
[01:31:17] Jeff Tantsura: Apologies. Sorry about that.
[01:31:19] Jiandong Jin: To handle it properly with the network resources allocated to to the. So, again, we only provide one mechanism to tell the head end nodes the NLP idea that it should use to encapsulate it in the data packet. Existing data based solutions are applicable. Since NLP is decoupled for SR policy, the mechanism proposed in this draft also applies to SRB and flux algo logic topology. So this this is utility community attribute introduced in this document. We call it an RPID, utility community. It's very simple. A new type is solicited to be assigned by Anna, and only one field the the value field is used to carry the NRP ID. So for next steps, questions and comments are greatly appreciated. We will revise the document based on the received input, and we solicit the working group to consider adopt this draft draft, which is very simple, and the purpose is is. Thank you. That's all.
[01:32:46] Ketan Talaulikar: Hey. I'm sorry. Pressed the wrong button. Apologies. But curious question. How many color communities can you carry on a single n r for different NRPs on a single route?
[01:33:03] Jiandong Jin: You mean for for for route Is
[01:33:06] Ketan Talaulikar: it one to one or is it many to one?
[01:33:09] Jiandong Jin: Many to one. The color is the same, and the NRP ID is different.
[01:33:15] Ketan Talaulikar: Will it exceed the normal BGP packet size and two fifty five communities?
[01:33:24] Jiandong Jin: The the private to the private route for different colors are advertised by the endpoint separately.
[01:33:36] Ketan Talaulikar: So it is one to one? One route to one color community?
[01:33:42] Jiandong Jin: One NRPID for one customer, and many customers can share the same as our policy path.
[01:33:55] Jeff Tantsura: Probably should follow-up.
[01:33:56] Ketan Talaulikar: Yeah. I'll take it on my email list. Thank you.
[01:34:00] Jiandong Jin: Okay.
[01:34:01] Jeff Tantsura: Do we have any further questions? Okay. Thanks for the presentation.
[01:34:09] Jiandong Jin: Okay.
[01:34:10] Jeff Tantsura: So we've reached the break time. We will resume the next session with the presentation on Source-Selective BGP and Beach BLS, and we shall resume at top of the hour. See you shortly.
Session Date/Time: 24 Jul 2026 14:00
[00:00:04] Susan Hares (Sue Hares): At and your kind permission, I think we'll should we start two minutes or we're gonna start two minutes early. Come on. Sure,
[00:00:23] Yuzha (Yuja): Hello, everyone. I'm Yuzha from lab, and thanks to chance for giving me the opportunity to talk first. And the the the topic of my presentation is about the pro problem statement and the road map for BGP flows back monitoring. Thank you, And it's a new draft it's a new draft and first introducing in IDR. And here is the problem statement. As we know, the BGP flows back is widely used in carrier network for traffic handling, steering, or the attack mitigation. But the existing flows back only provides what we control where the successful rule propagation does not imply effective enforcement. And especially in data plan, the enforcement outcomes are not directly visible to the controller, And, also, the flow spec rules may become ineffective due to some reasons, such as policy conflicts, installation failures, and some, something others. And as the feedback from some operators and the device vendors, we think it's a real problem in operational network, and they think the operator operate or operators may need execution monitoring to understand the rail enforcement behavior and continuously optimize traffic handling strategies. And to achieve end to end flow spec monitoring, we designed a framework as shown in the slides. It contains three three plans, which are the intent plan, control plan, and data plan. For for this for this frame framework, it covered the left circle of the flow stack monitoring from the traffic handling intent to policy generation and to the enforcement or the observation feedback and also have a state machine in the controller. And the different telemetry may contribute different information. And the key points we think is the monitoring can now touch it by a single protocol alone. So maybe we need a whole framework to describe this work. And we identify five key information categories to achieve the monitoring. And the first one is the road life circle. It tracks the policy life circles through machine status, and it it is maintained in the controller and using the other information from the telemetry mechanism. The second information is route event routing. It's a events driven reporting of per road control plan changes, and we have we have to upload a draft in grow working group to doing some extension in BMP. And the third information is about the route status and the statistics. It provides the per router flow spec status and the statistics flow spec. It may also have a extension in BMP. And the fourth is the traffic treatment outcome. It's observed data plan treatment results, and we also upload a new draft in OPSA work working groups this time to doing some extension in IPFIX. And the last one is the operational realization state. It describes the device side flow spec enforcement realization, and it may maybe use some YAM based model or some others. And each of telemetry protocol can be be as a part of the technical components in the framework. And we searched the ITF ITF and the funding there have a gap between the existing draft and the the real deployment. So the circle in the table is what we think may having some extension to cover the gap, and that is what we are trying to do. And there also have a road map in the slides, and we have the upload to draft the IDR. And this one is about the roadmap to giving same problem space to describe the problem statements. And the feedback binding is extension and inflows back way too and also have some others work in grow and OPSAWG. And for the state machine, they think it's not suit it's it's not belong to each of telemetry protocol. So we put it in the road map draft, and it will maintain the controller and using the different information from the device. In the next, we are hoping to find collaboration a collaborator to refine the road map and the related protocol work. And we're also welcoming early implementer to validate to validate the the this function. And also because it's across different working groups, so we're we're really hoping to collect feedback from the different community. Thank thank you so much.
[00:06:26] Jeff Haas: Do we have any questions? So on behalf of Robert, since he does not have mic access at the moment, his comment in the chat is that this information is useful on the controller only and that BGP is a spray and tray protocol. And he doesn't think that this information should be in BGP. And in the moment, wearing coauthor hat with Yuja, you know, that is part of the problem is not everything here can or should be carried in the BGP for this ecosystem. So she has on the prior slides, you know, some of the components will have a feedback mechanism about installation state monitored through BMP and, you know, forwarding effectiveness through things like IP fix. So this work is definitely going to be hitting many working groups, and it's gonna be informed by what we do here in the, you know, IDR for flowspec.
[00:07:24] Jimmy (China Mobile): Thanks, Jeff.
[00:07:26] Jeff Haas: And I see no further questions.
[00:07:28] Susan Hares (Sue Hares): Thank you.
[00:07:29] Yuzha (Yuja): Thank you.
[00:07:34] Susan Hares (Sue Hares): So I have one bit of feedback, for your chart. The question is whether BGP LS should be included. I I I have some quandaries, but I for completeness, we should talk about that. Thank you.
[00:07:53] Jeff Haas: K. We're gonna go for the prior presentation.
[00:07:57] Susan Hares (Sue Hares): I should complete the chair slides and then
[00:08:01] Jeff Haas: We could return the chair slides, sir.
[00:08:04] Susan Hares (Sue Hares): K. Back to eight. And then it'll just be a moment and okay. This is our second session. You saw or should know the note well. Hopefully, you've all seen the ITF note well. What this session is under ITF behavior policies and IPR policies. Please see the note well in the beginning of the first the second session and the first. The drafts for today, we had the problem statement, the road map map for getting feedback back out of flow spec information. Now we're gonna go into some filters and some actions, and that's the remainder of the specs we have. But first, I'll go through the basics of flow spec v two IP basic. IP basic because we're focusing on filtering IP related information. Okay. I don't see anything. Let's go to the next presentation.
[00:09:23] Jeff Haas: Yeah. So the next one was supposed to be the follow over from this half. Gee, I'm not actually seeing it in the list. Yeah. I think we have to actually physically move it.
[00:09:34] Susan Hares (Sue Hares): Let's just go on to the flowspec.
[00:09:38] Jeff Haas: Yeah. Let's do it for
[00:09:39] Susan Hares (Sue Hares): IP basic, and then we'll come back to the group. Unless you've got it, in which case
[00:09:45] Jeff Haas: Nope. We will go ahead and do that next then.
[00:09:46] Susan Hares (Sue Hares): So let me go ahead and do that. Okay. This is a revision of flow spec we've been talking about for a while. We think we're down to something solid that other drafts can work on and then implement. So, again, as you've probably seen in previous, if you've been here a while, you've seen it in previous sessions. If this is your new first step into flow spec v two, let's go through the basics. The changes are, we always had user order, and that's the difference between flow spec v one and flu v two is the format of the of the packets and the fact that you could have user ordering. And our whole point is after that, we just want defaults to work. We want to have partial deployments work and we're just taking actions in extended communities because they pass fairly well through the network. Okay. So I'm gonna first look at the changes we've had since the last IETf and then some details on the proposal and then some assignments for filter families and components just so people can get started and issues about partial deployments and actions. Anytime you wanna take up, let me know, Jeff. So, again, the current version uses frame order for components. That's the difference. Previous ones choose framed order for just the filter families, and, we decided that frame order, meaning what comes across the wire, is the best setup. This is the header change. We made a tweak to put the dependent filters change first before the user order, but everything is in the same content. Then we have filter families, which have a type of length and a value. So filter families are very flexible. They can do lots of things. Let's look at the types that we've generally set, the component flags. I will come back to that in a moment once I do the filter family examples. The filter families are what you might expect, l two MPLS f SFC tunnel traffic, but the one we're going to focus on most is IP basic filters. To those filters, we're going to go ahead and add a component. We changed the components to have, flags that I'll discuss in just a moment in four bits and 16 bits. We sort of stole four bits off the top. Why did we steal it? Well, because we would like to have a signal that some components are are optional and if they can't be installed, they can be ignored. The default is mandatory. If you can install it, the whole filter term is not worked. So those are the two pieces. Dependencies. Dependencies is essentially grouping. If a dependency filter is zero, then there's no dependencies. If it's non zero, then all that share the same numbers share the same fate. So so example, do you wanna give the DSCP example?
[00:13:45] Jeff Haas: Yeah. Sure. Can give that. So picking on one of our own platforms, we have something that doesn't universally support DSCP between our different platform types. So this means that flow spec originated with no you with a the same format through the entire AS would selectively install on some components and some not based on how that would work. So the easy example is if you're trying to actually do a batch on DSCP, you know, for a given destination, and that's part of, you your match criteria, DSCP often being used for class based filtering. If you can't match that, you may end up blackholing everything because it's basically your escape hatch for your firewall rule. So in the current flow spec, there's really nothing we can do about that. The platform is either going to accept it, reject it, and, you know, exactly how that behaves will impact how things work. The alternative with flow spec version two is if they do share fate as a, you know, filter chain, these things can be bound together where if, you know, the same device doesn't support rule one where the SCP is present, don't do either of these things because they're not safe to do unless you do them both.
[00:15:01] Susan Hares (Sue Hares): So that gives us something that we can share faith between various filters. I think I went to film filter family ordering as that we did in both time going through actual packets. Now what about components? We tried to take the same thing. And this is where we have IP basic. And for those who have IDs, I tried to look at all the proposed IDs and give you a number. Notice we've got lots of spaces. We're spacing out by 10, and we have a lot of space. One thing we did is I tried to sign them so that if you had a draft, you could go home and say, oh, this is where Sue put it in first. I can use that and I can go home and write my draft and come back and you have something to start with. This is sort of a kick start. Of course, everything has to go through adoption and implementation, but we're trying to kick start this effort with some assignments. So if you have a draft and you don't see your a number for you on this list, come see me. We're just trying to kick start the whole effort because we had 20 plus drafts, and you've all been waiting for me to set up the Jeff and I to set up the filter families. Now this is IP basic filter families, which uses a AFI/SAFI and IP as one of the other components. You could have a filter family that combined IPv4 destination components components with I p v six. If you're interested in that sort of thing, come talk to me.
[00:16:58] Jeff Haas: I can jump into that one real quick. So one of the things if you go back one slide, this is really the tricky piece of flow spec version two. Now we've got a stable PDU format at this point, so hopefully, that plus procedures are now boring. That's exactly what we're looking for. People can implement things. Using the example here, 8955 has no destination as code point one, source is code point two, etcetera. You know, they had no space in them. This meant that if you wanted to add on, as we see here between, you destination and source, you know, some other match criteria so that the sort order of the firewall was natural, we couldn't have done that at 8955. And we took first stab here on this, you know, page by starting by numbering by 10, and Sue had to do that two or three times to get things in the lines. You know, those of us that are old enough to use programming languages that actually had line numbers, we remember these remembering exercises quite well. We're probably going to have to do one more around because what we've found from this exercise is that we ended up crowding things just with what we have today, and we're trying to future proof this. So it's likely there'll be one more round of remembering, maybe by hundreds. We have enough space for this, and that should hopefully leave us enough space for the future.
[00:18:24] Susan Hares (Sue Hares): So but this is only for the IP basic filter family. If you have another filter family, you might be able to use another definition of component. So this is a highly flexible revision because we really don't wanna do this a couple more times. We think two is fine. I think Jeff just went through that partial deployment. Jeff, you wanna go through partial deployment?
[00:18:53] Jeff Haas: Yeah. So our headache with no firewalls, in general is that, you know, capabilities vary widely depending on what type of platform you have. And if you have, you know, any network, it's made out of a set of heterogeneous SNO components. Some of these things might be really good at banging, you know, packets fast. Some of them might actually go down to layer four and do clever security things. And we're trying to support multiple use cases within flow spec, which means that we have two headaches for deployment. Headache number one, if you want to originate no flow spec programming in the network, you want to send programming that can be absorbed and used successfully at some portion of the networks. You know, example, the black nodes in the the graph with maybe, you know, more complicated layer four filters, and then maybe other devices that have to be, you know, slightly, you know, stupider that may take, you know, less stuff. And this also goes to the second motivation, which is we will have, you know, both flow spec version one and flow spec version two mixed in, you for a period of time. So we do need to have a story that allows these different AFI SAVI's to mix appropriately and to carry programming back and forth when they're necessary.
[00:20:04] Susan Hares (Sue Hares): There is a discussion in the draft about ordering flow spec in v one and v two. Carrie's got a question.
[00:20:15] Carrie / Chunghwa (HSBC): Hey. Just a quick question. Do you envision a case where a filter is announced using f s p two and would never be a backwards compatible? Or
[00:20:29] Susan Hares (Sue Hares): Oh, yes. Absolutely. There's there are several cases where a filter will not be backward, but compatible. There was not space and the numbering is going to be different. Okay? We finally took that break in order to get everybody off and going because we weren't really seeing our initial hope was that it would just be a direct transfer that had so many restrictions and so many problems. We eventually went to not a backward compatible. Same functionality, but the numbering's different and the PDO is different. The base functions are there. I think you can see it, but we had to change that. Good question, Care. Now that's all about filters. FlowSpec is two things, filters and actions. Okay? What we're going to do for the first round is allow extended communities to work with both flow spec v one and flow spec v two, but we're gonna require some extra text. Let me go through that. There are there are several types of actions. When we went and and Jeff and I went through all the proposals for actions several times, and we were able to group them in types of actions. There's furthering a constraint of actions, grouping either by interface, by configured something. You have a group. And that will interact because if you group by interface and then you group by another, ID, maybe a sub ID or something, that would be two different things that might interact. So all the drafts we'll need to do if in they're in the same type is to explain or to, you know, say, implementation specific interaction. If you're in a different category, for example, grouping versus applying traffic shaping or some change to the packet, you probably would be okay. So what we're going to require is if you're in the same type of group that you put something in the spec that describes how you're going to interact or you assume you can't have two actions in the same group. This gets us down to very few interactions where the majority of conflicts are in the redirect, but most people pick one type of redirect. So in the future, however, if we wanted to do more order, we're going to have BGP community container. But we decided to give you rules here and adopt as many as we can with these basic filters and the extended community actions, and then we'll go off and work on making a consistent b g b community container. And that's ingesting my requirement. Now there's one other thing that we've decided to let go by configuration so we can kick start, which is the failures of an extended community action. You might, after a failure, want to stop processing, continue processing, or decide between the two. For example, if you can't set your DSCP, you may not want to sample or redirect. K. So what was the minimal implementation? The minimal implementation is one affixaffy pair, probably IPv4 or IPv6, some extended communities, the basic filter family format, and a set of filters. You may say I don't know those filters. That's a partial filter discussion. Okay. The other thing you'll find in the draft is careful writing of validation, both syntactic and semantic checks. This borrows heavily from the flow spec v one, so I won't go over it. And I think that's it. LRI checks is here. Syntax limits. Do you wanna go through that, or can we go on?
[00:25:25] Jeff Haas: Just hit it very briefly. The primary headache with flow spec is that it's, you know, basically machine code. It's really hard to look in here and decide what to do, so we have to be as safe as we possibly can. When we can actually do a parsing of the contents to make sure it structurally sounds and tactically whole as TLVs, want we to make sure that we can do as best we can to know what treaties withdraw.
[00:25:51] Susan Hares (Sue Hares): The route validation comes out of v one, which is you're trying to validate the route against the best unit gas. If the pay path is empty or the AS Confederation, there's specific language that was added to flow spec v one, we are inheriting that. And I think I've gone through the next steps, but we're I'm gonna work with each of the existing flow spec working group drafts to revise and republish under flow spec v two. We will start adoption of individual drafts in August, and we will tend to say, there any objection while we go through all of these adoptions knowing that there's gonna be a lot of refinement. And for extended community actions, we will adopt both for v one and v two, but we'll have to add a section. And I think I went through the rest. Any questions on the basic and where we're going? Okay. We held an interim. We've announced it here. We're gonna consider that since we haven't gotten wild stampedings or people finding a a tomato to throw it, Jeff and I, or whatever foods you have out there that we're on the right track. Okay. We're gonna go through the Sav rule. That was the yes. Come on up. That was skipped last time, and I gave you the overview so you could be thinking about that, and we'll come back to more of that. Thank you.
[00:27:40] Representative from China Unicom: Hi, everyone. I'm from China Unicom. Today, I'm behind my team to introduce our draft with our tidings, our related information using BGP LS. LS. Well, I quickly introduce the updates in this version zero five. The first is clarification of the no scope of a SAV rule. This word is is stated that A SAV rule is scoped to the node identified by local node. Describe to TLV, it carries SAV-related information originated or made available by. And then the now I will not intend to be general purpose mechanism for distributing our strain and the poor interface Internet go pre fixed table course and NTRBGP OS deployment. And the next is alignment and the extensibility of the SAV mode TLV. It's worth in that the currently defined mode values are aligned with the enhancement met modes in the general SAV capability document and are used as misalignment mental data formatry. If future SAV mechanisms introduce the informant semantics that cannot be represented by the current to date model failed, may the current corresponding BGPIs representation will need to be extended or updated. And the the next is operational consideration. This worry requirement that implementations and the operators control the origination and the distribution of cellular analysis using dimensions such as control it for cellular mechanisms. My insurance application should also support incremental updates and territory patient availability caused by the intentional distribution policies. And the next is color coloration of melt source data. And this is following thinking. We received the a youthful comment from Jack. Thank you. And if a contour controller already has a complete and real time view of all cell use collecting the same data through BGPIs, it limited the value. So we think that device, if forced cell use may come from outsourced. For example, local server agents, region regional controller, domain controller, the local policy pricing, the controller may know the intent policy, but the final rules on each device. The local com computation and the policy merging may create gaps between intended and actual cell station. And the BGP-LS could apply the control of view of the rules actually enforced by devices. And the details of the consideration, we will update in next version. Thank you. More comments and discussion, welcome.
[00:31:20] Jeff Haas: Any questions? So one of the feedbacks that I had given the authors as part of our discussion is that this is mostly a consideration for large scale for BeachBLS. So we're we're going to be running into this as a more general use case, not only for Sav, but other use cases as well. So we may, as a working group, wanna take a look at scaling mechanisms that help out LS, And I suspect the wisdom from LSVR might actually be able to help us as well.
[00:31:48] Susan Hares (Sue Hares): K. K.
[00:31:49] Jeff Haas: Thank you.
[00:31:51] Susan Hares (Sue Hares): Jeff, could you give me comments on hierarchy and scale? Yes. Okay.
[00:31:57] Jeff Haas: And prioritization.
[00:32:08] Susan Hares (Sue Hares): That's remote to the Yes.
[00:32:23] Carrie / Chunghwa (HSBC): K.
[00:32:29] Jeff Haas: Okay, Nick. You have slide control, and you're ready to go.
[00:32:32] Nick Gao: Okay. Hello, everyone. I am Nick Gao. Today, I am presenting the Bitwise IP filters for BGP flowspec v2 on behalf of all my coauthors. Okay. So here's the agenda today. We're trying to describe the problems we're trying to solve, and, we will describe how do we use this kind of bitwise filters to solve this problem. And, also, we will introduce a new encodings because that needs to be updated with dash zero six of IP basic. And, also, we can describe some if we have some time, we can describe some other use cases and the next steps of this draft. Okay. Here is the use case we're trying to solve. Basically, we have subscribers on the left and the service on the Internet, at the right. And, we want to insert several service clusters between the subscribers and the Internet. And those service clusters requires symmetry sessions, and the router x and router y, we want the vendor agnostic solution. So router x and router y can be from different vendors. And the the session is not synchronized between the service clusters, so the same session must go through the same service cluster. And the traffic distribution assumption is that the traffic is distributed almost uniformly across the least significant log and bits of the subscribers' addresses. So that's the assumption. And this assumption often holds for if you have large numbers of typical subscribers, fixed net or mobile. Okay. So, basically, the requirement is that the the the the service must be inserted between the subscribers and Internet, and the same session must go through a same cluster cluster and the dynamic adding or removing those service clusters is required. And, of course, we need more balancing. So how do we do that using the service device filters? Basically, we can deploy symmetric device filters on router x. Basically, we match source addresses on the listing even two bits of the subscribers address base. Basically, it's source address on subscriber facing router x, and we match against on the decision address for the other direction on router y because it's Internet facing. So, basically, combined with the assumption, we can open the traffic between different service clusters dynamically. So if let's say, if that's we want to scale down off peak, then, basically, we insert new for a v two rows v two NUIs to match against the different, leasing if you can bits. Now we have only matched the leasing significant bit so that we low balance traffic into only two clusters instead of four. So we can shut down two of the four service clusters to scale down for lower power power power some consensus or something like that. And, again, raw text matches the source address field and raw to y, we matches the destination address field. So it's symmetric. And the the update encoding is something like that. Instead of a container single pattern max pair, now the value of these filter components up to v contains a list of pairs. A pattern is a value we're trying to match, and the mask is a b b mask that indicates which b positions we want to match. Okay. So and the there's a list of this kind of pairs, and the these pairs forms a logical or. So, basically, if an address matches any of these pairs, it is considered a match. So, basically, it's a logical or in the sense up to v for this this pattern mask pairs. And, also, one thing that needs to be mentioned here is that the positions of those bits we want to match can be discontinuous. Basically, they are arbitrary bit positions to match that is indicated by the mask field. And the formal definition for the and address is considered for as a match for a pair is using the b y's end operator. If the end operator the result of the end operator is the same, then, basically, the the address is considered a match. So that's the updated encoding. And, of course, the procedures is also updated. The full version is in the draft, but the concise version is here. Basically, to confirm with the dash zero six and zero seven of IP basic for two, basically, each component right now each component's right now only appear at most once in an MRI. So inside the same component, we sort those pairs in a strict ascending order. And each pair because we need to sort them, we need to compare them. And each pair is treated by the string and compare using a mean CMP function to do that. But for this comparison to be deterministic, the don't care bits in the pattern field must be set to zero on transfer and treated as zero on receipt. So there's no ambiguity. One match will only be represented by the single pattern mask pair. So the sorting will be deterministic in this case. And that's inside that sub TLP will sort those pairs using this procedure. And for the comparison between different noise that contains a sense of TLP, basically, we treat the whole TUV as a string, binary string, and compare that using MNCMP just like other TUVs today. So that's it. That's procedures. And the other use case is, basically, we can do some kind of symmetric sampling using this kind of bitwise filters because it's basically, it's a sub problem of the symmetrical bands. You know, just simple partial the partial traffic into the cluster. That's fine. And the other interesting case is that because now the address content the the subtitle v the value of the subtitle v contains a list of pattern mask pairs, then, basically, we can assign multiple identify multiple source address prefixes and the decision address prefixes in the same in your eye. So let's say if you have three different source addresses and four decision addresses, you can put that in the single first to filter using bitwise filters. Yeah. So instead of a 12 because if you're using existing filters, you'll need three by four, which is still 12 for spec filters to do that. So yeah. And the updates from dash zero four, basically, we welcome our new co author, and we also update the encodings as we mentioned before. And, also, we add an error handling session. And thanks to Jeff, we also add a session describing the interactions with the existing filters. And thanks, Joe. We also clarify the filter. Those p positions can be discontinuous, and they are just arbitrary p positions there. So that's the update. And, also, on the next test, we're trying to find a vendors that is interested in implementing this, and we're also calling for coauthors. And, we would like to hear from the potential users that there might be, more use cases for this kind of bitwise filters. And if there's enough support, maybe we can consider, working group adoption poll. And, yeah, any suggestions are welcome. Thank you very much.
[00:40:50] Jeff Haas: K. Do we have any questions? And while we're waiting, so if you anybody who's online to take a look at the IP basic slides, if you would look at slide 13, you'll make note that as Nat was talking about for prioritization, the bitwise filter mask, you know, are more specific than the source and destination fields they govern, so that's why they're sorted that direction. And I see no questions from the room. Thanks for the presentation, Ed.
[00:41:21] Nick Gao: Thank you very much.
[00:46:00] iFit Presenter: Self is a survey company verifications. This draft divide at the to distribute the to together with information. So the effect you have can be applied to specify flow or medical lease solutions. This can define a new BGP pass attribute, a fade attribute, and the divide to a fade type, the IOM type and the the automatic type. And define the multiple, a fade attribute including for the I IOM type defined for sub tier V, including IOM pre allocated options. IOM implement choice options. M directly export option and options. For the automatic automatic type, define to stop tier way, including what led to market market as a sub tier and enhancing of the market as a tier base. And that if I add new track assembly actions, traffic assembly as ascend ascend in the communities, which carry the same thing right information for our marketplace. Next slide, please. This is a bit attribute attribute at TM and tier V and the sub tier ways. This is IOM pre allocated to choice of share sub tier way. This is IOM implement the choice of share sub tier ways. Oh, okay. Next. Okay. This is IOM d x of sub tier way. This is OM each page of of the sub tier ways. Next, please. This is auto auto market sub tier base, including enhancing enhancing the auto market market sub tier and the traffic Simply extending the com communities. Compare simply to buy something simply in the field and to buy it re reserve a field. Next, please. Okay. It looks like up operations with a faith attributes. A level of faith and generally, published a little work as a centralized con set country and determine in the particulars use traffic to be a monthly according to service requirement. The country country or each were dependent to a big type apply to the specified traffic flows. The country list send the BGP flows back up updated a message into a hate device. Finally, any I traffic failed to us, a fake attribute, and the traffic is simply extended communities by the present. The hit device automatically generate SCLs according to the received track failed to us, and in catalyst, I paid for the amount in coming despite check flows packs. We disabled f-eighty. Once the centralized essential, it can lead to a template the marketplace gets traffic flows kind of is to order counters pounding new hotels. Head device, we are removing the SCR with the fail and the stop come duty I fate for the incoming spare traffic flow packs. Next, please. Okay. Welcome. Any comments and suggestions? We we believe this document are waiting is waiting for Thank you.
[00:50:18] Susan Hares (Sue Hares): Would you go back one slide? Two slides, maybe. Notice no. One slide's fine. Just a bit of context. Notice this is a combination of the iFit attribute, which is an attribute that does inline filtering as part of the iFit work in addition to flow step filtering specs in addition to a community to take care of an action. This particular draft is talking about the combination and the action, which is a sampling action, which is a particular extended community. It would interact with other things that set a marker, for example, a DSCP. So that action community has to be noted that way. The flow spec filter probably in the draft needs to be a little bit more laid out. But this presentation gives you a good idea of the power of the combination. I will send you specific comments
[00:51:37] Carrie / Chunghwa (HSBC): on
[00:51:37] Susan Hares (Sue Hares): the filter. Hopefully, you begin to see some of the ways people are going to use it. Thank you for your presentation.
[00:51:48] iFit Presenter: Thank you. And
[00:51:54] Jeff Haas: our next will be on Quick. You're good to go.
[00:52:02] Carrie / Chunghwa (HSBC): This is from HSBC. I'm going to talk about the flows back attention for quick. So background, traditional traffic filter may based by five tuples, such as source address, destination address, and the source port, destination port, protocol. For the quicker traffic, the five tuples may lessen. So we need to extend the the flows back to distinguish the same tuples quicker traffic. So list draft is to do list draft define some throws back a components to match the leads and protect quicker header field. In this picture, quicker have has a two packet type. Long quicker header packet and the short header pack quicker packet. There are some unprotected field such as quicker header flag, quick destination connection ID, and quick source connection ID. So we can use this unprotected filter to filter the quick packet. This is three modified first bag components. The first is quick destination connection ID. We can match the destination connection ID a quick header. And the second is quick source connection ID. We can match the the source connection ID in a quick header. Soda is quick header flag. We can use this flag to distinguish different quicker packet type. There are some use case we can use for rate a limit for quick flows or make some security policy based on different quick packet type. Or we just use the quick connection ID to fill the packet? I'll let you all. Thank you.
[00:54:44] Joel Halpern: I am somewhat puzzled by the use of quick connection ID in BGP flow spec. As I understand quick, connection IDs are basically random numbers. They are generated by the communicating parties when the communication starts. You don't know them in advance and they can even change them during the communication if they want. So you don't know what they are. You can't set up a filter, a security policy that says, allow connection ID seven because you have no idea what's gonna use connection ID seven. So I'm having trouble understanding. I could vaguely believe there's some use of the flags. I don't know it, but that doesn't mean it's a bad idea. But connection IDs are random numbers, and I didn't think we wanted BGP flow spec on the basis of random numbers.
[00:55:42] Carrie / Chunghwa (HSBC): Yes. Thank you. In this solution, the connected IC may be reported to the controller. If we don't know the connected ID, the solution does doesn't take it.
[00:55:53] Joel Halpern: But they're not reported to anybody. They're known only by the two endpoints.
[00:55:57] Carrie / Chunghwa (HSBC): Yeah. Yes. Thank you.
[00:56:02] Haibo (Bob) from Huawei: Hello. Hello. Hi, Bob from Huawei. I have two questions that for connection ID, there may be may be deep for the pack in the pack for the chip to to analyze. And, also, the quick ID the cache ID may be variable length, so it also may be difficult for chip to process.
[00:56:24] Carrie / Chunghwa (HSBC): Okay. Same here. Yeah. The the connection ID, the length is variable, so we need to set the the the lens of the connection ID. Thank you.
[00:56:35] Jeff Haas: Yep. That's two quick comments. So, actually, first comment, the prior speaker was Joel Halpern, HP Sorry. For minutes. Towards Joel and that the prior point here, when the hardware can actually inspect this sort of thing. You know, let's say that there's an IP fix extension that is no added for no quick. It is possible that this might be just another random thing into the packet that firewalls go out and move. I have prior experience fifteen years ago with an employer that used to grab stuff based on offsets inside of layer four traffic. So this stuff does actually happen in in real life. But to the broader point from HiBoe, this actually is an example of how hardware with different capabilities are expected in flow spec v two. We're going to have cases where some hardware has, you know, incredibly, you know, sophisticated capabilities mixed in with stuff that can basically do layer three, layer four only. So this is going to play very much into how do we incrementally deploy these things and how do we have mixed networks that are different levels of sophistication.
[00:57:46] Carrie / Chunghwa (HSBC): Yeah. Thank you.
[00:57:48] Jeff Haas: Thank you, Chunghwa.
[00:58:03] Susan Hares (Sue Hares): Come on.
[00:58:08] iFit Presenter: Yes. Hello.
[00:58:13] Haibo (Bob) from Huawei: This is Haibo from Huawei. And this this time, I I will show a pretense practitioner about p b prospect to redirect the the balancing group. Okay. This is our motivation. Currently, for providers, they also always use prospect to adjust the traffic. But now well, kind of now, there are some gap in kind of BGP prospect. Now the b full prospect can use to redirect IT and then only to only one thing on the top. Also, we may use the first spec to redirect to SR policy, but also the only support the tool redirect to only one endpoint. So the gap is that when we want to to redirect traffic to multiple NetHoP, how can we do that? This is a center of that. For now for the the operator for operator for our app, they may there may be income some some traffic incoming about fifth fifteen fifty fifteen fifteen g. But now they want to divide the traffic through different links. They may throw through r two, r three, and r four. So so the so and also that the split may be diff may be dynamically to down by some link link some link in, like, congestion and the latency and other things. So we want to our solution is that we want to introduce our redirect and load balancing community group. We want to use this community maybe use the use according to the BGP one community. This this attribute is a flexible attribute. It can contain multiple tier of bits in one community. So we want to use a new community that maybe contain multiple path tier of each path tier of it used to redirect to a different path. Here, this is this is the sub TLV format. They may be come contain a flag to indicate the restriction of the of the past info. And as value maybe so maybe it's set to react to IP net top and all all all well, and maybe some waiting information also maybe with that to a partner policy. This is our key update from this version. This version, we introduced the new control flags such as t d, f, and bits. The bits are used to used to restrict the redirect on tunnel only because why we want to redirect traffic to a policy. When the policy is unreachable, then may we may be do some downgrade. That's that's the traffic redirect to IT. But the one t b to set, So the traffic will not do downgrade. Now the t b's the t b's user to re restrict the traffic only redirect to IP, but only support to LPM to direct route and not to such other routes such as BP routes. The FB is used to redirect to restrict the traffic only redirect to prospect. The next step is our we now also, now our job, we want to many want more comments and suggestions. And also, we are now trying to implement implement this these jobs and want to some interpreter with some other vendors. That's all. Thank you.
[01:01:54] Jeff Haas: Do we have questions? And while we're waiting on questions, so an observation, you have a more interesting redirect function.
[01:02:03] Haibo (Bob) from Huawei: Yeah.
[01:02:04] Jeff Haas: And, you know, part of our conversation is how do we allow for the different mixes of these things. So we're looking forward to your contributions to that discussion.
[01:02:12] Haibo (Bob) from Huawei: Yeah. Oh, thank you.
[01:02:14] Jeff Haas: And I see no further comments. Thank you for the presentation. Okay. It's not good. Yeah. One more. This will be our final presentation for this IETf. You have control, Could you confirm that it we we can't hear you at the moment. We are currently not hearing you, so I'm going to type in the chat. I'm going to recommend you disconnect and restart MeetEcho. That sometimes helps. You usually have to be careful about browser permissions. And we are still unable to hear you. Going to type further in the chat, Jimmy. Do you have a local coauthor you'd prefer to present if you can't?
[01:04:31] Susan Hares (Sue Hares): K chain one. Present.
[01:04:40] Jeff Haas: Certainly. If that's what Jimmy prefers. You in communication?
[01:04:49] Susan Hares (Sue Hares): You're getting a WeChat. Right?
[01:04:52] Jeff Haas: Yes. Please let us know what's
[01:04:53] Haibo (Bob) from Huawei: going on.
[01:04:54] Yuzha (Yuja): Yeah.
[01:05:04] Jeff Haas: So for for those who currently can't see anything, Chungwang's in the process of communicating on the side. We'll see what we can do. We've just forward the note, even though this is last presentation, we do have a few minutes left. So I know everybody's eager to get
[01:05:20] Jimmy (China Mobile): some Hello. I changed
[01:05:23] Haibo (Bob) from Huawei: Hey. I changed
[01:05:24] Jimmy (China Mobile): my computer can't wanna hear me.
[01:05:27] Jeff Haas: We can hear you now. You have slide control. Please proceed.
[01:05:31] Jimmy (China Mobile): Okay. Okay. I'm sorry. Hello, everyone. This is Jimmy from China Mobile. I'm going to introduce the draft class ID filter for BGP flow specification on behalf of my co authors. And and let me begin with the problem between a as showing the in in picture. Between p one and p two, there are two transport pass through the backbone. Pass one is the default path, and pass two is a pre deployed low latency pass. For latency sensitive traffic, we may want to steer it from pass one to pass two. The mechanism is flows back redirect and match their traffic and redirect it to the low latency pass. To to match different destination prefix, p one needs to and it needs one one flows back rule per prefix. Pref in this case, prefix 21, 22, 23, or or and so All these prefix sit behind p two. They all share the same path, but there's no set matching in RFC 8955. Every rule supports only one prefix. So in prop in production, the number of prefix can be in thousands. Each rule consumes one entry in in router, the hardware simply runs out. So our solution is class ID, a two octa local significant I identifier. Here's how it works from top to bottom. First, the the operator tells the controller the destination prefix 21, 22, and 23 belong to the same group assigned the the class ID x, and this is the input. And the controller that sent BGP flows back to p one. The filter is class x class ID x, and the action is redirect onto pass tool. On the device side, p e one use local route policy to map its learned routes to class ID. The mapping source can be the IP free prefix itself or or BGP attributes, such as community, large community, x or AS pass or color. The route policy remarks each prefix forwarding entry with the cross ID. So now the when when traffic arrives at p one, that's the destined for a prefix 21. The forwarding looks up and returns class IDX. The flows back engine match the class IDX and redirects onto the low latency pass. One rule cover all prefixes in the group. So the rule can't drops from o of n prefix to o of p domains. So why why not just add a community matching component to float back? There are existing draft. So here's three reason for class ID. First, attribute agnostic. Class ID is not tied to community. Today, I want to aggregate by prefix, and maybe tomorrow, we need a pass or or something else or color. So me so on one mechanism, no new components type per per attribute. No. So the and the second, locally controlled, the grouping reflects the local nodes top knowledge avail. P one decides which prefix from a group via its own route policy. No dependency on whether upstream happen to attack the the the right community as the operator has full control. And and the server community matching is simply is a special case for class ID. And and briefly on encoding, the class ID is a new sub TLV under the first bandwidth to IP basic TLV. The and the is operator val pairs, each val being a two act act act class ID. And if a speaker does not recognize this sub sub, it's it it can it it discard the LRI and the consumer parsing. And I n r one code is required. Secure security consider consideration. Class ID is locally significant and inter introduce no cross domain trust. And for and to sum summarize, flows back and not aggregate prefixes in some traffic engineering scenarios, and excess excessive number of prefix may lead to rule explosion. Cross ID solve this problem. And rules can drop drop from o of prefix to o o p domains. And the next step, we are seeking WG discussion and a input. And and I think that is all.
[01:12:11] Susan Hares (Sue Hares): So this is Sue. Please repeat again. Although, is class ID something you write into the packet? Or is it a logical concept that you bind to a set of matches?
[01:12:38] Jimmy (China Mobile): A class ID is is it to spell things
[01:12:46] Susan Hares (Sue Hares): Let's start with the first question. When you when you mark class ID, is it something you write into an I p v four or an I p v six packet?
[01:13:00] Jimmy (China Mobile): No. It's not in in the in the I in the packet.
[01:13:06] Susan Hares (Sue Hares): So it is bound logically to a set of matches. Okay? So that's the point I wanted to bring out. In many of the rest, they are looking at something written into the packet. Here, we are looking at something policy binds to a packet based on filter policy as a combination. Thank you. I just wanted to highlight that. Yeah. Yeah.
[01:13:41] Jeff Haas: So Thank you. Related comment. So I understand you are teaching your silicon how to match this class ID. I you comment in your, I think, final slide that you think this is locally significant, and I mostly agree. You know, this is intended to be bound to a given device. This has a little overlap with some of the use cases with the path redirect feature, you know, which uses a generic magic number to do things. So a thing I would find helpful for working group discussion is if you could explain to the list the differences, you know, between this and path redirect.
[01:14:24] Susan Hares (Sue Hares): Okay.
[01:14:28] Jimmy (China Mobile): I can do this later.
[01:14:30] Jeff Haas: Excellent. We have no further questions from the room. Thank you for the presentation. This concludes IDR for IETf-one twenty six. Our next scheduled meeting is IETf-one twenty seven in San Francisco.
[01:14:48] Susan Hares (Sue Hares): Watch the wheel in case we have an interim.
[01:14:50] Jeff Haas: And it's soup and when exactly where I was expecting, watch the mailing list in case there's a reason for an interim. One of the things that we would request, you know, for the flow spec authors, you know, as you noted, we listened to the working group's request to try to split things based on the functions that the IDR is doing. This set of flow spec v two documents are very closely coordinated because of the numbering work that we have to do and of the feature interactions. So we will be reaching out to all of the authors of the various, you drafts looking to get flow spec adoption to help coordinate things. And, you know, if that coordination becomes more challenging, a interim may be the best way to proceed. Any closing remarks? There's no closing remarks from the other chairs. Have a good day. See some of you at the, no, closing social.