Report from the Data Store Design Team Breakout

Report from the Data. Store Design Team Breakout Session draft-nmdsdt-netmod-revised-datastores-00 IETF 97

Breakout Session • • • Meet Wednesday 1: 30 -7 pm Lots of questions and clarifications No changes in the design A positive experience Walked thru Implications and Issues

New Issues in the draft • Examples • More descriptive text • Timeliness – Data in <running> should appear in sync with <intended> – Data in <applied> should appear in sync with <operational-state> • "Factory default" config

Example 1: simple config • • Straight-forward config example Full walk through edit-config->running->intended->applied->op Discuss templates and inactives

Example 2: system-controlled • Loopback interface – implicitly created by system • In <operational-state> – <interface origin="system><name>lo 0<. . . > • Part 2 adds user config – Now explicitly in <running> and <intended> – <interface origin="static"><name>lo 0<. . . >

Example 3: delayed cleanup • BGP Peer list – Explicitly created in <running> – Fully populated • In <operational-state> with origin="system" • local-address and local-port • Delete five peers and commit – Peers continue to appear until "released" • Sockets closed and local resources released • In both <applied> and <operational-state>

Example 4: ephemeral data • Interfaces created in <running> • No installed FRU • Interfaces do not appear in <applied> or <operational-state> • When FRU is plugged in: – Interface is created and populated with data – Unconfigured ports of installed FRUs will exist – Statistics are initialized to zeroes (like new) • Key is that FRUs do not break config validation • Only FRU-related, not "logical" interfaces – LAG interface with no installed member interfaces

Example 5: dynamic data • Unnamed dynamic data source – Don't want to address the i 2 rs issues here • Data merged with <intended> into <active> • Issue: fix arrows for "after" control-plane datastores?

Issues • <active> – No need • constraints on <applied> and <operational-state> – SHOULD for "when" – "expected" for others – No point modeling rules that aren't followed, but Postel Principle applies • <applied> in RESTCONF: take to NETCONF WG – Disagreement of goals of RESTCONF • Does it need all NETCONF capabilities? • Is it the "Easy" button?