**Session Date/Time:** 19 Mar 2026 03:30

The following is a transcript of the IETF 125 LSVR Working Group session.

**Jie Dong:** We have one minute to start. It sounds like an in-meeting room problem, because he's plenty loud online. Let's get started. It's 11:30. Acee, do you want to give some introduction of this, or do you want to run the slides?

**Acee Lindem:** Um, you did them. You can go ahead and go through the slides. I mean...

**Jie Dong:** Okay. Welcome to the IETF 125 LSVR working group session, and welcome to Shenzhen. This meeting is being recorded, as always. So, here's the Note Well. We are always on Thursdays, so I believe you have seen it many times. But just make sure you have read it carefully and also, if you have any questions, just need to read the references, RFCs, or BCPs. Here are the meeting tips. We recommend you to use the in-person Meetecho tool and join the mic queue. And for the remote participants, please make sure you have a headset and mute yourself if you are not talking. Here are the resources for the meeting. I think you already used it for the whole week. Here's the agenda for today's meeting. We have four presentations after the chairs' update. And two of them are the working—one of them is a working group document update and three are individuals. So here are the status of our working group documents. The first one is the YANG model, `draft-ietf-lsvr-bgp-ls-yang`. It's on today's agenda. Recently, this draft has been updated with the 03 version, and the authors are also working on the updates of the BGP YANG model, the base YANG model. So we hope we can get some updated information from the authors. And for the second working group draft, the L3DL, it has been—it has expired and no update since May last year. And recently, the authors have revived the L3ND and L3ND-over-P2P drafts and plan to proceed with these drafts in the LSVR working group. So today we will discuss about the plans on these drafts during the presentation. Here are the individual drafts we have so far. Many of them are on the today's agenda. And for the drafts which are not on the agenda, I hope we can also have some mailing list discussion if there's good interest in this work. Maybe we can also have them discussed in the following working group sessions in the future. Here's the liaison. I was reminded by our AD that we have received the liaison from IEEE for one year. So we really need to give a response from this working group. And we can also discuss this during today's meeting. For the erratas, recently we received two errata reports on the RFC 9015, and one is technical, one is editorial. I hope the authors can take a look and give their feedback or confirmation. Okay, I think that's all for the chair slides. Any comments on this agenda or the status of the working group?

**Acee Lindem:** Yeah, yeah, this is Acee Lindem. I'm going to reply to those—I just looked at them quickly, but I'm going to make sure before I verify those two errata. But I'm going to look at them this week.

**Jie Dong:** Okay, good. Thank you.

**Keyur Patel:** Keyur Patel from Arrcus. I was just going to—sorry, I didn't mean to interject you, Mahesh, but I was just going to reply as an author that I'll respond alongside with Acee on the erratas. Apologies, Mahesh.

**Mahesh Jethanandani:** Okay, no problem. So, I think in one of the documents—maybe it's the BGP-LS draft—there was a mention of—yes, thank you. The second bullet item says "authors are also working on an update to the BGP YANG base model." Does—can anyone clarify what is this change? Because I'm not—as an author of that draft—aware of what the change being asked for is.

**Jie Dong:** Yeah, maybe this is a little bit confused. I mean—what I mean is authors are working on this another BGP base YANG model, not to trigger any update from the BGP-LS part.

**Mahesh Jethanandani:** Okay, because the phrasing clearly says "also working on the update to the BGP YANG base model." Just to be clear, because we're trying to get that draft out for publication.

**Jie Dong:** Yeah, they're in parallel.

**Mahesh Jethanandani:** So if there's anything that's pending, we'd better know it now.

**Jie Dong:** Right. Sorry for the confusion caused. Okay, so now we move to our first presentation. Let me check if I can hand this control to you. Okay. Please go ahead.

