**Session Date/Time:** 26 Oct 2026 14:00

[00:00:24] **Sue Hares**: Okay. I have the revised repositories. Okay. Nope. That's not what I want. Okay. Keyur and Jeff, do you see my... Do you see the note well on the screen?

[00:01:15] **Keyur Patel**: Yep. I can see it.

[00:01:17] **Sue Hares**: Okay. We are good to go. We will start now because the agenda's packed. Greetings, folks. I am going to remind you this is an this is an interim meeting of the ITF. It is under note well, meaning you should pay attention to both the professional manner and extended respect you give to all your colleagues, per ITF policy. You should also be aware that any ITF contribution is as defined in ROC fifty three seventy eight covered by the ITF policy, or you can see ROC eighty one seventy nine. The procedures are covered by ROC twenty twenty six and ROC twenty four eighteen. You will find out in the next ITF that part of that will include moderation on lists. With that, let me start with the agenda and the chair slides. We are going to go through our topics by our major categories. The first category is SR/TE drafts. Then... And the... We have two presentations by Zhenqiang Li. Then we're going to go to flow spec, and we're going to go through both changes to the basic. O nine will be released today. I wanted to make sure Jeff had a chance to look at it as a coauthor. So he's just coming back from a bit of time off, so we'll take a look at that. You'll get it published. I'll go through the presentation on that. We are then going through the filter drafts and adoption and then through the extended community adoption. Jeff will then, at 11:00, give a course section. In the course section, give an update on the forty two seventy one BIS. I'm sure he'd love you to participate on GitHub as well. Then we're going to neck... Best selection governed by Next Top. I will give an introduction. Olivier, who I have unfortunately spelled his name wrong. My apologies, Olivier. And Kevin will give two sample presentations, and I will give some focusing on a question regarding draft-idr-idr- multi next top, which is again spelled wrong. My apology to Kaliraj and coauthors. And then we will go through questions on next top, on path resolution via next top, which have been raised by some of the SR metric authors. I'll give a a background on it, and then we'll come to the question. We'll then have a few minutes to discuss if the path... Best path next hop selection proposed by Olivier is a good way to go forward. And lastly, we will go through core adoptions proposed and on the list, and then we'll talk about what we're going to do at ITF-one hundred twenty six. With that, I will go right in. The status is on GitHub. I did not complete the status on working group last calls on adoption. I will send that out to the list. Any questions on our agenda for today? If not, I'm going to drop directly into the next presentation. Just a minute. And I am going to pass the slide control to

[00:05:59] **Zhenqiang Li**: Actually, Sue.

[00:06:00] **Sue Hares**: Our speaker.

[00:06:00] **Zhenqiang Li**: To chat. Luuk Song will be taking over from who's having microphone problems.

[00:06:06] **Sue Hares**: Okay. Just let me then pull back the... Take back the control, and you've given it to Yujia. Please go ahead, Yujia.

[00:06:24] **liusong**: Hi, Sue. Can you hear me?

[00:06:26] **Sue Hares**: I can hear you. Wonderful.

[00:06:28] **liusong**: Hi, everyone. I'm liusong from China Mobile, and I will introduce BGP SR Policy indications for BFD configuration. Today, BGP SR Policy carries past intent to the hidden, but the social eight SPFD profile is still config... Configurated separately through network configuration. This carries two problems. First, it it is operational complexity and it turns service turn uptime. Second, independent provision can leave policy and monitoring intent inconsistent. So we define an optional S-BFD parameters within the encapsulation attribute carried with the asset quality SR Policy NLRI. The desired Min TX Interval and detection multiplier for that candidate path. If the parameters are absent, our receiver does not support them. So exciting device level defaults are used. There are two main benefits. First, it gives operators a single provision plan. Policy intent at S-BFD profile arrive together and remove the separate per policy CLI or NetConf state. Second, it closes the BGP SR Policy capability gap. The related PCE S-BFD adaptation has been adopted as a PC working group draft, demonstrating support from both the BFD and supporting working groups for this work. This gives BGP SR Policy the equivalent capability. There are any questions to the working group. First, we also say separate S-BFD provisioning as an operational gap for BGP SR Policy? Second, does this optional subtitle rate create any issue for exciting BFD, Spring, or IDR behavior? And we welcome other feedback. Thanks.

[00:09:38] **Sue Hares**: The reason I asked these authors to to make sure they had BFD and Spring support for this draft is we will not go forward with adoption unless we have some sense that BFT and Spring agree with this process. Okay. Are there any comments that I've missed in the chat room, Jeff or

[00:10:16] **Zhenqiang Li**: There are no questions in the room.

[00:10:18] **Sue Hares**: Okay. Let's go on to the next slide. Let me take back the share slides, and we'll go with the next one.

[00:10:30] **ruiqianhu**: Oh, okay. Can you help me?

[00:10:58] **Sue Hares**: Yes. I can hear you. Thank you very much.

[00:11:03] **ruiqianhu**: Okay. Hello, everyone. I'm ruiqianhu from China Mobile. Together together with my co author, Zhenqiang Li, also from China Mobile, I'd like to present our draft, BGP extensions for network resource partition. I I can't control.

[00:11:48] **Sue Hares**: You are controlling. You just may see a delay in the presentation. Why don't I take back the control and you tell me what to do next? Okay?

[00:12:03] **ruiqianhu**: So sorry.

[00:12:04] **Sue Hares**: You are on you are on the problem presentation. Go ahead with that, and then we'll we'll we'll go ahead and get the slide to the next. K. Go ahead. You're on the problem slide. Go ahead and present that one.

[00:12:25] **ruiqianhu**: Okay. Let me start with the problem. The existing draft draft- iETF-idr-s are policy-nrp. Extends BGP SR Policy protocol, RFC 9256, to distribute NRP IDs with a structure one to one banding between each NRP and an SR Policy. This works well for a small deployments. But as the number of NRPs grows, SR Policies grow linearly. The next the next. Oh, thank you. Our core solution is to decouple SR policy from NRP. Instead of extending the BGP SR policy protocol, we extend the standard BGP to advertise NRP ID information in regular routing updates. Using a new, positive, opaque, extended community. Our key idea is that it is an service, not the ASR policy that requires an NRP. In this way, multiple NRPs can share one common SR Policy path, the next. This exam brings two key benefits. First, higher scalability for slice deployments. SR Policies no longer grow linearly with the number of slices, and the duplicated motor... Monitoring sessions are removed. Second, lower operational complexity. The same mechanism applies to both SR-TE and SR best effort. It also introduced the no new security considerations. Overall, one one shared path can save multiple slices, where NRP resolution and the course are still enforced at the resource layer. The nice size. Okay. Thank you. That covers the core of proposal. Now I'd like to open for discussion. First, do you also see the one to one NRP to SR Policy binding as a scalability and operational gap as less deployment scale up? Second, does this approach raise any issues with the existing TEAS, SPRING or IDR technologies? And we welcome any other feedback. That's all. Thank you.

