[{"author": "Adrian Farrel", "text": "

Morning, Kevin. Thanks for showing up at short notice.

", "time": "2022-11-10T09:31:05Z"}, {"author": "Jorge Amodio", "text": "

date on the slides is wrong

", "time": "2022-11-10T09:31:15Z"}, {"author": "Kevin Shortt", "text": "

Thanks for having me.

", "time": "2022-11-10T09:31:18Z"}, {"author": "Andrew Alston", "text": "

Morning all :)

", "time": "2022-11-10T09:36:04Z"}, {"author": "Lou Berger", "text": "

Good morning, please join us for joint minute taking at: https://notes.ietf.org/notes-ietf-115-tvr?edit

", "time": "2022-11-10T09:37:46Z"}, {"author": "Qiangzhou Gao", "text": "

Morning all :)

", "time": "2022-11-10T09:39:29Z"}, {"author": "Abdussalam Baryun", "text": "

good morning

", "time": "2022-11-10T09:44:07Z"}, {"author": "Jorge Amodio", "text": "

In the past we didn't have routing flying in space :-)

", "time": "2022-11-10T09:45:23Z"}, {"author": "Wes Hardaker", "text": "

@chairs I'd suggest cutting the queue at this point to get through the rest of the material

", "time": "2022-11-10T09:45:41Z"}, {"author": "Lou Berger", "text": "

@wes thanks - we have 25 minutes for discussion - we can take 10 minutes here

", "time": "2022-11-10T09:46:24Z"}, {"author": "Dirk Trossen", "text": "

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)?

", "time": "2022-11-10T09:47:25Z"}, {"author": "Lou Berger", "text": "

@dirk at least some is in scope, think a fair question to ask at mic

", "time": "2022-11-10T09:48:13Z"}, {"author": "Abdussalam Baryun", "text": "

good question

", "time": "2022-11-10T09:48:31Z"}, {"author": "Russ White", "text": "

this also causes us to ask some other questions, like \"how do I know about resources that are not currently not on line?\" ...

", "time": "2022-11-10T09:49:25Z"}, {"author": "Scott Johnson", "text": "

dynamic routing is rather critical, from the input we have gotten from the community.

", "time": "2022-11-10T09:50:20Z"}, {"author": "Adam Wiethuechter", "text": "

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

", "time": "2022-11-10T09:51:35Z"}, {"author": "Russ White", "text": "

this should deal with the dynamic topology ... the key is reachability to a resources across any path ... the path might change

", "time": "2022-11-10T09:52:07Z"}, {"author": "Lou Berger", "text": "

@tony was that the question

", "time": "2022-11-10T09:52:28Z"}, {"author": "Jorge Amodio", "text": "

of course you can have failures but think about a satellite that passes over a given point every x number of time units

", "time": "2022-11-10T09:52:45Z"}, {"author": "Daniel King", "text": "

@Dirk - Good question. Do we need to consider a reliability, or probability, of the link being available at a scheduled time.

", "time": "2022-11-10T09:52:56Z"}, {"author": "Scott Johnson", "text": "

the concept of neighbor discovery needs to be including in this thinking as well, adding to the definition of dynamic.

", "time": "2022-11-10T09:53:17Z"}, {"author": "Lou Berger", "text": "

also change in other metrics, e.g., delay, loss probabiliy, available data rate

", "time": "2022-11-10T09:53:24Z"}, {"author": "Joel Halpern", "text": "

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\".

", "time": "2022-11-10T09:53:48Z"}, {"author": "Jorge Amodio", "text": "

I believe it is way longer, perhaps days

", "time": "2022-11-10T09:54:23Z"}, {"author": "Tony Li", "text": "

If we agree that we want liveness, then 'not nanoseconds' is a given.

", "time": "2022-11-10T09:54:39Z"}, {"author": "Daniel King", "text": "

Yes, at least for LEO, UAV, we are considering minutes, hours, days.

", "time": "2022-11-10T09:54:47Z"}, {"author": "Jorge Amodio", "text": "

deep space as well

", "time": "2022-11-10T09:55:02Z"}, {"author": "Daniel King", "text": "

Months :-)

", "time": "2022-11-10T09:55:13Z"}, {"author": "Jorge Amodio", "text": "

SSI - Solar System Internet is slowly evolving, and we don't have yet a routing solution

", "time": "2022-11-10T09:55:59Z"}, {"author": "Daniel King", "text": "

Folks, we are trying to reflect some of the chat questions and responses in the minutes. Feel free to visit edit/add your points.

", "time": "2022-11-10T09:56:07Z"}, {"author": "Daniel King", "text": "

https://notes.ietf.org/notes-ietf-115-tvr?edit