**Arvind Babu:** Yeah, hello all. I'm Arvind Babu from Cisco Systems. Today I'll be presenting the updates of BGP-LS YANG model draft on behalf of my co-authors Mahesh and Keyur. So it's a working group draft and it's been dormant for quite some time now. So let me start with a quick recap on what the draft proposes. So basically it defines a configuration and management for BGP-LS, BGP-LS-SPF, and it can also be extended to BGP-LS-VPN. It also defines a model for the link-state database. One more point to note is the model is heavily operational in nature, more than the config. Let's get into the design aspect. The model is basically split into two modules, each with distinct responsibilities. The first one is `ietf-bgp-ls.yang`, which is the integration layer. It describes how the BGP-LS is attached to the actual BGP model. So the model augments the base BGP YANG at two levels: one is the global AF/SAF level, and the other one is neighbor AF/SAF level to support the list of BGP-LS, BGP-LS-VPN, and SPF. So at both levels, the model incorporates prefix limits and other configuration details. It provides a statistical container for both global and neighbor AF/SAF metrics. So basically, it is the module that plugs link-state distribution into the standard BGP model tree. The second module is `ietf-bgp-ls-db.yang`, which is the database layer. Basically, it defines the normalized or digested link-state database representation. So at this layer, the topology is modeled as databases containing nodes, with each node containing links and prefixes and other stuff from BGP-LS. So every object carries some common metadata as handle, type, topology ID, PDU ID, and list of attributes. This is a quick overview of the YANG tree of the previous revision. So at the LSDB level, we have databases, each database is scoped by VRF name, instance, protocol ID, and area ID. Within each database, the core hierarchy is database to node, and from node there is link, prefixes, and their corresponding or related attributes. We can see the LSDB view on the left, and it's object-oriented, stores the digested topology format. We have node ID, which is exactly the node descriptor which we get from BGP-LS, it's represented as string. There is also an handle ID, which is the internal representation of how the LSDB records store it, and PDU ID, which we get from the source advertisements or which we create when we get the advertisements. The attribute captures the type, length, and value of each attribute TLV. What we have on the right side is the TLV, and it stores it in the actual wire format. Yeah, we got some comments on the previous draft version. There are also a couple of gaps in the approach we have taken. So I just first start with the list of gaps. So it internally maintains handles for DB entry and attributes, which are tracked as keys, not the actual BGP-LS keys, and the descriptors are stored as strings, which is difficult for filtering and not providing any flexibility to filter. Attributes are also tried to fit into the union of native YANG types and mostly the assumption is the attribute will be a single leaf, but the BGP-LS attributes are not so. So basically, BGP-LS has different kinds of attributes. I'm listing some a few of them, like it has multi-valued TLVs like SRGB or taking start label and the range values. It has variable length TLVs like extended administrative groups. There are a couple of nested TLVs, like the AS path can come under L2 bundles, which can come under a link attribute, and similarly for flexible algo definition, which internally holds multiple sub-TLVs. There are a couple of comments also received, like we should include support for all the link-state NLRIs from RFC 9552—whatever we captured in the draft too is a subset of it. We need some key modeling change. Yeah, so NLRIs are variable length; there's no native construct for variable length TLV containers. So that has to be considered in, and there is also the interoperability challenge where the endpoints may receive unknown TLVs, unknown NLRIs, or within a known TLV, there can be unrecognized TLVs or sub-TLVs. So we needed a strategy to preserve unknown TLVs. So what we have as a changes in the latest revision is we have not touched the augmentation part, but we have made changes to the LSDB. So LSDB, as defined before, was previously defined using TLV-centric representations, but in the new proposal, the BGP-LS topology NLRIs and attributes are now represented using NLRI expanded structures. It will be mostly inline with how the 9552 construct works. Yeah, so known attributes are explicitly modeled with typed YANG fields. We have made use of the known YANG types, routing types, OSPF types, and ISIS types have captured the RFCs. The unknown and unsupported attributes are preserved as binary blobs or strings. This is for extensibility and interoperability. The revision right now includes only the node NLRIs and node-related attributes, but we are actively working on bringing in the complete support or the IGP topology support that is captured in RFC 9552. That's a ongoing work. So this captures the current YANG tree in the recent version. Basically, if you see the BGP-LS topology, that is where the changes are made. So under BGP-LS topology, there can be multiple instances, each instances are derived from VRF name, protocol, and identifier. And within the instance, there can be multiple nodes, links, or prefixes, or SRv6 SID containers, or SR policies. I just zoomed into the node container where inside the node container, there can be different protocol nodes. We have captured only the OSPF node, and OSPF node is keyed using the area ID, router ID, and DR ID as specified by the RFC 9552. And we also have the node attributes—this will be a list of node attributes and they are keyed with identity reference. What we have on the right is the set of node attributes. Once again, if you take one example like SR capabilities, the SR capability container internally has SRGB, which also defines two leaves: start label and the range size. Yeah. So the code and the current issues can be tracked at the GitHub link which is given. So we are working on supporting the other known NLRIs specified in the 9552 draft and other BGP-LS RFCs. We are requesting the working group for review and feedback. So that's all I have. Thank you. Any questions?

