Re: [Netconf] Draft Charter Proposal for NETCONF WG

<ALEX>, inline

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Thursday, March 02, 2017 9:42 AM
To: Eric Voit (evoit) <evoit@cisco.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Draft Charter Proposal for NETCONF WG

On Thu, Mar 2, 2017 at 9:23 AM, Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>> wrote:
> From: Ladislav Lhotka, March 2, 2017 8:38 AM
> "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>> writes:
>
> > From: Andy Bierman, Wednesday, March 1, 2017 11:00 AM
> >
> > On Wed, Mar 1, 2017 at 4:01 AM, Ladislav Lhotka
> <lhotka@nic.cz<mailto:lhotka@nic.cz><mailto:lhotka@nic.cz<mailto:lhotka@nic.cz>>> wrote:
> >
> >> On 1 Mar 2017, at 10:58, t.petch
> <ietfc@btconnect.com<mailto:ietfc@btconnect.com><mailto:ietfc@btconnect.com<mailto:ietfc@btconnect.com>>> wrote:
> >>
> >>
> >> ----- Original Message -----
> >> From: "Juergen Schoenwaelder"
> >> <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de><mailto:j.schoenwaelder@jacobs-u<mailto:j.schoenwaelder@jacobs-u>
> >> niversity.de<http://niversity.de>>>
> >> To: "Mehmet Ersue" <mersue@gmail.com<mailto:mersue@gmail.com><mailto:mersue@gmail.com<mailto:mersue@gmail.com>>>
> >> Cc: "'Netconf'" <netconf@ietf.org<mailto:netconf@ietf.org><mailto:netconf@ietf.org<mailto:netconf@ietf.org>>>
> >> Sent: Monday, February 27, 2017 10:14 PM
> >>> On Mon, Feb 27, 2017 at 09:44:06PM +0100, Mehmet Ersue wrote:
> >>>
> >>>> 6. Revise the current NETCONF datastore concept as a protocol- and
> >> modeling
> >>>> language-independent standard as part of the network configuration
> >>>> framework. Use the datastore solution proposal in
> >>>> draft-ietf-netmod-revised-datastores as its basis. Will be used as
> >>>> a normative reference in protocol specifications.
> >>>
> >>> There is no point in dupliating work in WGs that have a common
> >>> history and a common set of active contributors.
> >>
> >> Juergen
> >>
> >> I am not sure what you are proposing;  Currently, datastores are
> >> poorly described in RFC6241 and RFC7950 and the publication of
> >> another incomplete description in the shape of
> >> draft-ietf-netmod-revised-datastores
> >> will likely make things worse.
> >>
> >> I see a need for a datastores RFC, probably separate from the current
> >> specifications, and do see the NETCONF WG as better placed to do it.
> >>
> >> I think that the rush to  get
> >> draft-ietf-netmod-revised-datastores
> >> out is militating against the long term health of NETCONF.
> >>
> >
> > I agree, and I would also add draft-ietf-netmod-schema-mount to it (of which
> I am a co-author).
> >
> > Original NETCONF and YANG were limited but (mostly) coherent and, in a
> way, simple and elegant. The recent developments are afterthoughts and
> kitchen sinks that will destroy these qualities.
> >
> > Instead of rushing with these documents, we should step back and think
> about a new architecture that could consistently support the new
> requirements.
> >
> > I think the entire approach to virtual servers is too complicated with schema-
> mount.
> > Instead of keeping the protocol fixed and playing tricks with the data
> > tree, it might be better to keep the current YANG we have, and enhance
> > the protocols in order to access virtual servers from the 'real' server.
> >
> > <Eric> Both Schema Mount and Peer Mount allow local application
> > referencing to remote information.  Life is easier for application
> > developers as underlying transport protocols are abstracted away.
> > Abstractions similar to Mount have proven themselves in other
> > contexts.  I am hoping YANG mechanisms move more in this direction.
>
> We should distinguish data mount from schema mount. Currently, getting the
> content of YANG library and YANG modules listed therein is sufficient for
> constructing the entire schema tree, and schema mount should work the same,
> i.e. one shouldn't need to get any instance data in order to construct the
> schema.
>
> The confusing point here is that YANG library itself is exposed as state data, but
> it should IMO be treated more as meta-data rather than regular data.
>
> >
> > The answer to whether YANG is only for single device abstraction or
> > also for multi-device abstractions is a fairly core proposition worth
> > disambiguating in the NETMOD charter as well.  Per the thread above, I
> > concur that if we continue down the ‘multi’ path, there may be
> > implications to draft-ietf-netmod-revised-datastores.
>
> I am not sure that I completely understand what you mean by multi-device
> abstraction

An example here would be a data plane box (e.g. BNG) which spins up multiple VMs to handle its control plane session establishment.

An operator doesn't want external systems to individually address every control plane VM.  Rather they want a YANG model for this logical+physical combination.  In this case each VM might use Peer (data) Mount to build a multi-device abstraction.  BTW: doing it this way also allows the same mounted YANG object data to be addressably exposed for each VM without requiring another YANG model to be made.

There are plenty of distributed server implementations out there.
Why is the software partitioning of the server implementation interesting
at the modeling level at all?  This is plain old master-agent/sub-agent stuff.

IMO accessing virtual servers is a protocol issue, similar to named virtual hosts
in an Apache server. (i.e., lots of entry-points all sharing 1 IP address).

Eric

Andy

<ALEX>

First, +1 regarding the need to distinguish schema mount and data mount.  To me, schema mount is fundamentally about definition reuse.  Really, it is about the ability to reuse definitions that would have been ideally defined as a grouping, but weren’t.

Data mount / Peer Mount basically provides an ability to federate a datastore.  For this reason, I think it is very timely to consider data mount while the WG is looking at revising the overall datastore architecture.  This is a lot more than master-agent/sub-agent stuff.  With a sub-agent, the sub-agent is a slave of the master.  This is different here, and there are use cases that will benefit from such a capability – including but not limited to the use case mentioned by Eric.  The current architecture reflects a very “box-centric” view of the world.  The question is if we want to move beyond those constraints.

</ALEX>

> but I think that device-less abstraction is also worth
> considering: apart from the particular client-server session context, there
> appears to be a need for specifying (and standardizing) more complex data
> models consisting of multiple modules, and augments (that are used for this
> purpose e.g. in RFC 8022) are sometimes insufficient.
>
> Lada
>
> >
> > Eric
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> >
> >> Tom Petch
> >>
> >>> /js
> >>>
> >>> --
> >>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> >>>
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> Netconf@ietf.org<mailto:Netconf@ietf.org><mailto:Netconf@ietf.org<mailto:Netconf@ietf.org>>
> >>> https://www.ietf.org/mailman/listinfo/netconf
> >>
> >> _______________________________________________
> >> Netconf mailing list
> >> Netconf@ietf.org<mailto:Netconf@ietf.org><mailto:Netconf@ietf.org<mailto:Netconf@ietf.org>>
> >> https://www.ietf.org/mailman/listinfo/netconf
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> >
> >
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org<mailto:Netconf@ietf.org><mailto:Netconf@ietf.org<mailto:Netconf@ietf.org>>
> > https://www.ietf.org/mailman/listinfo/netconf
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67