Please help capture comments/discussion in-line below # IETF 115 TVR BoF Minutes {#ietf-115-tvr-bof-minutes} Version: Nov 10, 2022 ## Thursday, November 10, 2022 {#thursday-november-10-2022} 09:30 - 11:30 Thursday Session I (London local time, UTC+0) Materials: https://datatracker.ietf.org/meeting/115/session/tvr Note taking: https://notes.ietf.org/notes-ietf-115-tvr Meetecho: https://meetings.conf.meetecho.com/ietf115/?group=tvr&short=tvr&item=1 Audio stream: https://mp3.conf.meetecho.com/ietf115/tvr/1.m3u Zuilip: https://zulip.ietf.org/#narrow/stream/tvr WG ICS: https://datatracker.ietf.org/meeting/115/sessions/tvr.ics Session ICS: https://datatracker.ietf.org/meeting/115/session/30001.ics * Chairs: Lou Berger, Russ White * Secretary: Yingzhen Qu * Note takers: Adrian Farrel, Daniel King, Russ White, Eve Schooler, .... Available post session: Recording: http://www.meetecho.com/ietf115/recordings#TVR Jabber log: http://jabber.ietf.org/logs/tvr ## Slot# Start Duration Information {#slot-start-duration--information} ## 1) 09:30 10min Session Intro {#1-0930-10min------session-intro} ### Presenter: Chairs and AD {#presenter-chairs-and-ad} * Lou Berger: Note well. The agenda is different from what was posted a couple of days ago. * Lou Berger: Agenda timings are deliberately approximate ## 2) 09:40 ~15min Time Variant Routing Problem Statement {#2-0940-15min--time-variant-routing-problem-statement} ### Presenter: Rick Taylor {#presenter-rick-taylor} ### Draft: https://datatracker.ietf.org/doc/html/draft-taylor-tvr-prb-stmt-00 {#draft-httpsdatatrackerietforgdochtmldraft-taylor-tvr-prb-stmt-00} Start time - 9:36 * Kevin Fall: I worked on this 10 years ago. Internet routing has roots in 1958 publication from Ford Fulkerson and Dijkstra. The operations research community looks at the same problem space. Consider dynamic trans-shipment problem which is a similar set of problems, but solutions could be very different (e.g., could packets live in a buffer for a day in transit?) \*\*See: Constructing Maximal Dynamic Flows from Static Flows, Ford Fulkerson, https://pubsonline.informs.org/doi/abs/10.1287/opre.6.3.419 * Rick: First, existence of research is a good thing. Existing problems and solutions can inform us. For stable network in the internet, we're very familiar with it, and I'll talk about Manet later. Approaches like timetables for rail system can give us info. * Lou: We will have time at the end for Q/A but already we have eight people in the queue, so we will need to cap questions now to continue with the agenda. * Alex Clemm: Missing "what would you do with this information?" This is missing from the problem statement, better be explicit. * Rick: Fair. Quick answer is there is an opportunity if we know something is going to change, we can save time and network resources not getting things wrong or tracing faults. There are various use cases in IoT and Space(based networking) where we need to know about availability of links in advance. If we know something is going to change we can do the calculation ahead of time. * Tony Li: See mailing list. Are we covering dynamic topology? If not, the problem is quite straight-forward and we already have techniques dealing with links taking out. If a link is scheduled to come up, do we wait on liveness information to propagate to declare the link up. * Rick: If a schedule is going to be up, it would be a mistake to believe it. We always have to deal with failures in routing protocols. The "dynamic question" is a scoping question: I think start simple, but don't discount more complex situations * Lou: I think you already have this dynamic topology in scope on your slides (on slide #2, for example, peers changing or new links coming up T2 and T4.) * Rick: MANET "dynamic" can be very chaotic, so I tend to avoid the word, but "yes" in this scope if the links come down and up and nodes move around if it has corresponding predictability, we *are* talking about dynamic topology \*Russ (chat): this does cover dynamic topology cases; service reachability is the issue, not the specific path to reach that service * Erik Kline: like bus or train schedule, it's related to drive directions, special and different from today's routing and deserves a space to consider it * Julian Lucek: This BoF is timely for me. I recently came across a n/w with remote sites with a single fiber and a fiber switch on the access so that the site border router can be changed. * Rick: This is another example of the same kind of use case. It's reducing the data transmitting capability when something happens. if you know what to expect, you can be ready for it. I don't know if this isn't solved, but I don't think it is. \*Scott Johnson (chat): The concept of neighbor discovery needs to be included * Andrew Alston: I live in part of the world where power is not always stable. I can do fast reroute, but if I can know the schedule for power outages, how I react can depend on what I know about the cause and duration of the outage. So knowing may allow planned rebalancing which is importantly different from people in a remote NOC who might just think it is a temporary router failure. Additionally, learning algorithms may be able to make good use of this info and act accordingly. I see lots of possibilities and am extremely interested in this. * Rick: Don't get caught up on how to create schedules. But once we have a schedule and work out how to get it around the network we can do a lot. * Dirk Trossen: Perhaps there are different variants to consider. Other dynamic conditions under which you might want to change your routing. * Rick: I take your point, but I don't want to boil oceans. I also don't want to get to ECA and network programming. I agree with your points, but I just want to focus on what is achievable in a reasonable scope. * Lou: Just to be clear it will come up later that other things can change, such as bandwidth, energy, etc. * Rick: we have use cases for that later. * Dirk: Yes, it could be driven by energy costs, and use contextual information that could be boiled down into the scheduling API. * Rick: completely agree. it comes down to whether we have a schedule, and whether we can define the schedule. * Edward Birrane (chat): There are use cases that include other factors that change, such as power, cost, etc. * Rick: Defer to later presentation * Stewart Bryant: When a node or link changes, there is transience. Can we minimize disruptive effects of micro loop changes (due to rate of FIB updates) * Rick: Yes, if we can plan for future outages, we can plan to work around microloops. we can pre-agree on topologies to avoid those microloops. * Stewart: Not simple because of convergence of FIBs. Thus we need a process of changing topologies * Rick: Yes. This should be in scope. Can we describe "in general terms" how to do this? Then we can move the solutions to the (e.g.) IGP working groups * Stewart: these techniques were documented in the routing area years ago in RTGWG. * Russ (chat): this also applies to higher performance situations, where the application can know about scheduled events, hence adjusting timers to anticipated temporary changes in delay/jitter * Zulip/Jabber * Dirk Trossen: This being called 'time variant routing', let me ask a maybe silly question: is time * the only predictable dimension of variance in routing we may care about? Or may we care about other predictable changes to routing (e.g., based on locality)? * Lou Berger:@dirk at least some is in scope, think a fair question to ask at mic * Abdussalam Baryun:good question * Russ White:this also causes us to ask some other questions, like "how do I know about resources that are not currently not on line?" ... * Scott Johnson:dynamic routing is rather critical, from the input we have gotten from the community. * Adam Wiethuechter: Knowing if a resource that is far better for me t solve a problem is offline, but I know will return at a set time, I now must weigh if it is worth waiting for said resource or spending additional resources that are ill-fit to the problem I am currently facing * Russ White: this should deal with the dynamic topology ... the key is reachability to a resources across any path ... the path might change * Jorge Amodio: of course you can have failures but think about a satellite that passes over a given point every x number of time units * Daniel King: Good question. Do we need to consider a reliability, or probability, of the link being available at a scheduled time. * Scott Johnson:the concept of neighbour discovery needs to be including in this thinking as well, adding to the definition of dynamic. * Lou Berger: also change in other metrics, e.g., delay, loss probability, available data rate * Joel Halpern: The presenter just alluded to a question that we should be clear on. What time scale and precision of timing are we concerned with? He said "not nanoseconds". * Jorge Amodio: I believe it is way longer, perhaps days * Tony Li: If we agree that we want liveness, then 'not nanoseconds' is a given. * Daniel King: Yes, at least for LEO, UAV, we are considering minutes, hours, days. * Jorge Amodio: deep space as well * Daniel King: Months :-) * Jorge Amodio: SSI - Solar System Internet is slowly evolving, and we don't have yet a routing solution QUEUE CLOSED ## 3) 09:55 ~15min Use Cases {#3-0955-15min--use-cases} ### Presenter: Ed Birrane {#presenter-ed-birrane} ### Draft: https://datatracker.ietf.org/doc/html/draft-birrane-tvr-use-cases-00 {#draft-httpsdatatrackerietforgdochtmldraft-birrane-tvr-use-cases-00} Start time - 10:05 All questions deferred to item 3.3. * Zulip/Jabber ## 3.1) 10:00 ~15min Topology Management Challenges for Satellite Constellations {#31-1000-15min-topology-management-challenges-for-satellite-constellations} ### Presenter: Dan King {#presenter--dan-king} Start time - 10:21 All questions deferred to item 3.3, * Zulip/Jabber ## 3.2) 10:35 ~15min Carbon-Aware Networking Use Case {#32-1035-15min---carbon-aware-networking-use-case} ### Presenter: Eve Schooler {#presenter-eve-schooler} Start time - 10:33 All questions deferred to item 3.3. * Zulip/Jabber ## 3.3) Discussion of all three use cases presentations. {#33-discussion-of-all-three-use-cases-presentations} * AB: This is interesting and I'm willing to help. Proposed solution is not clear. Are we only changing the metrics or also the algorithms? We should also be clear on the conditions and stability of routing mechanisms. * Russ: We need to work out the use cases and models and then push these to the protocol working groups to work out what to do with them. We're trying to get to the point of solid use cases before dealing with solutions. * Dean Bogdanovic: Seen this at several recent IETF meetings. It is a big multi-dimensional problem. IETF might not have enough expertise to handle all dimensions. IRTF might be a better place until we understand the problem. * Lou: One challenge is "What does the routing area do?" Transport area had a side meeting, it's a big problem, so other Areas may need to work * Dean: It's a big problem, you have to define a policy, and then how to enforce this on the network * Dan: I disagree. This is not an IRTF problem. This is an engineering problem, and I see this being applied to existing infrastructure. * Dan: I see some commonality with these use cases and we have a current draft in the routing area; perhaps we can work together. * Mallory Knodel: I want to support this work. I think this has to be mainstream in a lot of the IETF, not just one place. In IRTF, we talked about how to reduce footprints, and sometimes the source of the electricity might also be a problem. There needs to be a general approach to reduction and minimization. * Lars Eggert: A principle we might use to narrow the scope. Can we limit to scope where changes to topology happen in a percentage of the RTT (so as not to overlap with similar function in transport) * Joel Halpern (relayed by Lou): What is the scale of timing we are talking about? ## 4) 10:55 ~15min Technology Gaps / Potential WG Topics {#4-1055------15min-----technology-gaps--potential-wg-topics} ### Presenter: Rick Taylor {#presenter-rick-taylor-1} Start time - 10:55 ## 6) 11:10 10min Open Discussion {#6-1110-10min-open-discussion} Based on the chat dialog, there is some difference of opinion on whether multicast and multi-path should be in vs out of scope. Start time - 11:11 * Kevin Fall: Lars reminded me a bit what happened, when DTN was a research group, we intentionally confused the acronym, D could delay, disruption or whatever, so the research would be in scope. What is the scoping defintion? Maybe to refine that, we can ask what is the covering? There are use cases, the space example also have overlap with underwater that are 5-times in order of magnitude. If your going to separate the store and forward, what is the connection to scheduling, knowing what paths, places and storage exists also important. properties of nodes along the path are also important, reliable or not, whether it's in a geography we can trust etc. that might be out of scope. The richness, we have discussed over years. * Brian Sipos: One thing we haven't talked about is on the management side there are things like NetConf which has running datastore vs. candidate datastore, but you can't schedule them, you only get one of them. When multi-tenancy comes into play, don't want a separate mgnt org to handle the scheduling and time rates for every time something changes. * Lou: At a WG earlier this week, someone pointed out there are building blocks to creating schedules. We definitely want to reuse where possible. * Toerless Eckert: One question is how to get from here to running code that would be useful. If one way to get there is to build a system using mainly existing IETF components, this would be good to show as the goal. We have examples of WGs how this has been done (cf ANIMA). If this is more fishing, with a big system design then we have experience with SIGs (see MOPS and IOTops). Just as a process recommendation. * Lou: Thanks for that, after the meeting we will review and see what will happen. We met with Alvaro and what you see is potential work items we already identified, we need to see if these are relevant. We need to identify items that are deliverable and actionable. * Toerless: as a contributor I'd like to see how these components can work together. * Rick: I see that. The result should be these are relevant pieces and how they work together. * Jari Arkko: I like this. Cool. We should do it. Interesting use cases. Caveat: there may be chicken and egg... Schedule creation is out of scope is good as local optimization might not be for other cases. Energy is an interesting and complicated case, you have various aspects of power and techniques to consider, such as implementation where a node could be in a low-powered state, so you can reduce energy, or you can be totally off, and then you dont have to tell anything to the network. Some use cases are clear, like satellite where you turn completely off and continue to rotate around the earth, while some others might be more complicated. My suggestion is to focus on the easily defined use cases. * Adrian Farrel: Want to agree and disagree with Lars. I want to agree that there is part of this problem space is the time variant provision and awareness of service points and direction of Transport paths and I want to disagree because I Think this is about packet routing inside the network. Transport is an overlay over packet routing. Both have a part to play, so we need to do an analysis of both problems, and work out which ones we are solving and then work out where to solve them, and not just use the existence of one problem to say well you can't talk about the other problem * Dean Bogdanovic: It's an interesting problem, but don't make it a kitchen sink for all problems. Let's work out what we can solve. If we try to add all possible things in, we will get lost. * Rick: agree. One we can't schedule the whole internet, second we can only achieve what's achievable. * Colin Perkins: (no hats) There has been a lot of previous work and research. Reasonable to explore whether we can do a focused work. Echo Lars, think about time variance and link latency to scope the problem. Will also tell you whether you need to solve transport problems. Space and underwater networks have radically different properties, make sure you have the right subject experts involved. QUEUE CLOSED # ============================ {: id=""} ## Polls - Room had 134 people, according to MeetEcho. {#polls---room-had-134-people-according-to-meetecho} 1. Are you interested in seeing this problem being worked on in the IETF? (Raise hand for yes) Raise hand : 74 / 94% Don't raise hand : 5 / 6% More than half the room have raised hands for Yes. 2. Do you think a new Routing WG is needed to work this problem? (Raise hand for yes) \[Note: may be other WGs in other Areas\] Raise hand : 64 / 74% Don't raise hand : 22 / 26% Good percentage of folks responding, with majority saying yes. Some question about whether it should be in Routing, or in multiple groups. 3. Are you willing to contribute as an author or reviewer if a new WG is formed? (Raise hand for yes) Raise hand : 65 /86% Don't raise hand : 11 /14% ## 7) 11:20 10min Wrap Up / Summary / Next Steps {#7-1120-10min-wrap-up--summary--next-steps} ### Presenter: (Chairs, AD, IAB Shepherd) {#presenter-chairs-ad-iab-shepherd} * Andrew Alston : These are not votes, but just indication. I read this as "maybe this should be in routing, but whatever, I am willing to work on it" * Lou: I think that's reasonable. There might be more WGs. * Alvaro Retana (responsible AD) : Is there interest? Yes, people are here and the polls. People think there are problems and are interested to solve and contribute. We need to scope down the problem. This was a non-WG forming BoF to gather use cases and area of interested. The potential area is very wide and we need to scope it down to things we can work on and are clear. Need to discuss this on mailing list. What are the (small number of deliverables) and move forward. * Mallory Knodel (AD shepherd) : Where else is this work happening? Is some of this ITU-related. Need to gather this info. great to see all the interests and that's a strong sign. * Lou : please continue this energy on the list. We will work with IESG and IAB on next steps. Thank you for this successful session. Meeting ended - 11.33 ==> There is very substantial discussion in the Zulip chat alongside this meeting. Readers of these minutes should also read that chat. ## Adjourn 11:30 {#adjourn-1130}