**Jie Dong:** Thank you. Acee.

**Acee Lindem:** Yeah, Arvind. Acee Lindem-Marcus. You said you were having some problems—Arvind, your voice is echoing—can you repeat with louder please? Yes, I heard you say that you were having problems with TLVs of variable length. We have those in the OSPF model, RFC 9129. I mean, usually it's just—it's variable length because there's a nested sub-TLV, or whatever, a list of those. And we also have unknown TLVs. I'm not sure if we have the best way of handling it, but you could look at that—how we handle the variable length and unknown TLVs and sub-TLVs.

**Arvind Babu:** Sure, Acee, we can—yeah, we can check that offline and discuss. Yeah. Thank you.

**Jie Dong:** Any other comments? Ketan.

**Ketan Talaulikar:** Um, yeah, thanks for progressing this work. I had a question to the authors and the working group: BGP-LS is like a moving train and I would say lots of things getting added on top. What are the working group and authors' thoughts on like putting a limit on what you would take in and push the base model out, rather than keep adding more and more things that are constantly added, especially in BGP-LS?

**Arvind Babu:** Ketan, can you reply to that?

**Keyur Patel:** Keyur Patel, Arrcus. I would say, speaking as an author, that since we have done or we've put pretty good guardrails around BGP-LS-SPF, the YANG model would strictly follow the guardrails of BGP-LS-SPF here. Thank you.

**Ketan Talaulikar:** So, Keyur, just to understand, this is a model for BGP-LS-SPF, BGP-LS, both, right? I think it is—probably good to just put like whatever I think RFC the base BGP-LS spec and be done with it, but I'm assuming that other BGP-LS extensions can extend this or augment as they go along.

**Keyur Patel:** Sure. Keyur Patel, Arrcus. Agreed, noted. And I'm not sure if Mahesh wants to add more.

**Ketan Talaulikar:** Yeah, I mean just to be clear, my only point was that we try and not make—keep this growing larger and larger, and then we have like some something there saying "this is what we will take" and then more can be added in further documents.

**Mahesh Jethanandani:** Mahesh here. Yeah, agreed with what Keyur said. I think we do want to get the model out with the minimal amount of changes needed. So happy to stick to that.

**Jie Dong:** I agree that maybe we need to draw a line for to finish this work as soon as possible, and for the future work, maybe they can be done with augments. Okay, no further comments? Let's move on to the next—next presentation. Keyur, you will present this one?

**Keyur Patel:** Yes. Keyur Patel, Arrcus. I'm going to give an update, short update, I've only got one slide, courtesy Randy Bush, on L3DL and L3ND. Both these drafts are in fairly stable state. They are two different options. At this point, we would like to solicit feedback from working group as to which path should we take? Should we take L3DL path, then we probably want to go down the path of updating LLDP-v1 for Hello and BFD for liveness. This is already been talked about and can be done. And if not, we have L3ND in a pretty stable state and that would be path to follow through. So the questions on behalf of authors and somewhat, and we can take this on the mailing list, G, if needed, and Acee, is to say, "hey, what path should we take forward and how do we nail this going forward?" The drafts are in pretty stable state.