[00:15:29] **Sue Hares**: Do we have any... Krier's got a question in the chat room. I see no I do not have any hands raised. If you will respond to the chat room from the coauthors, we'll go on with the next presentation. Folks, these two drafts will ask these questions on the list as well. We will need those answers. If you have ideas and want to comment them at ITF one twenty seven as well or on the list, please do. Okay. Now comes to the summary of o nine. O nine will be released today. There is something that we have not discussed in o nine, which is the, whether we need open capabilities for filter families, and that was raised. So we changed in o eight, and o nine the fact that we are... The MRI that flow spec v two is working on. The... We used simply a flow spec NRI with one AFI for flow spec v two and two SAPIES, Unicast and VPN. This is a change from the previous drafts. Okay? The flow spec ordering is user order, filter family, component, and then component values. Here is the header. You will notice the length, the dependency filter chain, the user order, the filter family TLVs are following. The filter family TLVs have this form, family type, family length, components. Now filter family ordering. FlowSpec v two must pass filter family TLVs even if the implementation doesn't understand them. That gives a distribution. All filter TLVs must be ordered in strictly increasing fashion, and filter types and filter type specific components must not occur more than once. K. I've repeated the ordering. Dependency chains is a number. If it's zero, there is no consideration given for dependence. If it's nonzero, then filter flows back v two just share the dependency in faith. That is if value one is invalid, then all the filters with the dependency value are invalid. Component flags. This is where discussion on the list with Robert was helpful in bringing this out again for people. Jeff and I mentioned this at ITF-one hundred twenty seven. There's an optional flag that signals if a component can't be installed, it can be safely ignored. The value for it is mandatory. If a mandatory component cannot be installed, the entire filter term for the flow spec is not installed. Here's an example. The rule match on one twenty eight, one one one eight, and I believe that should be a 24 at the top, then port DSCP f e one and permit. And then you have the second rule with a a more more specific... Excuse me, a less specific, more general form. If the rule cannot install rule one, then all packets. If both rules have dependency 10, then rule one is invalid. Both are ignored. Filter families. Jeff, just interrupt if I've done something wrong. Perhaps my... We have filter families. What we changed from previous versions is we renumbered to give more space. That allows us to add space in the filter families. We did the same with components. Now two filter families are useful to understand... Or three are useful. The IP basic is v four. The IP v six basic is the v six addresses. You will find that we have numbered components in those two so that they are, in the same numbering component space. I will show you that. CATs and routing are two other filter families. Routing gives information that if you match on a particular NRI, it will go ahead and check the routing information. I will go... We have a presentation. Here are the components that we've done for I p v six, And you'll notice at the top, we have packet content quick quick headers. All of those are receiving positive adoption calls, so is Bitwise filters. Partial deployment. Only a portion of the nodes, white, support a filter type. The route reflectors and VDG check only the meaning. Notice it distributes but is not engaged. Reason two, upgrades. We may have only a portion of nodes. In which case, the picture would be slightly different but the same concept. You will have some nodes that know and the rest that pass and distribute. Actions opposed in flow spec v one or flow spec v two. There are types of actions that group types of actions that shape traffic, types of actions that change an ITP packet, redirect, and flag for assembly or terminalling. We have one action today we will be discussing that's an adoption that applies to traffic movement, shaping, compression. We have another that does redirect. I think that will help you understand it. This is an open issue whether we should have a community that specifies what happens on an action failure. For example, if you cannot compress, do you continue on? We said that in flow spec, the one actions that has to be done by comments in the text. We are also looking if an action community might help with your... To spread throughout domain, what happens if you should fail. Minimal compliance. We would assume at least one AFI, SAFI, Unicast, and some extended communities recognize all support one. If you don't support one, what's the difference? If you are in the partial deployment and you recognize all and pass, that's different than what I mean by support. Support is that white part that actually does it. Components, you would need to support mandatory that you set. Validation. We have syntax and semantic checks, route properties, route actions. In the LRI checks, we have a link 20, although I had a comment whether it's link 20 or 16. We'll walk through that. I may have an error in in, dash o eight. There's a nonempty filter family, possibly empty, and sub TLV... All TiVos and sub TLVs are in their parent. If there's a failure, it's a session reset. Bad thing. Okay. Now what about validation? This is something between o eight, o nine. It was pointed out that it's easy to to validate, that is check that that you are on, going through the flow spec v two validation with Unicast or with the VPN for multicast or the v six. These are based on filter families plus the IP. I am unclear whether... I think you can do the same for FSv2 and components. I'm unclear if l two VPN should be added. We will... Would like feedback on the validation as that again is a is a change. Syntax limits. If you have a failure in the syntax limits with either the ascending... Ordered ascending or ordered ascending for components will treat as withdraw. Again, we could use some review of the syntax limit text. Route validation. Flow spec, if it failures, is not valid for traffic filtering and is not installed. These are the validate for the route. The best patch Unicast is what I just went through. I went through how that affects filter families. We need specific comments on that to see if we've got it right. Next draft steps, revise to o nine republish, take care of the adoptions, and then look at the extended community adoptions. We'll then go on to work on the community container, which is needed for ordered actions, and we'll start a draw... Individual drops. Keyur?

[00:26:56] **Keyur Patel**: Real quick. Just a note that version 10 will cover the capabilities as well. Right?

[00:27:01] **Sue Hares**: Yes. Version 10. Or at this point, maybe version 10 will contain the capabilities. So you can say I have a capability of this filter family. Okay. This is maybe a repeat. I'm not seeing the emission. I think Jeff ordered it. The directional is inbound. That is probably something we need to clarify on the directional on that. So thank you, Joel and Robert, for general comments. At this point, more questions. Otherwise, we will launch into a review of the existing things in adoption. Okay. I will bring up the next presentation. These are time filters.

[00:28:27] **Zhiwei An**: Go ahead.

[00:28:31] **Li Zhang**: Sorry. Oh, okay. Okay. Sorry. It's a delay on the slides. Okay. I can hear... I can see it. Okay.

[00:28:37] **Sue Hares**: And do... I'm gonna pass you the slide control. If if you have a problem, let me know. You are on the first slide.

[00:28:49] **Li Zhang**: Okay. Okay. Good good morning and evening. And this is Li Zhang from Huawei. I will introduce flow spike extensions for time scheduling. And if there is some delay in the network. I cannot see the second slide.

[00:29:19] **Sue Hares**: That's okay. I will I will take back slide control. You are on the second slide. Please go ahead.

[00:29:27] **Olivier Vroonen**: Yeah. Yeah. Yeah.

[00:29:28] **Li Zhang**: Okay. And I think this page is almost the same with the next page. So maybe we can just skip this page. We can go ahead to next slide.

[00:29:43] **Sue Hares**: Yes. I've got you on the next slide.

[00:29:45] **Li Zhang**: Oh, okay. So the problem is that in some cases, the operators wish to perform different actions for their same traffic at different time. So the f... Flow spec factors, may need to support time based scheduling. For example, in IP carrier backbone networks, traffic varies periodically, and traffic surges during daily rough hours and may lead to congestion in their network. Therefore, the time based flow spec filters are necessary to perform different actions at rush hours and light load hours. FSv2 already provides a filter family named the time filter family as introduced by Sue in their last presentation, and they also assigned 200 for for its type. So this draft defines a new component within this time filter family, which is named the schedulingtimecom... Component. They include a list of scheduling time information struct. The format of the scheduling time inform... Information struct is shown in the figure on the right of this page. It includes a schedule ID, which is uniquely in the component, and it has a lens to indicate that the lens of the value field. Now it has two flags and also have a start time and the time of the time window. And, yeah, I think it also have a frequency and a recurrence count for the theoretical scenarios. And we can go to next page. So we... This draft received was three Thomas during the adoption, which is all from Linda. The first line is about the extensions to flow spike version one. Since the working group has decided not to add a new app component... Components extensions to flow spike version one, so we removed their extension extension to flow spike version one in this... In the in the draft of version file. Another second comment is about the clar... Clar... Clarifies the behavior when multiple schedules overlap because there is a priority field in there's... In the in the structure. So we have a think about the... This this comment, and we think the priority field is a mistake. Actually, we don't need this field, and we have created this mistake in zero zero five version. And the last the last comment is the start time and end time are absolute UTC times, and please state the clock synchronization assumption and the expected behavior for clock score or error. And we have aid of some clarification in the r zero five version to state the assumption for clock synchronization and that's expect... Expected behaviors when the clock clock loss of cyclonization. And I think that's all about this presentation. Thank you.

[00:33:45] **Sue Hares**: Thank you for giving the presentation. We will go on to the next presentation and take questions at the end of the filters.

[00:33:59] **Li Zhang**: Okay. Thank you.

[00:34:00] **Sue Hares**: Thank you. This is... Nat, are you there? You've got... I'm gonna pass you this. I'm gonna pass you the slide control. You should have it Okay.

[00:34:16] **Nat Kao**: Hello, everyone. I will give an update for the updated format of the IPv four source and the session POS filters. And, it's... That's no... Not not too much differences between the last version, but, we redesign... Redesignated the the filter type, component type to align better with the current dash zero eight version of the FSv2 basic draft. And the component family for I p v four is the I p v four filter family. And the component type, there are two types, one for destination and one for source. So that's all. And the lens and the value field are actually the same from the last version. We have a lens, which indicates, how long the value field is, and the value field is, comprised of, pattern and mask, tuples, and, each indicates a match. So, basically, it's the... Almost the same with the last version. And, it's similar in I p v six. Basically, we have two filters, source and decision, and, they have different component types, for decision, one for decision, one for source. And the the component type is I p v six basic filter family. So, yeah, that's it. It's... That's not too much differences between the... This version and the last one. Alright. So... And the current temporary assigned component, type values, which aligns with the FSv2 IP basic draft. We have IPV for, the sensor address, POIs filter 800 and 4 for source 8800 and 10. And for the source source address POS filter 1100 and 111100 and 10. So, yeah, that's basically this... The the update format. So, that's all.

[00:36:23] **Sue Hares**: Thanks, Nat. Again, the authors have been very kind to stop. I've gotta take back the slides. Just a minute. The authors have been very good to adjust to the new numbering scheme. This is now the packet filter, which we've had some discussion. Yujia should be ready to present at this time. I'm not... There's Yujia. Okay. And I'm giving you the slide control, Yujia.

[00:37:09] **Yujia Gao**: Okay.

[00:37:12] **Sue Hares**: It's

[00:37:17] **Yujia Gao**: I think I cannot control it right now.

[00:37:21] **Sue Hares**: That's okay. I'll go ahead. Here's slide two. I'll take it for this time. Just say next slide.

