These are the draft meeting minutes from Interim meeting on June 18,
2015. Please comment. If I don’t hear from anyone by Friday, they will be
published as-is.
—Tom
NETMOD Virtual Interim Meeting (June 18, 2015)
* Participants
- Acee
- Ambika Prasad Tripathy
- Andy Biermann
- Anees Shaikh
- Benoit Claise
- Einar Nilsen-Nygaard
- Martin Bjorklund
- Harish
- Helen Chen
- Ignas Bagdonas
- Jeffrey Haas
- Kent Watsen
- Lou Berger
- Mahesh Jethanandani
- Marcus Hines
- Norm Strahle
- Qin Wu
- Rob Shakir
- Robert Wilton
- Shitanshu Shah
- Steve Ulrich
- Susan Hares
- Thanasis Kypartis
- Vishnu Pavan Beeram
- Lada Lhotka
- Xufeng Liu
- Yingzhen Qu
Agenda:
- Agenda Bashing
- draft-openconfig-netmod-opstate-00
- draft-openconfig-netmod-model-structure-00
Meeting starting.
Anees presenting:
Now Rob Shakir presenting:
Draft: http://tools.ietf.org/html/draft-openconfig-netmod-opstate-00
Slides:
http://www.openconfig.net/file-cabinet/netmod-interim-opstate.pdf?attredirects=0&d=1
https://www.ietf.org/proceedings/interim/2015/06/18/netmod/slides/slides-interim-2015-netmod-13-0.pdf
* Slide #2
KW: Is the request for consistent state true for all three kinds of
operational state?
RS: Yes
AS: It is important that all the state is in a consistent place that is easy
to find by automated tools.
* Slide #3
LL: Is intended configuration the same as config true in YANG and
applied/actual/operational state is config false in YANG?
RS: yes
MH: Is config for a line card not present intended or applied state?
JH: is there a distinction between counters that are never intermingled with
config true nodes?
BC: You only want an operational true flag, not a distinction between
statistics, actual, applied, ... state?
AS: Operational true is a subset of the config false data. The motivation is
to be able to get only the config false data where the device has determine the
value on its own (that is, the value does not come from the config).
MB: Is operational true only needed if you have the config in the same data
tree?
RS: yes
RS: I need a way to get all the config false leafs or the operational true
leafs (as defined above).
MB: There may be several solutions, one of them could be a separate datastore
with the same data model.
KW: I think I understand synchronous means a commit makes the operational
state reflect the config state.
KW: And an asynchronous system would not immediately reflect the config state
in operational state after the commit.
KW: Is this defined in NETCONF?
MB: A successful write to :running means that config is valid and will be
applied but you can have config for non-existing line cards etc.
MB: I would add an axiom: Any solution should work with NETCONF.
LL: What about hostname set by a CLI - is this intended or applied or ...
state?
RS: In cases where there are multiple writers, the need for retrieval of
operational state becomes important.
BC: In a synchronous system, does it make sense to replicate data?
RS: There are always parts of a device where systems tend to be not
synchronous.
RS: On the wire, duplication may be dealt with by proper design of RPCs.
MB: I am concerned about large and complex data models with almost redundant
definitions.
AB: Yes, this sounds more like a protocol problem than a data model problem.
RS: It is a one-time pain for a module writer.
RS: Do we optimize for module writers or for NMS writers?
LL: I do not understand applied operational state and the other operational
state.
RS: YANG config true = intended state, operational state derived from config
true (intended state) = applied state, other operational state is the remaining
state not resulting from config.
RS: YANG config true => intended and applied state, YANG config false =>
operational state
MB: The terminology confusion needs to be resolved.
MB: Intended config is my configuration file, once loaded, it becomes applied
config?
KW: I continue to be confused by the terms synchronous and asynchronous.
MB: Are not all systems asynchronous in your definition? Are there examples
of synchronous systems?
RS: Intended config means syntactically correct. This does not mean that a
system will actually be able to apply it.
AB: A NETCONF OK means more than syntactically correct (e.g. if you write the
<running> datastore).
TN: One hour gone, we made it to slide #3 out of 9.
RS: We do not want to tightly couple this to NETCONF semantics.
MB: But we are trying to understand your concepts from a NETCONF perspective.
AB: I like to avoid rewriting RFCs.
AT: Syntax checking is already part of YANG.
RS: Intended config is expected to be syntactically valid, it still may not
be applied without failures.
JH: What do you mean when you use the term RPC?
JH: is committed config (running datastore) == intended config?
RS: yes
JH: The active state is usually a different node in the data tree, different
from the config state.
RS: No, they have different branches in our proposal.
AB: We should keep the model stateless as much as possible, the distinction
needs to happen at the protocol.
MB: The duplication of intended and applied config does not seem to be
necessary. Note that there is more, a startup value, an ephemeral value, etc.
AB: proposal may not take into account Benoit's draft re: other SDO moudles
KW: start-up/candidate datastores not relavent. running datastore ==
"intended". how running is set (via wriatable-running or candaidate commit)
not important. Operational state isn't related to datastore. e.g., not such
thing as operational state of startup or candidate datastore. Not clear if
oprerational is even part of running datastore, or if it's more like another
datastore that happens to have running datastore values intermingled in it...
* Slide #4/#5 (somehow)
MB: There are semantics how leafs are related to each other that go beyond
simply naming conventions.
RS: I can easily check whether intended state == applied state and I can
easily obtain the related operational state.
AB: Putting things under a certain container is not needed since you can
define RPCs that have the proper semantics.
RS: Do not just think NETCONF, there will be other systems involved.
AB: I think JH stated the requirement that being able to retrieve the state
data associated with a resource.
JH: They are trying to use YANG for models that are not used with NETCONF.
RS: But we have conventions and coding styles in many other languages.
AB: There are rules for identifiers and they do not distinguish different
combinations of characters to mean different things.
KW: We need to define clear terminology and we should go back to the problem
description.
Back to slide #3:
MB/KW: definition of intended vs applied raised again, are they not the same
given all servers are effectively assyncrounous?
BC: recommandation to clarify
ACTION ITEM for the authors: terminology
- for intended, applied
- synchronous/asynchronous
ACTION ITEM for the authors:
- example of full NETCONF synchronous: RPC and datastore/leaf update. What
are the consequences? duplicate leaf in /config and /state
- example of (non-NETCONF) asynchronous: RPC and datastore/leaf update
KW: NETCONF/RESTCONF are synchronous protocols but state application are
applied asynchronously.
RS: We like to have distinctions in the data model so that they are protocol
agnostic.
TN: Can we articulate a clear problem statement after almost two hours?
AS: some agreement in understanding, some distance in solution. need to
clear up terminology
Wrap-up: review of requirements on slides 2 and 3
Slide #2:
- point 1: clear, and we have agreement (already the case with config=false
statement)
- point 2: not clear
- point 3: clear, and we have agreement
- though re: point #3, JS questions if any YANG statements are NETCONF
specific
- AS says that it's really a statement about the protocol so the wording
is a bit misleading
Slide #3
- point 1: not clear (most likely due to terminology)
- point 2: clear and agreed (already the case)
- point 3: not clear (again most likely a terminology issue)
MEETING ENDED @ 12:15 Eastern
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