", "time": "2022-11-10T09:56:19Z"}, {"author": "Scott Johnson", "text": "

this gentleman needs solar panels and batteries :)

", "time": "2022-11-10T09:56:37Z"}, {"author": "Jorge Amodio", "text": "

:thumbsup:

", "time": "2022-11-10T09:56:56Z"}, {"author": "Joel Halpern", "text": "

@Scott Johnson, no actually he has a large backup power plant. But the large scale power outages affect things around him.'

", "time": "2022-11-10T09:57:37Z"}, {"author": "Jorge Amodio", "text": "

I think when we go to use cases this may get more clear

", "time": "2022-11-10T09:58:26Z"}, {"author": "Daniel King", "text": "

The CCAMP/PCE veterans might remember the concept of a VNT - Virtual Network Topology - that we discussed for setting up multi-layer networks, this feels like a scheduled VNT.

", "time": "2022-11-10T09:59:03Z"}, {"author": "Scott Johnson", "text": "

@Joel Halpern I understand. I am presently in the middle of a hurricane. I deployed my AS because other peoples networks kept failing around me due to such events :)

", "time": "2022-11-10T09:59:29Z"}, {"author": "Edward Birrane", "text": "

There are uses cases for reacting to conditions that change over time (peak power costs, data caps, etc...)

", "time": "2022-11-10T10:00:22Z"}, {"author": "Scott Johnson", "text": "

The multi-homed redundancy use case.

", "time": "2022-11-10T10:00:28Z"}, {"author": "Scott Johnson", "text": "

A great many use cases, Ed. I agree completely.

", "time": "2022-11-10T10:00:53Z"}, {"author": "Scott Johnson", "text": "

95th% billing, for example.

", "time": "2022-11-10T10:01:27Z"}, {"author": "Abdussalam Baryun", "text": "

it is good to have schedule yes I agree

", "time": "2022-11-10T10:02:17Z"}, {"author": "Abdussalam Baryun", "text": "

It is interesting WG use cases

", "time": "2022-11-10T10:02:49Z"}, {"author": "Dhruv Dhody", "text": "

@Daniel King Also RFC 8413 if we consider TE

", "time": "2022-11-10T10:02:52Z"}, {"author": "Scott Johnson", "text": "

What happens when the schedule changes but that is not possible to notify the nodes in time to make a change useful?

", "time": "2022-11-10T10:02:58Z"}, {"author": "Scott Johnson", "text": "

Propagation latency being the problem.

", "time": "2022-11-10T10:03:40Z"}, {"author": "Daniel King", "text": "

Would a scheduled topology only consider network metrics, what about say energy cost ($)?

", "time": "2022-11-10T10:04:22Z"}, {"author": "Russ White", "text": "

to the point about microloops ... this also applies to bgp hunt reduction as well as microloops in link-state protocols ... scheduling would help us reduce the effects of these things because we could invoke the proper techniques to make convergence less disruptive

", "time": "2022-11-10T10:06:33Z"}, {"author": "Russ White", "text": "

another point ... if an application knows about a change that is coming, it can adjust its timers to compensate for the future jitter without changing all its timers permanently ... this could help performance, even in higher performance networks

", "time": "2022-11-10T10:07:35Z"}, {"author": "Tony Li", "text": "

Why the topology changes is pretty much irrelevant.

", "time": "2022-11-10T10:07:43Z"}, {"author": "Russ White", "text": "

wouldn't know link x is going to go down in y seconds allow devices to precompute the correct alternate path, and then use something like ordered fib to change the forwarding in the correct order to stop microloops from actually looping traffic? I think this is what Stewart is getting at?

", "time": "2022-11-10T10:09:21Z"}, {"author": "Tony Li", "text": "

Yes, of course.

", "time": "2022-11-10T10:09:49Z"}, {"author": "Lou Berger", "text": "

@dhruv - as you might guess - I'd like to see TE considered as in scope

", "time": "2022-11-10T10:11:10Z"}, {"author": "Dirk Trossen", "text": "

Relating to my comment at the mic on having suitable API to the scheduling (system) may also allow for using the information for other network functions. For instance, access authorization is a key aspect when attaching to a new network domain, pre-authorizing based on schedule information would reduce the effective downtime and thus facilitate smoother reconnection (handover).

", "time": "2022-11-10T10:12:12Z"}, {"author": "Lou Berger", "text": "

@tony agree, but it gets interesting when schedule support future adjacency options, e.g., @T4 can peer with nodes c or d, but not both

", "time": "2022-11-10T10:12:47Z"}, {"author": "Rick Taylor", "text": "

@Dirk - I completely agree that having future network change information available from the lower layers would allow very interesting upper-layer behaviour