[00:37:29] **Yujia Gao**: Okay. I will start. Thank you, Sue. I'm Yujia from GuangchenSong, and I will introduce the packet content filter. And here is the update filter components in coding. As we as we can see, we have allergen the FSv2 assignments with the IP basic draft, and the component type is 3,000. Next, please. And here is the problem statement. The large DDoS attacks can put heavy pressure on downstairs links and scrubbing centers. Operators have seen attacks that reuse the same visible payload across many packets. This is a simple low cost way to generate a large volume of attack traffic. Even when packet headers vary, that repeated pattern gives us a way to identify some of the attack traffic. This drafts adds a packet content filter so that flow spec can match those bytes at no offset and help block matching traffic ups... Upstream. And as Robert points out on the mailing list, this only works when the content stays the same across packets. It... It's okay. And if the bias keep changing as they often do with encrypted traffic, I fix the content match will not help. So this is an option for attacks with a stable visible person rather than a general solution for encrypted traffic. Yeah. And here is a use case that shows why operators want this capability. In a carpet bombing attacks, traffic is sparried across changing destination IP addresses. And together, that traffic can come just to link towards access next network and increase the load the scrubbing system. So if traffic analyzers find a stable payload pattern, the operator can distribute flow stack rule to selected upstream mitigation points. Devices that supports content matching can then block matching packets earlier, reducing the downloads their congestion and the scrapping loads. And the robot and Zhenqiang also focus on concern about the impacts on forward performance. We we tested content matching on a switch that's that's it in the ASIC. And at 100 Gbps of attack traffic, the average store and forward latency was about two microseconds, and that was better than the expected. And the details are in the backup slides. If anyone interested in... You can find it. And finally, some comments are focused on the security considerations. For the eBGP, receiving a rule does not mean a router should install it. The router still needs to check the rule and apply its local import policy. We would only able this filter on EPGP session based on explicit trust and solidation arrangements. And they also expect operators to use it only as selected mitigation points. And also... We also gave some secure... Security consider... Account considerations. And as as Jie Dong suggested, notes targets could help identify which mitigation node's rule is meant for, but each each node still needs to decide whether to install it and the router reflector scenarios. We will say how that study, how to make that decision clear and how to contribute to the border flowspec v2 work. Thank you.

[00:42:26] **Sue Hares**: Thank you for that good short condensed presentation. We've run out of time for that. Please ask questions in the chat room or online. I am going to now share the next set of slides, which is on the quick presentation. Just give me a second while I bring up the quick presentation. Yujia Gao, are you presenting this one as well?

[00:43:04] **Yujia Gao**: Yes, I will.

[00:43:06] **Sue Hares**: Okay. Thank you. That'll make everything easier. I am still controlling your slides. You're on the problem solution and benefits.

[00:43:14] **Yujia Gao**: Okay. And this draft is about the flow spec for quick. And here is the problem, solution, and the benefits. The traditional flow spec matches traffic using fields such as IP addresses, ports, and the the transport transport protocol. For quick, different connections may use the same UDP port. So this felt alone may not give operators enough granularity for traffic steering. So this draft proposed three new FSv2 components based on visible quick header information, which has a destination connection ID, the source connection ID, and the header flag. They can be used with the IPv4 and IPv6 filter families. Then this slide also shows the intended use. When a controller identifies traffic that needs attention, it can use a no connection ID to steer matching traffic to a selected path. The header flag can also be used to match certain quick packet types. Other quick traffic using the same UDP ports can continue on its normal path. This could support more precise traffic steering, help isolates problematic con... Connections, and enable more targeted mitigation of attacks against quick services. Connection ID can change during the lifetime of a connection, so the controller would need to update the role when the ID in use changes. And here are the proposed components layouts. We have allegiance them based the FSv2 IP basic design. The two connection ID components match a specific ID value while the header flag components use bitmask to match selected bits in the first header bytes. These components give FSv2 additional ways to match quick traffic without inspecting the contents of encrypted traffic. And that's all. Thank you.

[00:45:47] **Sue Hares**: Thank you very much, Yujia. We're gonna go on to the next presentation. Let me share those slides. We're now going to look at the routing filter family. Let me see if I've got... I took... There is a more detailed set of slides on this, but due to time, I compressed it for, the rest. I encourage you to look at the details on the routing information because they've been assigned to a filter family, and we think it'll be very helpful to have a prefix and then have a filter. Please see their original slides. Here's the filter family. You have a component type where you have a list of source pairs and the numera... The numerical operator to match either destination, origins, and source. Now how does that actually work? The user extracts from the packet either a source or a destined IP address depending on the type of source information or destination information filter. It looks up the IP route in the BGP LOQUIV associated with the active BG route, evaluates the AS attribute of the received route, and then evaluates whether the origin AS matches or, the packet. And this allows the packet to have a match that includes source of destination address plus routing information. This is also true for the community routing information where the filter family for destination has a destination address plus a community. And those are two drafts, and we have the same thing. Extract the IP address, see their source or destination. Look it up in the low crib, and evaluate the community of the retrieved route. This gives some additional indirection that ends this presentation for filter families. Give... Given time, I would like to go on to look at, actions, but I wanna pause here in case you have questions on the filter families. These are the filter families we are going ahead and looking at for adoption. We have fairly good adoption for that. Okay. Any questions? Just a minute. I'm locating the next. Okay. The first of our actions is in addition to the path redirect draft. I'm going to present that for the authors. Serge Krier is one of the authors, Jie Dong is, but I'm gonna quickly show you that it's the same redirection ID. Instead of just having it go to s r tables, it's going to binding SIDS. And that's its basic functionality. Instead of a a redirect path redirect, it's going for v six to the SID or the binding SID based on either an index or an SRV six. And there is a longer presentation and good argument, but I'm catching us up on time. Any questions about this action? These actions are available for v four and v, for v... Flow spec v two and v six. However, however, I'm I'm... Some of them may not have a strong sense for v one. Any questions? Okay. I hope this review is... Yes. Yang presented Yang Yang Huang presented slides. Please look at his slides. His slides are better. But I am gonna ask you, Yang, to to go ahead and wait and see if we have any questions questions on that prior to get... Going through the slides. That's because we're a little bit behind on time. And please look at his detailed slides, and we'll pick it up for questions. Another one that we have for, that has been on the list is the direct... Redirect IP from the folks at China Mobile. Who is presenting today? Is it Zhiwei? Okay.

[00:51:38] **Zhiwei An**: Okay. Can you hear you? Can you hear me?

[00:51:41] **Sue Hares**: I can I can hear you? Go ahead. I will progress the slides.

[00:51:46] **Zhiwei An**: Thank you. Hello, everyone. Today, I will present our draft on g p flow spike redirect to a direct connect IP rights. Let me start with the current redirect IP paper. Flow spike, a room matrix traffic, and a specific IP address, the... This receiving router performs longest perfect match match lookup for the target in its next hop resolution database. It then forwards the matching package according to the resulting root. The problem appears when the operator intends to use a particular direct connect link. If that link fails, aggregate of default route may still resolve their target IP. The redirect policy can therefore stay active even though the intent... The direct path is no longer available. And in the first example, let's leave unnecessary redirect act. And in the second example, it causes a forward loop. Please to the next slide. Please change for the next slides. Thank you.

[00:53:12] **Sue Hares**: I'm on the scenario one slide.

[00:53:15] **Zhiwei An**: Yes. In scenario one, the control installs flow spike rule on r one. The rule matches the traffic for network two and redirect it to our first interface address... Addresses link a. Link a has a delay on one millisecond, but its IGP metric is 100. Normal destine... Destination routine performance to pass through with a total metric of 20 and a delay of twenty milliseconds. While a is available, the redirect provides the intended low latent pass. And now if the is failed, r one removes... Is connected the routing to their target. However, aggregate or default route still resolves that target through r three. R one keeps applying the redirect and the traffic resources r four through r three. There is the SIMPAS that ordinary destination forward or use. The re... Redirect no longer provide the load case service, so keeping it active is unnecessary. With the decided to what... R one in what case the policy will, when it's because detects that is available. The back phase here is to stop applying a redirect whose direct link requirements can be no longer be met. It it doesn't restore the the failure one millisecond pass. The next slide, please. The scenario two.

[00:55:17] **Sue Hares**: Yeah.

