Rob,
Benoit,
I want to pick up on this very specific point. I think Lou’s mails imply a
similar position, but I want to be clear.
On September 10, 2015 at 04:40:30, Benoit Claise (bcla...@cisco.com) wrote:
A common architecture includes a central configuration data
store that is being updated by the manageability framework and
updates read by the subsystems affected by the change (e.g. the
BGP service or the interface manager). In this case, there is
no other source of configuration except for the content of the
data store.
The configuration file/‘store’ of a system shows the intent of how that system
should be configured. We can agree that all implementations need to have this.
The applied configuration is the value of those configuration elements a
daemon/software component/programmable memory is actually running, which can be
compared to the intent. Essentially, this is *dynamic* information which is the
*state* of the running system. Implementations *do* store this. I think the
point that you are making here is not that it is not supported. The point is
that it is dynamically built at query time, according to a different schema.
You're right. Good clarification.
Regards, Benoit
This different schema is bad news, programmatically. How did I know that the
static (IOS-alike configuration):
router bgp 65497
neighbor 192.0.2.1 remote-as 65500
Needs me to run:
show bgp ipv4 unicast neighbor 192.0.2.1 | i remote AS
and then run a regexp that extracts the following AS number after the words
‘remote AS’. Today - I probably need to write a mapping table that tells me
that.
The requirement is that we can determine, for a particular leaf - what the
intended value is, AND the value which is applied, PLUS be able to “easily”
retrieve the state associated with that construct - in a way that is
deterministic, and does not require per-leaf mapping tables to be maintained
like we might have to today.
The point about identical values is that *in cases where no such retrieval of
the actual applied config values is possible* a system can simply make all the
applied leaves pointers to the intent. This would be akin to the ‘show’ command
doing the equivalent of ‘show running-config | i 192.0.2.1.*remote-as’ and
extracting the remote-as from there AFAICS.
Regards,
r.
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