**Rob Shakir:** Yeah, can you hear me? Can you hear me?

**Jie Dong:** Yes.

**Rob Shakir:** Okay. Just one addition to the bullet list here. The authors' recommendation actually is A, that we decide if we actually want to do this, but B, if we are going to do this, it should almost certainly be L3ND for a very simple reason: it's a simpler protocol with less extraneous nonsense in it. L3DL has its own entire transport layer, it has its own security mechanism because it's all written over basically raw Ethernet packets. L3ND is just using plain old boring TCP and TLS like every other protocol in the world. So there's really just less extraneous stuff—it just has the semantics. The semantics are basically the same. So I just wanted to clarify that. Thanks.

**Jie Dong:** Thank you. Acee, you want to say something on this? Can you speak a little bit louder, or close to the mic?

**Acee Lindem:** Yeah, I think—can you hear me now?

**Jie Dong:** Yeah, it sounds like very far away from us.

**Acee Lindem:** Yeah. So, I—I don't think we need to go through those slides that just—those two slides I did, I don't think we need to go through those because Rob basically said the same thing that L3ND is where we should go and leverage... can you put the slides? Yeah, go ahead and put the second one on—or put—yeah, put those up. This one? Yeah, that was—that was the old one, old one. Can you share from your laptop? You can share screen if you have the newest one on your laptop. There's a share screen button at the bottom. Yeah, I do. You got it? Is it coming? Not yet. I need to stop the share. Let me check. It's coming. You can share now. Okay. Share screen, maybe. Yeah, I did. Is it coming? And by the way, can you maybe switch to another mic? Maybe are using the wrong mic? It sounds the voice very—sound very far from us. Okay, is this better? Still—there's the—it's—no, it's not better. Sorry, Acee, you sound like you're on your laptop's built-in mic instead of your headset. Can you check your mic configuration or... Can you see the—can you see the slides? No. Okay. Anyway, I'm going to just... and your voice is still not that clear to the room at least. Yeah, I'm going to... how's that? Is that better? Still the same. Is that better? Hmm. So I'm not going to use the slides then. Anyway, all I was going to say is I—I concur that we should go... Can you speak a little bit louder? How's this? You still can't hear me? Still does not work. But in the beginning you tested the mic, that was very good. Then you changed something or... Is it only Acee, or you can hear others from remote well? I can hear you clearly. Okay. So that—that should be the mic. Maybe Acee's rejoining us. Can you hear me? Still the same. Yeah, it's a little bit difficult to hear you and understand what you are talking about. Maybe Acee's quit and join again? Let's wait for a moment.

**Mahesh Jethanandani:** Maybe we move forward with the next presentation and have the discussion in the end? How about that?

**Jie Dong:** Yeah. The next one is Li Zhang. Okay, good afternoon everyone. This is Li Zhang from Huawei. I'll introduce the Applying BGP-LS Segment Routing over IPv6 (SRv6) Extensions to BGP-LS-SPF on behalf of my colleagues Jie and Keyur. So let's recap the document and in this document we introduced the SRv6 node attribute TLVs from the BGP SRv6 to BGP-LS-SPF, including the SRv6 capability TLV, the node MSD TLV, and also the SR algorithms TLV. And we also introduced the SRv6 link attribute TLVs, including the SRv6 End.X SID TLV and the Layer 2 Bundle Member Attribute TLV and also the SRv6 link MSD TLV. And we also introduced the SRv6 prefix attribute TLV to SPF, and it only includes the SRv6 Locator TLV. And we also introduced the SRv6 SID NLRI, and it includes the SRv6 SID information TLV to carry the node SID information. And we also introduced the SRv6 SID attribute TLV, which includes the SRv6 endpoint behavior TLV and the SRv6 SID structure TLV. And we also provide some descriptions on the endpoint behaviors that may be carried in the SRv6 endpoint behavior TLV. So in this 04 version, we add a new section 3 on the SRv6 SIDs and reachability and also do some editorial updates. So I think this is the comments from Acee in the last IETF 123 meeting. His comments is suggest us to provide more descriptions on the installation of these TLVs into the RIB. So we add a new section 3 to introduce the installation of the SIDs and locators to the RIB. So for the forwarding entities for the locators advertised in the prefix NLRI, it must be installed to the forwarding plane when the associated algorithm is supported by the receiving nodes. So for the SRv6 SIDs received from other nodes that are not directly routable, it must not be installed in the forwarding plane. It need to check whether it is covered by a locator. So for the next step, we also welcome for comments and suggestions to improve this document, and I think we also think this document is quite stable now, so we maybe request a working group adoption. Okay, and that's all. Thank you.

