These are the preliminary notes from the interim meeting on June 25,
2015. I am still awaiting notes from Ignas who also took meeting minutes
before I post the official minutes. If there are any comments/corrections to
what I have below, please post here as soon as possible.
—Tom
NETMOD Virtual Interim Meeting (June 25, 2015)
* Participants
- Acee (AC)
- Alia Atlas
- Andy Bierman
- Anees Shaikh
- Aseem Choudhary
- Balazs Lengyel
- Benoit Claise
- Clyde Wildes
- Dan Romascanu
- Einar
- Giles
- Ignas Bagdonas
- Jason Sterne (JS)
- Kent Watsen
- Mahesh Jethanandani
- Marcus ????
- Martin Bjorklund
- Phil Shafer
- Qin Wu
- Robert Wilton
- Sam Aldrin
- Susan Hares
- Tarek Saad
- Tom Nadeau
- Vishnu Pavan Beeram
- Xufeng Liu
- Yingzhen Qu
Meeting starting (10:06am ET)
Agenda:
- Agenda Bashing
- draft-openconfig-netmod-opstate-00
- draft-openconfig-netmod-model-structure-00
Anees Presenting
Going over terminology based on slides exchanged over e-mail. Applied/actual
configuration should not be fetched when a yet to be defined <get-oper> is
defined. In other words, get operational should fetch only protocol negotiated
values and counters. This would require a flag other than config = false to be
defined.
- KW: is the applied/actual having the value "auto"?
- AS: yes
- KW: would the term "distributed" be better?
- AS: no
- JS: how far do we need to go to consider a config node "applied"? (e.g.,
distributed systems)
- AS: systems will differ, what matters is what they perceive to be applied
- SH: where would ephemeral state be catured?
- AS: it's not captured in this model, but makes sense to view as intended
config that is not persisted
- MB: where would interfaces configured by system (not user-configured) be
captured in this model?
- AS: should be part of intended config
- MB: so system should update intended config to capture/add these additional
nodes
- M?: should show up in applied config (not intended)
- MB: so applied config can contain more than just intended config...
- AB: applied state a child of indended state?
- MB: right, since parent is config=true
- RW: given interfaces MAY have config, then an unconfigured interface (line
card plugged in) still takes default config, no?
- AS: makes sense that there are some default config values applied to it,
just not from intended config
- SH: ephemeral operational state goes into operational state too?
- AS: yes
- AB: proposal about data organization, but there is a yang statement too
- AS: no, proposal has both.
- AB: Disagree duplicating data-model nodes, scales better to use datastores
[KW: Juergen made same point on list]
- AS:
- MB: agree that should be possible to use w/o NC, but datastores aren't
NC-specific either [witness RC]
- TN: isn't this the same thing? - two option: decorate model vs add an
operation
- BL: protocol option better, as otherwise it would grow the saize of the
model greatly
- AS: putting it into the model (data structure) can be simpler
- MB: is 9/10 follow model-structure, but 10th doesn't, even though valid
YANG, the whole thing falls down
- AB: overloading names could cause conflict - e.g., an address book's
"State" value
- AS: may not be important to standardize models at this stage, without much
much operational experience, not too much value in existing models
- BC: do we have people that want to work on an optional proposal? [no one
steps forward]
Moving on to model-structure draft (10:58am ET)
- Anees presenting
- MB: how is putting a device node under arbitrary parent?
- AS: useful anchor point, not stricly necessary but very useful and don't
see anything harmful in it
- AB: adds more payload to every message in every protocol
- AS: don't understand payload comment
- AB: adds string to instance-identifier
- BL: ex: alarm, the length of the instance-identifier is an important point
- MB: what's the point of having top-level "/device", why not just "/"?
- PS: more than that... <i missed it>
- AS: so bring up everything one level would be better?
- MB: yes
- AS: yeah, i agree
- AA: what is the argument behind having "/device"? - string length?
- AB: no value
- AS: thought a single anchor would be useful
- BC: regardless of single anchor, is there agreement of having any common
anchor points?
- AB: likes catalog part
- BC: likes it too, who would organize it?
- KW: like catalog too, but thinks the catalog should also contain
transformation to/from lower-level models
- AS: agrees that there can be a multiplicity of top-level models
- TN: this may need to be an informational draft
Moving on to Meta-Model Structure slides (Acee presenting)
- JS: re: logical network level, should different logical routers have
different NETCONF sessions?
- AC: sounds like an SNMP like solution
- SH: why policy under each protocol as opposed to at the top?
- AC: it's like an object can be applied to each protocol
- BC: how far we with YANG1.1 and is there anything useful in it for routing
design team?
- MB: ~1 open issue left and then will publish draft, should be ready for
WGLC.
- BC: when Y1.1 is published, we'll need to advertise it to other design teams
[Meeting Ends @ 11:50am ET]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