[00:55:18] **Zhiwei An**: Scenario two shows a more serious consequence. Here, s four is a traffic stop... Shopping system, and the network tool connects only to r two. R one redirects the traffic for network two to s four's directed... Directly connecting interface address. Normally, s four cleans the traffic and reinject it towards neck... Network two. The reinjector pass was... Applies apply r one's redirect rule again, and it omit from the. And now, if the direct link between r one and s four files, the aggregation or direct routes still resolve... Results as far as target address through r three. R one then keeps the redirect policy active and sends the matching package to r three. The example is the IP forward without a to as well. The package still carry network two as the original destination. R three looks up the destination, and the next hope is r one. So r three will assess the package back to r one. The traffic looks and show is TTL express consuming resources and presenting deliveries when... With the decide to one... R one, e n validates the direction policy. When the direct leak fails, list breaks the loop. And the the next slides, please. And in the last last slides, policy declines existing policy with D equals to zero, retains their current behavior, upgrading device doesn't autonomously change the the in policies that were previously advertised For policy with D equals to one, surprising receiver follows to the draft and associated the target with the direct connection leak and invalidates. The policy will let the link will unavailable. This is a local policy state change. The controller doesn't need to withdraw and re... Otherwise, test the the route solely because the link stayed changed. Less hard. Thank you.

[00:58:09] **Sue Hares**: We'll have to take questions on the list. I wanted to give everyone a taste of the rest of the presentations. I have one more, of the presentations, which I will, again... My apologies to the, authors. I'm gonna give you a very compressed, presentation on this traffic compressed extended community. Yes. Yes. I realize that was a little redundant in the words, but they are taking a global administrative community. They are selecting compression algorithms based on RFC thirty one seventy two and using the parameters. That's what they're signaling. Ingress node is the normal place for receiving the match and acting as compression controller far... Prior to forwarding to a constrained WAN or DCI links. If there are multiple ones, extended, of extended communities, the first one takes precedence. Hardware offload is important for this. If it does not exist, the function reverts to standard uncompressed. My note on that, please see the mandatory and optional flags and the dependency. This type of thing is where we have that.

[00:59:46] **ruiqianhu**: If...

[00:59:50] **Sue Hares**: I believe... That's a good question, Joel. I will take that to the authors unless they are online. I did not get an act to see they would be online at this time. I will ask them to answer that in email, Joel. Good question. Joel also asked the questions on some other portions of this. So, Joel, I will not answer for the authors, but I will take that to the mail list. Thank you, Joel. Okay. Well, we're just about right on time. Thanks to the kindness of Yang Huang because I skipped his presentation, which was really great, but I was behind on this schedule. Now the purpose behind all of this was the fact that there is an adoption call going on for all of this. One comment. And, John, if you can give me back one more minute of the presentation, I... Flow spec v two. The idea for the flow spec v two work is it's a group of work. And what we found is we wanted to adopt a group of filters and a group of actions to shake out any problems we have with the base spec. Unfortunately, we found several, we found a couple things that could be clearer in the base spec. O nine and o 10 will take care of that. I have o nine in a GitHub repository. Keyur mentioned the thing that will be in o 10. Okay, John. It's up to you to bring us the forty two seventy one bis, and let's see if I can successfully pass the slide control. It is now yours.

[01:01:56] **John Scudder**: Looks good. Hi, everybody. Good morning, afternoon, evening as the case may be. Yeah. So we're gonna talk about, forty two seventy one BIS again. I mainly want to cover the changes that I published on Thursday in version o three and also just give us a little bit of a reminder about the project. I think the overall project is, like, well enough underway that I don't have to keep reintroducing the whole thing. We're working to take our base specification and bring it up to date. A reminder of the project scope and, you know, I don't wanna pick on anyone by name, but it did come up recently just to put it is that we are and aren't doing. And I think it's worth being clear, both just as a reminder and, in case, anyone wants to, open this back up for for saying no, that actually shouldn't be the scope. But since since we introduced the project, we have said, our goal here is to document what is, and that it... It's not to make changes. It's to take our existing RFC set and for the components of the RFC set that are sufficiently mature to bring them to full standard, which has a whole set of its own requirements that exist in the IETF process documents, and those have been covered in previous presentations. And, of course, you know, we we have our regular working group process available for any kind of changes that people think we need in our in our document set. So... But point here is that forty two seventy one bis is not the place to change our technology. That it is the place to document our technology. There's gonna be... You know, there there are sometimes corner cases, but as few as possible. So now I'm gonna jump into what the last time I presented, I talked about draft one. So we're now up to three. Draft two was just a minor update. I realized that it's useful, to me if no one else. I hope also to others to have a detailed change log embedded in the document and not just, something you have to go and scrape out of GitHub. And also in that version, I added references to extended message support. So, hopefully, every place in the spec that you now see something talking about message length, you'll also see a reference that says, please be aware that 8654 changes the the message length if it's in use. And I wanted to have that published as a baseline because I wanted version three to cover exclusively revised error handling because it's a big diff. And it was both bigger and harder than I expected it to be, but we have it out now for discussion and review. So what does it do? It... As hopefully most or all of us know, I think a decade or more ago now, we did RFC seventy six zero six, which basically scooped out the previous error handling procedures that we did, which were essentially always... If you see something, reset the session. And for sessions that are in established state, instead, what we do is insofar as possible, we do the smallest possible correction to to both maintain the session in in some kind of correct state without resetting it. And it was extensively discussed at the time that we were standardizing this, that it has pros and cons. The the big con is really that your session can get desynchronized, and you... It's harder to notice it because you don't have every alarm bell, and you're not going off because the Internet's melting down because your session reset. But that's that's, you know, just... That is what the what the spec is. So the the ask to me now was take this and integrate it properly. And the one normative change I made is to say... To to add a sentence that says this is that it's okay to revert to the session reset behavior by configuration if an implementation wants to offer that as a configuration option. So the the changes to integrate it, it... I was thinking it was gonna be more of sort of a cut and paste job. It was very much more of a rewrite the whole section job. I would very much appreciate eyeballs on to make sure that it makes sense. I think it does. So several things were left out from seventy six zero six. It... There's... The FSM is just wrong when... Now when when it comes to... I can't remember the name of the event, but it's in the... In that issue reference there, issue one forty. But there's a whole bunch of FSM work, and I... It it wasn't part of the existing seventy six zero six, so I deferred that. There's a whole grab bag of attributes that are all updated as part of seventy six zero six. I did not think we needed to do that in 4271 this. And then there's some sort of philosophical stuff in sections one and eight, and I think maybe those can go into an appendix. I don't think they really need to be in the main line of forty two seventy one bis. And unlike the other RFCs we've integrated so far, I did not let... Add seventy six zero six to the obsoletes list because, of course, we still need it as a live RFC to to be able to update those... That long list of other attributes.

[01:08:46] **ruiqianhu**: Yeah. Okay.

[01:08:48] **John Scudder**: So this is a a... Essentially an excerpt from the change log, which is more comprehensive. We discussed on the list taking out a paragraph about unrecognized well known mandatory attribute. I did take it out. And then it turned out that after this work was done, there were a whole bunch of error subcodes that are no longer reachable. We never send those errors with the the updated version of the spec. So I added the notation deprecated next to all of them, but I left their symbolic names in because people are still still gonna wanna be able to log those. And logging them by name would be nice. And finally, I I threw in a definition for recognized because we we lean fairly heavily on... You know, if a thing is recognized, then you do one thing. If it's not recognized, you do another thing, and I I realized, oh, we've never defined this. So now there is a definition. I think it's the right definition, but, again, having some eyes on would be welcome. And then finally, I wanna acknowledge and highlight that Robert expressed a principled concern about, you know, just the fundamental suitability of seventy six zero six in... Maybe not universally, but in many situations. And, you know, as I presented upfront, I don't think that litigating that is part of the project scope. So I acknowledge his concern, but I don't intend at this time to make a... To make any updates relative to it. So that's version three. Up next, I've got a couple of fairly small PRs to merge in. One is a a pseudo code update, and one is a very small approach to integrating four byte AS. And I think that I'll be able to opportunistically take care of some other issues. I don't wanna bite off any other large changes before the cutoff for obvious reasons since we have a week. And I have... Last time I presented, I gave the working group a very large list of discussion and review requests. And as a result, I got none or almost none. And I think that the lesson to me there is a reminder that if you ask for everything, you get nothing. And this time, I wanna ask for one thing. And what I want is I would really like the working group to put some thought into what do we wanna happen in this spec about an LRI encoding. So there's there's a a long standing issue open about this, about the fact that we have two different ways to encode AFUSAFI one one. It's my view at least that the the legacy encoding is, you know, not the preferred one. It would... If we were doing this today, we would use the forty seven sixty encoding for everything. But, o g, we have a legacy encoding and for for good reasons. What do we wanna do about that? So we could incorporate forty seven sixty fully into the base. And the row for doing that is basically... It's really sort of icky and weird for the base spec to be written in terms of an encoding that we don't love. And, also, I didn't put this in the bullet, but also to leave out the encoding that we do love. Like, that's just a little bit odd. On the other hand, no matter what we have to we have to keep the legacy encoding around because it's gonna be a very long time until implementations can safely... Or at least implementations intended for deployment in the wider Internet can just ignore it. And, also, it will just be more work to integrate forty seven sixty. Right now, it's a a very successful standalone spec, and, you know, the effort that I've just done for version o three demonstrates that it's possible to to call out to it, and it it saves quite a lot of effort. And and I also do wanna ask both, do we wanna say something stronger than discouraged as I've added to version three, or, you know, does anybody think I'm wrong that that actually the legacy encoding is encouraged for AFI SAFI one one. So I don't know that we have time during this meeting, although I'd gladly accept any comments as far as I'm concerned. But I would really like feedback on the list, and I'll also open a a mail thread on the list just to give people something to respond to. So finally, you know, next steps, just as a reminder, we're working in GitHub. You are very welcome to claim issues. You're welcome to contribute PRs. I also really appreciate when people do go and review issues and add comments. It's seriously helpful. So as I said, the ITF one twenty six slide deck, I had a big grab bag of issues. About half of those have been resolved, but a whole bunch of others are still open. You know? Although I said I'm gonna ask for one thing this time. You know, if you feel like helping me with more things, I have added them all at the back of the slide deck. I'm not gonna show them right now, but they're there for your reference. Yeah. That is all. And I'm... If we have time for discussion, I'm happy to have discussions too.