", "time": "2022-11-10T10:13:17Z"}, {"author": "Tony Li", "text": "

@Lou Berger Is topology planning in scope? That becomes MUCH harder.

", "time": "2022-11-10T10:13:37Z"}, {"author": "Daniel King", "text": "

Nanosat and microsats, have finite power that needs to be considered so that links can be scheduled between (solar) power regeneration. RF and FSO interfaces differ in power consumption and BW capabilities. You also have a choice to continue a path in space via ISL, or bounce along earth ground stations.

", "time": "2022-11-10T10:14:02Z"}, {"author": "Lou Berger", "text": "

that's part of what we need to decide

", "time": "2022-11-10T10:14:04Z"}, {"author": "Lou Berger", "text": "

BTW completely agree - we've been heare before with virtual topologies

", "time": "2022-11-10T10:14:30Z"}, {"author": "Tony Li", "text": "

That sounds like an offline optimization problem, IMHO.

", "time": "2022-11-10T10:14:46Z"}, {"author": "Lou Berger", "text": "

That's a fair approach/ Part of the purpose of this meeting is to decide scope

", "time": "2022-11-10T10:15:29Z"}, {"author": "Lou Berger", "text": "

or at least discuss and get some sense of where interests lie

", "time": "2022-11-10T10:16:02Z"}, {"author": "Jorge Amodio", "text": "

:point_up_2:

", "time": "2022-11-10T10:16:27Z"}, {"author": "Russ White", "text": "

It could be that we end up deciding there are problems here, but they cannot be solved through \"traditional\" routing ... so offline might be the only real option

", "time": "2022-11-10T10:16:27Z"}, {"author": "Dirk Trossen", "text": "

@Rick Taylor this could position the 'time-variant' work on one on 'schedule system for network functions' (i.e., suitable APIs for pushing and pulling information), while 'routing' may be the key use case category in the WG, while the first aspect may well be applicable beyond. It avoids boiling the ocean but still make the work of wider use (for others).

", "time": "2022-11-10T10:16:34Z"}, {"author": "Scott Johnson", "text": "

what happens when there is a link error, and you want to unload stored data into an available commercial link in a dynamic fashion to deal with the unplanned link outage.

", "time": "2022-11-10T10:17:03Z"}, {"author": "Russ White", "text": "

Transport and unplanned outages would seem to be out of scope ... (?)

", "time": "2022-11-10T10:18:04Z"}, {"author": "Lou Berger", "text": "

transport as in transport protocol, e.g., tcp/quic?

", "time": "2022-11-10T10:18:30Z"}, {"author": "Jorge Amodio", "text": "

BP

", "time": "2022-11-10T10:18:46Z"}, {"author": "Adrian Farrel", "text": "

@russ Surely if you have a schedule for unplanned outages? Oh, wait!

", "time": "2022-11-10T10:18:52Z"}, {"author": "Jorge Amodio", "text": "

LTP

", "time": "2022-11-10T10:18:55Z"}, {"author": "Zheng Zhang", "text": "

Suppose that all the routers in the network decide to use a path schedule plan B, how to guarantee all the router's FIB work in the same time? If we download the RIB to FIB in advance? how to trigger the switchover when the primary link/node doesn't down?

", "time": "2022-11-10T10:19:00Z"}, {"author": "Scott Johnson", "text": "

in practical application, they must be in scope, it seems.

", "time": "2022-11-10T10:19:06Z"}, {"author": "Russ White", "text": "

@Zheng Zhang This is part of what Stewart was talking about, I think

", "time": "2022-11-10T10:19:42Z"}, {"author": "Tony Li", "text": "

@Zheng Zhang We wait for liveness to propagate and then switch FIBs at a predetermined time.

", "time": "2022-11-10T10:19:53Z"}, {"author": "Robert Raszuk", "text": "

To me this looks possibly as problem statement which could be addressed in two relatively simple ways ... a) add cron to IGP and BGP to grecefully dry some paths according to schedule b) Rename this WG BOF to RVR - Redundant Variant Routing meaning active-active accoring to schedule

", "time": "2022-11-10T10:19:56Z"}, {"author": "Scott Johnson", "text": "

do not assume it is only packets that are being routed. in many cases, packet delivery is already broken.

", "time": "2022-11-10T10:20:34Z"}, {"author": "Lou Berger", "text": "

all solutions are on the table ;-)

", "time": "2022-11-10T10:20:39Z"}, {"author": "Zheng Zhang", "text": "

@Tony Li OK. It needs specific processing in FIB, right?

", "time": "2022-11-10T10:20:55Z"}, {"author": "Adrian Farrel", "text": "

