Session Date/Time: 11 May 2026 14:00
Sue Hares: ...discussion, but I will run through status in the first five minutes. So, I've... I'm going to give everyone about two or three minutes after, and then Jeff, you think two to three or five minutes? What do you guys think? G or K?
Keyur Patel: I think two to three minutes is good. We can start.
Sue Hares: Okay. Then we'll go... I'm anticipating based on our working group discussions that people will tailor their participation based on what function we're doing. If we're doing Flowspec V2 for our first section, then we'll come in. Uh, we didn't get any response from anyone else who was locked out of the IETF 125. Okay. I'm on... I'm on the hook to do the status. Uh, and K, G, and Jeff, G made some corrections, but I may have missed something on our long status slides. So, please chime in if I missed something else.
Sue Hares: Sue, I cannot hear you. Can anyone else hear Sue now?
Sue Hares: I... I'm not speaking yet. Uh, can you hear me now?
Jie Dong: Yeah, yeah. Now it's fine.
Sue Hares: Good, good. Thank you, G. Okay, I will start in with the Note Well. Uh, I said I'd give us a few minutes, but I'm anticipating today that it'll be one of our first interims where we have targeted agendas. This is one where we have a Flowspec V2 agenda. All of IDR interims and IETF meetings follow the IETF process and policies. This is a Note Well. Uh, I'm going to briefly go through this. IETF participants are expected to behave in a professional manner and extend respect and courtesy to their colleagues. See the guideline. If you're aware of any IETF contribution that is covered by patents or patent applications that are owned or controlled by you, your employer, your sponsor, you must disclose the fact or not participate in the discussion. For the detailed process, see RFC 2026, RFC 2418, and lastly, uh, IETF routinely makes public written video and audio and photographic records of all IETF activities, uh, and you can... it will include privacy information that could be considered as your personal information. Okay, let's go through this. The status is what we've got first, then we're going to go through some changes that Jeff and I have worked through on draft-ietf-idr-fsv2-ip-basic. Uh, we're thrilled to see many people who are looking at that on this meeting. Then we will go through four presentations on Flowspec V2: draft-ietf-idr-bgp-ifit-capabilities for IFIT, bitwise filters, Flowspec content filters, and Flowspec binding. Once we agree that the basic text that we've changes... made changes to is workable, we'll start the adoptions for the rest of the Flowspec V2 documents. Okay, this is a lengthy status. I am doing it so we have a point where people can look at it, so get comfortable and I will try to do this quickly. Uh, please interrupt me. We have plenty of time in this interim. I allocated two and a half hours for a good technical discussion. Uh, this charter is our only pretty much status. The charter is being reviewed by the IESG later this month. Charter milestones right now are being updated by Keyur. We will eventually take that over as the chairs. We're trying to start using BGP-LS, BGP-SR, BGP-SRTE, and Flowspec V2 as beginning flags so you can filter. That was one thing. There are other action items from the working group charter call we're still working on: the DC ops group, the IANA bis procedures, and cleaning up IANA allocations. Some things just take much longer than I had hoped. Uh, now where are we with drafts? We have two drafts at the RFC Editor: draft-ietf-idr-bgp-ls-link-mtu and draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle. We have at the IESG draft-ietf-idr-rt-derived-community. There are three discusses to resolve, so we're... Keyur is working actively to resolve them with the authors. draft-ietf-idr-flowspec-path-redirect has received favorable comments. It's at the IETF last call, so is draft-ietf-idr-bgp-fwd-rr. Uh, both of those I expect to go to the IESG later this month. draft-ietf-idr-sr-policy-metric needs version 09 to resolve the AD's comments. And thanks to Keyur, draft-ietf-idr-flowspec-srv6 has gone to the IESG. It refers to draft-ietf-idr-flowspec-path-redirect. The ADs requested that the... this go together with the Flowspec redirect draft. What are waiting for write-ups? We have draft-ietf-idr-bgp-model. G is the shepherd, but we're waiting for some final use scenarios to be resolved by the authors. draft-ietf-idr-sdwan-edge-discovery is in review. Keyur, did you have any further comments on that, since we're running this pretty informally?
Keyur Patel: Um, not yet. No.
Sue Hares: Not yet. Okay. That's okay. Um, as you will notice as we go through that our chair team, which actively includes G as both reviewer and shepherd on many of these drafts, uh, there's a lot of work for each of us. We're working as fast as we can. Uh, speaking of which, IDR... draft-ietf-idr-rt-derived-community. G is the shepherd, and we're waiting for the authors' revision of the last nits. And then we come to draft-ietf-idr-rfc4360-bis. Keyur's reviewing process. If you somehow missed any comments on that, I'm sure that we would take comments on the working group list. We need... although this is a bis, we still need comments as we go to the IESG. Jeff is taking care of a best draft. Uh, there are some post-close discussions. Please, those are occurring on the best list, but if you have any comments, please send them off on the best list. draft-ietf-idr-bgp-ls-sr-mpls-elp. Joel, this is one that you'll see direct chair comments from the IDR chairs to you. I want to pick up this draft as we look and see if its base drafts have been upgraded. I'll send a direct query to you and the chairs.
Joel Halpern: Understood. Understood. Thank you.
Sue Hares: Thank you, Joel. Okay, those are working group last calls. Uh, I'm trying to do these by groupings again. We have draft-ietf-idr-bgpls-inter-as-topology-ext. There's been some good discussion between Keyur and A-June, but we have to wait on some resolution there before we close that one. draft-ietf-idr-sr-policy-seglist-id has cross-review information, and um, we're in active working group last call. As I do these drafts with spring interaction, I've allotted three weeks for them. That gives us time to close all the... to close all the issues regarding spring IDR work. Um, we have some pending... we have some pending comments... ah, I will get to the 5G edge services shortly, uh, Linda. Um, so the 5G edge... let me go through this from top to bottom. I'm sorry. draft-ietf-idr-linklocal-capability, we will be starting a working group last call shortly. It's in the course. draft-ietf-idr-5g-edge-service-metadata, Linda, I've been asked by Keyur to do a BGP-DIR review before we head it into working group last call. I need to get a BGP-DIR reviewer, and I have to get... since I'm work... one of the secretariat team for the BGP-DIR, I need to get someone who's going to respond to us fairly quickly. So you're behind a BGP-DIR review. Um, draft-ietf-idr-node-target-ext-comm and registered wide communities. Robert and Jeff, we're going to come back up to those two drafts again. We will need your help within the next month, but I drafted, begged, pleaded Jeff to do the Flowspec V2 work because of our outstanding list. Um, the draft-ietf-idr-bgp-bfd-strict-mode and the draft-ietf-idr-dynamic-cap, which is linked to draft-ietf-idr-bgp-bfd-strict-mode, are also behind this SR... excuse me, behind the work for Flowspec V2. So authors on these last four drafts, we made a decision to try to catch up on Flowspec V2 and then pick those up. Uh, pending draft-ietf-idr-bgp-ls-sr-epe-over-l2bundle. I was... I got the responses back from the authors. You'll find that that is actually in working group last call. draft-ietf-idr-bgpls-inter-as-topology-ext is closed, but I need the authors to give me the correct registry name, otherwise we could get into problems. And there are a whole bunch here in the BGP-LS that need responses from their authors. Uh, pending in the SRTE, we have draft-ietf-idr-sr-policy-path-mtu. They need to put in the cross-working group section. I'm going to take a moment here and explain why we're doing a cross-working group section in the last appendices. I've said this on the list, but I'll repeat this here for everyone's knowledge. Unless we have this... what we found with the NRP draft is that it took us too long to close the issues after working group last call closed. So what we're doing is we're trying to think ahead and make one call to the working groups instead of three so that we get everything completed and then send it off to Keyur as our AD. Uh, draft-ietf-idr-sr-te-policy-attr. If you are in that author and you're listening to this or you're here in the meeting, that needs to have the two-byte length and the reserve path settled before we can go farther. Here we are with the Flowspec V1. We have restarted the Flowspec path redirect, uh, and Gunter has picked that up. Uh, there are three implementations but only one report, so Gunter's taken the goal to get not only the revision of the path redirect that matches the implementations but also the implementation reports. We also have another Flowspec V1 outstanding, which is draft-ietf-idr-flowspec-l2vpn, but we do not have two implementations. Lastly, I do know that draft-ietf-idr-flowspec-srv6 is pending. I will be working on that once we settle the Flowspec V2 basic. That was an adopted draft with SRv6 filters and it's on the hot list. Uh, it was approved for Flowspec V2 but probably needs to switch to Flowspec... excuse me, it was approved for Flowspec V1 but it will probably need to go in the filters for V2. Okay, core pending calls. We have these sets of calls from the core working group. We thought that draft-ietf-idr-performance-routing would want to present today. We will fast-track these with the authors for IETF 126. And we have one pending adoption for regular SR. It needs a cross-working group section. Again, we're going to where we get start with these cross-working group sections even for adoption so that once you're adopted, we don't requestion whether it should be adopted. Uh, we've had that happen. Okay. Again, these are more... this is adoptions for SRTE that are pending. They're close, but they need the cross-working group section. And more adoptions that need the cross-working group section. Okay? Uh, these are adoptions for Flowspec V2 drafts. Notice we have three of them presenting today. The rest of these drafts, you need to look at the Flowspec V2 discussion. Any questions? I think I made that in 15 minutes rather than 10. I apologize for the lengthy status, but we don't... haven't done that in the past. Any questions? Comments? Anything on the list that I'm not seeing? Oh, and Jeff has the status, but I did a lengthy one just in case some people don't go through the blobs. The... we think we track the GitHub day-by-day, so if you want the best status, please go there. Okay, Jeff and I are going to tag-team the Flowspec revision. Now, this is a working interim, which means questions are really important here on Flowspec V2. Jeff, do you want to start with anything on this one, or shall I start the motoring of the slides?
Jeffrey Haas: I can drive a bunch of it if you like.
Sue Hares: Pardon?
Jeffrey Haas: I can drive a bunch of it if you like.
Sue Hares: Okay, I'll flip the slides, you go on. Okay?
Jeffrey Haas: Okay. Uh, Jeff and I did a lot of revision. Uh, I think I'll go... I'll do the first two slides, Jeff, because they're from the IETF 125. Uh, look, we've been working to have a focus to just let defaults work. The user order is required by some applications, which means if the user wants it to go in this order, the filter... the filters will be done in that order, and we've added a user field. But some applications just want defaults to work, and that's the way a lot of them are deployed. There are two approaches: simple order and frame packet order. But there's the problem you may want to insert things, and there's a problem of partial deployment. And we pretty much said at 125 we're okay with starting with actions in extended communities and living with it. Uh, the discussion at 125, I asked three questions. Uh, we agreed frame order for filter families, and we agreed that ascending order for filter components would be useful. But Jeff and I have a few extensions when we work through some of the details. An action. Notice the order is user, then filter family types, and then components. Okay? And these are the filter families: zero for reserved, and then between that something before L2, then MPLS, then SFC, then tunnel traffic, then IP basic. Okay. You want to pick up here, Jeff?
Jeffrey Haas: Sure. So, just brief background of why we're working on the packet changes at all. So Flowspec V1 had two big problems associated with it. Problem number one, the components were... had no length field inside of them, and this basically prevented us from doing any sort of incremental update to the protocol. Uh, the second problem that we ran into is that, you know, the order that we have for the IP components in Flowspec version one is basically targeted towards use cases that are great for distributed denial-of-service attack mitigation. So, if you look at the order... the order that we're talking about is what we actually create firewall rules from the Flowspec routes themselves. And, you know, the natural order that we get from the sort rules of RFC 8955 is great for DDoS. It's not so great for other things. What this left us with is two goals for Flowspec version two. First one is moving to strict TLVs to get ourselves to the point where we can safely upgrade the protocol in an incremental fashion. Uh, PCEP as an example, took our encodings for the actual components and through a length field inside of their encoding of things. And, you know, the second piece, you know, we needed some ability to bypass the natural order when that made sense. And so you have an open mic. Um, the... the second related piece for the ordering means that if you don't want to use the normal use case, you need some way to basically be able to override it. And the user order field is a, you know, very strong override field for that purpose. Next slide, please. So, general idea, you know, for the... the stack of things is that we want to go uh, basically inside of packet pipeline processing order. Lower layer protocols to higher layer protocols, but we also had cases where something's not strictly a protocol, it's sort of a middle layer. We can pick MPLS as an example of that, segment routing as examples of that. We also have tunnels that we want to be able to interact with as well. So this sort of puts us somewhat in the middle. What this means is our conversation here is one part about the encodings we have on screen, but far more about, you know, the natural order that we have things for defaults. And the user order means that some use cases you simply bypass it by manual configuration, but the rest of it, we want to have the default orders make sense. The issue that we had in the prior slide, you know, that was covering the encodings, was that we had the TLV grouping order and dependency as part of a TLV set. You know, these things are really, you know, more applicable to the Flowspec route itself. And then there's questions about what we actually wanted to do for the internals. Next slide, please. So, much of the work for this last push tries to capture what prior discussions had been about what we were using these things for. So the first thing that was done is we pulled the filters... sorry, the dependencies to the very top of the queue. And uh, the... by having it at the top of the PDU, one of the open questions that we'll be discussing, you know, in next bit of working group email, is whether or not the filter chain itself is part of NLRI key. You know, it's sort of naturally what it is right now without further discussion, but it doesn't necessarily make sense for its use case. That said, everything else largely does, and therefore, you know, putting the stuff that's key/non-key a little bit more segregated made more sense. User order is intended to apply to everything that's within a specific NLRI, and then after that, it's, you know, the standard IETF TLVs and sub-TLVs. And our top-level TLVs are the filter family. Uh, you know, this very slight rename, we tried to figure out, you know, this is a grouping of things. Uh, they are often associated with each other. Well, family's what we chose. Next slide, please. So, at that level, this is very boring. You know, these are just the things that are associated with each other. Uh, we want them all to have, you know, common semantics with them, and exactly where they go into the default sort order uh, will depend on discussion. You know, so one of the things that we're going to be working through as we have not only the presentations today, but list email about all the other things looking to glue into Flowspec V2, is significant amount of discussion about how these things are actually numbered and whether that gives us a natural filter order or not. Next slide. The rest of our work here, again, components are largely just TLVs. One of the things that did change in this revision is we are discussing what incremental deployment meant for Flowspec V2. One of the common things that we have is the need to add a little bit of extra state that may impact individual components. Um, and again, you know, the general idea is that we want this sort order to be a natural sort order for the application. We are not changing IP basic, you know, from what it was for DDoS. Next slide. Uh, we're looking to keep things largely in the same orders, but we even in Flowspec V1, we had implementations that did not necessarily support all of the filter components. So part of our discussion was what happens when something can't locally be installed. We have implementations that behave in very different ways. Some of them are controlled by configuration, some of them are just simply enforced by the hardware. Uh, to be able to reflect what an implementation should do when it doesn't have the ability for whatever reason, configuration, policy, whatever, to install a component, is that the operator can signal whether this component is optional or not. And a very good example out of, you know, some of these use cases is like, maybe DSCP is a nice-to-have. Uh, you would like to be able to take specific actions on it, but, you know, on a match component, maybe if your implementation can't look inside of that bit of the packet for some reason, maybe that's only an optional thing. In that case, you can just simply ignore the lack of ability to match for it. Uh, but the default case, optional bit is set to zero, is that it is mandatory. We have... if you can't support it, it means you can't do anything that's associated with this NLRI. And, you know, that means you have to worry about dependencies, which we'll talk about a little bit later. Next slide. So, dependencies. Uh, one of the things that was clarified in this version of the draft, we shrunk the dependency space down to four bytes. Uh, simply, you know, four bytes should be plenty for any of these sorts of things. Uh, if it's zero, well then we don't care about the dependencies. The operator just says, uh, you know, this rule is completely independent, we're not going to worry about things. But if it is non-zero, effectively what we're doing is, you know, tying together rules into a linked list that says if you can't install for some reason one rule inside of that list, all the other rules themselves are treated as invalid and are removed. Um, and the bits that we have for optional/mandatory are intended to help influence this. Next slide. So, easy example here, you know, if we happen to have, you know, like a pair of rules, you know, one is effectively, you know, more specific/less specific. Uh, in this case, order does matter. You know, it's matching overlapping destinations in 10/8. It's matching the same, you know, Layer 4 port, TCP port 25 for email. And the first one basically says that if DSCP has been set, you know, this practice happens for certain types of operators where they'll do ingress marking for approved traffic, uh, well if your implementation is able to match that, you can permit that and then discard everybody else. The problem is, if the implementation can't handle DSCP and can't do rule one, then it just sort of falls through to rule two and we end up with dropping everything, which is not necessarily what we're looking to do. Um, so the choices for the operator here is that either DSCP itself is an optional thing, uh, and you're allowing it to go through, or alternatively, you'd rather not do enforcement at all if you can't do it correctly. Next slide. Filter families, as I mentioned, are intended to be ordered based on applications, you know, things like is this MPLS, is this, you know, uh, service function chaining, uh, is this matching on tunnel traffic, etc. Um, within the filter families, everything has to be ordered. And, you know, the ordering considerations here are tied to being able to canonicalize the packets in a consistent fashion across the network. You know, if you don't have that, your NLRIs really can't easily be compared inside the implementations. Uh, very similarly, we're insisting that a given NLRI component, you know, at either the filter family level or the filter component level, must be unique. You can't have more than one instance of that. And what that means is that your use cases for compounding things need to be in the value fields. Next slide, please. Component numbers. Uh, you know, here we basically have preserved the general ordering, you know, for Flowspec version one. And, you know, the order here is uh, been offset by tens. You know, why did we do that? Well, this is one of the other discussions that we've had about Flowspec version one. When it's time to actually do something, how do you actually add something in the appropriate spot? Our common example we've talked about is TTL. TTL is something that most people would probably want to match at a very low number uh, and have it take a very strong effect. Uh, but in the prior ordering, 1 through 13 meant that 14 was the soon as you put it in, it would have probably the wrong sort order. So what we need to do here is leave some space by tens. Well, this might not even be enough. One of the discussion points we should be having is as we look at our extra use cases, where do those install in, and have we left enough space for future things? Next slide. Partial deployment is one of the things that's already been a problem for Flowspec version one, and as we add in more flexibility for Flowspec version two, it becomes very challenging. You know, as an example, we have two common use cases. You know, for example, you know, do your nodes have to actually install the rules? You know, if it's something like a route reflector, we want to have some flexibility to pass these things around, you know, in an ignorant fashion. Uh, the second piece is as you incrementally install new features throughout the network, perhaps you're only expecting some portions of the network to be able to install those rules. Within Flowspec V1, we solved this partially by being careful about how rules are pushed around the network. Uh, either central route reflector and everybody's expected to understand it, or at the very least, if they don't, it fails in a consistent fashion. Yujia will be talking about how we get some of signaling for this as part of her presentation, I believe. And, you know, the second aspect is that, you know, as we incrementally deploy new things, we want to be able to have them work in a consistent fashion, and this is where our dependency chains end up helping us. Next slide. Actions. Uh, we know that actions in Flowspec version one are somewhat problematic, just simply because they do have interactions. One of the things that we've been trying to do as a analysis framework is trying to talk about what classes of actions that we have, and you know, the list on the left is a rough set of classes. We know that within a single class, as long as you only have one item, these things largely are not conflicting. That's not necessarily a guarantee, but it's, you know, a good heuristic that tends to work out well for us. Um, in the case of Flowspec version two, we could potentially add some additional rules covering this sort of thing. The problem is the extended community mechanism that we're using in Flowspec version one and also targeting for IP basic don't give us a lot of room to tie in how these things can interact or what class they may occupy. So this is eventually going to push us to, you know, more sophisticated encodings for this in Flowspec version two, likely using the community container and therefore overlapping the wide community work that Sue was talking about earlier. Next slide. Uh, so when we do have failures for Flowspec version two using the extended community formats, we basically have three potential options. We can just simply stop processing, you know, if we can't accomplish the intent that the operator's pushed, you know, for the things that have been set. Uh, one of the options is that maybe we ignore some subset of things. You know, implementations do this as well. Uh, and in some cases, maybe the implementation has some ability to signal that we could do one or the other based on choice. An example of a conflicting type thing is, you know, again, maybe our DSCP operation is being set. Uh, we've requested sampling and we have redirection. Well, if your implementation, for example, can't set DSCP, well, we have options: we simply don't apply the filter. Option two, well, maybe we apply the subsets that we're capable of doing. And option three, maybe we give the operator some choice. Next slide. Um, in terms of minimal conformance, uh, what we're doing is basically 8955 with the Flowspec version two encodings. Uh, same thing for IPv6. Uh, other profiles are being built for things like SRv6. Next slide. Validation. Uh, validation logic is where we spent a lot of our effort going from 5575 to 8955. You know, thanks to Christoph for actually doing a lot of that wrangling for us. Uh, one piece is strong syntactic and semantic checks, uh, and the second piece is the validation of the properties of the routes. You know, for that sort of thing, uh, we have things that we can do as a general Flowspec-wide behavior for Flowspec version two, and some things are going to be particular to individual components and are going to complicate our validation story. Next slide. So, at a critical failure level, you know, basically if you can't do simple TLV enveloping for the Flowspec packet, there's not a lot you can actually do. You have to assume that the entire stream is corrupt. We're going to treat this as a hard reset and reset the BGP session, which is thing that we would prefer not to do, but you know, the only choice in this option. Next slide. Within well-formed TLVs, you know, we do have some ability to check the contents. We can basically say that if we understand what this filter family is and what its components are, you know, then we can actually check: does this component have a valid length for this type of component? Is the component value well-formed if we understand that? You know, if we have an error in those things but the TLVs are otherwise well-formed, we have some ability to do "treat-as-withdraw". The challenge here is what "treat-as-withdraw" will mean. An example is maybe we received a valid Flowspec encoding, we've propagated it downstream, and then we receive something from upstream and it's intended to address the same filtering behavior. Well, is it the same route or not? It's very difficult to tell, so not propagating the thing that we've been sent is at least part of the job. Uh, but we may not be able to successfully withdraw the other route. This is unfortunately a common problem for Flowspec version one and also with BGP-LS as well. Next slide. Once we actually have decided that the contents are good, we're going to do the same types of validation that we did in Flowspec version one. Uh, primarily this is to address operators having customers that wish to actually send in Flowspec routes. This is actually a deployed thing, although, you know, the practice of it is somewhat dangerous given how powerful Flowspec can be. Uh, the mechanism in 8955 and previously 5575 effectively says, "make sure that the route has a destination field and make sure that that destination field is attached to a Flowspec route that has been announced by the announcer of the underlying unicast route as well." You know, if that's not the case, you know, it didn't come from that cone, then we're just simply not going to accept the route and use it. Uh, in a very similar fashion, we're also checking properties of the AS path for that and we've also implemented some of the RFC 9774 behavior where AS sets are just simply not valid. Uh, when we do fail for this sort of thing, the route is considered from a installation point invalid and we just simply do not install it. Next slide. That... that's the updates that we've done this round. Questions? Nat?
Nat Kao: Hi Jeff, I have noticed that in slide 13 that we have posed a new limitation for the components that each component can appear at most once, right?
Jeffrey Haas: Mm-hm.
Nat Kao: And I... I have some... for example, we might have some use cases that, for example, we have 10 different source prefixes and 10 different destination prefixes, we want to drop or redirect traffic between those 10 prefixes. And if there's a limitation like this, then we need 10x10 = 100 Flowspec rules to do that. If we can allow multiple occurrence for each component, then maybe we can form a logical OR for both source prefix and the destination prefix. And between different components, they are logical AND, so we can do it in a single Flowspec rule to match against any traffic between those 20 different prefixes. Uh, did you... yeah, so that might be more efficient for signaling and probably it's better for TCAM usage on the hardware itself.
Jeffrey Haas: Uh, so the thing I'd recommend and please also repeat this on the mailing list so we can actually have this discussion for broader review. But what I would actually suggest based on where we've been heading is that the intent that we've had for Flowspec components across families is that every single component is treated as a logical AND. And if your encoding was to try to repeat a given code point with the intention that's treated as an OR, that's sort of muddying up the syntax a little bit. My recommendation for this specific use case would be, you know, we already have match fields for source and destination prefixes. What I would recommend is a new component that is intended to be a prefix list. And, you know, within that component, the rule is any match, you know, within the prefix list would be sufficient. And part of your conversation then is what is the numbering for this in the component list? Is it better or you know, less preferred, you know, than the existing destination match?
Nat Kao: Okay, so maybe we can define a new component type that allows a list for source or destination prefix, is right?
Jeffrey Haas: That would be my first suggestion, yes.
Nat Kao: Got it. Thank you.
Jeffrey Haas: Okay, I see nobody else in the queue. Okay, Sue, I think we may be done. Perhaps we should move on.
Sue Hares: Okay. Then our next one is IFIT, which should be... just a minute, I'll pull up the slides. I actually have Nat on the next one on the slides. We'll take Nat next. Go ahead. And I'm going to pass the control to you. Pass the control to you, Nat.
Nat Kao: Okay. Hello everyone. I am Nat Kao, and today I'm presenting the Bitwise IP filters for BGP FlowSpec. And on behalf of my all co-authors. Okay, the agenda is basically what we're trying to solve. Basically, we're trying to do the dynamic service load balancing using the Flowspec bitwise filters, and we will discuss about the encoding and the deployment guidelines for this kind of filters. Okay, here is the architecture, the scenario we're trying to solve. Basically, we have subscribers on the left-hand side and internet on the right-hand side, and we have some service instances that each the traffic of the subscribers must go through before they reach the internet. But those service instances may require both directions of the traffic, so the same session must go through the same service instance or there are probably some session table problems for each service instance. So, we're trying to deploy Flowspec rules on router X and router Y that so that we can load balance the traffic between each service instance while keep the same session of the traffic through the same service instance. Okay, and the traffic assumption, the traffic distribution assumption is that each subscriber, the behavior of each subscribers are almost the same across the least significant look-and-bits, so basically we can load balance using the least significant look-and-bits on the subscribers list, so yeah, that's the assumption of the traffic pattern. And also the requirements are basically the session both directions of the traffic go through the same service instance, and we need to load balance between service instances and dynamically. So basically we can scale up and scale down. So if it's off-peak, we would like to shut down some of the service instances for better energy consumption. So that's a requirement we want to solve that using the Flowspec V2 bitwise filters. Okay, so basically when we have four, for example in this example we have four different service instance SVC0 to SVC3. And basically we deploy four different rules on both router X and router Y. For the subscriber-facing router X, we match against on the least significant two bits on the source addresses which is the address of the subscribers. And on the other hand, on the other direction, which is the internet-facing router Y, we deploy bitwise filters that match against the destination address which is also the subscribers' address. So this ensures that the same session, the both directions of the same session go through the same service instance. And because we have the assumption that the traffic is distributed almost uniformly across the least significant look-and-bits, so basically the traffic we can dynamically... we can load balance the traffic across these four different service instances. Okay, so that's the initial status. And for the off-peak hours, maybe we can shut down two service instances for better energy consumption. So basically we deploy new rules that only divide traffic into service zero and service one. And then when we deploy these two new service rules, Flowspec V2 rules, the traffic is only going through service zero and service one. And then when we remove all those old rules, then we can shut down service two and three so that we can dynamically scale up or scale down for this kind of services using the Flowspec bitwise rules in the centralized control fashion. Okay, then the encoding of those components are basically straightforward. We have a value, and value is consist of a two-tuple: prefix and mask. And the prefix is a value we want to match, then the mask indicates the bit positions we want to match. And also as I mentioned before, this component can occur multiple times in the same NLRI, and when this happens, these multiple occurrences form a logical OR. So basically if the address matches any of the instance of that, for example, destination address bitwise filter component, then it is considered a match. Okay, so yeah, that's a logical OR. And thanks for Robert, and he suggested us to add the deployment guidelines. Then basically we have listed four guidelines for these bitwise filters. Basically, we suggest that you use both either bitwise filter or the existing prefix filters from 8955 and 8956, but not both to avoid confusion. And also when deployed with redirection actions, these Flowspec rules are actually PBR rules, so forwarding loops can happen. So yeah, please be aware about that. And also if our redirection destination there are ECMPs to the redirection destination, then the matching packets are still subject to the hash-based load balancing towards that redirect destination. The example is that, for example, if we want to redirect traffic to service instance zero indicated by an IP address, then there are ECMPs towards that IP address, then we still the hash... traditional hash-based load balancing still occurs in this case. So yeah, that's it. And also the last guideline is that please be aware of the performance and the scalability of this kind of bitwise matching because it differs from the traditional prefix matching filters. Okay, and the updates in this version 04, basically we clear multiple occurrences behavior in this version, and we also added the deployment guidelines in this version, and also add a new example which is symmetric traffic sampling use case. Okay, and next steps: basically we would like to find implementers that are interested in this use case and also call for co-authors. If you are interested, please contact us. And also we would like to hear from the users that maybe there are more use cases for this kind of filters, and any suggestions are welcome. So, any questions? Yes, Joel?
Joel Halpern: Could you go back to the deployment guidelines page for a moment? Here. Unless I'm misunderstanding you, in the use case you outlined, I would think that on the side from the user you would only want to check the bits if the destination... if the source address is one that is supposed to be load balanced. And in the side from the internet, you would only want to check the bits if the destination address is from the set that you're supposed to be load balanced since routers normally serve more than just this purpose. And so I would expect one would normally want a prefix filter plus the bitwise filter. Exactly the opposite of what you said in this first bullet. So I'm a little confused.
Nat Kao: Because, for example, if we want to do a CIDR match for longest prefix match first for the first 16 bits, basically we set the mask to one for the first 16 bits, and the list, for example significant two bits to match against a value for that subscriber's address. So yeah, it matches both. And so you would... the point... the reason for excluding it is you should probably note in the draft then.
Joel Halpern: Okay, your expectation is you would include both the filter and the balancing bits in the bitwise mask. Okay. Now I understand why you're excluding it and it makes sense. Thank you.
Nat Kao: Yeah. Thank you.
Sue Hares: Any other comments? I think the one thing you'll have to work with is the... perhaps if you want is if you wanted to combine this with the prefix list that Jeff suggested earlier, we should talk about that. Anything else on this topic? Okay. Then we will go back to the presentation I skipped over, which is from Xiaomin, and let me bring that up. Hello everyone. Can you hear me everyone? I can hear you just fine. Thank you. I'm going to give you slide control. Let me know if you can...
Xiaomin: Okay, okay. Uh, I can...
Sue Hares: We are seeing you move your slides. You are currently at slide eight. Do you want me to... okay, why don't I take back slide control and you can tell me when to move the slides? Just a minute. You just tell me when you want to move the slides. You're on the first... you are on the second slide.
Xiaomin: Yeah, motivations and objectives. With the evolution of IP transport networks towards the intent-based and autonomous networks, flexible deployment of iFIT based on network dynamics and service requirement is getting a must, such as simplified iFIT configuration, enhanced real-time monitoring of iFIT, and adaptive to network dynamics. This draft defines the BGP extensions to distribute BGP FlowSpec based traffic filtering together with iFIT information, so the iFIT behavior can be applied to the specified flow automatically. In this way, iFIT is automatically enabled and running. The solution: define a new BGP path attribute, IFIT attribute, which is composed of a set of TLVs. Define two iFIT types: the IOAM type and the Alternate-Marking type. Define multiple IFIT attribute sub-TLVs. For the IOAM types, define four sub-TLVs, including IOAM pre-allocated trace option sub-TLV, IOAM incremental trace option sub-TLV, IOAM DEX option sub-TLV, and IOAM E2E option sub-TLV. For the Alternate-Marking type, define two sub-TLVs, including Alternate-Marking sub-TLV and Enhanced Alternate-Marking sub-TLV. Define a new traffic sampling action, traffic sampling extended community, used to carry the sampling rate information for IOAM monitoring. Next slide, please. This is IFIT attribute TLV and sub-TLVs. In the IFIT attribute TLV, the value field contains one or more sub-TLVs. This is IOAM pre-allocated trace option sub-TLV as defined in RFC 9197. This is IOAM incremental trace option sub-TLV, the same as the IOAM pre-allocated trace option sub-TLVs. Next slide, please. This is IOAM DEX option sub-TLV as defined in RFC 9326. This is IOAM E2E option sub-TLV. Next slide, please. This is Alternate-Marking sub-TLV as defined in RFC 9343. This is Enhanced Alternate-Marking sub-TLV. This is traffic sampling extended community format. Yes. Next slide, please. BGP FlowSpec operations with IFIT attributes enable iFITers. Generally, in operator networks, the centralized controller determined the particular user traffic to be monitored according to service requirements. The centralized controller also need to determine the iFIT type applied to the specified traffic flows, then the centralized controller send the BGP FlowSpec update message to the headend device, and the head device automatically generates ACLs according to received traffic filter rules and encapsulate iFIT for the incoming specified traffic flows packets. Disable iFITers: once the centralized controller determined to terminate monitoring the specified FlowSpec, it can withdraw the corresponding NLRI routes. Then the end device will remove the ACLs related to the traffic filter rules and stop encapsulating iFIT for incoming specified traffic flow packets. Next slide, please. This is some IANA considerations. IANA requested to allocate the value as the type code of the attribute in the BGP path attribute registry. IANA is requested to allocate the value as the type code in the registry entitled BGP Transitive Extended Community Types. This document requests the creation of a new registry called IFIT Attribute TLVs and IFIT Attribute sub-TLVs. Next slide, please. Next steps: any comments and any suggestions are welcome, and refine the draft according to the feedback. That's all. Thank you very much.
Jeffrey Haas: A question for you: as best I'm able to tell from your draft, this is not a feature that is strictly restricted to FlowSpec; it could be used for normal BGP routes.
Xiaomin: Yes, yes. It's a BGP extensions.
Jeffrey Haas: Okay. Um, and if this is usable for FlowSpec as well, as normal BGP, have you given thought to how this feature interacts if you cannot actually install iFIT on a given device for forwarding purposes?
Xiaomin: Okay. Uh, we will make implementations in some devices later.
Jeffrey Haas: I will type my question to the chat. You can respond there if you like.
Xiaomin: Okay, okay.
Sue Hares: This would be an important issue to raise on the list because finding out if this is... if the iFIT is general, then we need to solve... meaning it's available for other NLRIs besides FlowSpec, then we need to see the rest of the rules for this attribute or point to another iFIT draft. If it's specific to FlowSpec, Jeff's question is extremely important. What happens if you cannot install the iFIT function? What do we do with the rest of the rules? Remember we had the rules that said... okay, I will give you a moment to read Jeff's comment in the chat. If you want to respond to that in the chat. In which case we're going to go on to the next presentation. Please go ahead and work on the chat.
Yujia Gao: Okay, thank you. This presentation covers two related FlowSpec V2 drafts, and this is the first one which is about the packet content filter. Uh, here is the current draft status. This work was first proposed at IETF 119. Since then we have done several follow-up activities, including design, implementation, and discussion. Based on that experiences, we update the draft to version 4. In the following slides, I will introduce the latest updates. Uh, as we know, the main motivation for the payload filter is DDoS mitigation. We need a new type of FlowSpec filter to match traffic with specific payload characteristics. Through discussion with operators, we found this filter can be useful in real networks, and it can also be used in some traffic handling or optimization scenarios. In the FlowSpec V2 framework, this filter belong to the more IP filter. And based on the latest design, we defined the fields and ordering rules for the payload filter. The encoding and behavior will continue to align with the ongoing FlowSpec V2 work. Uh, here is the software implementation we did before. We use openBGPD and FRRouting to demonstrate the effectiveness of the filter. The results show that the payload filter can help effectively achieve... can help mitigate attack traffic. And we also conducted a hardware deployment using a commercial device with switching chips. The traffic statistics confirm that the rule can effectively achieve packet dropping. Uh, based on the discussion and implementation, we proposed some operational security and scalability considerations. Um, they are introduced in the last interim meeting. At this time, we added them into the draft, and people can find the detail in the new version. We welcome any question and comments to help improve this work, and we would also like to request working group adoption for the draft. Uh, and this is the second FlowSpec V2 draft. The topic is about the feedback binding. It focus on how to bind a FlowSpec rule with a feedback action so that the controller can request execution feedback from target devices. Uh, this draft was first proposed at IETF 124. At the last meeting, we introduced the overall framework for FlowSpec feedback optimization. After further discussion, we think the scope of this draft should be focused on defining a feedback action as an extension of the FlowSpec V2 action. This action tells the target device that the controller wants feedback information. Other parts of the framework, such as how the feedback is reported and what format or protocol is used, will be organized in a separate roadmap document and will be introduced at IETF 126. So this time, uh, I will only introduce the scope of this draft and limited it to the definition of the feedback action. For this draft, the problem is quite clear and it has been widely recognized by operators. Existing FlowSpec is mostly one-way control. The controller sends a rule to the target device, but after that, the controller may not know what's really happened on device. For example, was the rule installed successful, or is it matching the expected traffic, is it actually help with mitigation or traffic handling? For operators, this information is often not directly visible. So we would like to provide a way for the controller to ask the target device for execution feedback. This feedback can help operators understand the real behavior of the rule and improve their traffic handling strategy. This slide show the basic encoding of the feedback action. It is carried in the community container with fields such as feedback ID, reporting interval, trigger mode, and report scope. The design is still expected to be refined based on the ongoing FlowSpec V2 work and comments from the working group. And we will continue to clarify the roadmap of the FlowSpec feedback framework and optimize the action field design, and also conduct initial validation. And we would also like to request adoption for this draft. Uh, that's all. Thank you.
Sue Hares: Any discussions on this one? So, I would like to pick up a bit of the discussion on what we've changed. Yujia, can you go back about three slides, four slides? I think that'll be the right one. Okay, so that's right. Uh, so the new FlowSpec action is requesting execution feedback. Go to the next slide. So, this type of reporting is saying what you need to give back. Um, that is important because oftentimes you get a FlowSpec filter and you have no idea. The... these... go to the next slide. Yep. One of the... so, that's one idea that people have mentioned several times is the fact there's no feedback. BGP is a very difficult thing for that feedback. You may be able to have feedback in something like the Yang publish mechanism. So realize that that could happen there. You could say "I really want feedback on this" and you could trigger some of the notif work out of Yang, which might be more effective. Okay, so realize that we could combine these things. So that's one comment. Anyone else want to discuss that?
Jeffrey Haas: So, Yang streaming telemetry has been discussed in earlier versions of Yujia's presentation. And so has BMP feedback as well. So having many options to provide the feedback will be useful. Uh, one of the related conversation points is if a local device can't install rules for some reason, it could carry that to other devices in the network. There are some FlowSpec use cases where the hop-by-hop distribution of the FlowSpec rules, you know, might be helpful, but most FlowSpec deployments tend to just use BGP as a distribution mechanism and currently does not care whether each device installs the rules or not.
Sue Hares: That's correct. This is... this would be an additional feature. But by using those other predefined mechanisms that we've suggested, it might provide a better flow path for the response. Okay. Anyone else want to comment on this? Okay. I want to cycle back to one other thing that's a change from our previous presentation on the changes to IP basic. Because we're moving the... one of the things I had hit very strongly in a previous presentation on FlowSpec V2, we hit something we could not... okay, we hit something we could not fix with our previous presentation and move the component ordering for the IP basic to a skip-by-10 numbering. That means we could stay with the IP basic draft only and slip in new components between those numbers. Some of those might be the ones we've just specified. Um, and that's why you'll see some of the optional bits and mandatory concepts. For those who've presented today, you might want to look carefully about that. Jeff and I will start discussions on the list. Uh, also, we're welcome to discuss this if you want to unicast your questions to Jeff and I. Since we couldn't keep the... one of the tenets we had tried to for no IP basic changes as far as numbering, this new numbering seems to have opened it up, so we might not need the extended IP numbering, but might use just one numbering of the components with an IP field. That may simplify a lot of these adoptions and may help us. I don't know if that was clear. Okay. Jeff, anything else, or Keyur, anything else we should cover this morning?
Jeffrey Haas: That's it from me.
Keyur Patel: Good from my end. Thank you.
Sue Hares: Jie, anything else we should cover? I notice we had some questions on the list. Not hearing you speak, Jie. If you want to chat, that's fine too. Anything else we should cover, Jie?
Jie Dong: Uh, nothing from my side.
Sue Hares: Okay. Thank you, Jie. As you see... thank you, Jie. Uh, I think then we'll close the session. Thank you very much. Uh, we will be doing these targeted interims, hopefully to make everything a little easier. Thank you very much. Have a good day.
Yujia Gao: Thank you, Sue. Have a nice day.
Sue Hares: You too. Thank you, Yujia. Thank you all. We're going to close the session now. Thank you very much.
Xiaomin: Thank you.
Jie Dong: Thank you. Thank you.