[01:15:10] **Sue Hares**: I believe we are picking... We might wanna pick up this discussion after we do the best next hop. Jie has one comment in the chat room you might wanna pick up. So...

[01:15:27] **John Scudder**: Although we can do do it in in positive terms instead of negative terms or or maybe both. It's a good suggestion. I'll, I'll have a look at that. Okay. Thanks. Thanks for your attention. And, just one other comment. May... You know, possibly, we can, you know, since 01/27 is not that far off, we can also have more in-depth discussion about any of this that seems needed then. Thanks again.

[01:15:51] **Sue Hares**: I think I... That was one of my hopes is this would tee up people to be close to John's asks to John's, getting some of this 4271 work, on GitHub. We are branching into the third session, which is relevant to some of John's work on forty two seventy one, but we are looking at best path selections best on next hop. This arose from adoption of a call on some of the new... In the core area on draft-idr- BGP best path next hop selection. So, we have a problem. As times moved on and John's working on a forty two seventy one BIS, we had next support, top support that was the first IPs. And then the 2,000, there's MPLS. And by now, another twenty years have gone by, and we have SR MPLS, SR v six, SSC tunnels. So there's a variety of next hop information that's distributed, and there becomes in several of these drafts a request for update of, selection rules. Now these new drafts, are good work, but, if I'm gonna send these drafts to Ketan, I'm sure he'd love to see a common road map that reflects some of the charter and so with the rest of the ISG. So these slides sort of give you a quick road map discussion of this. I am gonna... In order to get the bigger size that I need, turn off the chat so if my co chairs will make sure if there's an urgent chat thing that I have it. Now if you look at it, what I really wanna focus on is what is actually happening in the draft as far as distribution of next stop information and selection. And all I'm gonna really go through is what it covers and what it distributes. The status there is for you to read. I am assuming that you can follow along. So we have AdPass that provided multiple pass. They distribute things that impact some of the selection. We have draft ITF, IDR, BGP, best path selection criteria, which draft - ITF, IDR, BGP best path next hop selection refers to. It dealt with what happens if we're not using IP and we're using MPLS. The chairs found that this was past working group last call in 2019, stalled at the AD or ISG form, and deployed heavily. So as draft ITF, ID or BGP bestpath selection refers to it, we're gonna push it through in addition. Now this reflects some of the comments that John has on forty two seventy one. This in GitHub, I'm sure maybe John and I can pick up this thread as we go forward. The AGI... The AIGP, the nontransitive attribute, had multiple domains in a single alias. It distributed metric and then impacted the selection. The prefix SID for influence provided distribution of information. The tunnel encapsulation has distribution and some would say based on SRTE, some of the selection of whether the the endpoint is really there and what's the distance to it. The... All the SRTE and SRPM work has distribution, but I'm going to underscore that up until this point, IDR simply distributes the work and shoves it over to SRPM and says, you deal with it. We are selecting only best distribution. If we look at intent, intent aware routing from s r... MPLS SRV six from CP, CAR, and CT, You... These informationalexperimental RFCs are deployed. They deal with distribution and selection. If you look at next hop characteristics, they distribute information. S s d one edge discovery distributes and does local... Hints at local policy selection. So does next next top nodes that uses next... The NHC function to distribute information and hints at local policy selection. RFC, forty two seventy one BIS, we're walking through the various selections and discussions, trying to make sure we have what is. Draft ITR, IDR-bestpath-next hop looks at selection via path resolution. Multi next hop attribute, and I will be presenting that. And I'm super glad that Kaliraj is here in case I trip over myself on that attribute. But what I'm focused on that, and it'll be one of the let... Presentations after, Olivier presents draft-ietf-idr-bgp-bestpath-nh-selection is how multi... The multi hop attribute distributes, has selection, and then has actions in it. Okay. There is distribution from extended communities from RFC 10,005, selection via local policy from draft ITF, IDR, EBG, DMC, extended community information distributed from draft IDR fare, and selection field local policy and edge discovery, has distribution and selection. Notice this last group distributes it and then tickles something in local policy. Recommendations need to be scrubbed to make sure they're accurate. Now what does bath resolution concept that draft-idr-bgp-bestpath Next Hop selection for Voges. It says we're gonna have a path resolution tuple with a resolution key. Most of them in his... In that drafts has IP as a resolution key and then a resolution context. There's the context of the actual function and some local policy. It proposes changes to forty two seventy one bis and by reflection that would have to come with forty two seventy one... Excuse me. It proposes changes to RC forty two seventy one, which means we need to look at how that also impacts forty two seventy one bis. The sections that you should look at in this short and well written draft is sections three dot one, three dot two, three dot four, three dot five. The question for this session is, does it work? Is it a good paraffin? Does it work with forty two seventy one? Here's my one slide. What does it do? This comes from the text that it works before tie breaking in nine dot one dot two dot one and in tie breaking. The key is resolved for the BGP using an IP, the resolution context that he recommends for ninety twelve, ninety two fifty two, and CAR CT, and then the resolution constraints, which are derived from resolution context and configure. The resolution chain, the forty two seventy one is in the next hop check and the... Adding a path resolution check, which can be enabled or disabled by config. Now what happens in 42, the tie breaking? That's where you remove from consideration all routes whose key resolution preference is not the lowest. This means you're sort of working with the side function that does the checks on path resolution key and gives you back a preference, and then you use it. When you remove it, then you look at the interior cost of the route, by the metric returned applying the constraints. The constraints are if the path resolution is resolvable, no path can be determined, the cost should set to max. So this must be tracked if you add it to code to make sure it's doing the right thing. Now, hopefully, I've given you an introduction. And where do we go from here? First of all, listen to Olivier. He's the one that wrote it. It's well written. It's a good read. First thought was... And I I open... I had editors when we adopted the draft in case we should put everything in this draft. My co chair said that was a bad idea. Well, after they thought about it for a while because it overwhelms a well written focused draft. Second is to use the concept as a mechanism to sort through all these drafts because eventually, I'm gonna shove them at the ISG, all these drafts that are asking for working group last call, and I want them to say, here's our road map. We really are working to a road map, and we've sanitized it. Okay. That's it. I'm a little bit behind time, but you've been through the first presentation. Olivier is next, and then Kevin gives you an example with the next next hop, and I will try to work on the rest at the end. I'm going to stop presenting and go right to Olivier.

[01:27:36] **Olivier Vroonen**: And,

[01:27:43] **Sue Hares**: Yes. Here we are. Olivier, you now have the slide control.