**Jie Dong:** Thank you Li. Any comments? Acee, you may take this chance to test your mic. Yes.

**Acee Lindem:** How's this? Is this better?

**Jie Dong:** It's the same. Sorry.

**Acee Lindem:** Oh man, I connected... hmm.

**Jie Dong:** He's back. Okay, so any other comments except Acee? Maybe Acee, you can send your comments on the chat box or on the mailing list. Yeah.

**Ketan Talaulikar:** Yeah, I—I agree and echo what Rob said—this has been around for just far too long. I would really at this point push, really push for having a adoption or like—I mean poll to the working group, whatever it is, and get a direction and let's move forward, right? One way or the other, let's do that. And we also need to respond back to the IEEE liaison, and I hope that this poll gives an answer that the chairs can then, you know, send to IEEE. And—and we just move ahead.

**Jie Dong:** Okay, thanks. I think this draft has been—with us for a while and has been presented several times. According to the charter, this work is also within the scope. So after I will check with Acee about what would be the next step, and—it will happen on the list. Okay, thank you.

**Keyur Patel:** Thank you chair.

**Jie Dong:** Next is Chenyang. Hello, chairs and experts. This is Wen Chenyang from China Unicom. I will introduce the BGP-LS-SPF extensions for SRv6 policy state synchronization. The other authors include Jie Xu and Lin Zhu. First let's start with the problem statement and solution overview. The problem this draft aims to solve is that BGP-LS-SPF can distribute SRv6 SID information, but it lacks the ability to indicate whether a particular SID is actively being used in an SR policy. So this draft defines a new optional sub-TLV for the SRv6 End.X SID TLV that carries policy state information. And using the sub-TLV, it could improve convergence during policy changes by providing real-time visibility into SID activation status. SPF computation takes SRv6 policies into account to generate compliant paths. So let's move on to the design of SRv6 policy state sub-TLV. As we can see in this sub-TLV, the fields include type, length, flags, and reserved. The sub-TLV provides a mechanism to indicate whether SRv6 SID is currently active in one or more SR policies. So for flags field, the first bit is P-flag. When the P-flag is set to 1, it indicates that the SRv6 SID is currently active in one or more SR policies. When it is set to 0, it indicates that SID is not active in any SR policy, or the policy statement is unknown. And the bit 1 to 7 are R-flags reserved for the future use, and they should be set to 0 on the transmission and should be ignored on receipt. So for operational considerations, first, policy state advertisement. The SRv6 policy state sub-TLV is included in the SRv6 End.X SID TLV when the advertising node has knowledge of the SR policy state for the corresponding SID. When the policy state of an SRv6 SID changes, the advertising node should update the corresponding SRv6 End.X SID TLV with the current policy state information. And second, for BGP-LS-SPF route computation, BGP-LS-SPF implementation that support this extension may use the policy state information during SPF computation to prefer paths containing active SR policy SID. And third, backward compatibility. The SRv6 policy state sub-TLV is optional. Implementations which do not support this extension will be silently ignored sub-TLV. So that's all my presentation. The questions and suggestions are welcome.

