[netmod] Re: 2nd WGLC on system-config-08

[Andy Bierman <[e-mail]>]

On Tue, Aug 20, 2024 at 5:54 AM Jürgen Schönwälder
<[e-mail]> wrote:

> On Tue, Aug 20, 2024 at 12:20:55PM +0000, Jan Lindblad (jlindbla) wrote:
> >
> > PS: And with a well designed merge operation, one might in the future
> >     even move towards breaking the monolithic <running> into pieces,
> >     like we do for the <candidate> singleton today.
> >
> > [janl] Could you expand on that last PS? I’m not following your train of
> thought here.
> >
>
> If you take the configuration of a web server, then it is common
> practice to organize the configuration of different sites a server is
> serving into separate files. (I am talking about modularity of config
> instance data, not modularity of the underlying data models.) The
> server then loads the configs of all active sites and merges the
> settings somehow to derive all the internal settings necessary to
> provide the configured services.
>
>
The <system> datastore is not a functional partition, like virtual WEB
servers .
The split between system and client is somewhat arbitrary and quite
implementation-specific.
It does not provide modularity at all.

<running> as a datastore is conceptually monolithic, but required to be
that way in implementation.
Certainly the protocol operations are not required to operate on the entire
config at once.

I do not see any significant difference between system-created config and
traditional client-created config.  In modern distributed systems, the
system config
could actually be (at least partially) client config, even using the exact
same operations as a "real" client.
The distinction between system and client-created data is no longer
relevant.
The immutable flag addresses the relevant issues.


Andy


In the NC/RC world, we have a single monolithic <running> and hence
> all the busy merging needs to happen on the client side or you hope
> that clients respect each other instead of stepping onto each others
> toes when they make changes. I can see possible advantages of
> splitting our monolithic <running> into multiple <running>s that are
> then merged on the server side into the grand unified <intended>. This
> gives us modularity, possibly easier to manage access controls,
> perhaps execution gains if it is possible to localize validations that
> do not always have to generate and revalidate the grand unified
> <intended>.
>
> I understand that this may sound far reaching since the IETF tends to
> move sloooowly and to be rightfully conservative about more radical
> proposals. On the other hand, having a plan where to go with a
> technology may help to guide current work and to avoid getting stuck
> with point solutions that at the end make it impossible to evolve
> beyond a certain stage.
>
> /js
>
> --
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>
> _______________________________________________
> netmod mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>