[01:27:52] **Olivier Vroonen**: Hello. Yes. Looks good. Okay. Hello. So I'm Olivier from Cisco. So I will present you the BGP best path next up selection draft on behalf of the coders. So this presentation is more of a recap the last presentation with a focus on the two concept of the resolution topel and the resolution constraint. So as Sue already explained, so the common statement is that RFC forty two seventy one is considering that next step is actually used for forwarding. So the result will be conditioned, the I b g p best pass tiebreak based on metric is close to that next step. So with new data plane, this assumption may not be true anymore. So we have two issue with that. It's traffic drop or a suboptimal routine. So what we are trying to address in the draft, in most case, implemented by other vendor to address those issue. So the goal of the draft is really to standardize those behaviors. So the the first issue, the traffic drop. So let's considering this MPLS VPN network. So p slash m prefix is advertised by p one and p two to p three. If we are looking at p three routing table, we have a next step reachability for both next stop one and next stop two. But if we are looking at the MPLS table, we have a broken LSP toward the next step one. So just based on r c twenty two seventy one, only the next step reachability is considered. So that mean we will compare cost of next step one and next step two, and then select next step one, which has a broken data plan, which would lead to a traffic load. So So the next issue is the suboptimal pass. So assuming the same topology, this this time, we add some intent traffic with some asset policy for a low delay pass. So in green, we have the low delay pass, and in red, we have the IGP pass. So still at p three, routing table, we have, next up reachability to both with the, IGP cost. And on the policy table, also, we have also, post next up, reachable via the color with the low delay metrics. If we are looking at the BGP tables and based on RFC forty two seventy one, the IGP cost is reported to BGP. So the comparison was upon on the IGP cost, which will lead to the selection of the pass... The upper pass, which is the... Not the optimal pass for for this specific use case. Now if we're assuming that we report the correct cost to BGP, so if we take the same topology, but this time, the asset policy on the upper pass is down. So we're still looking at p three routing table. We have the next stop reachability, But now the asset policy, so we have the one... The next stop one, which is down. So in the BGP table, we will get the new correctly reported next stop. So the EGP next stop cost and asset policy cost. This will lead to a comparison of cost type completely not comparable because we have a delay cost with an IGP cost. So to tackle this, so we come with a resolution preference. So this is something that an operator could configure on the device. So for this example,, we put a preference of 110 to LDP and a preference of 20 for the asset policies. So based on that preference, we will remove all the candidate pairs, which has a preference value higher than 20. But in this case, it will just remove the past one, and we will keep only past two for the selection. So we have some relation with the BGP best pass selection criteria. So the BGP best pass criteria is really focused on reachability check. It's more MPLS centric, so it doesn't address the... How to determine the internal cost, and it doesn't provide a solution for inconsistent type metric comparison. So we are in touch with the of, this this draft to see how we can, work together. For the past resolution to pull, so as explained for the motivations, the l f c, forty two seventy one couple which resolutions strictly to the BGP next step. So modern network, dissociate the forwarding destination from steering intent and encapsulation across multiple BGP attributes. So the triple here formalize what to resolve by bending the destination target to its context into a single resolution entity. So the resolution key, so that part is mandatory and is the target destination. So it could be, resolved via, existing attributes, so BGP next up attributes or the tunnel egress endpoints, the TLV or a service six seed information. Linked to that, we have the resolution context. That one is optional. So here, it's more to add more context to the resolution of the key. So it could be the caller extended community, the tenor encapsulation attributes, or an SRv6 sub TLP. For the resolution constraints, so we already have a lot of implementation that let us do some local policy to enforce the constraint on the next step resolution. So here, the goal is to formalize this existing practice into the BGP decision process. So the natural constraints could be expressed transport and steering criteria derived from the resolution context. So an example could be transport type, cold bending. The application of this constraint resolutions to resolver evaluates the resolution key against the constraints set by the resolution context. So an underlying resolving entity must satisfy this constraint to be considered as valid. If we don't have any specific context of local constraint policy, we just fall back to the standard behavior of l f c forty two seventy one. So that's it from my side. I think I was a bit too

[01:34:36] **Sue Hares**: I would like I would like to pause here and let people ask questions of Olivier. It's important to meant... To ask it or make comment. Kaliraj mentions except for accepting the new path selection using a new preference. It is documenting existing practice. The new preference is not mandatory since resolution schemes are able to provide the funk... Same functionality without path selection change. Kaliraj, would you make... To make any of that comment?

[01:35:22] **Kaliraj Vairavakkalai Vairavakkalai**: Yeah. I was just replying to John's comment. And, also, I agree that most of the text in this draft, it is like... So resolution constraints. Right? So that is what we tried to do when we did CT that we generalized the problem and extended the way the base forty two seventy one talks about next stop selection and made it, like, look at few buckets, bucket of next stops with tunnels and regular and then colored. So it just generalizes the problem for the intent based solution as well as other constraints of solution. So that is what this draft is doing, which I encourage. And I had discussions with Olivier when he had questions about this draft to be earlier. And that's what I had suggested to him except for the path selection change bit, which makes it standards thing. The remaining things is, like, documenting what is existing, and that's informational. That is good. And because the path selection change itself seems like it's not mandatory, I mean, it's not be forced on any implementation because there are other ways of achieving it. If you think about it, what it is telling, it's telling what the service wants. Whether the service wants a tunnel route or not, that service itself knows. If it's l three v, it needs tunnel routes. So it can look at routes which are only tunneled. And then when we have intent based thing, then also the color community tells what kind of intent this thing wants. And if we are able to classify the reachability information to different buckets, like best of word tunneled certain color tunnels, then we are able to do the path selection resolution without any new preference attribute. That's what I was thinking. I mean, locally configured preference.

[01:37:13] **Olivier Vroonen Vroonen**: Yeah. Yeah. So for so for for us, I think, yeah, BGPCT and and the resolution schema is just an example of how to implement it. We have also the same with BGP car, but it's more a generic framework that we we want to define.

[01:37:31] **Kaliraj Vairavakkalai**: Yeah. I mean, I agree with the whole intent, but the only point that I'm a little bit uncomfortable with is a new path selection thing. And if it is like... If some some implementations are using the new config and some others are not and still able to achieve the same result and whether interoperability of both these flavors, everything works okay, then I think it may be fine, but we need to have more thought about that. So like I said, I mean, even the resolution scheme, it is not specific to intent based thing because even today, even before CT and everything came, all the implementations were doing that. They were looking at only the tunnels... Tunnel routes and doing the constraint resolution. So that just... Those solutions can just formalize the existing thing for intent based things.

[01:38:25] **Jeffrey Haas**: Go ahead and go next. So I think the draft here solves no... Out of our core problems. Three buckets of things that we really need to deal with here. This... But are we going to allow for path selection to include, can I reach the destination is one of my time breaking criteria is for this route to be selected? People are are in favor of that. This can thing that do the hidden property that's not really called out well before 271, but we've engineered boards now for the entire time of... Is that we use the, you know, the next top.

[01:39:06] **Sue Hares**: Jeff, your your your audio is breaking up for John and I. Maybe you want to put this in the chat room so that Yeah.

[01:39:21] **Olivier Vroonen**: I'll put

[01:39:21] **Kaliraj Vairavakkalai**: the text.

[01:39:22] **Sue Hares**: We can have the good point. Okay. I will try to take Jeff's point. Okay. He's gonna stick to text. People look at the chat room while we... We're going to... He cares about three things. And while I do that, Olivier, I'm gonna swap to the next slide just because that will help us stay on target for time. Okay. Oh, I don't need to read. Okay. Fine. Read the chat room. I'm going to stop the slides and pick up the next part of my question with this. Actually, let's go with a... With the indication of Kevin's slides. I think Kevin will give... Gives us a better concept. Go ahead. I'm gonna give you the slide control.

[01:40:35] **Kevin Wang**: Okay. Hi, everyone. My name is Kevin Wang from HPE Juniper. And we have coauthors from Jeffrey Haas. He's my colleague. And we also have from HP three and Jeff from Amedia. So here's the problem statement. We know, like, today's BGP only signal the next hop attribute of a route. But in certain scenarios, such as the core fabric global load balancing or the GLB, we would also like to know the next next hops as well. So as we see in this topology, which is a three claw topology, well, let's consider the traffic from L 1, over those switches towards L 2. You have three parts, a b c, which are the direct next hops. And then here, if you take next hop a, your next next hop would be X 2. If you take take next hop b, next next hop will be Y 2. If you take next hop c, your next echo will be Z 2 to reach L 2. Right? So let's say in case, the link x two fails, always congested from s one to l two, we want to leave l one to be able to offload the traffic from next... Next hop a towards next hop b and c so that you would have less traffic go through link x two to mitigate that congestion. So this is the high level idea. And, what we want here from BGP side is to be able to signal the next next hop in addition to the next hop, from the switch's perspective. Note here, from BGP side, we only, signal this for the next next hop topology discovery. The actual congestion or the failure disc... Discovering is done by another draft. The draft is done from the... I think now there's a new working group at IETf for this. So to signal the next next hop, we do it under the existing NHC attribute. So here's a refresh of the n s... NHC attribute, where it defines our next hop for validation purpose. And then it... And now you to define those next hop related characteristic here. Well, each tier, we would have our code, our and our variable field. So to use the NHCP to signal next next hop node, what we do here is we use the characteristic code of two and the next is variable, and the content would include the, current routers, BGP ID, which we call next hop BGP ID because the current router's address is signaled as next hop. And in addition, it also included the next next hop BGP IDs, which could be one in the three claw case and could also be many, like, in the five claw or seven claw cases. The relationship of this draft towards the one, we just see of the, best path next hop selection. As you can see here, the next next hop node is intended for the global node balancing purpose or the remote protection purpose. So it will not affect the next hop selection. So to this extent, it's less related to the draft that we just see. Rather, the next next hop node information would be used by the fast pass to to the node balancing or to the protection. So this draft was initially, introduced two years back, and I presented it at, in the interim meeting of '20 February 24. And then last year, Jeffrey Haas also presented at IETf-one twenty four. Right now, it has been adopted by the working group, and, I'm reviewing the commands from the BGP directorate reviewer, which is Daniel Bernier. And I'm also adjusting the commands from the routing directory audio review from Luuk Hendriks. So next step is to publish the draft version two with all of those commands. Thank you.

