Session Date/Time: 24 Jul 2026 09:30
[00:00:05] Jia He: Give me confirmation if needed. If he want to confirm, maybe he also come to the mic. I think get started. Okay. It's 11:30. Let's get started. So welcome to the LSVR working group session in Vienna. Please know that the session is being recorded. Okay. Here is a note well. I think we're on Friday, so people should have been very familiar with the text. But we still encourage people who participate in IETF to know that all their their the guidelines for the behavior and also the about IPRs. For more details, please read the documents listed here. Here are the meeting tips for both the in person participants and also remote participants. For remote participants, please use a headset and turn it on. Keep your audio and video off unless you need to present. And here are the resources for this meeting. Here is the agenda for this session. We have four presentations after the working group updates. So we have a kind of compact agenda. Okay. Working group personal update. Acee Lindem has stepped down from the working group co chair position, and we would like to thanks to AC for all his contributions to this working group. Thank you, AC. You want to say something? You yeah. Please continue to participate in this working group because your expertise would be very important to us. And, we also would like to welcome Krishna to join us as a new working group co chair.
[00:02:24] Yisong Liu: Yeah.
[00:02:30] Krishna Kalyaniraju: Thank you all. Thanks, Jia and Acee, for considering me and Ketan and Keyur for supporting it. Yeah. You know, I'm an active participant in the BGP, BEST, and CIDR ops working group and also, you know, monitoring the the LSVR working group. So, yeah, I'm excited to be part of the group. And, you know, there's a lot more exciting stuff we have to do in the AADC front and, yeah, we'll see how it goes. Okay. So, yeah, in April, right, we did a a poll on the neighbor discovery, and this is the link to the email that has been sent to the working group. The results of the poll are also been the link is provided here. You know, we haven't received any interest from the working group and no there were no responses. So if anyone wants to say anything in this, yeah, this is the time. Okay. Yeah. AC?
[00:03:44] Acee Lindem: Acee Lindem, Arrcus. Yes. Because we have sort of backed off on that discovery protocol, and Keyur and myself and Xiaohu's been he's been reminding me that we have this draft. We may be pushing forward with this very old draft. It's the LLDP discovery
[00:04:12] Jia He: Mhmm.
[00:04:12] Acee Lindem: For for BGP neighbors, and it it doesn't have everything that l three d l had in it. But, actually, people have implemented subsets of this already. I know at least Nokia has something where they're using LLDP already to use it, so we might be pushing that forward. I'll send an email.
[00:04:38] Krishna Kalyaniraju: Yeah. Is that part of the IDR working group?
[00:04:42] Yisong Liu: I think that gave up discovery to us. Right?
[00:04:44] Krishna Kalyaniraju: Oh, this is. Okay.
[00:04:49] Keyur Patel: Keyur? Keyur Patel, Arrcus again. I think this work is important. I think we want to revisit this. It's quite unfortunate. Some of us didn't get to get a chance to voice during the, poll, time. But I think, we want to do something with a very scoped effort inside data centers and rather than widening the scope across for the general BGP applicability. So if we can take that into consideration, that would be phenomenal. Yeah.
[00:05:27] Acee Lindem: Yeah.
[00:05:33] János Farkas: I would like to repeat what we had in a meeting where we at least we are working group and eight zero two dot one members who are joining that eight zero two dot one wants to address the needs of the industry. So if anything needs to be done with LLDPV, are welcome contributions and so on. Like, we have developed LLDPV to, based on LSVR's needs at the time. Thank you. Yep. Thanks.
[00:06:08] Krishna Kalyaniraju: Yeah. Then we'll look at the working group adopted documents. So the BGP-LS YANG, so there is an update, and it's there on today's agenda. Yep. The LSVR, the L3DL, which is, you know, expired, and we are going to mark that as a working group data document. Right? Yeah. These are the individual drafts, and three of them are on the on the agenda. So, you know, we request members to, keep making progress on your individual drafts. Okay. Yeah. So the l three deal. Right? The I the I triple e last one. Right? So we will work with the rest, you know, on the next steps. Yeah. So there were the two errata, 28835 and 8836. The AD has, you know, approved the errata. So this has been verified. Right? Yeah.
[00:07:38] Jia He: Okay. In addition to the current working group documents, I think we have also have several active individual drafts. So we think we also need to consider the next steps for this working group. Currently, there are maybe two part of work can be considered. The first is we continue to move forward the work, which is in the scope of the current working group charter, including enhancements and extensions to the BGP SPF based specification. And, also, he we also see some other related use cases, which may be benefit using BGP SPF as a protocol. So we can consider to have presentations and the drafts discussed in this working group and maybe also extend the applicability of the BGP SPF to other scenarios beyond the data center. It's also something we can consider. If, in the end of the meeting, we have, extra time, maybe we can also have some open discussion about the next steps.
[00:09:01] János Farkas: Oh. János Farkas. If I may say just one word on the liaison. I checked the draft posted on the list Yeah. And it has a tone of the discovery work has been stopped. But this is not what I hear in the room. So if if the liaison response should be refined, then it would be nice. Thank you.
[00:09:25] Acee Lindem: Acee Lindem, Arrcus. As far as that, I'd like to point out that, well, the l two LDP v two is really helps with it. The actual discovery work was started way, way before with LDP, the draft from Ericsson. And, additionally, the draft from Ericsson was just a copy of l three d l TLDs. So I don't know what you're talking about.
[00:10:04] Jia He: Yeah. For this, neighbor discovery topic, I think the working group poll result has been sent to the mailing list. If we want to continue the discussion on that, we can we encourage you to you can bring to the list. And, also, currently, the IDR LLDP discovery draft is in IDR working group. Right? So maybe we need to also check with IDR whether which working group this draft will move to and how we will proceed.
[00:10:37] Ketan Talaulikar: Ketan? Yeah. I think if I understand János's point was that there was some discussion right now about, you know, looking at taking up the work as based on LLDP. And he was quest asking whether the liaison should be refined. I think that the response to the liaison is overdue for over a year. So my recommendation would be that that be sent because that captures what the result of the polls that the chairs did. And, you know, just go about the regular business. If there is interest in adopting the new proposal or, like, the old proposal, but adopting it, we can always send another liaison. János, would that be that be
[00:11:30] Jia He: okay? Thank you. Yeah. Thank you, Ketan. Now let's move on to the the first presentation, which is about the BGP-LS YANG. Let me share the slides. And
[00:11:50] Aravind Prasad: ID, do we have the control of the slides?
[00:11:53] Jia He: Let me hand you the control. Let me see where is you should have control now.
[00:12:09] Aravind Prasad: Yeah. Fine. Okay. Hello, all. I'm Aravind from Cisco Systems. Today, I'll be presenting the updates of BGP-LS Yang draft model on behalf of my coauthors, Ashish and Keyur. Yeah. To start with the agenda, I'll begin with a quick summary of the changes since last revision. We have a public GitHub repo which tracks both the model and the draft changes. So all the contents of the agenda are corresponding to some pull requests which brought the changes. So p r 17 actually brought in support for link prefix and SRv6 NLRIs that will be covered in slide two, three, and four. P r 19 covered three correctness issues. So and p r 21 added some improvements to the draft text, and p r 22 introduced validated Yang instance examples. And finally, I close with open issues and the path forward. With respect to the version four, this is a substantial revision which added approximately four k lines to the model. We have added 54 new TLV identities. We corrected few bug fixes as well as we added four validated examples. On the model side, the previous version actually covered the node NLRI, its attributes, along with some opaque fallback for the unknown NLRAs and attributes. The recent version actually focused on completing the model, which brought in support for link prefixes, SRv6, NLRIs, and their related attributes. On the document side, we we almost updated the introduction, expanded the terminologies, updated security considerations, as well as started some necessary normative references. Okay. Yeah. So the yang changes which got in via the pull request, it mainly contains or it has distributed into three main areas. We introduced a new sub module for OSPF. We also expanded the topology types of module. We also added additions to the topology attributes as well as to the LSDB sub modules. The new OSPF submodule removes duplication in the OSPF descriptor definitions. It introduces shared node link and prefix groupings that can be used for both OSPF v two as well as v three. Each grouping carries a scope indicator as well as the area ID. It also supports the o s p f route types, and these common groupings are applied consistently across the o s p f n l r a types overall in the LSDB. Yeah. And with respect to the topology types, as I told before, like, we have added 54 TLV identities. The slide shows only a subset of it. Mainly the examples are link MST, remote router IDs, such as in this it's EP, EPS it's prefix it's EAGs, as well as service related identities. There were some corrections which were needed in the existing model. So there were duplication of seat types so that we corrected, and we added additional protocol enums as well as we removed a duplicate definition, which was there for SRGBISS flags. So those were corrected. And this is where we expanded the LSDB, whichever new identities which we defined, that becomes a usable model with this expansion. So in the topology attributes model, we added groupings for IGP link prefix attributes as well as SRv6 variance and and fallback for unknown attributes. In this LSDB module, we added protocol specific list for links, prefixes, and SRv6, which is across different protocols like OSDF v two, v three, ISIS, and BGP EP. And the list key follows identifiers used by each of these protocols. For example, for ISIS, we use system ID of PSN. For OSPF, we use the area and route IDs and so on for the other protocols. The attribute list are also type dispatched and guarded, ensuring that the selected identity matches the actual attribute types. Yeah. And this this slide was related to the correctness bug fixes which came in via full request 19. Firstly, they include affinity container which was using a wrong expression, main expression, so that was corrected. Also, the node name, which was allowing up to six five five three five characters, whereas the RFC nine five five two suggest to restrict it at two fifty five, so that was corrected. Also, the description of AS code was actually stating the opposite of intended meaning, so that was also corrected. We also focused on the the draft testing improvements. So the introduction now clearly explains the super scope of the document as well as the structure of the modules added. The terminology section has been updated. We also added introductory text text to help readers interpret the tree diagram. All five module sections now contain complete explanatory pros, including descriptions of the protocol specific NLRI keys. The security section is also updated. We also updated the normative wire of the references. And we also added validated instance examples. The examples cover OSV of v two node link and IPV for prefix information, the first the first example. And the second example covers v three with SRV 16 attributes. The third one with ISIS and attributes covering segment routing capabilities and adjacent CC labels. And the fourth example covers BGP-EPE with the peer adjacent CC. So these are not simply minimal XML skeletons, but they exercise important keys and attributes giving implementers and reviewers realistic data that they can compare against the schema. Yeah. And finally, the open issues, there is one issue which is still open with respect to our GitHub, which is specific to the RIP support. Our proposal is to keep the RIP support outside the scope of this document, and with that, the draft is currently ready, and we request working group last call. We are looking for inputs on this particular issue as well as feedback from the working group in general. Yeah. Questions, please.
[00:20:05] Jia He: Yeah. Thank you. I think there's a lot of work in this update. Any comments or questions? Kaden?
[00:20:26] Ketan Talaulikar: Since this work is related to BGPLS, which happens in IDR, I would suggest that these kind of updates, incremental updates be cross posted to IDR as well.
[00:20:40] Jia He: Yeah. Sure.
[00:20:41] Aravind Prasad: Sure, Ketan. Yeah. Thanks.
[00:20:47] Jia He: And you have a question to the working group about the resolution of the issue number nine? Yeah. So what is the author's preference, or is there any consideration?
[00:21:02] Aravind Prasad: We we prefer it's out of scope of this document, but we look for look forward for the inputs from the working room.
[00:21:16] Jia He: Okay. I think we can maybe have some further discussion on the list and select the feedbacks. If it is out of scope, I think it would be more straightforward for this document to move forward.
[00:21:29] Aravind Prasad: Yeah. Sure, g. Thank you.
[00:21:32] Jia He: Okay. If there's no other comments, we can move to the next one. We check. I'll clear this. Wait a moment. Okay.
[00:22:02] Lei Zhang: Good morning, everyone. This is Lei Zhang from Huawei. I will introduce the draft applying BGP-LS SRv6 extensions to BGP-LS-SPF on behalf of my. And in this version, we have two new from China satellite network and China mobile. They provide a valuable commerce to this draft. And so this is the overview of this draft. We just applied SRv6 extensions for BGP-LS to BGP-LS-SPF, including the SRv6 Node Attribute, attributes, prefix attribute TREs, and a new state RI and say the attributes TREs. And we also provide the and upon behaviors that can be used for BGP-LS-SPF. And so the updates since version zero four, the way addresses it way addresses the the comments from Java and Xiao Zhuang from in The Middle East. And we also do some updates to improve the readability. So the first change the first change is the comment from which is which is the requirements for cody coordination between MSD and link. We add a sentence in section four dot three to elaborate that link. I'm a to limits should also be considered during the SRT parts computation. And the second update is we we receive our comments from for the processing for multiple locators. This is the scenario survey you have you want to configure multiple locators for one node. So he is not clear for the proceed procedures in this situation. So we modified our sentence to elaborate that if more than one locators is a provision for all nodes, the each of them should be otherwise as individual prefix and also s r six locator TRE. And, well, he has another comment, which is about whether the metric in the prefix metric TRE will be used for final route computation. We also update the sentence to say this is used for the final route computation. So for the next steps, I we also work on for comments and suggestions, and we all think this this draft is stable and mature enough for working group adoption. Okay. That's all. Thank you.
[00:25:44] Jia He: Thank you. AC?
[00:25:54] Acee Lindem: AC, Linda, Marcus. I noticed you defined a new type of BGP-LS NRI. Is that out of the document the the the Ketan's document? The document? Is that did it come from that? I didn't I didn't read the other document, but I know she got the SID inform you got a new
[00:26:16] Lei Zhang: SID information. SID is not a new defined. It is just a form of the. Right?
[00:26:24] Acee Lindem: It it wasn't that one. That's where that's where you because I because you could've taken the choice of made that a TLV on the link NRLI as well. But the choice was already made in the other document to have a separate type of NRLI. How do you identify the for the adjacencies, how do you identify which one it's associated with? It doesn't look like it's look like it's just a SID. Like, a neighbor, how would you associate that with a neighbor? It's not on it doesn't say how you do that. Or an interface. How do you because if it's separate NRLI, how do you bind that to a neighbor? Is it it says it it's used for advertising SIDS for interfaces and neighbors yet And right now, we only support point to point. You know you know, the the BGPLS topology is solely point to point.
[00:27:31] Lei Zhang: Yeah. Yes.
[00:27:32] Acee Lindem: So you really don't need it. You really don't need it for neighbors. How do you as how do you bind it? It because it does say in the draft, it goes to interfaces or neighbors.
[00:27:45] Lei Zhang: Yes. Yes. I I haven't
[00:27:48] Acee Lindem: Do you
[00:27:49] Lei Zhang: understand that, Maybe answer to this question. Yeah. Maybe we I I can consider that.
[00:27:55] Acee Lindem: Okay. I'll wait. I'll let you go.
[00:27:56] Jia He: Maybe Ketan can help to answer that.
[00:27:59] Ketan Talaulikar: Yeah. Ketan Talalikar as a working group participant. So AC, the NLRI is meant for SIDS associated with a node. The link s r v six link attribute TLVs is the one that does the SID for the adjacent to SID for the neighbor, and that goes as a link attribute. Yeah. The the one on the second bullet is the link attribute, and it's associated with the neighbor.
[00:28:29] Acee Lindem: So Yeah. Yeah. But but it doesn't say that you can have the SID attribute TLVs associated
[00:28:36] Aravind Prasad: with the link.
[00:28:38] Ketan Talaulikar: Yeah. It's there if you see I mean
[00:28:41] Acee Lindem: It's in the other document?
[00:28:42] Ketan Talaulikar: It yeah. It's it's in
[00:28:43] Jia He: the Yeah. It's in the p g p r s s r v six Obviously
[00:28:49] Ketan Talaulikar: So so the ones be included here. Yeah. So the ones associated with the link goes with the link and l r I and it's in there. That that said, what is called end dot exit. And the one with this with the node, and that could be, you know, just like a prefix or anything goes as separate. So, yeah, it's a bit
[00:29:14] Acee Lindem: Yeah. I I see you added and this is good. I see you added more about programming for the locators, but I think you should have that for the other TLVs as well. Which ones are used by the protocol and which ones are just for provisioning SR because this is a protocol specification
[00:29:34] János Farkas: Alright.
[00:29:34] Acee Lindem: Whereas the one you're referencing is just b d I mean or else even if you don't describe it completely, it shouldn't be an indirect reference. You should also have how it's used a reference for how it's used by the SRV six data plane. That would be good if you just put that and put the reference to where how this is used. Like, instance, the local, you know, the local block you're advertising have a reference to how that's used similar to is it's in ISI as an OSPF. As opposed to just the reference to the BGPLS encoding of it in the other document. Anyway, that's my comment.
[00:30:18] Lei Zhang: Okay. Thank thank you for comments. And we we can start that in the next version. Thank you.
[00:30:32] Jia He: Any comments? Any further comments? Yeah. I think this document has been presented several times. Once it addressed ACS comments, maybe we can consider the next step. Yeah. Okay. Thank you. Right.
[00:31:22] Yisong Liu: Morning, everyone. I'm going to present our draft about use cases and the requirements for applying BGP-SPF to multiple domain and hybrid overlay underneath networks. This is a work joint work from Tsinghua University and. Here is the agenda. We will count three scenarios that extend the PGP SPF. Scenario a is a single domain domain. Scenario b is about interconnecting multiple domain domains. Scenario c is about using BGP s l SPF in hybrid overlay and underlay networks. After the three scenarios, we will talk about some gaps versus the base PGP SPF, and we will ask the working group for some feedbacks, and we will talk about the next steps. So for the app that what we need is The base the base BGP SPF has already is app these applications to data center fabrics, but there are real networks that be that are beyond those data centers. For example, global cloud networks about real time communications, cloud cloud gaming, and so on. So these networks are built from are built from multi domain networks and and maybe built from together with some other. So they are the these are the environments we are focusing about. So the base PGT SPTF assumes a single domain, underneath domain with the full trust and a full with the with ability. But in the scenarios we are discussing, networks are not only a single domain, and they are not purely underlay. Operators can make a can make a heavy use of over the links, and the base specifications does not cover the multi domain extensions and the or the only extensions. That's the gap we are addressing. We also want to emphasize that the routing system we are optimizing is about the path for ingress and egress. But in the real applications, users may need to select endpoint and make a endpoint attachment to decide where is the ingress. And this is of the application layer, and it's out of our scope. So this is a scenario eight is a synchronous extension, a single overlay domain. Here, nodes are connected with with overlay means. PDT SCF already fits the domain shape because it's a single domain, but the links are over there. So the challenge is that the state is not directly observable. And we should the network should directly actively measure the performance metrics such as latency, and dose, and bandwidth on this all the links, other what has these measurements, and then compute a path based on application needs. This is some new requirements. For example, measure only links to neighbors to establish a connection and a computer pass over the multiple metrics. Scenario b addresses some interconnecting some scenarios such as in in the connecting multiple domains. The motivation is that one flat as SPF domain does not scale. The link state database might become very large, and we only have one fourth domain. So networks interconnected interconnect multiple domains to partition one operator's network for scalability and for the isolation of peer across operators when the the trust is limited, and we want to hide some internal details. Here's a simple example. Better test runs notes from multiple calls. For example, Azure and a u AWS. If it was a link, we've seen in Azure, for example, from, send to US, fails, the traffic can borrow the send to US link from within AWS as a backup. The pace goes China CN from across to AWS, traverses AWS cross ocean link and then crosses back to Eastern US and forms a path across multiple overlay domain. These scenarios is some requirements. For example, we we should have some internal top topology, scope of lobby, domain dominance metrics across domains, prevent inter domain loops and the computer hierarchical. Scenario c is a hybrid overlay underneath. Underneath networks may need to interconnect throughout overlay because the native underneath paths between them can be far far optimal. We demonstrated that the two networks can be geographically close, but far in the underneath. For example, the Sunnet, the research and education net in China to and as a career in Korea. The native on the native path between them might detour from US or Europe. But because the inter domain routine follows business relationships, not only from the geographical areas, remains them from through a overshot node. ONA ONA node can actually beat the native ONA path. This scenario requires, for example, mix the ONA links with ONA links in your topology. Compute a single path that that can cross the both layers and keep the and install that the path into the data center. And then finally, we we we can keep some we can keep some selection policy aware so that operators can enforce constraints such as avoid this ES or prefer some own segments. So here's the summary of what the base SPF does not cover and what are these scenarios it. For example, PGT SPF assumes that we only have a single SPF domain. But in in the in in the news scenarios, we need to extend the BGP-SPF to support multi domain scopes. We should accept the links to the inputs from all the measurements, not only from some directly observed and configured metrics. We should also consider pace communication methods supporting multiple metrics and some necessary classes. We also needed to extra install the install the computer pace, like, through some something some something like SRV six to support a unified forwarding across both underneath and the over the links. So for the next step, we would ask ask for for the working group's feedback on the scenarios and the requirements. So this is my my my first time. So we would ask ask your feedback. Are they realistic and commit and commit? Is anything missing or overreaching? Second is use cases and the request document as this is in in the scope for LSVR alongside of future protocol mechanism draft. And we also, welcome interest in collaboration and the future adopt adoption discussion. So comments and the question are welcome.
[00:40:17] Jia He: Yeah. Please.
[00:40:19] Acee Lindem: AC, Linda Marcus. Yeah. I think I think this is good. You know, in the applicability document, we alluded to use the underlay and the overlay, but didn't think about any coordination of of this. This would be you definitely need some new protocol mechanisms because the overlay path is going to unless you're going to do traffic engineering with the information, the overlay path would potentially cover many links in the underlay. Yeah. You're measuring. So how to do that is an interesting interesting problem. I think you can come up I I I don't wanna try and do it off the top of my head, but it's it's it's interesting to try and use the overlay mechan measurements to influence the underlay.
[00:41:15] Yisong Liu: Yeah. Thanks for your comments. That's a great idea. We are also considering some measurement methods. We are developing some methods to actually measure the as as and then and performance metrics between.
[00:41:36] Acee Lindem: One thing we left out, we have no external prefixes. So maybe that would be a mechanism to have an external prefix that you inject in there, and you could control the metric on that. I just I know I know we talked about the external. We said, okay. We're not gonna put it in the first version. But it's something that if this is used, it's gonna be it's gonna be needed anyway.
[00:42:05] Yisong Liu: Yeah. Thank you for your comment. We are considered to to refine our our our our draft. Yeah.
[00:42:16] Acee Lindem: And this is what and said, we also left out the summarization. That might not be exactly your use case, but that is another thing that could potentially be added if you're doing a deployment.
[00:42:29] Yisong Liu: Yeah. Thank you. We can discuss later in many needs. We are put post a mail in the list, and we can continue our discussion.
[00:42:41] Jia He: Yeah. As a working group member, I also have a a quick question. So you are talking about several use cases. Some requires an early and overlay integration into one, maybe topology. Yeah. And some others require maybe multi domain support for BGPRS. So which one do you think will be is higher priority for this protocol to if we want to do some extension to it?
[00:43:13] Yisong Liu: So Yeah. You mean the difficulty?
[00:43:16] Jia He: Priority. You I mean Priority. Yeah. Which one you think is maybe higher priority or it's maybe the first step you want to extend the protocol?
[00:43:26] Yisong Liu: Or Yeah. I think we can do I think we can do for for loading the order of capacity. Yeah. We can firstly do the research on scenario a because maybe may only may only need some measurements measurements for to to to better as a better input of the link state link state database because nowadays, the BG SPF allow accept the state you can in the inputs with preconfigured metrics. Yeah. I think we we can we can implant the the the the protocol for the order of complexity. Yeah. First, we can we we can work in we can work on the scenario a and then b and then and finally, we will reach reach to reach a c.
[00:44:30] Jia He: Yeah. I think the for the measurement, maybe that would rely on some working other working groups. But we think maybe for the in your case, you would rely on that mechanism to measure or detect the the overlay links performance or cost or other characteristics. Yeah. I'm seeing like that. Yeah. And, also, we need to think about whether for that case, p two p r s itself need to be extended. What will be the next thing we need to do to support these cases?
[00:45:04] Yisong Liu: Yeah. Yeah. Yeah. We are also seeking for by coming from other working group to as an active measurement method for our protocol.
[00:45:15] Acee Lindem: Yeah.
[00:45:16] Yisong Liu: Thank you.
[00:45:17] Jia He: Okay. Thank you.
[00:45:18] Keyur Patel: Thank you.
[00:45:21] Jia He: Okay. I need to do it for myself. That's okay. The the clicker.
[00:45:33] Krishna Kalyaniraju: Okay.
[00:45:41] Jia He: Okay. This is a update about the draft on the BGP SPF NRI selection rules. I think there are some recent update. And now, also, we want to discuss one scenario which may we see the current rules may delay the convergence or introduce additional advertisements. So maybe we can take a look at the case and see how we can make optimization to that. So this is a quick recap. We know that BGPRS SPF is leverage the mechanism in both BGP based protocol and also the BGPRS. While the NRI selection rules for this, trust family has been specified in the RFC ninety eight fifteen in the section 6.1. But we found that in some scenarios, the current, NRI selection rules in the RFC may not be efficient enough in terms of, there may be redundant route advertisement, which are not necessary from the SPF computation's perspective. Actually, you advertise the same information multiple times. And in some cases, this may also cause delay in the rules convergence, which may not be what we want. So we have several problem scenarios discussed since this draft and also propose some updates to the selection rules in the RFC. Currently, have, three scenarios in this slides, but only two of them are in the draft. For the third scenario, we can see whether we can have some discussion in the session first, and then we can update the draft accordingly. Okay. The first scenario is, showing this, diagram of topology. Basically, there's a new session established, and r one will advertise this link in our eye to its peers. And then r two will firstly receive this advertisement from r one and advertise it further to its peers like r four and r five. But r three will also receive this advertisement and advertise it further to r four. Then r four will pick the and now I received from r three because it has a larger BGP ID in its peer. So r four will advertise this route further to r two. As well, we also pick this route from r four because of the larger BGP ID and advertise this copy of this route further to the peers r five, which shows that the routes advertised in the second time, actually, is a redundant advertisement. It has exactly the same information considering the SPF computations need, and the sequence number is also the same. Okay. Here's the second scenario. You see, in some topologies, you may have multiple parallel links between two BGP neighbors. And as shown in this picture, r one and r two have two, parallel links and parallel BGP sessions. And in this case, no matter in which order r one ad advertiser the browse to r two, there may be duplicated advertisement of the same, NRI to the peer r four. So this is slightly different from the previous one as the route is exactly the same because they are from the received from the same BGP peer, but with on from different sessions. Now it's the the third problem stereo, which is about the cold restart on this RX. Like, in before the restart, initially, all the nodes would have RX and NRI with sequence number 100. Then RX restart, and the the as sequence number is goes back to one. So Rx will send a new NRI with sequence number one to its direct peer r one. And according to the current rule in the RFC, rule number one, r one as a direct peer of this Rx, it will prefer the route received from this peer so that it will advertise an ROI with sequence number one further to its peers. However, at r two and r three, if they already have another copy of their still NRI with sequence number 100, they will not select this new NRI with sequence number one. So, like, in this figure, I think for r three, because, the preferred NRI was received from r one previously, it will, replace the previous NRI, and they will send it further to its peers. But on r two, the previous NRI would prefer the NRI. It's not from r one, but from r four. So r two will still prefer to stay with NRI with 100 as a good number. It may also send this after NRI for back to the r one because this is a it's a current preferred NRI. Then r four will send this updated NRI with sequence number one to r two, which makes r two only have this latest version of the. And r two will send this to r one because of this maybe router ID or other selection rules. Then, also, it will send it further to the downstream peers like the r five. Same thing we will have on r five that it will firstly send the the still NRI to the peers, and we will not send data further to its downstream peers because it's not still still not converged to this the latest version of the sequence number one. And only when the all the peers of r five send data to updated And now I will seek sequence number one. R five will select this one and maybe send it further or send it back to the other peers. So we can see that in this case, two and r five will not select this latest NRI. At the first time they they receive it, and it will take some time for them to send it after advertise the latest NRI further to its peers, and they may also introduce, additional stay on our eye advertisement in network. So that is the the scenario and the problem we found in this with the rule number one. So here are the considerations, whether we need to make some changes to this, NRI selection rules for BGP RSSPF. Because for the this NRI or for the routes with the same sequence number, the information used for the SPF computation will be the same. You don't need to redundant advertisement to to speed up the convergence in SPF. And for the persistent, perspective of the as consistent SPF computation, additional route selection and advertisement due to the comparison of other attributes in the routes may be not necessary. Right? And for the parallel link case, if we have the parallel links with the same peer, some additional rules may be needed to in re provide a deterministic selection result if you want to make it sure that the the result will always be the same. So that is we propose to update the selection rules. There are two update rules in the draft. The first is we add a rule after the comparison of the sequence number. If we receive the the rows with the same sequence number, which is as the the current selected one, we will not do any change. It will still keep keep with the current and will not introduce additional advertisement. And, another rule is also added after the current rule on the comparison of the BGP ID, which is, to align with RFC forty two seventy one. If we have multiple peers with one BGP speaker, we will prefer the one with the smallest peer address. That is something to make sure you can, converge to the same result in some cases. And about, scenario three, the cold restart, let's say that the rule number one may cause additional advertisement and may delay the convergence. And, actually, if we only based on the rule number two and three, we can still ensure that the route converge to the latest NRI, including the cold restart case. As long as we can make the stay on our IP sent back to the originator to trigger the new update with a larger sequence number. So we would like to discuss whether we may consider to remove the rule number one or make it optional. Yeah. Questions? Yeah. We would like to collect comments.
[00:55:32] Acee Lindem: AC Linda Marcus. Like we talked about over the course of the week, I think the changing the last rule and adding that rule to always send back NRLI with a higher sequence number is a good I is a good ID. I don't think we can use the sequence number alone. I think we might have to also do something with the actually, you'll replay what what if the attributes are different? You know, you're gonna have to handle that case.
[00:56:15] Jia He: Yeah. The other attributes, I think
[00:56:18] Acee Lindem: Yeah. I mean, if the you know you know, somehow somehow if, you you know, you can have the same sequence, you can have a cold restart. But for the cold restart case, I I think we should just have you know, add that rule that we talked about you have on that, the if the stale, we should add that like we talked about. And I think for the redundant advertisements, I'm wondering if you have the redundant advertisements, how are you going to do the eCMP over those parallel links? If you if you just suppress the advertisement, how would you do eCMP?
[00:56:54] Jia He: ECMP, it will be based on the SPF computation result. It's not based on the route either.
[00:57:01] Acee Lindem: Okay. Okay. Okay. Yeah. Yeah. Okay. Okay. Yeah. Because you're going to the node, not the right. Okay. Yeah. Like, you're talking like a prefix Yeah. And or a lot. Yep. That would work. Yeah.
[00:57:14] Keyur Patel: I actually, one question I have for you is, isn't this an implementation specific modification, particularly when you are looking at optimizing the cold start?
[00:57:29] Acee Lindem: Well, what I what what I what we talked about I mean, you probably haven't read them. There's probably there's 20 emails on this that just between the offers of this and you. We're going to simplify it, take out that rule to try and do it in one pass and do it more like the IGPs where the stale the the new one gets doesn't get it until the stale one sent back to the originator. And that
[00:58:01] Keyur Patel: But that would be an implementation specific optimization. No?
[00:58:04] Acee Lindem: No. That's that should be how you handle it. We could take out the we tried to do it in one pass, but the cold start is not is not a frequent you know, not it's not a common scenario. A lot of times, you're gonna have the sequence numbers
[00:58:20] Jia He: Yeah. It's
[00:58:21] Acee Lindem: a in your saved. Right?
[00:58:24] Jia He: Normally, it will take not take effect the rule number one. Right? Yes. Just but when there's the code restart, rule number one may actually actually delay the convergence in some cases. Is it just
[00:58:39] Acee Lindem: In some cases, depending on which path you know, how the paths are. So we can take that out. But we we also need this rule. If you have a more recent version, a stale one, to get that back to the originator so the originator just like OSPF. Yeah. Get it back there. We're gonna that I think that's a that that's a good change. And in that way I mean, this isn't a common scenario anyway. But in that way, we'll handle we had this case before anyway for stale NROI that doesn't exist after the restart. For instance, you have a link that doesn't, you know you know, that it's not provisioned anymore that or a prefix that's no longer exists. This will handle both those cases, and you'll have a one one way to handle stale NROI, whether it's stale where a new one exists or stale where the new one doesn't exist.
[00:59:38] Jia He: Yeah. I think it's also helping that case. Simplifies it. Yes. Yeah. Thank you. Any other comments?
[00:59:54] Ketan Talaulikar: Hey. AC, you those 20 mails on the working group list would have been really great. You would have you're sharing your wisdom with everybody would be super unless we are list is very silent, you know, and ITF is paying a lot of money to keep that list.
[01:00:18] Jia He: Yeah. We can have more discussion on the list. I think this is a valid case. Just we need to figure out how to optimize it. Yeah. With some changes to the draft. Okay.
[01:00:31] Ketan Talaulikar: And the first the first email
[01:00:33] Krishna Kalyaniraju: that we got from
[01:00:34] Jia He: you. Really? That's okay. Okay. I think we finished our presentations. Just we may still have a oh, no. We are right at the time. So if you have any opinion about the next steps or any, question, comments to about the presentations today, bring it to the list, please. Okay? And see you hopefully, see you in San Francisco.
[01:01:07] Krishna Kalyaniraju: Yep. See you all at San Francisco.
[01:01:11] János Farkas: Thank you.
[01:01:27] Jia He: Stop the stop the slides.
[01:01:31] Krishna Kalyaniraju: Is that the slide? How about that?
[01:01:35] Keyur Patel: This one.