Subject: Re: [mpls] [netmod] YANG - Intended-Config & Applied-Config & Derived-State & Operational-state...grrrr... !!

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 1 Apr 2016 11:02:07 +0200

Operational state often has a different lifetime than config. Hence,
keeping config and operational state together in the same structure
(with the same naming) causes you problems down the road.

/js

On Thu, Mar 31, 2016 at 06:44:06PM +0000, Rajiv Asati (rajiva) wrote:
> 
> While working on MPLS LDP yang model (https://tools.ietf.org/html/draft-raza-mpls-ldp-mldp-yang), we noticed the possible confusion around structuring intended config, applied config and derived state *.
> 
> On one hand, one may have 'intended-config’ (RW) and ‘applied-config’ (RO) in the same construct (container), and ‘derived state’ (RO) in a separate construct (container). 
> 
> 	This keeps config together, but doesn’t help operational state, which requires
> 	Both Applied-config and derived-state.
> 
> On the other hand hand, one may have ‘intended-config’ in one construct (container), and ‘applied-config’ and ‘derived state’ in a separate construct (container). 
> 
> 	This simplifies figuring operational-state, but divides the config types.
> 
> There are pros & cons either way. It would be good to have some guidance/text around guiding one over another, so that other models can leverage. Otherwise, we are going to end up with yet one more discrepancy (among various protocols YANG models), & confusing if not inefficient modeling.
> 
> Perhaps, we ditch both of the above approaches, and settle on keeping all three of them in the same construct. It might simplify the organization a bit. Of course, that also has 2 options - have all the data types in intended-config, and then in applied-config and then in derived-state. Or have intended-config, applied-config and derived-state for each data type. Latter might be slightly better, given that not every data type will have all three.
> 
> 
> Thoughts? 
> 
> -- 
> Cheers,
> Rajiv Asati
> Distinguished Engineer, Cisco
> 
> 
> * https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs <https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04>
> https://tools.ietf.org/html/draft-openconfig-netmod-opstate
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 4 Apr 2016 19:57:05 +0000

Hi Juergen,

> Operational state often has a different lifetime than config. Hence,

Hmm..Could you please clarify the above a bit more?

-- 
Cheers,
Rajiv

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Apr 2016 22:43:56 +0200

> Hmm..Could you please clarify the above a bit more?

The classic example:

When I pull out a configured interface, the operational state of this
interface is gone but not the config - if I put the interface back, it
should come up configured as before. Obviously, I can also have
operational state of an interface that has not been configured yet.

/js

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 6 Apr 2016 02:28:03 +0000

Hi Juergen,

Thanks for the clarity. I somewhat agree. Different lifetime shouldn't really cause any impact.

One nit,

When I pull out a configured interface, the operational state of this
interface is gone but not the config - if I put the interface back, it
should come up configured as before.

Depends. If LC itself is removed, then all the related interfaces would be removed from the running-config. And reinserting the LC may not bring their individual conf back (ignoring the notifications).

Obviously, I can also have
operational state of an interface that has not been configured yet.

Yes.

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services

On Apr 4, 2016, at 5:44 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

The classic example:

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Apr 2016 08:28:59 +0200

> Depends. If LC itself is removed, then all the related interfaces would be removed from the running-config. And reinserting the LC may not bring their individual conf back (ignoring the notificatio…

Assuming LC means line card if not discard the following (and explain
what LC means). I believe the answer here is that systems treat this
differently and there is no universal answer. Some systems seem to
store line card config on the line card itself, other systems
associate config with the physical location of a port or interface,
yet others associate config with a name of an interface (which may not
indicate the physical location of an interface). Since implementations
really differ here, we support multiple implementation options in the
interfaces data model.

/js

---

From: Gert Grammel <[email-masked]>
Date: Wed, 6 Apr 2016 14:08:17 +0000

This case is another reason why the intended config should not be touched
by the server. Juergen is right that there are lots of different
implementations. It is the implementer¹s choice where to put configuration
state. Typically if a server supports rollback, the state is stored in a
database, otherwise it is often stored directly on HW. Both versions
survive a reboot. If you remove the LC (=Line Card?) the result is either
a) intended = config != active in case of a central config repository or
b) intended != config = active in case of config stored on LC

a) is a case that is often tolerated or even desired, as it allows to
pre-configure HW before it becomes physically available. B) is an error
condition.

Gert

On 2016-06-04 03:28, "netmod on behalf of Juergen Schoenwaelder"
<[email-masked] on behalf of
[email-masked]> wrote:

>> Depends. If LC itself is removed, then all the related interfaces would
>>be removed from the running-config. And reinserting the LC may not bring
>>their individual conf back (ignoring the notifications).
>