**Jie Dong:** Thank you. Any comments on this presentation? Acee, please.

**Acee Lindem:** Yeah, I was just wondering, the—do all the nodes necessarily know their SID is being used in a policy at—head end? Speak a little bit louder or close to the mic. It's okay, but it could be better. Thank you. My question is whether the nodes that advertise the SIDs know that it's being used in a policy actively. They might not, right? Because it's only the head end that—I mean, I guess you could—you could say that if it's in the same domain and they have that AF-SAF, they might be able to tell if they pass that information to the BGP-LS-SPF SAF.

**Jie Dong:** Yeah. Did you get the question, or you want Acee to repeat again?

**Wen Chenyang:** Maybe Acee could please repeat it more clearly? I'm...

**Jie Dong:** Maybe I can help. Basically I think Acee asked whether the node which advertise the SID is aware of whether the SID has been used actively by SR policy, because the SR policy state may be maintained only on the ingress or head-end node. Is that what your question?

**Acee Lindem:** Exactly.

**Wen Chenyang:** Maybe I think the SID information—like this active information can be sent to the ingress node or the controller to help the SPF calculation and make the SPF calculation result will be more suitable for the SRv6 policies' requirements and states. Actually, I think this question we need to think about it after this meeting and discussion.

**Jie Dong:** Yeah, please take this to the mailing list. Yeah. Li Zhang, you want to ask question?

**Li Zhang:** Yes, I have a comment for—for this. We can assume that the node—it can aware that it is active in one SRv6 policy, and it advertise—"I'm active in some policies"—but then the other nodes will compute path using this node, right?

**Wen Chenyang:** Yes.

**Li Zhang:** But this may cause to another problem is that then the other BE traffic may come to this node, and then this node may be congested.

**Wen Chenyang:** Yes, this is a good question. We think this active or not information in this draft, we think it should be advertised to other node, but whether choose—which path they should be they want to choose is determined by the ingress node or the controller.

**Li Zhang:** Okay. Okay. Thank you.

**Jie Dong:** Yeah, as a working group member, I would like to check what is the use case of this information. Do you think that will be—in which case the ingress node will take this state in case—let's assume it's aware and can be advertised in the network? How would the ingress use it for—for the path computation and what would be the benefit or use case? Maybe it can be clarified or specified in the document also.

**Wen Chenyang:** Okay, we will supply this.

**Jie Dong:** Okay, any further questions? Okay, thank you. Now we can come—come back to Acee and Acee, will you share the slide or let me stop sharing here. Is this one? Okay, let me go back to the first page. You have the control now.

**Acee Lindem:** Okay. Like I was saying, we were—we had started with the L3DL about in it was around 2019 it became a working group document. And there was also an alternative to take everything that was LDL and just plop it into LDP when they had because now LDP can support multi-frame. So rather than—at the same time they—the authors had been thinking about L3ND which is a simpler protocol, it makes use of the IT both UDP for the Hellos, multicast UDP, and TCP for the states, and it has a bootstrapping of the TCP sessions based on these Hellos. And this is where as a working group member and chair, I think we should go this route with great speed. Now people can propose other things, but I think I think we've we've looked at a lot of alternatives and this is where we should go. Apologies for the microphone not being loud enough.

**Jie Dong:** Thank you, Acee. So I think we need some feedback and views from the working group. Firstly, I would like to check with authors of the L3ND draft: do you plan to proceed with this document in this working group or in—as a replacement to the L3DL?

