> On Sep 11, 2015:6:48 AM, at 6:48 AM, Robert Wilton <[email protected]> wrote:
>
> 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.
Anees/Rob, can you guys please add some color to the above descriptions
to help clarify things for Robert?
—Tom
>
> Thanks,
> Rob
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
