Re: [CCAMP] [Inventory-yang] New Internet Draft on Peer-Mount

Alex,

Great meeting you this week, and thanks for the many presentations about interesting and sometimes pressing topics. I have read the draft and have a few comments.

First of all I want to say that I understand the value of this use case. In fact, we have implemented a fairly similar proprietary mechanism more than 10 years ago, and it is still in daily use around the world today. That said, I can also attest to the wealth of implementation difficulties when it comes to make this efficient/reliable enough for a broad range of use cases.

Restricting this mechanism to only provide read-only data is smart :-) when it comes to limiting potential issues. To standardize federated config management in this vein would be a truly massive undertaking. Still, what you propose isn't easy to get right. We will have to open a can of worms (even if we avoid the "config true" barrel of worms).

You have obviously thought about this quite a bit, but let me ask what you think about the following:

1) Performance & caching

The primary problem we see with our existing, proprietary implementation of something in this direction is that the performance is not good enough for many use cases. The mechanism is used a fair bit, so clearly it is good enough for some. Every time a call to another server is required (and you even talk about cascading mounts), a delay is incurred. This can of course be mitigated by caching strategies. Anyone who has studied distributed caching algorithms knows this is really complex, though, and results are not always ideal.

2) Authentication & mount server mgmt

You propose a YANG module for management of mounts. This list includes details about server IP addresses etc, but not user credentials. This means the structure is not usable by itself, additional knowledge is required to do the reading. I am not so sure everyone would want to manage their device federation and authentication/authorization mapping using this model structure (we certainly would not), so maybe it would be better to just provide a list of host names (string) and leave the exact meaning of that string out of scope?

3) YANG model merging

Since we are in the YANG world where all data we read is well described by a YANG DM, we'd like the clients to know what the mounted YANG looks like. This is a non-trivial matter even with YANG-mount, but here we're also not mounting entire modules, but rather pointing at random points in those mounted models. How a client is to make sense of that situation is not entirely clear, even if it is only for config false.

4) YANG-push, gnmi subscriptions, etc

You mentioned yourself that it may be difficult to create the (synchronized?) responses to any client's subscriptions over this data. Maybe it could be left out of scope, but doing so would make the federated solution appear as something negative to clients.

5) Consistent network configuration

The mechanism described in section 4.2 is a kind of configuration mechanism. I do think it looks rather weak, however, compared to the functionality available to applications running on top of common NETCONF servers. In order to get proper transactional behavior, clients will typically need to validate and coordinate their consumption of configuration changes, and that sounds difficult to achieve with this approach. I fear this would lead to low quality systems (i.e. not fully transactional, not properly validated, etc).

So to summarize, while I say "we need this" (and have and use this in our proprietary context), I'm also saying it's not going to be easy to standardize.

Best Regards,
/jan

> we have just submitted a new Internet Draft regarding Peer-Mount, a mechanism that allows to reference and incorporate information from remote datastores.  This will allow, for example, a network controller to provide a federated datastore containing management data transcending individual network devices without needing to keep this data redundantly.  You can find the draft here: https://datatracker.ietf.org/doc/html/draft-clemm-netmod-peermount-00
> 
> The concept of Peer-Mount was in fact originally introduced several years ago but not pursued further due to lack of interest and IETF use cases at the time.   It is being revived now, with a few modifications, in light of IETF interest in network inventory, network topology, and related use cases that have emerged since. Inevitably, these use cases may lead to the need to incorporate some management data regarding particular state or configuration that is already maintained on networking devices into a holistic network-wide view.  Unlike Schema Mount, which allows to reuse existing model definitions by allowing them to be  instantiated in a local data tree, Peer Mount is aimed at incorporating a  local view of data subtrees that are remote, authoritatively owned and maintained by separate systems.
> 
> We believe that this work belongs into Netmod, while the potential users are in network inventory - hence we are cross-posting this to netmod, ivy, and ccamp.
> 
> --- Alex (on behalf of coauthors)
> 
> -- 
> Inventory-yang mailing list
> Inventory-yang@ietf.org
> https://www.ietf.org/mailman/listinfo/inventory-yang