Session Date/Time: 17 Mar 2026 03:30
The following is a transcript of the TVR (Time-Variant Routing) session held on March 17th during the IETF 125 meeting.
Speaker 1: All right, good morning. I have 11:30, so let's get started. Ni hao, welcome to TVR working group. It's Tuesday, March 17th, so top of the morning to you. Let's see, Ed is remote today, Adam is also remote, so you get to hear me doing all the talking today. And Gunther is also in the room, our AD.
Speaker 1: Here's our Note Well. I assume most people have read this before. These are your responsibilities. These are the IETF conduct guidelines. Since this is China, we will paraphrase this as: please do not disrupt the harmonious operation of the working group. Here's some meeting tips if you haven't figured out how to deal with Meetecho yet. And some links to useful stuff. And more details on how to deal with Meetecho. If you're in the room and you haven't picked up on the onsite tool, then please also scan the QR code in the back of the room.
Speaker 1: We're going to be doing minutes, and Daniel and Ed are going to be helping out on that. And those are our mailing lists. Quick review of our milestones. So we finished our use cases, yay! Requirements—that was supposed to be done October '24, so we're only a little late with that, but fortunately it's with the IESG already, so sort of done. And then our data model is also with the IESG, and only a year late on that. This leaves us outstanding with the applicability statement and then implementation and operational considerations.
Speaker 1: Here's the state of all of our documents right now. Again, we've got two that are currently in IESG review. The requirements document does have a SECTOR review pending. The ALTO exposure draft—that's been adopted. We didn't see any progress on that this meeting. And then we've got two outstanding personal drafts: applicability and path verification. Here's our agenda for today. We've got this introduction, then we'll talk about requirements, talk about applicability, then path verification, and then we've got a long time of open mic. Any agenda bashing? All right, let's get with it.
[Presentation: Time-Variant Routing (TVR) Requirements]
Daniel King: Hi, good morning everyone. My name is Daniel, I'm one of the authors of the TVR requirements document. Oh, can I—I have control. Great. So, I don't think we need to spend too much time on the motivation. This is really sort of high-level requirements with some examples of how TVR might be used in the network, but clearly referring to the use case document that we can then build solutions around. So we have our data model, but there are several other ancillary technologies that also relate to TVR. This is the document that just defines how we use—or the requirements that we might want to clearly define with how we use TVR in the network.
Daniel King: We have a relatively mature document. It's been stable now for several months. We requested multiple directorate reviews, and we received several comments from each of these reviewers. So thank you very much. I think Bo provided one of the most detailed reviews that required some additional text, and we'll kind of go through that because that essentially reflects the changes in the latest version of the document. What is kind of missing, and we might need to chase up—so it's something we can discuss with the chairs—is we haven't received a security directorate review of the document. I believe that is Frank.
Daniel King: So, based on the reviews and some other comments that came from the list, we have a new version of the document. Apologies, we sort of submitted it relatively recently, but there aren't any substantive changes. So it's really about sort of cleaning up, addressing any ambiguity with some of the requirements, maybe restructuring the document slightly, and also addressing some operational considerations. And I think this is kind of showing actually that the work that we've done in the working group is reaching a level of maturity, the fact that we are kind of thinking about operational and security, which tends to be towards the end of some of the sort of the protocol work that we do in the IETF. But ideally we should be thinking about these from the very start when we develop technology in the IETF, but often it's generally sort of the later stages where we really get into the detail.
Daniel King: So, what have we actually done? Well, here is a list. As mentioned, it's just making sure that we have no sort of unknowns or ambiguity with the document. We needed to just sort of have clearer technology definition for some of the external interfaces between some of the functional components—so essentially sort of the orchestrator, the SDN controller, or whether it's a PCE, etc. It's entirely up to the implementer. We also needed to just sort of clarify some of the protocols that may be used. We needed to talk about domain granularity for scheduled routing and some multi-domain applicability. We also needed to talk about some precision and instrumentation that would be required in a TVR network from an operational consideration. Obviously, sort of time synchronization is going to be very important.
Daniel King: The second set of updates are actually sort of the—I guess the majority of new text that's been added in the most recent version of the document around resource preservation and dynamic reachability. Of course, TVR is mainly focused on scheduled changes that you are aware of. You know, what we don't want to get embroiled in is dealing with sort of unplanned changes. So we've made that, you know, very clear that that should be down to whatever sort of centralized or distributed technology you've implemented that's sort of concurrent or ancillary to TVR. And we also started—or I should say finished—the discussion on deployment considerations that may define specific requirements about: is this sort of greenfield networking, or is this augmenting existing network technology and you're now sort of layering TVR on top, and sort of how do you approach that from an incremental perspective.
Daniel King: We believe, and I will speak on behalf of the authors, that we have addressed all of the outstanding comments that we received on the list and the four reviews that we received from the various directorates. Security is an important dimension for TVR, so we would encourage—and I guess as authors we could follow up with the person that was assigned the security review, again I believe it was Frank, or we may want to talk to the coordinator to see if—if Frank's unable to perform a review within a timely manner—again, sort of time's subjective here or relative—maybe we could get it assigned to someone else because it's—I think it's—would be nice to kind of close this and sort of move into last call. So I'll leave it up to the chairs on that.
Daniel King: I think that's it, actually. I'm not able to click.
Speaker 1: Any questions or comments?
Fonyan: Hi, this is Fonyan from China Mobile. And one question is for the diagnostics requirements. Do we have any words on the diagnostics, how we do the ping or trace, like that?
Daniel King: So, there is—there is a sort of section on operational considerations, but because sort of TVR is reliant on several ancillary technologies dependent on the sort of environment that you use it—because they're sort of highly diverse—we don't specifically state what technology or mechanism would be used except at a very high level that you you would want to ensure that a clock was synchronized within a timely manner and it was accurate, that you would want to identify who has received a current contract and you would want to—it moves into security—but authenticate potentially that entity and make sure you're receiving it from a sort of a verified or validated source. We are now thinking as sort of as authors of the requirements documents more about the operational aspects, and I believe in the charter there is a milestone which I guess would be a separate document that would talk about the operational aspects from an sort of implementation perspective. And reading Lee's applicability document, and maybe he can actually pick up on this conversation as well, there is quite a detailed operational considerations discussion in that document as well. But I think it's a really important topic. I just don't think we needed to get into a fine level of granularity in the requirements.
Fonyan: Okay, thank you.
Speaker 1: I'll point out this is also a fine question to bring up in TipTop. Ed, you're next.
Ed Birrane (Remote): Yeah, just with chair hat on, I think that we would need and would want to react to security area review. If you are able to request that in person, that would be good. If you do have—if you need any help, we'd be happy to push as well. Security review is one of the things that could wind up coming back with additional significant enough comments that we would want to address. The sooner we get the review in, the better.
Daniel King: I—I also, just sort of processing something I said a couple of minutes ago. So I said that we would request last call. Has the document already finished last call? So a follow-up question might be—well, I suppose it's highly dependent on what actually comes back from the security directorate. But if there was sort of substantive changes, then I guess we would request a last call again. Because what we've updated so far, I'm not sure if there's anything structural in the document, certainly nothing that would impact the solution or the YANG model itself. Okay. I guess we watch this space.
Ed Birrane (Remote): Yeah, the document right now, the requirements document is submitted to IESG for publication, which means it is going through that series of review. It's not in last call.
Daniel King: Okay. Cool. Thanks, Ed.
Speaker 1: Last comment? Going, going, gone. Okay.
[Presentation: Applicability of TVR YANG Data Models]
Sule Zhang: Okay, good morning everyone. This is Sule Zhang from Huawei. I will introduce the TVR applicability statement draft on behalf of my colleagues and contributors. Okay, so let's recall the definition for the TVR applicability statement draft. It is a milestone of TVR working group. It defines that this document should provide a applicability statement on how the information and data models may be used, and also the required ancillary IETF technologies to solve the use cases and requirements.
Sule Zhang: So, in our draft, we first introduced the applicability of TVR YANG data model, and describe when and how to use the TVR YANG data model. And secondly, we introduced the time synchronization aspects. It describes how and how to select appropriate time synchronization protocols or mechanisms. And we also provide some operational considerations on the schedule dissemination, execution, and recovery, and error handling. And we also provide several security considerations on how to mitigate the potential attacks. And we also provide a appendix on the code examples for each examples introduced in the use case RFC. So I think our draft fully meets the definitions for the TVR applicability statement draft.
Sule Zhang: Okay, so what's new in this new version? We firstly do some editorial improvements to make it easier for readability. And we also provide some TVR definitions for some terms, including the managing device, network controller, and also the managed devices. And we also provide some clarifications for the protocol usage and data stores related to the TVR usage. And we also provide some practical operator considerations and more details on how to handle schedule conflicts. And also we enriched the security consideration section, and also improved the JSON code in the appendix.
Sule Zhang: So for the detail, firstly we provide three definitions for the managing device, network controller, and managed device. For the managing device, it is an entity responsible for generating and maintaining the TVR schedules. And the network controller, it receives the schedule and generates and computes the routings. And the managed device, it receives the schedules or receives the computing resource from the controller and managing devices.
Sule Zhang: And in Section 3, we provide some clarification for the protocol usage and data stores related to the TVR usage. We, from the operators'—for the operators' considerations, we provide two data stores: one is the intended configuration data store, it is used for the schedule provision; and another is the operational data store, it is used to store the execution status and also the applied schedules.
Sule Zhang: And for the time synchronization section, also provide some practical operator considerations for the time synchronization. We provide a new term which is the Maximum Acceptable Time Error Bound. The time synchronization protocols or mechanisms selected by the operators, it should must not—it should meet the Maximum Acceptable Time Error Bound.
Sule Zhang: Okay. And we also provide more details on how to handle the schedule conflicts. So in this version, if there are conflicts between schedules, then it should retain the last known good schedule. And for the schedule updates, the completely replacement is used, and partial updates is not permitted.
Sule Zhang: Okay. And last, in the security consideration section, we also provide the considerations on schedule tampering and malicious schedule injection. We also provide some considerations on how to mitigate this risk, including the authentication and authorization, integrity protection, and audit logging, and other means.
Sule Zhang: Yeah. So currently there is no issues open in the repository in GitHub. And so the next step is to request a working group adoption and maybe also to continue to improve the document. And if there will be an independent individual operational and considerations document, maybe the operational and security content of this document can be moved to that document. Yeah. So I think that's all. Thank you.
Speaker 1: Thank you. Any questions?
Daniel King: Hi, Dan. Dan King. So I think this kind of pulls a few threads. So thank you very much for the update of the document. I responded a few weeks ago saying that from a—from an applicability perspective, should we be looking at several applications and doing sort of a high-level analysis for these different use cases, or should we maybe focus on one or two that have sort of a common implementation architecture and maybe similar sort of this ancillary ephemeral term that we've—that I'm using at the moment, ancillary technology that is also applicable to both those situations and then go deep?
Daniel King: So yesterday I spoke to Luis—Lui at Telefonica, and we're working on a project called TFS, which is the TeraFlowSDN controller, which is it—it's not a Linux Foundation project, but it's a sort of similar type network orchestrator. And there's some work that's going on in that project at the moment for energy-aware networking, sort of scheduling ports, therefore links sort of at a time-dependent for energy efficiency. So we could maybe take one of your use cases and use something like TFS to actually sort of do an experimental implementation that then becomes part of a wider community through the TFS project itself, but also generates quite a lot more substantive code than you currently got in terms of JSON that's in the document, which is actually broken in places. But it also—and what I'm also seeing—is that some of your new text is probably at least applicable to the—the additional milestone in terms of implementation/operational documentation. So I'm just kind of at what point do you shift that text, if at all, from this document to that document? End message.
Sule Zhang: Yeah, okay. I think there was a discussion on the—on whether we should cover every use case of the—every examples of the use cases RFC. And I think that conclusion for the discussion is we need to cover every cases. But now we will also would like to hear the working group opinions for whether we should to have a more deeper examples on one of the use cases. Yeah.
Speaker 1: So, you pretty clearly the applicability draft has to cover—cover all the use cases sooner or later, because otherwise you haven't covered the problem space, right? And so we have to talk about everything. Now, whether you do that through iteration through the various use cases or say something general, that's up to you.
Sule Zhang: Okay, thank you.
Speaker 1: And as to your last question on the slide here, the operational considerations document—I've seen no one interested in working on that, so I'm not optimistic that we're going to see that ever move. So I would expect that you should keep things here for now.
Sule Zhang: Okay, okay.
Ed Birrane (Remote): Yep. Ed, chair hat on. I agree with Tony. I don't think we need to pull out a separate operations document. At the time we were looking through that milestone, we weren't sure whether a separate document would be necessary. If we can cover it properly in this document, that is one less document, and that's a good thing. In terms of the scope of this document—chair hat off—my sense is that if if we can get coverage over applicability in a single document, that is preferred. I do wonder if we go down into centralized versus decentralized or or some of the other demarcation lines whether you will wind up just with one very, very large document with little overlap. But I think we should start with one and do our very best to have one. To that end, with chair hat back on again, is there any reason here—and obviously we'll take it through the mailing list—why we would see evidence why this should not be adopted by the working group, or why this layout would be insufficient for the working group to continue this document as a working group document? Crickets. All right, thank you.
Speaker 1: All right, thank you very much.
Sule Zhang: Okay, thank you.
[Presentation: Segment-Based Path Verification in Low-Earth Orbit Satellite Networks]
Speaker 1: Okay, I'm seeing two sets of slides for the next talk. Which set should I be using?
Adam Wiethuechter (Remote): I'm not sure.
Speaker 1: Okay, I will point out that the other ones were added later. They show an 11:46 AM addition, as opposed to an 11:15 addition.
Adam Wiethuechter (Remote): Then I would do the one that was shown later, unless the speaker has—okay.
Speaker 1: Okay. Try this. One second. Okay, you have control.
Yuxuan Wu: Hello everyone. I'm Yuxuan from Tsinghua University. And today I will on behalf of all the co-contributors and present our work on the segment-based path verification in low-earth orbit satellite networks. And here's the roadmap for today. And firstly we will see the emergent LEO satellite networks and their architecture, and then we will explain why do we need a path verification method in LEO—SNs. However, there must be some related works in terrestrial networks, so why don't we just implement the existing works in the SN directly? Does the SN affect existing methods? And finally, what design directions should we consider?
Yuxuan Wu: And today, the SNs are under heavy constructions. Taking Starlink for the biggest operational SN for example, has launched over 10,000 LEO satellites and attracted more than 10 million global subscribers, covering over 155 countries. And these companies are constructing their own SNs and equipped with the laser inter-satellite links to support long-range traffic.
Yuxuan Wu: And in an SN architecture, the end-to-end traffic follows the path originates from a user and ultimately converges to the terrestrial internet as shown in the figure. And the space segment can achieve global connectivity through the long-distance and high-speed ISLs. However, unlike the relatively static internet infrastructures in terrestrial networks, the LEO satellites are moving dynamically around the earth. The high dynamics cause the satellites to entering certain areas where the threats may occur, like information stealing, or more powerful attackers can even hijack the traffic and result in the path inconsistency.
Yuxuan Wu: So for the satellite network operators, it's important to apply avoidance policies to force the traffic to bypass the risk area. But the most significant is to verify the practical path indeed bypass the risk area. And existing path verification methods can be divided into two types: the delay-based method and the crypto-based method. And firstly, the delay-based method—it precomputes a target area where the verifiable relays may locate, and it enforces the traffic to pass through all the relays. Since the relays are very far away from the risk area, taking a detour through the risk area will result in a greater observed end-to-end delay. This is based on the fundamental assumption that the delay between two terrestrial nodes and their great circle distance has a linear relationship. However, our results show that the linear delay-distance relationship doesn't hold in SNs because of the dynamic topology, and it leads to low verification accuracy.
Yuxuan Wu: And the crypto-based method constructs a verification chain consists of nested MACs and checks the chain to verify the whole path. The intermediate nodes verify and update the verification fields in the packet handle hop-by-hop. However, the long header length will lead to longer processing delay and limited scalability in large-scale satellite constellations. So, the above analysis indicates that the high dynamic and large-scale SNs pose a challenge to the accuracy and scalability of path verification.
Yuxuan Wu: So we proposed the segment-based path verification for SNs. It use a collection of dynamic satellite relays to split the whole path into a series of consecutive segments, and it transforms from verifying the entire path into verifying each segment. And the workflow for each communication pairs proceeds as follows: First, the SNO Operation Center will precompute the relays and the source will construct the packet header containing the timestamps and relay authentication fields and other verification information fields. And the relays will probe the delay ground truth of the current segment by sending the probing packets to the previous relay and periodically. And when a relay receives a packet, each relay will verifies the segment. And if the packets do not traverse the risk area, it authenticate the packet header. And finally, the destination verify the last segment and makes the final decision to accept or drop the packets.
Yuxuan Wu: And in conclusion, we are seeing that the SNs are under heavy constructions. And since the LEO satellites are moving dynamically, they're facing more routing threats. And the high dynamic and large-scale SNs pose a challenge to the proposing a highly accurate and scalable path verification method. And our main proposal is a segment-based path verification method which transforms from verifying the whole path to verifying each segment and only requires the relay to authenticate, considering the efficiency. And more details can be seen in our drafts and welcome to contact us through the emails. And I think that's all for today. Thank you.
Speaker 1: Thank you. Question for you: I'd like to back up for a second, maybe I'm missing something. You're assuming path computation with full traffic engineering here, yes? So when traffic is injected into the LSN, we are computing an end-to-end path through the network, yes? Okay, if you've got that, then you know where you're trying to avoid, and you've presumably avoided the risk area in your path computation. So what's the real motivation for doing the verification?
Yuxuan Wu: Motivation for path verification. As we can see that for the high dynamic LEO SNs, it's inevitable to for the satellites to traverse some risk areas. So we will have the consideration that how can we know the actually path—the path actually bypass the risk areas we don't want the traffic to go through? And the existing methods is not efficient and have low verification accuracy in SNs, so we proposed our work.
Speaker 1: Okay, I'm confused by that. Right now you understand what the topology is, you understand your destination, you can do a path computation that's on the order of an SPF computation, which is reasonably efficient, and you can certainly cache it. And that avoids the risk area. So why aren't you correct by construction? The path that you compute is already going to avoid the risk area. You know which satellites are in the risk area, you're going to avoid all of them and compute a path outside of that. Isn't that sufficient?
Yuxuan Wu: I think to mean that only compute the the whole path to bypass the risk area is efficient.
Speaker 1: You yeah, you can clearly do that in a CSPF run.
Yuxuan Wu: But the thing we want to do is to verify it. Because if if there are some countermeasure attacks and...
Speaker 1: Okay, but the countermeasure attacks are going to happen in the risk area, yes? So you've avoided the risk area by construction.
Yuxuan Wu: Yes, but I think someone may propose a work to to help us avoid the the risk area, to help us calculate the path bypass the risk areas, but the things we want to do is verify it.
Speaker 1: Okay, I'm clearly not getting something, so I'll back up.
Yuxuan Wu (Tsinghua University): So I think you are asking: the path is already computed, why do you still want to verify it? And her point is: you have a computed path, but you want to make sure your packets is really using that path. Is that correct? Yeah. That's my understanding.
Speaker 1: I understand that. Okay, but my understanding of the threat environment here was one of jamming, not one of loss of control. So unless the satellites are compromised, then the path should be the path computed.
Ed Birrane (Remote): If you could go to slide 5, that might help. I I took the threat to be information stealing, not jamming.
Speaker 1: Okay, well if the threat is information stealing, then avoiding the risk area should be sufficient, yes?
Ed Birrane (Remote): If you trust it, yeah.
Speaker 1: Okay.
Yuxuan Wu (Tsinghua University): Maybe you can give some example why the path is changed, it's not going through the original design path.
Yuxuan Wu: We have mentioned the information stealing—it can be avoided by just bypass the risk area. But if more powerful attackers may hijack the traffic, how can we make sure our path already practical bypass the risk area? So if our packets do not actually bypass the risk area, is the packets safety safe?
Lin Han: Lin Han from Southeast University. I think this issue is more generic for satellite network. If traditional traffic engineering based network, there's no need for path verification because the network is closed, you control everything. So no need, as the chair said. But for satellite network, the link between ISL or link between satellite and ground, it's open. So someone maybe hack that. The furthermore is that you assume that the hacker can change the routing table or forwarding table, then you need to verify. But this is much more discussion after the basic issue get finalized. For example, what is the protocol for the LEO satellite network? Is it MPLS or IP? You didn't mention anything there. So I think this issue should be solved after a lot of basic issues are answered. Thank you.
Yuxuan Wu: Okay, thank you for supplementary.
Speaker 1: Thank you. Yeah, if you're going to lose control of the satellites, then all bets are off. So, yeah. Thank you very much, it was interesting. Thank you for your comments.
Speaker 1: Any other comments or questions? Ed, I guess you're still in the queue.
Fonyan: Once once again, China Mobile Fonyan. There is a suggestion for this is that we need to verify not only the packet header, but we also need to inject some information into the packet header during the forwarding process on each node. In that case, we can make sure all of the the the path we want wanted go and the real path is forwarded can be the aligned or same. That's my suggestion. Thank you.
Speaker 1: Right, this having path verification—some folks working on the SONIC routing architecture are doing that. I don't know if you've looked at SONIC, that also might be interesting. Thank you very much, it was interesting.
Yuxuan Wu: Also thank you, thank you for everyone. Thank you so much.
Speaker 1: Anyone else?
[Open Mic]
Speaker 1: Any other business? We have open mic. Or you could just walk up.
Daniel King: So I've just got my brain around merging the last two bullets on the charter—so sort of the applicability and the operational considerations and security. So let's assume then for a moment that actually we poll to see if the applicability document should be adopted. Great, working group decides: "Yep, let's do that." That then closes those two milestones potentially when the document gets finished. What's next?
Speaker 1: That's worth a lunchtime conversation if you want to have it. Any other comments or questions? All right, thank you very much. Bye-bye.
Ed Birrane (Remote): Thank you, everybody!