@Zheng and Russ. There are solutions and there are problems. The common problem is to avoid loops and drop-zones caused by mismatched FIBs. The solutions are many and established

", "time": "2022-11-10T10:20:58Z"}, {"author": "Scott Johnson", "text": "

in these cases, IGP and BGP already do not work.

", "time": "2022-11-10T10:21:05Z"}, {"author": "Tony Li", "text": "

@Scott Johnson If we do this right, we can change before packet delivery breaks.

", "time": "2022-11-10T10:21:07Z"}, {"author": "Kevin Shortt", "text": "

I'm trying to but I don't have access.

", "time": "2022-11-10T10:21:41Z"}, {"author": "Daniel King", "text": "

Predictable connectivity also applies to rural links in developing where power is finite and/or only available at specific (predictable) times.

", "time": "2022-11-10T10:21:44Z"}, {"author": "Scott Johnson", "text": "

howso, @Tony Li, when propagation delay exceeds timeouts?

", "time": "2022-11-10T10:22:15Z"}, {"author": "Kevin Shortt", "text": "

I'm having trouble getting my audio up.

", "time": "2022-11-10T10:22:18Z"}, {"author": "Tony Li", "text": "

@Adrian Farrel Are there other solutions available? A hard coordinated switch of FIBs would be doable.

", "time": "2022-11-10T10:22:25Z"}, {"author": "Kevin Shortt", "text": "

Will do!

", "time": "2022-11-10T10:22:55Z"}, {"author": "Adrian Farrel", "text": "

@Tony. Look at ATT's TDM network in 1995 :-)

", "time": "2022-11-10T10:23:05Z"}, {"author": "Jorge Amodio", "text": "

I think what we are trying to decide if it makes sense or not to work on this and if we need a new WG

", "time": "2022-11-10T10:23:21Z"}, {"author": "Adrian Farrel", "text": "

@Kevin, in Meetecho there is a microphone icon, you need to click it

", "time": "2022-11-10T10:23:30Z"}, {"author": "Lorenzo Miniero", "text": "

Yes, it's in the top left corner, in a box under your name

", "time": "2022-11-10T10:24:08Z"}, {"author": "Kevin Shortt", "text": "

Thanks everyone.

", "time": "2022-11-10T10:24:19Z"}, {"author": "Tony Li", "text": "

@Jorge Amodio Yes and yes. :-)

", "time": "2022-11-10T10:24:19Z"}, {"author": "Kevin Shortt", "text": "

The problem is I can't grant access to my microphone.

", "time": "2022-11-10T10:24:31Z"}, {"author": "Adrian Farrel", "text": "

Oh :-(

", "time": "2022-11-10T10:24:41Z"}, {"author": "Robert Raszuk", "text": "

@Kevin ... always happes to me .. Switch browser

", "time": "2022-11-10T10:24:48Z"}, {"author": "Scott Johnson", "text": "

@Tony Li I concur.

", "time": "2022-11-10T10:24:49Z"}, {"author": "Robert Raszuk", "text": "

https://support.google.com/chrome/answer/2693767?hl=en-GB&co=GENIE.Platform%3DDesktop

", "time": "2022-11-10T10:25:47Z"}, {"author": "Lorenzo Miniero", "text": "

Maybe you declined access to the mic during the preflight when you joined? Browsers tend to remember this setting, so you may have to check the settings and remove the refusal. Changing browser as suggested would prompt it again there

", "time": "2022-11-10T10:25:52Z"}, {"author": "Jorge Amodio", "text": "

TVR could be also for terrestrial apps, ie IoT

", "time": "2022-11-10T10:29:36Z"}, {"author": "Zheng Zhang", "text": "

The usecases are reasonable. But it's really hard to solve it. I am not saying I am negative with it. I just want to say, there are many challanges in it. such as how to calculate and download a path which is not existed (suppose the link is down and only up in schedule time)

", "time": "2022-11-10T10:30:56Z"}, {"author": "Russ White", "text": "

@Zheng Zhang the problem of how to know what should/might exist versus what does exist is a real problem ...

", "time": "2022-11-10T10:31:47Z"}, {"author": "Dirk Trossen", "text": "

@Zheng Zhang isn't the point of a schedule to know of the link availability in advance, possibly needing to still check liveness at the time of expected availability? Point of having an API to the schedule is for announcing possible link availability upfront.

", "time": "2022-11-10T10:33:03Z"}, {"author": "Adrian Farrel", "text": "

I think that a good chunk of time needs to be spent collecting these hard problems even before we start looking at the solution space

", "time": "2022-11-10T10:33:07Z"}, {"author": "Adam Wiethuechter", "text": "

+1 @Adrian Farrel

", "time": "2022-11-10T10:34:12Z"}, {"author": "Zheng Zhang", "text": "

@Russ White Understood

", "time": "2022-11-10T10:34:13Z"}, {"author": "Tony Li", "text": "

@Zheng Zhang The implementation is certainly tricky. Conceptually, however it's straightforward.

", "time": "2022-11-10T10:34:17Z"}, {"author": "Lou Berger", "text": "

@adrian completely agree and think it will be an important wg topic if there is sufficient support to form a wg

", "time": "2022-11-10T10:34:28Z"}, {"author": "Jorge Amodio", "text": "

@zheng Zhang that is why we are trying to figure if a new WG is needed to focus on this

", "time": "2022-11-10T10:34:39Z"}, {"author": "Zheng Zhang", "text": "

@Dirk Trossen The worst case is that, how to calculate a path which is not in the database. Maybe adviertise a non-existed route in advance?

", "time": "2022-11-10T10:35:31Z"}, {"author": "Tony Li", "text": "

Instead of SPF on the LSDB it's SPF on LSDB + link.

", "time": "2022-11-10T10:36:11Z"}, {"author": "Abdussalam Baryun", "text": "

yes we some times do

", "time": "2022-11-10T10:36:15Z"}, {"author": "Abdussalam Baryun", "text": "

echo

", "time": "2022-11-10T10:36:23Z"}, {"author": "Abdussalam Baryun", "text": "

hear echo

", "time": "2022-11-10T10:36:36Z"}, {"author": "Lou Berger", "text": "

+1 lots of opportunities for precalculation

", "time": "2022-11-10T10:36:38Z"}, {"author": "Zheng Zhang", "text": "

@Jorge Amodio Yes. I think this work is interesting but we will face/solve may problems :-)

