[{"author": "Edward Birrane", "text": "

If any support are lurking on the chat - getting a volume booston the mics is appreciated for our remote users.

", "time": "2023-07-27T20:07:13Z"}, {"author": "Russ White", "text": "

yes ... the bigger problem is the differential in volume from different mics ... turn it up high enough to hear Lou and then Tony blows your ears out :-)

", "time": "2023-07-27T20:14:49Z"}, {"author": "Tony Li", "text": "

Sorry...

", "time": "2023-07-27T20:16:09Z"}, {"author": "Russ White", "text": "

It's not your fault :-)

", "time": "2023-07-27T20:18:05Z"}, {"author": "Ronald in 't Velt", "text": "

To Lou's question: does that mean that TVR is supposed to work alongside a \"classic\" routing solution? (Since unplanned topology changes WILL happen).

", "time": "2023-07-27T20:18:20Z"}, {"author": "Russ White", "text": "

I think the answer to that is either TVR must work alongside \"classic\" routing or \"inside classic routing\" ... The simplest way would be to play the \"admin distance game,\" where the tvr control plane has better preference than standard routing protocol ...

", "time": "2023-07-27T20:19:49Z"}, {"author": "Russ White", "text": "

But this might not (necessarily) work because longest prefix always wins ... so we need to think about this a small bit I think

", "time": "2023-07-27T20:20:12Z"}, {"author": "Scott Johnson", "text": "

TVR exists to handle problems which are not solvable by \"classic\" routing.

", "time": "2023-07-27T20:21:37Z"}, {"author": "Tony Li", "text": "

Thinking is encouraged, but let's not reinvent the wheel, please.

", "time": "2023-07-27T20:22:12Z"}, {"author": "Russ White", "text": "

That doesn't mean we can take \"classic\" routing off these devices, however ...

", "time": "2023-07-27T20:22:15Z"}, {"author": "Scott Johnson", "text": "

If they are IP networks, that is true.

", "time": "2023-07-27T20:22:37Z"}, {"author": "Russ White", "text": "

@Tony -- agreed ... at some point we need to decide if we're trying to modify existing protocols, or if we're going to develop things that work alongside existing routing protocols ...

", "time": "2023-07-27T20:23:07Z"}, {"author": "Tony Li", "text": "

To be picky: only LSR gets to modify existing protocols. We can take them requests if necessary.

", "time": "2023-07-27T20:24:04Z"}, {"author": "Russ White", "text": "

:thumbsup:

", "time": "2023-07-27T20:25:39Z"}, {"author": "Ronald in 't Velt", "text": "

I take issue with \"only LSR ...\" :grinning:

", "time": "2023-07-27T20:26:33Z"}, {"author": "Scott Johnson", "text": "

I was under the impression we were solving situations where time changes its flow...

", "time": "2023-07-27T20:29:24Z"}, {"author": "Dirk Trossen", "text": "

@Rick Taylor isn't 'node availability' just a time variant attribute? Is that what you are suggesting?

", "time": "2023-07-27T20:32:46Z"}, {"author": "Tony Li", "text": "

That would be the TARDIS WG

", "time": "2023-07-27T20:32:47Z"}, {"author": "Daniel King", "text": "

Re: Brian's last point. https://www.ietf.org/archive/id/draft-kcs-tvr-requirements-00.html#name-scope-of-time-variability

", "time": "2023-07-27T20:37:41Z"}, {"author": "Daniel King", "text": "

We will have time-variant models that will require different granularities of planning time, either because of limitations or assumptions about wall-clock time or because of requirements for the use cases.

", "time": "2023-07-27T20:38:30Z"}, {"author": "Daniel King", "text": "

RFC8345

", "time": "2023-07-27T20:41:54Z"}, {"author": "Daniel King", "text": "

We wanted to reuse existing IETF definitions and augment as needed.

", "time": "2023-07-27T20:42:35Z"}, {"author": "Wolfgang Beck", "text": "

ical (RfC 5545)?

", "time": "2023-07-27T20:42:59Z"}, {"author": "Daniel King", "text": "

YANG Model for Network Topologies (RFC8345)

", "time": "2023-07-27T20:44:01Z"}, {"author": "Daniel King", "text": "

Essentially, defining the links that a schedule may be applied.

", "time": "2023-07-27T20:44:39Z"}, {"author": "Edward Birrane", "text": "

Hope would be that this requirements document would capture novel definitions and reference others.

", "time": "2023-07-27T20:44:58Z"}, {"author": "Daniel King", "text": "

Yes, Tony made a similar suggestion.

", "time": "2023-07-27T20:45:18Z"}, {"author": "Daniel King", "text": "

We started on solid ground, we can be more adventurous and also include some innovative definitions.

", "time": "2023-07-27T20:46:08Z"}, {"author": "Daniel King", "text": "

The previous speaker had some supplemental requirements.

", "time": "2023-07-27T20:47:00Z"}, {"author": "Daniel King", "text": "

I don't see an issue with further discussion and capturing controversial proposals and then using the WG to agree actual requirements, based on current scope and use cases.

", "time": "2023-07-27T20:47:56Z"}, {"author": "Scott Johnson", "text": "

Pretty sure even LEO time changes due to special relativity, and being on the moon, for example, changes time flow due to special relativity, Tony.

", "time": "2023-07-27T20:48:04Z"}, {"author": "Edward Birrane", "text": "

Daniel: Agreed

", "time": "2023-07-27T20:48:19Z"}, {"author": "Scott Johnson", "text": "

general relativity on the last part, rather.

", "time": "2023-07-27T20:48:28Z"}, {"author": "Daniel King", "text": "

I think there was also a suggestion for further use of conformance language.

", "time": "2023-07-27T20:49:12Z"}, {"author": "Russ White", "text": "

Do we want to always use A time, B time, or try to support both?

", "time": "2023-07-27T20:50:05Z"}, {"author": "Russ White", "text": "

i.e., A time is absolute (3pm on Tuesday) while B time is relative (2 hours from now) ... I think I might have those backwards, though, been a while since that seminar

", "time": "2023-07-27T20:50:43Z"}, {"author": "Edward Birrane", "text": "

Russ; would you join the queue?

", "time": "2023-07-27T20:51:08Z"}, {"author": "Daniel King", "text": "

I think a schedule could apply to single reality, but also another temporal reality.

", "time": "2023-07-27T20:51:36Z"}, {"author": "Daniel King", "text": "

We have constraints sub-section, and it feels like we could also add metrics, sub-section.

", "time": "2023-07-27T20:53:24Z"}, {"author": "Daniel King", "text": "

This would reuse existing IETF definitions and expressions.

", "time": "2023-07-27T20:53:50Z"}, {"author": "Daniel King", "text": "

Also, link attributes: SRLG, et al.

", "time": "2023-07-27T20:55:09Z"}, {"author": "Daniel King", "text": "

Again, servicing the use cases is the priority.

", "time": "2023-07-27T20:55:35Z"}, {"author": "Marc Blanchet", "text": "

Russ White said:

\n
\n

i.e., A time is absolute (3pm on Tuesday) while B time is relative (2 hours from now) ... I think I might have those backwards, though, been a while since that seminar

\n
\n

there are cases for both. B time is very useful when the original plan is changed based on events: \"reconfiguring the plan\".

", "time": "2023-07-27T20:59:58Z"}, {"author": "Russ White", "text": "

Correct ... which is why I asked ... A-series is important when you want something specific, B-series is useful when you want to deal with a point in time that is relative to some other point of time ...

", "time": "2023-07-27T21:03:23Z"}, {"author": "Russ White", "text": "

I think we really want *both ... but this seems to add complexity ...

", "time": "2023-07-27T21:03:47Z"}, {"author": "Russ White", "text": "

(I'm not concerned with the philosophical argument over which is \"right\" here, just using these terms because they can be useful to describe the two different ways of describing time)

", "time": "2023-07-27T21:04:35Z"}, {"author": "Edward Birrane", "text": "

There should be considerations for nodes with either no absolute clock or no good absolute clock.

", "time": "2023-07-27T21:05:31Z"}, {"author": "Russ White", "text": "

:thumbsup:

", "time": "2023-07-27T21:08:26Z"}, {"author": "Scott Johnson", "text": "

Isn't that most of them, Ed?

", "time": "2023-07-27T21:11:56Z"}, {"author": "Edward Birrane", "text": "

Yup. Any you sometimes even have to watch the good ones. https://www.ion.org/publications/abstract.cfm?articleID=10574 :)

", "time": "2023-07-27T21:16:29Z"}, {"author": "Marc Blanchet", "text": "

for calendar properties/recurrence/..., @Wolfgang Beck wrote above about using iCal. Not sure the whole iCal thing, but certainly want to look at that, since it is a bit complicated when you look into the details.

", "time": "2023-07-27T21:20:38Z"}, {"author": "Scott Johnson", "text": "

Those results present some interesting physics questions, Ed :)

", "time": "2023-07-27T21:25:37Z"}, {"author": "Daniel King", "text": "

Re: Acee - Wondering if there may be a use case with ISTN (integrated Space Terrestrial Network) with traditional distributed/IGP and connecting with a transparent LEO/GEO satellite network that has a topology that does not support a distributed control plane, versus a regenerative LEO/GEO satellite network that might have distributed control plane capability.

", "time": "2023-07-27T21:49:08Z"}]