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

@Jorge - yes we need to talk soon.

", "time": "2023-11-09T08:34:53Z"}, {"author": "Jorge Amodio", "text": "

cool thanks!

", "time": "2023-11-09T08:35:24Z"}, {"author": "Sauli Kiviranta", "text": "

Good morning everyone :wave:

", "time": "2023-11-09T08:35:27Z"}, {"author": "Jorge Amodio", "text": "

GM Sauli!

", "time": "2023-11-09T08:36:27Z"}, {"author": "Eduard V", "text": "

Is controller mandatory for TVR? Could some TVR solution work in a fully distributed mode?

", "time": "2023-11-09T08:47:11Z"}, {"author": "Marc Blanchet", "text": "

on terminology, fine to reuse SDN terminology, but we need to be careful to increase the overall scope indirectly.

", "time": "2023-11-09T08:47:20Z"}, {"author": "Edward Birrane", "text": "

Good to join queue to address these?

", "time": "2023-11-09T08:47:45Z"}, {"author": "Tony Li", "text": "

@Eduard V Sure, it could be distributed. But it could (should?) be wholly in the management plane.

", "time": "2023-11-09T08:48:32Z"}, {"author": "Eduard V", "text": "

Management plane involvement means that it s not fully distributed.

", "time": "2023-11-09T08:49:25Z"}, {"author": "Tony Li", "text": "

? Everything touches the management plane. That's how configuration happens.

", "time": "2023-11-09T08:49:58Z"}, {"author": "Eduard V", "text": "

There are vendors that does not have management plane.

", "time": "2023-11-09T08:50:43Z"}, {"author": "Eduard V", "text": "

Manual configuration is still very popular.

", "time": "2023-11-09T08:51:24Z"}, {"author": "Tony Li", "text": "

No YANG? No CLI? No web page? Never seen that...

", "time": "2023-11-09T08:51:27Z"}, {"author": "Tony Li", "text": "

Manual configuration is still management plane.

", "time": "2023-11-09T08:51:54Z"}, {"author": "Lou Berger", "text": "

let's not invent yet another definition of sdn, see [RFC7426] and the controllers identified in [RFC8453] and [RFC7149].

", "time": "2023-11-09T08:52:10Z"}, {"author": "Eduard V", "text": "

CLI could be used by human. It is not a management plane.

", "time": "2023-11-09T08:52:12Z"}, {"author": "Tony Li", "text": "

rsync and ssh count. :) Let's not argue semantics.

", "time": "2023-11-09T08:52:41Z"}, {"author": "Lou Berger", "text": "

+1 to tony

", "time": "2023-11-09T08:52:58Z"}, {"author": "Adam Wiethuechter", "text": "

The human is the management plane at that point, please don't let it be me :)

", "time": "2023-11-09T08:53:09Z"}, {"author": "Eduard V", "text": "

How long the solution would survive if management plane would be disconnected (after configuration done)?

", "time": "2023-11-09T08:54:27Z"}, {"author": "Lou Berger", "text": "

I can't parse that

", "time": "2023-11-09T08:55:04Z"}, {"author": "Tony Li", "text": "

Presumably indefinitely

", "time": "2023-11-09T08:55:06Z"}, {"author": "Eduard V", "text": "

Fine.

", "time": "2023-11-09T08:55:21Z"}, {"author": "Eduard V", "text": "

Because SDN is searching for multi-vendor interoperability for 10 year, and would probably not find it for the next 10 years.

", "time": "2023-11-09T08:56:18Z"}, {"author": "Boris Khasanov", "text": "

Good old SDN-like \"headless mode\" :)

", "time": "2023-11-09T08:56:42Z"}, {"author": "Eduard V", "text": "

No. Any SDN is not multi-vendor.

", "time": "2023-11-09T08:57:04Z"}, {"author": "Tony Li", "text": "

Not all controllers and management planes imply SDN.

", "time": "2023-11-09T08:57:40Z"}, {"author": "Lou Berger", "text": "

thank you - wass going to make the same c omment at mic

", "time": "2023-11-09T08:59:08Z"}, {"author": "Lou Berger", "text": "

this is how/why we ended up with the \"controller plane\" term in detnet

", "time": "2023-11-09T09:00:11Z"}, {"author": "Lou Berger", "text": "

is inclusive of all realization approaches

", "time": "2023-11-09T09:00:40Z"}, {"author": "Eduard V", "text": "

Management plane is not multi-vendor either.

", "time": "2023-11-09T09:00:44Z"}, {"author": "Lou Berger", "text": "

why?

", "time": "2023-11-09T09:00:59Z"}, {"author": "Lou Berger", "text": "

there are standards for mgmnt (YANG/NETCONF/RESTCONF) and OAM

", "time": "2023-11-09T09:01:27Z"}, {"author": "Eduard V", "text": "