", "time": "2022-11-10T10:36:47Z"}, {"author": "Lou Berger", "text": "

@meetecho can you help with the echo

", "time": "2022-11-10T10:36:52Z"}, {"author": "Lorenzo Miniero", "text": "

Working on it

", "time": "2022-11-10T10:36:57Z"}, {"author": "Jorge Amodio", "text": "

I believe we need to save these discussion for a WG if we need one

", "time": "2022-11-10T10:37:02Z"}, {"author": "Lou Berger", "text": "

thanks!

", "time": "2022-11-10T10:37:04Z"}, {"author": "Abdussalam Baryun", "text": "

thanks

", "time": "2022-11-10T10:37:04Z"}, {"author": "Jorge Amodio", "text": "

focus on the \"bof\"

", "time": "2022-11-10T10:37:26Z"}, {"author": "Lou Berger", "text": "

exactly.

", "time": "2022-11-10T10:38:06Z"}, {"author": "Tony Li", "text": "

I'll be contrarian and disagree: we can do all of this without enumerating all of the reasons why the topology is changing. We just operate at the topological level of abstraction.

", "time": "2022-11-10T10:38:15Z"}, {"author": "Abdussalam Baryun", "text": "

yes that is right, we should focus in that direction

", "time": "2022-11-10T10:38:20Z"}, {"author": "Abdussalam Baryun", "text": "

bof if needed wg

", "time": "2022-11-10T10:38:38Z"}, {"author": "Lou Berger", "text": "

of course we're here to see if there is sufficient interest so identifying work to be done is helpful

", "time": "2022-11-10T10:38:40Z"}, {"author": "Dirk Trossen", "text": "

@Zheng Zhang if it isn't in the schedule, it is a hard problem (how do you travel on a bus which is not in any schedule?). One of the aspects of populating the database is also its curation for users of its information to ensure not just provenance but also veracity, also in terms of 'promise in the future'. As mentioned before, the work on ensuring/establishing such knowledge base is a key strand of work for me, possibly of use to other network functions, while its specific use for routing may be the other strand of work for TVR specifically.

", "time": "2022-11-10T10:38:44Z"}, {"author": "Lou Berger", "text": "

@tony not sure that is a contrarian view (at least from pov)

", "time": "2022-11-10T10:39:19Z"}, {"author": "Abdussalam Baryun", "text": "

@Lou, I agree

", "time": "2022-11-10T10:39:54Z"}, {"author": "Scott Johnson", "text": "

integrate datacenters and off-grid/grid interactive power plants.

", "time": "2022-11-10T10:40:37Z"}, {"author": "Adrian Farrel", "text": "

I agree with @Tony. So this is decreasingly contrarian. Knowledge of fact and knowledge of cause are both interesting, but not both necessary for all objectives

", "time": "2022-11-10T10:42:19Z"}, {"author": "Tony Li", "text": "