[01:45:32] **Sue Hares**: Thank you, Kevin Wang. This gives an set of information on how to send information that might be put in the context of that resolution context. Let me pick up with the next set of questions on this topic. Just a moment. Okay. I've just gotta get to the right slide. There's best path. Solver. So... Okay. So now I noted here in the presentation where various ones of these drafts impact forty two seventy one bis sequence. I'm asking you just to look at the... Just the selection criterias because you noticed certain places only seem to look, impact nine dot one dot two dot one, which is the path resolution, or, can it be resolved in this nine dot one dot two dot two is the tie breaking. So the ones that I am unclear about are some of the intent tie breaking, so I'll just notice that that is it. But notice we need in this general concept to see if we can handle the selection criteria and the path selection criteria with this new concept.

[01:47:31] **ruiqianhu**: K.

[01:47:32] **Sue Hares**: Now notice the best path has the selection using path contribution, and multi next hop has both path selection, tie breaking, and actions. And, Kaliraj Vairavakkalai, what I'm gonna pick up right now is the... What my observations are on this breaking down of the framework in multi next stop attribute versus path resolution. Kaliraj Vairavakkalai is the expert. I'm just going to give you a brief observation. It's distributing information, on many next stops based on a primary and a path rebare. By the way, this is not unusual. Multicast and TE point to end proposed the distribution of many different types of paths. So that's pretty much a function that we see coming out of. If not the next top drafts, definitely in the multicast and the point to multipoint distribution, and that's part of the BGP we need to do it. There is selection criteria that I found in the text that was explicit in nine dot two dot two, which says, while tie breaking and path selection as described in RFC forty two seventy one, nine dot one dot two dot two consider the highest cost among the next fat legs present in this attribute, meaning the list of multiple next tops. So that's a real clear that there's a constraint and a test that is equivalent to some of the tests that's in the this next top selection. Kaliraj Vairavakkalai and Oliver have begun to discuss, and as you see, we need to work through things. The final thing is the thing I want to bring up to the working group to think about. Many drafts has distribution. Many drafts have selection, and very few drafts have forwarding instructions. I didn't find push, pop, swap, pass, lookup, replicate. There is encapsulation in, r c, ninety twelve. But this last piece, I don't... It it may be the best thing. It may be something coming, but it is different. Okay? Now I wanted to focus on that just briefly to raise the question, not to give an answer. Notice the forwarding actions I've just gone to through. They... And I've added... You know, he's got replicate. Replicate is clearly part of the multicast. The arguments to the action are endpoint identifier, I p v six, MPLS, RD, RT, path constraints or proximity checks, transfer, class ID, load balance, payload encapsulation is part of it. We see that payload encapsulation in the ninety twelve, so that's not unusual. We see endpoint bandwidth attributes coming in out of the communities. This puts it in attribute. The real question I'm raising, not to answer today, but to raising is, do you want actions to be part of this, and how does it fit in? I'm only noting a difference. Okay. Kaliraj Vairavakkalai, did I step on myself too badly? If not, I'm gonna go on and talk about the rest.

[01:51:35] **Kaliraj Vairavakkalai Vairavakkalai**: I think you're good.

[01:51:37] **Sue Hares**: Okay. Thank you, Kaliraj Vairavakkalai. Now I'm gonna talk about SR and SRTE drafts. Okay. In SR and SRTE drafts, what... There... Everything is done by the SRPM. BGP elects a route, sends the distribution, and shoves it over to SRPM to make the decision based on the head end. As Ketan Talaulikar has reminded me as one of those authors, this is appropriate. This is what it should be. The distribution rules for the SR, which is the prefix SID, also is distributing with choices made. I'm not quite sure. I think after rereading the draft and the ediction, it's in the past selection. I could use some help from the authors and the prefix SID authors on that. Now there is also a whole bunch of metrics or path things in the SRTE. BGP SR policy metric provides a metric. BGP SR policy path admin flags provides flags that could influence whether a path is actually valid. Shut down, backup and eligible, ignore, drop, candidate, final node. These are checked right now in the SRPM, but you can see how it has the same characteristics. MTU is something that's looked at as far as the MTU of the virtual path. Okay? All of these right now are in the SRPM along with the policy path segment, which has a segment and a reverse path, or the TE attributes, have new set... Segment types. And policy CP validity, which sets a weight and a minimum... Minimum number of segments to make it valid, and the policy CP, which sets constituents... Valid constituents. Notice there's all of this under the covers in SRTE handled by the SRPM, not looked at in... By the BGP routing. It's all handled by the head end. Now there is a new proposal that was discussed at the time of the discussion on draft-ietf-idr-bgp-bestpath-nh-selection to be adopted as it was. It started to make... Say, no. We're gonna make some rules on the candidate routes. This has not been approved by Spring. This is not... Is just an idea coming out of a certain set of doctors. And what we're doing... Okay. So that's the that's the playfield. Okay? The next question is, as Jeff put in the chat room, is... Should there be a limit on the forms of distribution of information? Do do we have a limit? Right now, we let everybody distribute, and we focus at path resolution. There is path resolution by Olivier Vroonen's concept. There is path resolution as Kaliraj Vairavakkalai put and other put on the chat as a concept that is already in use, derived from some forty two seventy bis, what do we do? And I think, the headache is... John has put it, is the practice is diverged from the actual RFCs, and I'm trying to bring us back in. That's two questions. The third, like John, I want to try to limit it to maybe three questions. The first three, should there be a limit on distribution of information? Is this path resolution a good general concept or good for just this time, which is draft scope? And what do we do about actions? And perhaps I should add the fourth. I've not let... Seen any SRTE want to break open the SRP evaluation except a few authors? Okay. Thank you, Kaliraj Vairavakkalai, for the nit. Okay. That's a discussion. I've allotted... I initially allotted ten minutes to talk about this. We've eaten through a few of those, but I think our remaining presentations may be briefer than originally thought. Is there any more discussion you'd like to have on the list, or is this a good way to tee up interesting discussions for ITF-one hundred ninety... 127? Okay. I'm not seeing... Kaliraj Vairavakkalai, go ahead. I

[01:57:44] **Kaliraj Vairavakkalai Vairavakkalai**: think it's a good way to put everything that's there and give a landscape and compare and go forward. That's right. And just a quick answer to the question you had on whether we should have actions here. So the way I see it is, like, existing BGP Next hop has an action, And we just made sure that the new multi next hop has that action as well as more. So we're just expanding that. So current next hop sales just forward, and we are having more... And which is applicable to just IP forwarding paradigm. We're just making the multi desktop generic so that it has multiple actions possible and for different kind of forwarding patterns. Just want to put it out there.

[01:58:25] **Sue Hares**: Yes. And multicast has different type of actions as part of their work. I didn't include some of the multicast because they have replication, other things, point to multipoint, so we see other actions. I'm gonna stop now because I hear a background chatter. Okay. So I... Is there more comments on these? We have another five minutes or so just to go through some of this.

[01:59:20] **Keyur Patel Patel**: Hey. This is Keyur Patel. Can you hear me?

[01:59:22] **Sue Hares**: Yes. I can hear you.

[01:59:25] **Keyur Patel Patel**: And I think on the part resolution, did we not talk about... There are few more use cases that are remaining that also needs to be looked at, Sue.

[01:59:40] **Sue Hares**: I missed that Keyur part of

[01:59:43] **Keyur Patel**: On the next stop validation part, there are few

[01:59:45] **Sue Hares**: more

[01:59:46] **Keyur Patel**: cases that

[01:59:47] **Sue Hares**: we

[01:59:47] **Keyur Patel**: saved. In your earlier slide deck, I wanted to wait till the very end.

[01:59:53] **Sue Hares**: Yes. There are more cases. I just started.

[02:00:02] **Nat Kao**: Cool. Thanks.

[02:00:04] **Sue Hares**: Thanks. Okay. Anyone else? I I know that was a lot of push toward things. We... I really did have more time here for people to start to think about it. It may be a lot to have dropped on you on a Monday morning. Okay. I am going to stop sharing and go on to the core adoptions that are at the end of the session. And if we'll circle back, if you got in the middle of this and you wanted to say something, please go ahead. Donatas Abraitis, are you ready to be the presenter?

[02:01:06] **Donatas Abraitis**: Yes. Do you hear me?

