Re: [Netconf] Draft Charter Proposal for NETCONF WG

On Thu, Mar 2, 2017 at 9:23 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:

> > From: Ladislav Lhotka, March 2, 2017 8:38 AM
> > "Eric Voit (evoit)" <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>> wrote:
> > >
> > >> On 1 Mar 2017, at 10:58, t.petch
> > <ietfc@btconnect.com<mailto:ietfc@btconnect.com>> wrote:
> > >>
> > >>
> > >> ----- Original Message -----
> > >> From: "Juergen Schoenwaelder"
> > >> <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-u
> > >> niversity.de>>
> > >> To: "Mehmet Ersue" <mersue@gmail.com<mailto:mersue@gmail.com>>
> > >> Cc: "'Netconf'" <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

>
> > 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>
> > >>> https://www.ietf.org/mailman/listinfo/netconf
> > >>
> > >> _______________________________________________
> > >> Netconf mailing list
> > >> 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>
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
>