It is just reality, many YANG models should be developed and sync between vendors.

", "time": "2023-11-09T09:01:29Z"}, {"author": "Tony Li", "text": "

It's not perfect, so we shouldn't try to use it? ?!?!?

", "time": "2023-11-09T09:02:03Z"}, {"author": "Eduard V", "text": "

@Lou we are very far from success. But IETF has a good progress for the last 3-4 years

", "time": "2023-11-09T09:02:18Z"}, {"author": "Edward Birrane", "text": "

In the interest of time, I have locked the queue.

", "time": "2023-11-09T09:03:17Z"}, {"author": "Eduard V", "text": "

@Tony, it would not be possible to use in production for about a decade. Strategically it is right.

", "time": "2023-11-09T09:03:24Z"}, {"author": "Lou Berger", "text": "

what could not be used? The product of this WG?

", "time": "2023-11-09T09:04:26Z"}, {"author": "Christian Hopps", "text": "

YANG is used today to run networks.

", "time": "2023-11-09T09:05:06Z"}, {"author": "Eduard V", "text": "

Any involvement of management plane cross-vendor is not possible. Only is vendor lock then possible.

", "time": "2023-11-09T09:05:20Z"}, {"author": "Tony Li", "text": "

We could require that nodes be time synchronized and the mechanism is out of scope.

", "time": "2023-11-09T09:05:23Z"}, {"author": "Edward Birrane", "text": "

Synchronized to what level of precision?

", "time": "2023-11-09T09:05:48Z"}, {"author": "Eduard V", "text": "

@Christian, these YANG is very proprietary yet for any vendor.

", "time": "2023-11-09T09:05:56Z"}, {"author": "Christian Hopps", "text": "

so?

", "time": "2023-11-09T09:06:01Z"}, {"author": "Erik Kline", "text": "

In general, a cancellation or withdraw of a scheduled change could just be a new scheduled update containing the logical negation of everything in the original scheduled update.

\n

But it worth mentioning something along these lines? How something is logically negated is obviously dependent on parameter, model, etc...

", "time": "2023-11-09T09:06:08Z"}, {"author": "Eduard V", "text": "

long term it is fine to relay on management plane/SDN. Mid term it would block production possibility.

", "time": "2023-11-09T09:06:48Z"}, {"author": "Eduard V", "text": "

Fully distributed solutions are still important.

", "time": "2023-11-09T09:07:32Z"}, {"author": "Peng Liu", "text": "

the current version has section 8.5 for time accuracy requirement, it may be refined to address the time sync requirements in the next version.

", "time": "2023-11-09T09:07:55Z"}, {"author": "Lou Berger", "text": "

sure, the architecture should allow for both / any combination of solutions

", "time": "2023-11-09T09:08:00Z"}, {"author": "Eduard V", "text": "

May be I need to read a draft because presentation gives impression that fully distributed mode is not possible.

", "time": "2023-11-09T09:08:57Z"}, {"author": "Lou Berger", "text": "

oh, I wasn't talking about what it says, rather what it should say..

", "time": "2023-11-09T09:09:24Z"}, {"author": "Edward Birrane", "text": "

@eduard If you have specific questions after reading drafts then they would be best addressed on the mailing list.

", "time": "2023-11-09T09:09:53Z"}, {"author": "Jorge Amodio", "text": "

Nope

", "time": "2023-11-09T09:17:53Z"}, {"author": "Daniel King", "text": "

Hi All, thanks for the comments. I'm going to move some of these onto the list. Alas, I need to dash to CCAMP for my next presentation shortly, and then onto COIN. But I will parse the comments and post later today.

", "time": "2023-11-09T09:18:19Z"}, {"author": "Tony Li", "text": "

Maintenance...

", "time": "2023-11-09T09:27:40Z"}, {"author": "Marisol", "text": "

There is current work on topology model on the IVY working group, it will be good to work on alignment

", "time": "2023-11-09T09:28:13Z"}, {"author": "Erik Kline", "text": "

I think I agree with Rick; power might be a bit too specific relative to other things that might make a node functional or not

", "time": "2023-11-09T09:30:04Z"}, {"author": "Edward Birrane", "text": "

This approach would then presume a power-schedule list vs a maintenance-schedule list vs other lists?

", "time": "2023-11-09T09:30:34Z"}, {"author": "Tony Li", "text": "

So we should generalize...

", "time": "2023-11-09T09:32:01Z"}, {"author": "Erik Kline", "text": "

If the reason is immaterial to the ability to route, the current speaker's suggestion of a \"reason\" string might be sufficient

", "time": "2023-11-09T09:32:16Z"}, {"author": "Tony Li", "text": "

Can't hear Acee

", "time": "2023-11-09T09:38:05Z"}, {"author": "Don Fedyk", "text": "