[02:01:08] **Sue Hares**: Yes. I have passed you control.

[02:01:12] **Donatas Abraitis**: Okay. Let's try. Thank you. So hello. I'm Donatas. This draft is about adding past limit to BGP at... Path capability. I'll just go quickly through, and we will see how the job has evolved across the versions.

[02:01:40] **ruiqianhu**: Okay.

[02:01:43] **Donatas Abraitis Abraitis**: So the goal is simple. Just reduce the number of the paths that BGP speaker receives just to save some resources like secure memory. And today, that path capability... That with the at at path capability, receiver has no way to tell the sender how many it actually wants per prefix. So the send more than the receiver needs or can handle. And most of the implementations already have the configuration knobs to send all the paths or only some arbitrary paths... Best path, but that's purely local configuration on the sender. And while at path capability already lets the receiver signal whether it wants to send or receive path of So this seems natural to to to let the to let the sender signal that. With the zero version, we introduced a new BGP capability called paths limit. We choose a new capability instead of extending an existing ad path capability because capability just can't be extended in a backward compatible way. So this new capability only makes sense together with that. So it must be just ignored if that path is not present. With the first version, I am assigned capability code. At that point, we got the first implementation in FRR. It's available since ten point ten point one. With the fifth revision, we got a second implementation. And the latest revision has a change, which is... Actually, it's already published, but may... Maybe the slides are not updated. So the the idea was the the... There were two jobs, this one and another one that introduced a new subcode for notification when the maximum number of are reached. So with the sixth revision, we merged these two drafts into a single one... Into this one. So this covers the case where a session is because the number of received paths exceeds the limit. And I think keeping the sick... Signaling and error handling in one document is a cleaner way than having two separate drafts. So so the next step would be to see if we have more comments and feedbacks here on on the IDR list. We already got some, but more than welcome.

[02:06:16] **Sue Hares**: We are in adoption for this draft, and we... The chairs suggested initially that a merging of these two drafts would be okay and that we would adopt... We would listen to comments, but if the authors decided a merge draft, we would go ahead and count the adoption interest for both drafts. It is well on its way to getting interest from the working group to work on and refine this draft. So once we get it to a working group draft, we can send and and taking that they have two implementations, we will then ask IANA through the ADs for early allocation on the BGPCs notification subcodes with the name of maximum number of paths. Anything else on Donatas Abraitis's Kaliraj Vairavakkalai... Did you have a comment, Kaliraj Vairavakkalai? You... Go ahead. You're next.

[02:07:33] **Kaliraj Vairavakkalai Vairavakkalai**: Yeah. Just... Let me just voice out my thoughts loud. So, basically, the way I see it is, like, initially, we started with a full mesh, IVGB full mesh, and all the p... The c was they have full visibility. Then we introduce RR for the scaling purposes and... Which means that we are able to re advertise only one part, and that introduces path hiding. So we go to add path. And with add path, we have, like, either all paths or ECMP paths. Still, we give, like, end paths to each of the receiver. So so far, we have, like, these conditions where everybody in the network, all the I b g p p s, they receive either all the end parts or they receive one part. And in the cases where you have one part, there may be part translations because of the part hiding. But now I feel that we are entering a territory by allowing a per receiver control of how much parts they can receive. We are having a whole spectrum in between, one part and end part, where we can have a combination of each receiver wanting a different number of parts. And I wonder if we are entering a territory of new territory of having to juggle with the path handling issues, the oscillation issues, which could come with that spectrum increase. So whether it is a safe thing to do as a overall thing, I think we have been able to think carefully.

[02:09:08] **Sue Hares**: Any comments any response to that, Donatas Abraitis?

[02:09:17] **Donatas Abraitis Abraitis**: I see Robert's already discussing with Serge Krier.

[02:09:23] **Kaliraj Vairavakkalai Vairavakkalai**: To Robert's point, I think even with best external, we would advertise only one path. It's only which one path we do. So it's either one or n. Now it is a whole spectrum.

[02:09:42] **Sue Hares**: Keyur Patel, you have a comment here?

[02:09:45] **Keyur Patel**: Yeah. I just posted it on the chat, but one of the things, Donatas Abraitis, you gotta watch out for is inside an I b g p networks, typically, grouping of the peers has been done irrespective of what model deployment has been that Kaliraj Vairavakkalai has described, whether it's full mesh or a route reflector, you sort of club the peers under single update groups or peer groups or you name it. And that grouping can get severely violated if each peer comes around and says, want x number of paths, which are different. So something to watch out for.

[02:10:32] **Sue Hares**: These are a good comment. And, Donatas Abraitis, before we go to allocation, you should plan on answering at least your viewpoint on all of the... You know, give us back a response on the male group on performance, based on Serge Krier's comments, based on Kaliraj Vairavakkalai's comments. And, Robert has also given you r c six 6774. Please try to do that in the next week just to try to give your opinion of it, and we'll go from there. Any other comments? No, Donatas Abraitis, go ahead and answer if you want.

[02:11:20] **Donatas Abraitis Abraitis**: No. I just wanted to thank you.

[02:11:23] **Sue Hares**: Thank you for all the comments. We're gonna go to another core adoption. I'm gonna take back the slides and swap them over to the next presenter. Just a minute while I grab the slides. And Antonis Chariton is going to present. Hi. Welcome to your... Is this your first presentation? Yes. I'm gonna give you the slides, and we'll hope that it works. Perfect. I noticed she's at the ripe meeting, I think, in a little corner, so it may get noisy.

[02:12:14] **Antonis Chariton**: Yes. I hope you can hear me okay. So greetings from Sofia. I want to talk about this new draft that we have submitted. We plan to update RFC nine two three four about roles and the only two customer attributes specifically. And here is the current state of the art for route validation according to section five of that RFC. Basically, here's a network. It can have providers, customers, peers, and it can be connected to Internet exchanges through route servers. So we aim to create route slicks with this RFC. For the provider link, there is not much there in terms of OTC. For customers, the current RFC protects against route leaks, so everything is fine. For peers, it is also, providing instructions for BGP implementations on how to defend against route leaks coming from there. The problem is that it does not cover anything that comes from a route server, so when you are a route server client. And, we think that this is a potential missed opportunity. Basically, if the route server implements the standard, then you are protected. You kind of, you know, like, outsource all of your protection to it. So if, for example, something breaks, it could be an issue. And if this route server does not implement the RFC, then you're still vulnerable to route leaks. And this can cause problems as most IXPs right now do not have RFC nine two three four rolled out. What we want with this draft is to make this part also secure, and the way we want to achieve it is by following the same logic, the same code for route servers as we follow as peers. Basically, we can assume that they are at the apex of the value free principle. And the the algorithm, let's say, that we're doing is that if you receive a route from a route server that has the OTC attribute and the AS inside is not the route server, you can discard it. And this is similar to what you do for peers, basically. And, this is the presentation. It's in adoption call for a few days now on the mailing list, so I'm happy to answer any questions. And... Yeah.

[02:15:19] **Sue Hares**: Thank you very much. Is there... Are there any questions for Antonis Chariton? Okay. Well, there has been support for this on the mail list as a good catch for the original RFC. I think we will call it a good presentation. Thank you very much for your first presentation. You did very well. I'm going to grab back the slides, and we are down to the end of the session, for today. It's been a busy session. Is there any of the adoption drafts that you would like to see again? I'd like to ask that before we close because we're in adoption calls. We're trying to finish these adoption calls. If you dislike something, if you have a problem, please, like Robert has done or other people, they've been very specific on their comments, which helps the authors. So anything else? Any more comments on the path resolution? I marched us through this fairly quickly so that the last authors would at least have something that they could chat about, in their time, but it seems like I've brought this here with a few minutes to spare. Okay. So, the question is we've teed up a lot of things for adoptions. The flow spec v two work, we intend to adopt more and spend more time refining because we need to get the base spec and everything with enough draft tests so your chairs are intending to drop more there. With the core adoptions and the next draft adoptions, we're going to be a little bit more careful and refined. Please let us know what you'd like to discuss. I see a lot of talk on the list on Antonis Chariton' draft. Would any of you like to add that in in the sound, or shall we call it a wrap for today? Okay. Jeffrey Haas, any further comments?

[02:18:28] **Zhenqiang Li**: Assuming my microphone is working, no further comments.

[02:18:32] **Sue Hares**: Okay. Just in time. Keyur Patel, any comments?

[02:18:37] **Keyur Patel**: All good. Thank you.

[02:18:39] **Sue Hares**: Okay. Jie Dong, any comments?

[02:18:45] **Kaliraj Vairavakkalai**: I'm good. Thank you.

[02:18:47] **Sue Hares**: He's also up late. Okay, folks. That's it for today. We'll try to get minutes out. Thank you very much. Bye bye.