I'll then suggest that the format, storage, access, and delivery of the schedule is in scope. Computation of the schedule is out of scope.

", "time": "2022-11-10T10:43:43Z"}, {"author": "Jorge Amodio", "text": "

if we agree that a WG is needed part of the discussion will probably translate into the charter for such group

", "time": "2022-11-10T10:44:11Z"}, {"author": "Jorge Amodio", "text": "

obviously this has to go through the ietf process

", "time": "2022-11-10T10:45:37Z"}, {"author": "Adam Wiethuechter", "text": "

I'll add to @Tony Li and say that the definition of the data elements into and out of the schedule computations is in scope. (and thus how to format, store, access and transport them)

", "time": "2022-11-10T10:45:51Z"}, {"author": "Jorge Amodio", "text": "

focus on the need for the WG not the end solution

", "time": "2022-11-10T10:49:14Z"}, {"author": "Jorge Amodio", "text": "

can't hear

", "time": "2022-11-10T10:49:44Z"}, {"author": "Lars Eggert", "text": "

are we in the scoping discussion yet? or is this q&a on use cases?

", "time": "2022-11-10T10:49:51Z"}, {"author": "Tony Li", "text": "

The argument for the WG is clear: this is out of scope for existing WG's.

", "time": "2022-11-10T10:49:57Z"}, {"author": "Jorge Amodio", "text": "

@Tony agree

", "time": "2022-11-10T10:50:12Z"}, {"author": "Edward Birrane", "text": "

Agree

", "time": "2022-11-10T10:50:16Z"}, {"author": "Jorge Amodio", "text": "

now the $1M question is what area ?

", "time": "2022-11-10T10:50:34Z"}, {"author": "Abdussalam Baryun", "text": "

we need a proposed start of conditions and way to solve in general, and what we don't get into

", "time": "2022-11-10T10:51:08Z"}, {"author": "Zheng Zhang", "text": "

@Tony Agree

", "time": "2022-11-10T10:51:14Z"}, {"author": "Abdussalam Baryun", "text": "

yes what is policy

", "time": "2022-11-10T10:51:40Z"}, {"author": "Tony Li", "text": "

@Jorge Amodio Seems like we should figure out the work first.

", "time": "2022-11-10T10:52:00Z"}, {"author": "Jorge Amodio", "text": "

amen

", "time": "2022-11-10T10:52:13Z"}, {"author": "Jorge Amodio", "text": "

we'll need a clear charter

", "time": "2022-11-10T10:52:49Z"}, {"author": "Abdussalam Baryun", "text": "

thanks Lars, important comment,

", "time": "2022-11-10T10:55:16Z"}, {"author": "Abdussalam Baryun", "text": "

@Jorge, I agree

", "time": "2022-11-10T10:55:50Z"}, {"author": "Zongpeng Du", "text": "

Can source routing help here if the topology is changing, which can bypass the LSDB ?

", "time": "2022-11-10T10:58:34Z"}, {"author": "Tony Li", "text": "

??? The purpose of source routing is to bypass normal path computation. Why is that needed here?

", "time": "2022-11-10T10:59:21Z"}, {"author": "Russ White", "text": "

only if the source knows about the schedule, etc. ... but if that is so, then the problem is at the application layer rather than the network layer (?)

", "time": "2022-11-10T11:00:25Z"}, {"author": "Robert Raszuk", "text": "

@russ source may be network element not application ingress

", "time": "2022-11-10T11:01:07Z"}, {"author": "Adrian Farrel", "text": "

Source routing is just another form of TE. So we should discuss TE approaches versus distributed routing

", "time": "2022-11-10T11:01:14Z"}, {"author": "Lou Berger", "text": "

confused why you say \"versus\"

", "time": "2022-11-10T11:01:42Z"}, {"author": "Abdussalam Baryun", "text": "

ok I think this was not in the initial charter within first presentation, I think this should been in the first talk, thanks Rick.

", "time": "2022-11-10T11:01:46Z"}, {"author": "Lou Berger", "text": "

agree with the rest

", "time": "2022-11-10T11:01:52Z"}, {"author": "Adrian Farrel", "text": "

@Lou, because I did Latin at school?

", "time": "2022-11-10T11:02:08Z"}, {"author": "Jorge Amodio", "text": "

he is trying to show what this is \"not\"

", "time": "2022-11-10T11:02:21Z"}, {"author": "Tony Li", "text": "

amo amas amat

", "time": "2022-11-10T11:02:23Z"}, {"author": "Jorge Amodio", "text": "

which will drive on which area it lands

", "time": "2022-11-10T11:02:36Z"}, {"author": "Adrian Farrel", "text": "

..., amountain, amotorboat, amotorbike

