Session Date/Time: 20 Jul 2026 09:30
[00:00:56] Chairperson: Okay. Welcome to TVR, for IETF 120. It is 11:30, so it is time to get started. I would ask if anyone is near the the doors in the back that they close them just so that we don't get a lot of noise from the hallway. I can't page, though. So a couple of things. Just because today is the first day of IETF, if you are new, if this is your first IETF, please note that there are a number of IETF policies that you should be aware of by participating in the IETF. We do expect that you will follow these processes and policies, so I will just take a moment with this up on the screen for you to be to familiarize yourself with these either now and through the rest of the week. Separately, IETF conduct and guidelines. We do ask that everyone respects the the conduct guidelines that we have in these working groups throughout the week. We should be very hard on ideas and very kind to people. So please extend respect and courtesy as we talk through all of the technical things that we talk through. A couple of things. The IETF 120 meeting tips are probably not as interesting since this is IETF 120, but they are the same. So, please make sure to sign in, via the data tracker. Please make sure that if you come to the mic, you have signed in. Please, if you've come to the mic, make sure that you have joined the queue. If you are joining us remotely, please clip your audio and video off just to save bandwidth and make sure we don't get other sort of fandom noises. If you have made it to this room, you understand where to find the resources for the agenda and so on for the working groups. But, otherwise, here is the link for the Meetecho if you're struggling for to find it and the link for the agenda. Lastly, please join the shared notepad as integrated through Meetecho. Of course, we know that there there are AI tools that summarize these meetings. They they actually do a fair job, but having folks come in and help us take human notes is always appreciated. In particular, it is always helpful to make sure that people's names are spelled correctly in the minutes. So if you yourself have gone to the mic, also double check and make sure that your name is properly captured in the in the minutes. Otherwise, we have made a fair bit of progress against our milestones. Our use cases are done. Both the requirements and the data model are now in the editor's queue, So congratulations on that. We are working on the applicability statement, and good progress is made there. And from prior meetings, we have made the determination that implementation and operational considerations is not a necessary milestone coming out of the working group. But we have but we haven't actually taken that final pull through the mailing through mailing list, and that would be our intention. So this is just a a refresh of where we are. Separately, we do have two additional personal drafts coming in, which are small additional yang model extensions for things like life cycle and state and scheduling for interconnection scenarios. We're gonna hear about those today. Otherwise, here's our agenda. We're gonna reserve some time for open mic, and let's take a moment and agenda bash. Does anyone have any recommendations or changes to the agenda as is? Alright. Tony, do you have any other comments? Alright. So let us start with an update of the off-path exposure. Please. And Dan, I think you're the one
[00:05:06] Dan King: who has to give
[00:05:06] Chairperson: the slides? Thanks. Or no. The clicker has the slides.
[00:05:15] Luis M. Contreras: So hello, everyone. I I will provide an update a brief update on on the draft for off-path exposure of the TVR schedule. I couldn't provide in in the last I I I had a conflict, so I will basically summarize where we are. So sorry. As a recall of the the purpose of the draft, so, basically, it describes our long path mechanism so that we can expose to external consumers the the the scheduled topological changes. It can coexist with the on path, it's not I mean, both of them could be could be present. And, basically, it could help to offload the processing of changes from the network elements to external networks and external components, external modules, controllers, and and so on so far. So somehow it's matching the centralized solution described in the requirements draft. The draft was adopted in December 2023, and there had been a couple of maintenance versions, v01 and April v02. So the changes just for reflecting how the the draft has been evolving. There was a document cleanup. We removed some typos. There there are always typos, of course, and a number of appendices that were there providing additional information, complementary information. We need yet because of the evolution of the the the the working working group, The the applicability draft has been adopted, so we need to fix the reference that is is now in in version zero two. So this probably will, of course, will generate a new version. And, also, one of the changes was to remove all those appendices that were there. The appendices in in some one of the appendices identified potential gaps. Another one was referring to an open source implementation and so on so far. But particularly for the one identifying potential gaps, there was one of those gaps that has produced has basically motivated a new draft that I will present later today. There is the link in the presentation to the to the proper, let's say, mailing the mailing list. So, basically, commenting the different gaps that were documented there. So next steps. From the author's perspective, I we think I think the document is ready for progressing for the working group last call. Of course, as said, we need to update the the reference for the applicability draft. So now has has been adopted, so we need to add the adopted version. So and and if if it turns out okay with that, I will generate a version three with that change. But I would like also to take the opportunity of this presentation for asking for for any suggested change that the working group considered necessary for this. Otherwise, we'll be basically ready for for progressing from my purse my perspective. And that's all. Thank you.
[00:07:56] Chairperson: Oh, excellent. I thank you so much for that for that quick update. Any any questions? Alright. Thank you. Thank you so much. We'll we'll see you back in just a moment.
[00:08:08] Luis M. Contreras: Thank you. Thank you.
[00:08:10] Chairperson: So next up, we are going to talk about the status of the TVR requirements document.
[00:08:28] Dan King: Hi. Good morning, everyone. My name is Dan, one of the authors of the requirements document. Just a very quick summary of where we are. So, essentially, this was a document derived from the use cases right at the sort of the early days of TVR. We wanted to capture some of the key requirements. When we initially sort of published the first version of the documents, I think that was yeah. It says on the slide there. So September 2023, and, essentially, we finished the work sort of late last year and just spent the last couple of months stabilizing and addressing the various comments. The GitHub there on the previous slide, you can see sort of all the previous issues. The good news is there's no more open issues. Now we did have a maybe not significant, but we had a large number of comments coming from the various directorates because it sort of touches the document itself touches a variety of aspects of TVR around deployment and operational considerations, obviously, security as well. There was a lot of interest around the different use cases and environments that you might use, TVR. There were several comments in terms of the use of conformance language. And, actually, we started the document using conformance language, and then we took it out. If you remember sort of
[00:09:51] Chairperson: Oh, Dan, I'm sorry to interrupt from it. We we are getting some comments from the remote presenters that they can't quite hear. So if you could maybe adjust the mic up a little bit. Yep. Thank you.
[00:10:00] Dan King: Okay. Sorry, guys. So we we did have a comment a couple of comments regarding the use of conformance language, so we had to sort of clean that up. And, also, there was another comment from one of the ADs around what should be sort of mandatory requirements, and are are all of these requirements mandatory or some are optional? And because of the nature of TVR and the fact that there are scenarios where you might use TVR for extraterrestrial type environments, like LEO and orbits, sort of sort of even moon type environments, and several sort of near term deployments in terms of things like campus networking and making more efficient use of energy in rural environments. Absolutely not. Not all of these requirements are mandatory. It's highly dependent on the scenario that you're deploying them. So we sort of clarified that. We published what we think is the final version of the document that entered the RFC editor's queue very recently. Oh, well, at least it's gone through the ISG now, and we'll sort of shortly enter the RFC editor's queue. We have also updated some of the references, so the informational and normative references just to sort of clarify that as well. And now that the document is stable, we have submitted the final version, and we also agreed with the RFC editor to be a guinea pig for the sort of GitHub pilot for publishing the document itself. Think that's it.
[00:12:07] Chairperson: No. Excellent. Glad to see the progress. Glad to see these things have been resolved, and looking forward to off 48 and another RFC. Great. Alright. Thank you so much. K. So so those are our status updates, and then our next presentation is going to be on the applicability of the tvr Yang data models.
[00:12:40] Leyuan Pan: Okay. Good morning, Arren. This is Leyuan from Huawei. I will introduce on behalf of my colleagues. Okay. So this charter was adopted as a working group document after IETF 119, and I will I would like to express my thanks for the review from Luis, Jin Wang, and Adrian during the adoption. And we also submitted zero one version which addresses the comments and suggestions during the adoption. So this page shows the overview introduction of this document. It first introduces its applicability of model, including the model and the model, and also the encoding of the model and also the applicability of management protocols for including the net net conf, rest conf, and call conf. And that's it. It introduces the applicability of time of synchronization, including the hardware based time of synchronization mechanisms, and software based time of synchronization mechanisms. And the enterprise considerations on their scheduled database, and the enterprise operator operation of considerations, including scheduled dissemination, scheduled execution, and scheduled scheduled recovery, and so on. And, finally, it also provides the security considerations. So in the version one, we first aid a new author, which is Jin Wang from China Mobile and welcome Jin Wang as a new author. And we also add a new section, early-aware mechanism. This is also contributed by. And we also move some informative references to normative references, and then we also corrected us corrected some mistakes in the adjacent calls. And then we also did some editorial and readability improvements. So for the detailed key updates, first change is the early-aware mechanism. This mechanism is used to identify the fault schedules before they are executed. It is suitable for scenarios of where it's significant changes for use pop for example, it can be used in the satellite network because each each satellite has a stable albeit another in the schedules will not change significantly. Okay. And the second opt k update k update is way more some info informative references to normative references, including the requirements and also some RCs that are used in this applicability document. And the last update is the IP addresses in the examples. Also, suggested by agent way, use the IP addresses from the documentation range and also switch some of the IP addresses to IPv six. So for the next steps, we also continue to improve the document and welcome for contributions and comments. And we also keep along with the requirements and the young data model draft. Just two drops is already on the RFC Editor's queue. And that's all. Thank you.
[00:16:51] Chairperson: Alright. I do have just one question, which is as we have just talked about the updates to the requirements document as it's gone through the editing process, do you see any additional impacts to the applicability document based on any final changes in requirements or the data model?
[00:17:10] Leyuan Pan: Yeah. Yes. I I think I found some updates, you know, to be you know, to be need to be done for the applicability draft. I will do this updates after this meeting. Okay. Yeah. Yeah.
[00:17:23] Chairperson: Thank you.
[00:17:24] Leyuan Pan: Thank you.
[00:17:25] Chairperson: Alright. Moving right along. Any other any other questions?
[00:17:31] Dan King: Yeah. That's good. In the queue. I will answer it.
[00:17:38] Chairperson: Okay. No worries.
[00:17:45] Dan King: So, Dan, again, given that you've got sort of JSON code, so I presume that there's maybe some potential for implementation examples. And at a previous IETF, we kind of talked about potentially some TVR extensions to Teraflow SDN, OSM. These are sort of Etsy open source orchestration projects. Be really keen to see if we can use some of your examples, talk to Lewis and others about you know, is is this maybe some interoperability that that we could demonstrate for some of this work as well? Don't want to impact the applicability document itself, but maybe this could be sort of a concurrent activity. So at the next IETF, maybe finish this work with a hackathon.
[00:18:38] Leyuan Pan: Yeah. I think that's our good suggestion. Yeah. Maybe we can talk with the delays. Yeah. K.
[00:18:47] Chairperson: Just to jump in on that, I think that's a a good idea. And just to make sure that it doesn't get lost, it should probably go to the mailing list as well. Alright. Any any other questions? Then as we we move on, then we move away from the the chartered, work of the working group to two personal drafts that are being brought up to address comments on, the other work to fill in some open gaps. So, Luis is back.
[00:19:18] Luis M. Contreras: Yes. Hello again. I I I will cover now the presentation of this new draft, our life cycle and status state extensions for TVR schedule your model. So it's a proposition for basically, yeah, introducing capabilities for managing the the schedules once the the schedules are defined. So the base the TVR schedule, your model, basically captures temporal validity. So the schedule is defined and then is secured in due time. But there could be situations where maybe it could be of interest to have the possibility of of changing that that behavior or suspending that that schedule or basically operate on top of of that schedule. So with operators, yeah. We could find situations where we need to activate, suspend, deprecate, replace, or roll back predefined TVR schedule. So we will go in this direction of proposing mechanisms for that, essentially. So the problem statement is is that there can be ambiguity when schedules are provisioned in advance, or there could be situations that change along the time before the schedule is secured and we need to refine, fix, or or change. We can maybe need to supersede the the schedule with a new version because there are, again, circumstances that force us to do so, can be temporarily suspended. Maybe the the schedule was conceived with some situation of the network in mind, but that situation has changed, and and we need basically to fix to or or to adapt to the situation where the the the at at the point in time where the schedule will be secured, could be overlapped with new schedules that have appeared because of other needs, or, basically, it could be invalidated because, may in some point in time, it's not not any longer necessary or valid that that schedule. So, basically, the point is to to need to a way to distinguish the finished schedules and actively enforce schedules with, yeah, some tools for for that. So the the proposition of the draft is to add an administrative life cycle attributes to the schedule. So the point is that the applicability is no longer only depending on the time defined for sec executing the schedule, but also for these administrative parameters or capabilities. This is conceived as an optional augmentation. So we acknowledge that not all the use cases will require this administrative life cycle where we there could be, like, the use cases like the the classical use case with the the interaction with the satellite network that probably does not require this administrative life cycle, but others could require the administrative life cycle, the energy efficiency, or other use cases, the maintenance on the network, and so on and so forth. So this is considered to be optional augmentation. Of course, the idea will be to keep compatibility with the base TVR schedule semantics or not change anything on that. So, basically, building on top with adding these administrative capabilities so that the essentially, the conditions for apply and schedule will be, of course, the temporal validity, so the time at which the the schedule is defined, but also the administrative state. So going a little bit into details about the administrative states, and this is an initial thought, of course. I mean, open to to any feedback suggestion and and and change, of course. We have defined four states, depending state where, basically, the schedule is provisioned but not yet active. So, basically, somehow administrative done, let's say. Then the state was defined the state defined as active where the the the schedule is basically enabled and considered for application. That would be doing an analogy with the current TVR model, would be basically the TVR model as defined today. Then the state has inactive where an active schedule has been administratively administratively disabled and then deprecated with the the schedule is no longer recommended for use or no basically, it's not needed anymore. So, yeah, so the idea would be to add administrative capabilities for basically governing these different states. Apart from the administrative way of of handling the the schedule, we identify that could be convenient, maybe consider additional control parameters, and and we add there the the version. So, basically, we could have different versions along the time of a schedule, so it will be good to track the version that is basically the latest one to be to be active or basic basically, to to have a track of the different versions. Priority in case that there is a potential conflict between different schedules so that we can, you know, basically play with the priorities or to to to select the one that should be applied in one point on time. Some somehow, the the possibility of having a timestamp to understand what is what was the the latest modification of the of the schedule. So, again, we can help this can help us to to track the the different versioning and and so and the origin. So who was the the one or who department or whatever that provision the schedule. So, again, this helps on the tracking of basically, help us to do the administrative work on on the schedule. So next steps, the idea, of course, will be because it's this zero zero version to collect feedback from the working group. If any of this is of interest, the administrative, let's say, call the parameters for the versioning and time stamping and so to assess if the working group is interested on this work. As said, it's considered as an optional augmentation, so probably not applicable for all the use cases, but will be use cases that will be benefited for having these administrative capabilities. And if if, yeah, somehow there is interest and so to keep working on on the draft, prepare new version for next ITF, and, of course, invite whoever could be interested on this to to join the effort and and basically to we are open to any suggestion, feedback, and anything that could come from the working group. And that's all. Thank you.
[00:25:18] Chairperson: So I'll I'll ask the question then, which is, do we believe that this kind of status is is useful work? And further, do we think that these kinds of statuses are general enough to standardize? Maybe ask it a as if if maybe ask it a slightly different way. Does anyone feel that this is not something that should be standardized? Okay. Alright. Just always good to ask while we are together unless, Tony, you have a comment?
[00:25:53] Dan King: We have one person.
[00:25:54] Chairperson: Oh, I'm sorry. Don.
[00:25:59] Don Fedyk: Hi. Don Fetek at Lab End Consulting. One question using TVR is how do you how do you you you you basically are creating a predicted future. And at some point, you have to go back with the reality and and and and, you know, see, like, maybe things have happened to the network that you didn't you didn't anticipate in the schedule. Do you capture any of that in in this document? Do you have
[00:26:30] Luis M. Contreras: a way to do that? Well, it's it's somehow described as a kind of possible use case or situation, but it essentially will be that. You know, that the when you predict something, there could be things happening between the point you are predicting and the point that the the schedules will be executed that can change your your. So it's described somehow in the in the document that in the model itself, basically, nothing special. I mean, basically, we we would play with the the state of the schedule and and so. Maybe not not you got referring to add some maybe some rationale for the change or whatever is not considered at at this point.
[00:27:08] Don Fedyk: Yeah. I mean, it's it's almost like at at a certain point, you need to validate your you know, is is is the network where I think it would be for the next schedule to go on and and Mhmm. You know, because it could drift. It could be I mean, I always view TVR as, like, the way I think it's gonna be, but when it actually hits the time period, it may not quite Yep. Beat what it what you think it would.
[00:27:36] Luis M. Contreras: That rationale is not now in the document. Maybe it's worth it to elaborate on that. Yeah. Yeah.
[00:27:42] Chairperson: And so just a a a follow-up question, Don. I I wanted to the the way I interpreted that is if we decide to move a schedule to inactive, we want to understand why, such as a reason code. So the network does not look like what we thought in the schedule, and therefore, we will make the schedule inactive, and we may wanna capture why we made it inactive.
[00:28:09] Don Fedyk: Well, yeah, just the inactive the the the process of going through that and and analyzing it, what we would do. I mean, maybe we still implement it, but we but it's inaccurate. Like you know? And then or you recompute your new schedules and, you know, future schedules are are are now deprecated. So just working through those examples when it's when it's not quite what you think it is.
[00:28:37] Chairperson: Sure. Thank you.
[00:28:38] Luis M. Contreras: And maybe referring the trigger of why we take some action, maybe. Yeah. Could be an a a change in the network or maybe could be a new need that requires a new schedule that they could be interested to work on. Fair enough.
[00:28:51] Participant: So I think if you have multiple schedules, that's conflicting. You get low schedules from different sources. You got management or configuration problem. I don't think priority is the right way to resolve it. In that case, the data model better be sending some sort of notification or error.
[00:29:19] Luis M. Contreras: Yeah. Maybe we could play with the origin as well. Yeah. Maybe I mean, the decision may be not only based on priority, but who originates the the schedule maybe could be also a a driver for the priorities prioritizing the the one. Yeah. Okay. Maybe we need to think more on that. Yeah. Yeah. Thank you.
[00:29:41] Lou Berger: Hi. Lou Berger. Two comments following up on the last comments. I actually think priority is a is a useful and interesting concept here. Because if you do have conflicting schedules for for multiple writers, what do you do? And this this allows you to do something. While if you didn't have it, you're just in an error condition. Now, of course, everyone's gonna say their highest priority, so it doesn't solve that problem. But it it it's at least an indication to a device that it can operate on. The other point is, if you don't mind going back a slide to Don's comment, you'll notice these are administrative states. I think he was talking about bringing in operational state and operational status. We have a long history of having admin status, which is different from operational status.
[00:30:31] Luis M. Contreras: Mhmm.
[00:30:31] Lou Berger: So you might have an admin down, which is different than operationally down. And I think he was talking more about operationally than trying to combine with admin status.
[00:30:40] Luis M. Contreras: Okay. Thanks, Lou. Yeah. Okay. I need to think on that because the analogy is the router and so where you have both both the states. I don't know how that could be applied here. Maybe the operational, it will be the the normal one. Yeah. I I need to think
[00:30:56] Lou Berger: on that. What the discussion got me thinking of is where does current fit into this? You know, is active this is administrative active. What about the schedule that's active now that's sort of current? So it it brings in a whole operational states, maybe container parallel to admin states.
[00:31:17] Luis M. Contreras: Okay. Thank you.
[00:31:26] Chairperson: Agreed. Alright. If no other questions, then we will run into the second presentation, which is also another extension for schedule. Yep.
[00:31:39] Luis M. Contreras: So in in this case, this this draft is more, let's say, speculative to to see if there could be some applicability of TVR for interconnection scenarios, be it in transit and and this kind of thing. So it's it's more, let's say, it's more prospecting, let's say, a potential way to to follow. So the idea here is that that basically, let me say that this somehow inspired on on two things. One operational issue that we have in Telefonica some time ago with on a hyperscaler taking decisions that basically complicated of or interconnection. And, also, this idea of the new idea of network of networks so that, basically, we can compose somehow dynam dynamically different interconnections, thinking on disasters and these kind of things. So the the that was the the inspiration, and and now we're going to the draft. So, basically, the the motivation will be these situations where we have changes on on peering in the relationship between the autonomous systems that that discover once those those changes has happened. So autonomous system a takes on decision and and along the time autonomous system b is basically perceiving that decision and basically not having time for reacting to that. Also, typical case of maintenance event events that in one autonomous system produce and and basically now or are basically communicated in the best case by mail or phone or or or so. So, basically, not automated way of communicating those changes. And some of the cases around the capacity changes in one autonomous systems and or traffic engineering adaptations once there are failures in the interconnection and so. There are existing mechanisms today, like, the that somehow supports on automation in the interconnection. One is the BGP graceful shutdown where one autonomous system anticipating in advance or notifies in advance to the another autonomous system that some links will be shut down. So allowing the other autonomous system to somehow to react or have some time for reaction. There is also the API that that is being progressing in grow working group that allows to with a with another API, so an off path mechanism to request new interconnection sessions and basically handle that interconnection sessions, but it's basically for the setup of the of the session. And there is always this operational coordination that is basically between humans where engineers from autonomous system a discuss and talk with other engineers in autonomous system b. But none of these mechanisms provide a generic way of advertising future routing relevant events. Of course, the the shutdown of interconnections also, but also the creation of new interconnections. So there is some space there that maybe TVR could help to to cover that gap. So use cases that are documented in the in the in the draft, I briefly commented before. So maintenance, bidding, traffic engineering optimization, energy awaiting interconnects, with a energy use case in TVR. Multi provider coordination that basically refers to a scenarios that one one enterprise has multi homing and maybe that that company wants to play with the that multi homing, so advertising in advance to the providers of transit, the different changes that the the the company could have. And, essentially, our transit adjustments, so in case of maintenance in the network failures and so so that we can anticipate changes in the routes to the other autonomous system. So in order to to satisfy those use cases, we cover or we propose on a schedule object for interconnection that would be slightly deferred to to the objects that are now in the TVR schedule. Basically, the type of event that we are dealing with, the peering, the multi homing, or whatever, the affected entity, the time interval. So, basically, the the the ranges in time that the these changes will be produced, the scope, and the just suggested action. And examples of affected entities could be BGP sessions, of course, in a in a in a peering typical classical peering session or or transition. Changes about prefixes or maybe that we advertise prefixes in in in in one interconnection, we will remove those prefixes and and start advertising them in another interconnection. Events on interconnection links are basically affecting a lot of a lot many BGP sessions and also a relationship between autonomous systems. So, basically, a prepend thing prevents of autonomous systems and and these kind of things. Or, also, even slightly changes in the BGP parameters, the preference, and so. So that would be basically the the scope of of this schedule. Regarding the information exchange models, we could basically find three ways of of interchanging the information. The off pathway that links with the off path exposure draft that I presented first, where basically the we will be we will be advertising these schedule changes through APIs or off off path mechanism. A non path mechanism that would require maybe extensions to BGP. And, of course, we'll use BGP and maybe could require extensions on on there. And maybe hybrid mode where basically some maybe the advertisement is done on off path, but they're enforced on path and and so on and so forth. So, basically, these are different alternatives that we need to explore and and and, yeah, maybe could even combine in this hybrid mode. So next steps for for this will be basically to to understand if there is interest in the working group for this. It it makes sense for the working group to work on on on this. As I at the beginning, it's more speculative. So, basically, prospecting if there could be interest here for developing this. So if so, keep working on that and and prepare a new version. And, of course, again, whatever suggestion, comment is more than welcome, and that's all from my side. Thank
[00:37:42] Chairperson: So with with chair hat on, my question is this is an informational document that would discuss essentially the applicability of this work to the interconnection scenario. I know in previous working groups, we said we didn't wanna have what would essentially become multiple applicability documents. Do you feel that this should be its own document, or do you feel that this is a section of the applicability document that we have adopted?
[00:38:11] Luis M. Contreras: I think maybe yes in the sense that probably from this effort, we could define needs in other working groups, maybe in Grow, maybe in in IVR. So, basically, it could help us to understand what could be the needs to be developed in other working groups. So maybe
[00:38:29] Chairperson: And and if it's not and if it's distinct, that that's fine too. But if we if we do feel this is applicability to interconnect, maybe then that that pulls that part in.
[00:38:38] Luis M. Contreras: Yeah. Okay.
[00:38:40] Chairperson: Don.
[00:38:45] Don Fedyk: Yeah. A couple questions. I guess because you've got multiple entities doing the schedules, how do they advertise and coordinate the schedules between them?
[00:38:58] Luis M. Contreras: The yep. Yeah. So not not not well, I I guess that will be in the similar way that we that's with BGP today. You know? In the in the when you advertise prefixes, you receive one autonomous system receives the the information through BGP from different sources and basically create their own view on on the Internet reachability. So here probably it would be the same thing. An autonomous system could receive different schedules from different autonomous systems and then compose their own view and and basically add based on that view. But it is our guessing I'm
[00:39:31] Don Fedyk: not a BGP expert, but I I I believe they don't always share the the information across there. So wouldn't this require more sharing than is it is typically done in a in a in a system? It almost seems like you need some something up above that can understand both areas and then coordinate the schedules. In in the interconnection scenarios, basically, every administrative domain is autonomous and and will take their
[00:40:01] Luis M. Contreras: own decisions. So that central entity, I I do not foresee that.
[00:40:07] Don Fedyk: Well, yeah, well, not maybe physically, but logically. Yeah.
[00:40:13] Rick Taylor: It's more of a local peering. Rick? Hi. Rick Taylor. Interesting you were saying about parallel work that's happening in other working groups. So there's work on this in the DTN working group where, again, scheduled contact windows and all that kind of stuff and and how different autonomous administrative domains peer and share that contact information. We'd like feedback on the document we're working on. It lifts a lot of the TVR Yang shapes anyway. It's a little bit independent. It's more of a reference point to you, Luis, to say, have a look at it. Tell us where we've gone wrong, and I need to go and do the same thing and grow as well because I think several groups are now converging on this. Okay. We can't just cram it into BGP, but that pairing concept with time variance is increasingly important. So I think this is good stuff.
[00:41:12] Luis M. Contreras: Thank you. Scott?
[00:41:15] Scott Burley: Hi. Scott Burley. It occurs to me thinking about this that that and maybe I've just missed it in the documentation that that the probability or likelihood or your confidence in in the occurrence of events in in in the schedule, both inside a a domain and and outside a domain, could be useful not so much in in directing traffic, but in directing workforce in in feedback to network management. That if if the schedule if if a portion of the schedule is low priority, maybe that means that somebody should be paying attention to what's going on at that time during the operation of the network at two in the morning or something where normally there wouldn't be. And and equally, if if something occurs that is not expected, something was there's a part of the schedule that's high priority and it doesn't occur. Well, that that unusual occurrence is something that might be useful to automatically report to network management so that they can focus investigative energy on on that and have it that be initiated automatically instead of having somebody, like, reading manually through logs for
[00:42:38] Luis M. Contreras: it. Mhmm. Thank you. I I didn't thought in in that view, but in that perspective, but yeah. It's so useful. Thank you.
[00:42:47] Chairperson: And, Eric?
[00:42:51] Gunter Van de Velde: I think in one of
[00:42:52] Eric: your previous slides, you were talking about introduce introducing a new, structure. Yes. Thank you. Is it possible to apply the TVR to to use the the TVR yang to augment something like the attachment circuits as a service
[00:43:08] Leyuan Pan: yang model?
[00:43:09] Eric: I'll I'll I'll defer to Lou for the So you mean to number.
[00:43:13] Luis M. Contreras: To augment the the current model with this additional information?
[00:43:16] Eric: Yeah. There's a attachment circuits as a service Oh. Yang that builds l two Uh-huh. VPNs, l three VPNs, and
[00:43:25] Leyuan Pan: it might
[00:43:25] Eric: be possible to apply the TVR stuff to that.
[00:43:29] Luis M. Contreras: Good point. I would think on that my short answer would be, yeah, maybe yes. The only dependency will be that all the thermal system refer to that that that No. Reasonable. Okay.
[00:43:44] Eric: Yeah. Looking looking to Lou for guidance. Yeah.
[00:43:46] Luis M. Contreras: Okay. Thank you. Thank you.
[00:43:48] Leyuan Pan: Yeah. Good.
[00:43:59] Gunter Van de Velde: Hello there, Gunter, the AD for this working group here. So so the way I look into it from you know? So your approach is from the angle of, you know, from the operational aspect between different ASs and communities and things like that. So have you checked with the upper you know, with the with the IDs from the operational area as such? Because they may have a place for this also. I'm not totally convinced yet that this fits within the DVR charter as such. Yeah? So that is definitely something I would like to to to verify if it is like you know, if this is the right place or not. So for that, please check with the IDs there also.
[00:44:48] Luis M. Contreras: Okay. Thank you. No. I I didn't check, of course, yet because it's it's first version. But yeah. And even I as I said, probably this we progress this. This could derive working you know, working groups and probably, yeah, more ops working groups. Yes.
[00:45:06] Gunter Van de Velde: Yeah. Because, like, you know, what what was mentioned also about one of the priors, you know, people actually speaking on the mic here is a lot of this seems to, you know, to be related with BGP and having different operators speak planning to each other over future things that may or may not happen, that does not always work incredibly well. Thank you.
[00:45:34] Chairperson: Alright. If there are no other questions, I would simply say thank you for both of these. And one other comment on the on the prior presentation, it was marked as informational but normative in content. If you do an update to it, it probably shouldn't be information.
[00:45:52] Luis M. Contreras: Thank you. Thank you so much.
[00:45:56] Chairperson: Right. So at this point, we've gone through the updates of our chartered work and also two new pieces of work, and we now have a little over ten minutes of open mic if there is anything else we want to discuss while we are here together. The alternative is that we flag our schedule as inactive, and we we end the meeting a little bit early. So going once? One else? Twice? Alright. Thank you so much for joining us at IETF 120, and we will see you through the week and at TVR in IETF 121. Thank you so much. Yes. Thank you. I'm I will I will shoot you a Slack or or something, and and we'll see if we can get a little group together on Friday.
[00:47:03] Luis M. Contreras: Sounds good?