Skip to main content

Minutes IETF115: tvr: Thu 09:30

Meeting Minutes Time-Variant Routing (tvr) WG
Date and time 2022-11-10 09:30
Title Minutes IETF115: tvr: Thu 09:30
State Active
Other versions markdown
Last updated 2022-11-28


Please help capture comments/discussion in-line below

IETF 115 TVR BoF Minutes

Version: Nov 10, 2022

Thursday, November 10, 2022

09:30 - 11:30 Thursday Session I (London local time, UTC+0)
Note taking:
Audio stream:
Session ICS:

  • Chairs: Lou Berger, Russ White
  • Secretary: Yingzhen Qu
  • Note takers: Adrian Farrel, Daniel King, Russ White, Eve Schooler,

Available post session:
Jabber log:

Slot# Start Duration Information

1) 09:30 10min Session Intro

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

Presenter: Rick Taylor


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

  • 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

  • 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

  • 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
  • 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
    • 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
    • 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


3) 09:55 ~15min Use Cases

Presenter: Ed Birrane


Start time - 10:05
All questions deferred to item 3.3.

  • Zulip/Jabber

3.1) 10:00 ~15min Topology Management Challenges for Satellite Constellations

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

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.

  • 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

Presenter: Rick Taylor

Start time - 10:55

6) 11:10 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
  • 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.



{: id=""}

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

  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

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