", "time": "2022-11-10T11:03:16Z"}, {"author": "Zheng Zhang", "text": "

Fortunately I have google translation :-P

", "time": "2022-11-10T11:04:22Z"}, {"author": "Abdussalam Baryun", "text": "

@Jorge, yes Agree

", "time": "2022-11-10T11:04:27Z"}, {"author": "Jorge Amodio", "text": "

AMEN Rick

", "time": "2022-11-10T11:05:07Z"}, {"author": "Lou Berger", "text": "

@Zheng Zhang - send me the link ;-)

", "time": "2022-11-10T11:05:10Z"}, {"author": "Zheng Zhang", "text": "

@Lou You really don't need it :-P

", "time": "2022-11-10T11:05:48Z"}, {"author": "Lou Berger", "text": "

I didn't have proper British scooling

", "time": "2022-11-10T11:06:55Z"}, {"author": "Abdussalam Baryun", "text": "

good point Rick

", "time": "2022-11-10T11:07:07Z"}, {"author": "Tony Li", "text": "

@Lou Berger Tsk, you have no idea what you missed out on.

", "time": "2022-11-10T11:07:24Z"}, {"author": "Padma Pillay-Esnault", "text": "

FWIW the notion of predictive routing was introduced in LISP. There is a draft since a few years.

", "time": "2022-11-10T11:08:38Z"}, {"author": "Adrian Farrel", "text": "

Actually, I think my quote was wrong. I think it is...
\namotorbike, amotorboat, aminibus

", "time": "2022-11-10T11:08:53Z"}, {"author": "Lou Berger", "text": "

FWIW I think multicast and multi-path should be in scope

", "time": "2022-11-10T11:09:50Z"}, {"author": "Tony Li", "text": "

@Lou Berger Agree

", "time": "2022-11-10T11:10:16Z"}, {"author": "Adam Wiethuechter", "text": "

Agree @Lou Berger

", "time": "2022-11-10T11:10:26Z"}, {"author": "Zheng Zhang", "text": "

To Adrian, amazing, aminibus doesn't mean a mini bus, my friend

", "time": "2022-11-10T11:10:28Z"}, {"author": "Pete Resnick", "text": "

Responding to Rick's comment: Trust me, applications don't want to worry about this stuff.

", "time": "2022-11-10T11:10:51Z"}, {"author": "Zheng Zhang", "text": "

@Padma, could you please send the link?

", "time": "2022-11-10T11:11:07Z"}, {"author": "Jorge Amodio", "text": "

Not worry but be aware

", "time": "2022-11-10T11:11:10Z"}, {"author": "Tony Li", "text": "

@Pete Resnick Yes, but per @Dirk Trossen 's comments, there may be significant advantages to having applications that know the schedule.

", "time": "2022-11-10T11:11:43Z"}, {"author": "Pete Resnick", "text": "

@Jorge Amodio : Don't want to be aware. \"Deliver my data; don't tell me how it got there.\"

", "time": "2022-11-10T11:11:50Z"}, {"author": "Padma Pillay-Esnault", "text": "

Here it is https://datatracker.ietf.org/doc/html/draft-ietf-lisp-predictive-rlocs-10

", "time": "2022-11-10T11:11:56Z"}, {"author": "Zheng Zhang", "text": "

@Padma, Thank you :-)

", "time": "2022-11-10T11:12:22Z"}, {"author": "Dirk Trossen", "text": "

Tony Li said:

\n
\n

Pete Resnick Yes, but per Dirk Trossen 's comments, there may be significant advantages to having applications that know the schedule.

\n
\n

It's not just about applications but other network functions, such as authorization.

", "time": "2022-11-10T11:12:49Z"}, {"author": "Jorge Amodio", "text": "

Good comment, but do we need a WG or not ? :-)

", "time": "2022-11-10T11:13:49Z"}, {"author": "Zheng Zhang", "text": "

@Dirk, that's another question, if the user/source address/user-key will change or not?

", "time": "2022-11-10T11:14:31Z"}, {"author": "Pete Resnick", "text": "

@Tony Li I got here late. Which of Dirk's comments?

", "time": "2022-11-10T11:17:14Z"}, {"author": "Tony Li", "text": "

Scroll back in chat

", "time": "2022-11-10T11:17:36Z"}, {"author": "Pete Resnick", "text": "

@Tony Li Yes, still looking.

", "time": "2022-11-10T11:18:06Z"}, {"author": "Pete Resnick", "text": "

@Tony Li You mean \"link availability APIs\"?

", "time": "2022-11-10T11:20:25Z"}, {"author": "Tony Li", "text": "

Yes

", "time": "2022-11-10T11:20:39Z"}, {"author": "Kevin Shortt", "text": "