**Rob Shakir:** Okay, Rob please. Two things: one, L3ND is basically about as done as L3DL is. I mean, both of these really were done the semantics were done five years ago, seven years ago now, I guess. The authors, to be honest, are kind of burned out on this. We—we put a lot of work into it back in the day and it just sat there and whatever. We might be able to drum up enthusiasm for doing one more spin. I don't think we're going to tolerate another five years of screwing around with it. That's me speaking personally, and I think speaking for Randy, I can't speak for my other co-authors, they have their own opinions and are welcome to voice them. There was one other question, though, that was on Randy's slide and isn't on this one. Do we actually have users who intend to use this, intend to implement it, intend to ship it? What I don't want to do is spend a lot of time working on something that just goes into a black hole and never gets used. And I think in this case, given how long we've taken, there's a danger that we're doing it because we were doing it as opposed to because we still need it for anything. So that's really the question that I would put before the working group is, do we actually want this? If we want this, then I agree it should be L3ND. Just speaking as the one person I know who actually ever implemented L3DL back when it was called LSOE, I agree we should not be doing that again if we can avoid it. It's just it was fun but there's just a lot of machinery we don't need for this.

**David Lamparter:** David Lamparter. Just as far as implementations are concerned, I will say that implementing L3ND is about two orders of magnitude easier for FRRouting compared to L2, just because there's fewer moving parts. That doesn't mean someone's going to show up and do it, but it's much more likely.

**Rob Shakir:** Thanks. Just speaking as the one person I know who actually ever implemented L3DL back when it was called LSOE, I agree we should not be doing that again if we can avoid it. It's just it was fun but there's just a lot of machinery we don't need for this.

**Jie Dong:** So it seems that the authors would like to proceed with L3ND if there is interest or requirement from the implementers or the users. Is that correct?

**Rob Shakir:** Yeah, I think the chairs determine whether or not there really is a use for this. If there is, then it should be it should be L3ND.

**Jie Dong:** Okay. So I think we need to some—have some maybe poll the working group later about the use case or the requirement on this. What do you think, Acee?

**Acee Lindem:** Yeah, I think that's a good idea. That was one thing Keyur and I were talking about is that L3ND would be extendable to other use cases that people are talking about doing in other ways, and this could this could do both the discovery and the things like this congestion notification or information for ECMP balancing and other other things that people are suggesting doing in other ways. It could all be done with L3ND.

**Jie Dong:** Yeah, I agree. So maybe if there's no further feedback from the room or on this meeting, maybe we can bring that to the list to have a poll about use case. Ketan.

**Ketan Talaulikar:** Yeah, I agree and echo what Rob said: this has been around for just far too long. I would really at this point push, really push for having a adoption or like—I mean poll to the working group, whatever it is, and get a direction and let's move forward, right? One way or the other, let's do that. And we also need to respond back to the IEEE liaison, and I hope that this poll gives an answer that the chairs can then, you know, send to IEEE. And we just move ahead.

**Jie Dong:** Okay, thanks. Any other questions or comments? Okay. We finished four minutes early. So thanks for all the participation, and we will take these questions or discussions to the list. And see you in Vienna next IETF.

**Acee Lindem:** Yeah, I think we have this this discussion and adoption and we have the SRv6 BGP-LS TLV usage adoption request as well, both those two.

**Jie Dong:** That can also be taken to the list.

**Acee Lindem:** Yeah. Okay.

**Jie Dong:** We're done today. Thank you.

**Ketan Talaulikar:** Thank you. I didn't want to jinx the session with video from my side. It's known to happen, so thank you everybody. Bye.

**Acee Lindem:** Thanks G. Thank you Acee, hope we can see you in Vienna in person. Yeah, I hope so too. Absolutely. It's only 11:30 out here. That's a reasonable time to be up. I know, I'm looking at you later. Yeah, exactly. I'm going to—anyway, lots of other plans and I'm attending this at home as well. No, no. No, I just—I just wanted to have a look-see. Great job. Tomorrow lunch—lunch with Dan tomorrow? I check email, I'll talk to you. Should—should be fine. I just—one more thing I wanted to, you know, pick your brain and see that, you know, if there is something the under-connected BGP-LS, what motivates it. Okay, I'll look into it. What was the End.X? Oh, right. Okay, I'll check email after. Yeah, sure. Sure. See you. Bye-bye. Bye.