I think a request to go into a low power mode vs power off is a refinement. However sometimes low power is also happen with link up /down commands. I think some clarification in this area would help.

", "time": "2023-11-09T09:39:35Z"}, {"author": "Padma Pillay-Esnault", "text": "

IMHO Rick has a point if the power is off this is the same as having all links down? if so is it relevant here ... or just a higher hierarchy for grouped behavior ...

", "time": "2023-11-09T09:44:57Z"}, {"author": "Christian Hopps", "text": "

I stepped away for a second.. are we talking about Blinken Lights now? :)

", "time": "2023-11-09T09:49:55Z"}, {"author": "Tony Li", "text": "

We were...

", "time": "2023-11-09T09:50:14Z"}, {"author": "Edward Birrane", "text": "

We scheduled the blinking lights discussion for later. :)

", "time": "2023-11-09T09:50:21Z"}, {"author": "Christian Hopps", "text": "

important stuff

", "time": "2023-11-09T09:50:28Z"}, {"author": "Edward Birrane", "text": "

Toy example aside, overmodeling is a real problem.

", "time": "2023-11-09T09:51:06Z"}, {"author": "Tony Li", "text": "

We can now schedule blinking lights, and thereby convey Morse code, and thereby convey IP packets through a contact plan. :-)

", "time": "2023-11-09T09:51:07Z"}, {"author": "Edward Birrane", "text": "

ha!

", "time": "2023-11-09T09:51:15Z"}, {"author": "Adam Wiethuechter", "text": "

... --- ...

", "time": "2023-11-09T09:54:27Z"}, {"author": "Edward Birrane", "text": "

Queue locked for time.

", "time": "2023-11-09T09:56:26Z"}, {"author": "Eduard V", "text": "

Augmentation i \\s the only way. Or else who would map between Modules? Will it be possible? (some parameters may be completely different by semantic)

", "time": "2023-11-09T09:57:16Z"}, {"author": "Vishnu Beeram", "text": "

all IETF topology models are built on the base topology model from RFC8345

", "time": "2023-11-09T09:57:26Z"}, {"author": "Christian Hopps", "text": "

@vishnu that's the i2rs work I think

", "time": "2023-11-09T09:58:11Z"}, {"author": "Lou Berger", "text": "

so?

", "time": "2023-11-09T09:58:21Z"}, {"author": "Lou Berger", "text": "

don't follow the implication of it being produced by i2rs...

", "time": "2023-11-09T09:58:55Z"}, {"author": "Christian Hopps", "text": "

acee just mentioned looking at the i2rs model at the mic

", "time": "2023-11-09T09:59:15Z"}, {"author": "Christian Hopps", "text": "

just linking

", "time": "2023-11-09T09:59:32Z"}, {"author": "Lou Berger", "text": "

thanks'

", "time": "2023-11-09T09:59:33Z"}, {"author": "Vishnu Beeram", "text": "

@Chris -- yes

", "time": "2023-11-09T10:00:37Z"}, {"author": "Lou Berger", "text": "

@mic can we support the grouping+augmentation approach discussed in the previous slot with this document?

", "time": "2023-11-09T10:05:23Z"}, {"author": "Edward Birrane", "text": "

@Jing Would you be able to post your question in the chat - we had difficulty with your audio.

", "time": "2023-11-09T10:07:04Z"}, {"author": "Yingzhen Qu", "text": "

@Lou, we want to keep the schedule independent, and define the augmentation in a separate module. Some of the augmentations can be included in the same document. I think we're in sync

", "time": "2023-11-09T10:11:09Z"}, {"author": "Lou Berger", "text": "

Thanks Yingzhen

", "time": "2023-11-09T10:11:31Z"}, {"author": "Christian Hopps", "text": "

using capabilities never works though

", "time": "2023-11-09T10:22:29Z"}, {"author": "Christian Hopps", "text": "

but this is an LSR discussion :)

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

so is it historic scheduling to discussing LSR here?

", "time": "2023-11-09T10:23:37Z"}, {"author": "Tony Li", "text": "

The discussion is welcome. Moving the document forward is on LSR.

", "time": "2023-11-09T10:24:08Z"}, {"author": "Christian Hopps", "text": "

I just was referring to my capabilities comment

", "time": "2023-11-09T10:24:39Z"}, {"author": "Lou Berger", "text": "

sorry, poor attempt at a joke

", "time": "2023-11-09T10:25:08Z"}, {"author": "Christian Hopps", "text": "

heh

", "time": "2023-11-09T10:25:26Z"}, {"author": "Adam Wiethuechter", "text": "

capabilities gives me ptsd

", "time": "2023-11-09T10:25:35Z"}, {"author": "Adam Wiethuechter", "text": "

blame seL4

", "time": "2023-11-09T10:25:42Z"}]