There's a lot of about whether or not there should be a schedule. To turn things around a bit, would it be worth looking at the priority applications the network should serve and determine which of those applications REQUIRE/BENEFIT FROM such schedules and those that don't?

", "time": "2022-11-10T11:21:41Z"}, {"author": "Tony Li", "text": "

@Jari Arkko Are Time Invariant Volvos out of scope?

", "time": "2022-11-10T11:21:44Z"}, {"author": "Abdussalam Baryun", "text": "

thanks Adrian, important comment

", "time": "2022-11-10T11:21:55Z"}, {"author": "Jorge Amodio", "text": "

scope & charter

", "time": "2022-11-10T11:22:08Z"}, {"author": "Pete Resnick", "text": "

@Tony Li That's not in the category of what I think of as a \"significant advantage\" to applications. (Unless, like my old friends at Qualcomm, you mean that everything above the PHY layer is an \"application\".)

", "time": "2022-11-10T11:22:14Z"}, {"author": "Jorge Amodio", "text": "

To WG or not to WG, that is the question :-)

", "time": "2022-11-10T11:22:28Z"}, {"author": "Lou Berger", "text": "

@adrian agree - we had some discussions if tying in via interesting usage of ecn, but that's cross-area

", "time": "2022-11-10T11:22:34Z"}, {"author": "Lou Berger", "text": "

Poll coming:
\nAre you interested in seeing this problem being worked in the IETF? (Raise hand for yes)

\n

Do you think a new Routing WG is needed to work this problem? (Raise hand for yes)

\n

Are you willing to contribute as an author or reviewer if a new WG is formed? (Raise hand for yes)

", "time": "2022-11-10T11:22:56Z"}, {"author": "Lars Eggert", "text": "

apologies i was less clear than i could have been. another way of saying what i meant to express earlier is that even if tvr came up with a scheme that can (re)establish paths on sub-RTT end-to-end timescales, we don;t actually have a transport layer protocol that applications could use to exchange data over paths with characteristics that change so frequently.

", "time": "2022-11-10T11:23:35Z"}, {"author": "Tony Li", "text": "

Area decision should be left to ADs

", "time": "2022-11-10T11:23:37Z"}, {"author": "Abdussalam Baryun", "text": "

Agree with Colin,

", "time": "2022-11-10T11:23:56Z"}, {"author": "Tony Li", "text": "

@Pete Resnick Knowing that capacity grows by 3 orders of magnitude in 10ms might be useful.

", "time": "2022-11-10T11:24:25Z"}, {"author": "Padma Pillay-Esnault", "text": "

A comment on scope - we should be cautious on this as different devices - we mentioned aerial drones, satellites and rural deployments - they actually have very different requirements, constraints, or regulations \u2026 can we have some clarity on what scope we are aiming at ?

", "time": "2022-11-10T11:24:40Z"}, {"author": "Tony Li", "text": "

The common abstraction is topology.

", "time": "2022-11-10T11:25:09Z"}, {"author": "Pete Resnick", "text": "

Significant number of \"no\" to the routing area question. Probably need people to explain that on the list.

", "time": "2022-11-10T11:27:05Z"}, {"author": "Tony Li", "text": "

Take the area out of the equation.

", "time": "2022-11-10T11:27:42Z"}, {"author": "Stewart Bryant", "text": "

Alt to new WG is to incubate in RTGWG

", "time": "2022-11-10T11:27:46Z"}, {"author": "Jari Arkko", "text": "

I voted \"no\" for the new WG. What I wanted to say is \"don't create entirely new tech, just deliver an attribute or two to routing protocols\". That can go to a new WG but I was afraid if I had said \"yes\" to the original question that would open the gates for much more research than is actually necessary :-)

", "time": "2022-11-10T11:28:05Z"}, {"author": "Jorge Amodio", "text": "

#2 is tricky, I think area is tbd

", "time": "2022-11-10T11:28:09Z"}, {"author": "Abdussalam Baryun", "text": "

no it may not change the question

", "time": "2022-11-10T11:29:24Z"}, {"author": "Toerless Eckert", "text": "

Jari: +1

", "time": "2022-11-10T11:29:35Z"}, {"author": "Abdussalam Baryun", "text": "

means same Area but only done in another WG

", "time": "2022-11-10T11:29:45Z"}, {"author": "Abdussalam Baryun", "text": "

yes Scope within IETF routing Area

", "time": "2022-11-10T11:30:51Z"}, {"author": "Lou Berger", "text": "

please come joint the discussion at https://datatracker.ietf.org/wg/tvr/about/

", "time": "2022-11-10T11:31:46Z"}]