Hi Kent, Tom,
I don't really want to slow down the consensus process, but after the
discussion there are a couple of requirements that are not absolutely
clear to me. [Sorry for not raising them in the meeting yesterday, but
we had already spent a lot of time discussing the requirements and I
also think that you understandably went through the options quite fast
at the end].
On 10/09/2015 21:44, Nadeau Thomas wrote:
This is an official NETMOD working group call for consensus around the
requirements referenced
below and discussed in detail at the interim meeting held Thursday, September
10, 2015. At that meeting, the
chairs went over each requirement in detail and called for any objections to
each requirement (and sub-requirement). The question that was asked was “Are
there any objections to requirement X in general meaning as it is currently
written or with minor/editorial changes to how its written?” There were no
objections to any of the requirements, as is detailed in the meeting minutes.
However, to confirm these statements the co-chairs are opening this question to
the WG for period starting today, Thursday, September 10, 2015 at 5PM EST.
This period will close on Monday, September 14, 2015 at 5PM EST. If you
commented on the list previously, or at the meeting, there is no need to repeat
yourself; we have your position on
We will make a call of consensus shortly thereafter.
For your reference, the requirements can be found at this URL:
http://etherpad.tools.ietf.org:9000/p/netmod-opstate-requirements
but I will paste them into this message explicitly to be complete.
—Tom (as co-chair)
Terminology
From: https://tools.ietf.org/html/draft-openconfig-netmod-opstate-01
In order to understand the way in which a network operator or network
management system may need to interact with a device, it is key to
understand the different types of data that network elements may
store or master:
o intended configuration - this data represents the state that the
network operator intends the system to be in. This data is
colloquially referred to as the 'configuration' of the system.
o applied configuration - this data represents the state that the
network element is actually in, i.e., that which is currently
being run by particular software modules (e.g., the BGP daemon),
or other systems within the device (e.g., a secondary control-
plane, or line card).
o derived state - this data represents information which is
generated as part of the system's own interactions. For example,
derived state may consist of the results of protocol interactions
(the negotiated duplex state of an Ethernet link), statistics
(such as message queue depth), or counters (such as packet input
or output bytes).
1. Ability to interact with both intended and applied configuration
a. The ability to ask the operational components of a system
(e.g., line cards) for the configuration that they are currently
using. This is the "applied configuration".
b. applied configuration is read-only
c. The data model for the applied configuration is the same as
the data model for the intended configuration (same leaves)
d. For asynchronous systems, when fully synchronized, the data
in the applied configuration is the same as the data in the
intended configuration.
- I think that it would be useful to define what full synchronized
means. In this context, I think of it as meaning if none of the
configuration failed to be applied for any reason (e.g. due to absence
of hardware, or internal system error).
- Separately, this isn't specified in the openconfig-netmod-opstate
draft, but is there any requirement to indicate why an intended cfg node
isn't in the applied cfg? In the solution that I've proposed, I've
assumed that there is. It would be good to get clarification on whether
it is a genuine valid requirement or not.
2. Applied configuration as part of operational state
a. the ability to retrieve the applied configuration and
derived state nodes in a single protocol operation.
3. Support for both transactional, synchronous management
systems as well as distributed, asynchronous management
systems
a. For asynchronous systems, the ability to request a protocol
operation to not return (i.e. block) until the intended
configuration has been fully synchronized.
I'm not sure why 3 (a) is a requirement, or its unclear to me where this
is specified in the openconfig-netmod-opstate draft.
Thanks,
Rob
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
