Hi Alex,
Good questions, please see inline ...
On 23/06/2017 17:26, Alexander Clemm wrote:
Hi Robert,
We will do whatever is required to make the model future proof.
However, I am not quite sure of the particular ask. Perhaps this is my
limited understanding of NMDA. The following is really more of an NMDA
question: why would we require to duplicate the entire model under a -state
namespace, when we have different datastores and e.g. what is contained in
operational is "by definition" read-only? (Data that originated from
configuration is marked as intended) What would really be gained from that?
This extra -state tree is an interim solution only. I.e. it is to make
the NMDA model usable today on current devices that don't yet support
the operational datastore, rather than having to wait for NMDA
implementations to be available before the models are usable.
Once the devices support NMDA that they (probably) wouldn't implement
the extra "-state" module, as you say the same information is available
in the <operational> datastore with the same semantics.
Effectively what is reported in the extra "-state" tree is the same
information that would be reported in <operational>, and the semantics
should be the same.
Thanks,
Rob
The issue we were facing in the topology was that different instantiations
of the same (in the model) list element can originate from an intended
configuration, or it can be learned. If it is intended, it shows up in the
intended / config datastore, but ultimately all topology that is in effect
shows up in the operational datastore. It is not clear to me what this NMDA
guideline would provide in addition; it seems to not be needed and if
anything seems it would result in redundant operspecification of what's in
the operational datastore?
--- Alex
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Robert Wilton
Sent: Thursday, June 22, 2017 3:44 AM
To: Alexander Clemm <[email protected]>; [email protected]
Cc: 'Nitin Bahadur' <[email protected]>; 'Russ White' <[email protected]>;
'Xufeng Liu' <[email protected]>; [email protected]; 'Jan Medved
(jmedved)' <[email protected]>; [email protected]; 'Susan Hares'
<[email protected]>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
Hi Alex,
Do you think that it would be useful if the draft also included the extra
transient "-state" modules in an appendix (e.g. as per
draft-dsdt-nmda-guidelines-01 section 2)?
Specifically, I'm thinking to help make the topology module fully usable by
modules that augment it (e.g. by the TE modules if/when they adopt the NMDA
conventions), until NMDA implementations before widely available.
Thanks,
Rob
On 22/06/2017 06:29, Alexander Clemm wrote:
Hello I2RS Working Group,
This draft contains the updates to topology model as discussed in Chicago.
This concerned the issue about how to deal with the fact that we can
have configurable overlay topologies that are layered on top of
discovered, or "learned", underlay topologies. The solution simply relies
on the the
revised datastore architecture. The "server-provided" data node has been
removed; other than that the structure of the model can remain exactly
the same. The text has been updated accordingly to provide the
explanations.
--- Alex
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, June 21, 2017 10:03 PM
To: [email protected]
Cc: [email protected]
Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Interface to the Routing System of
the IETF.
Title : A Data Model for Network Topologies
Authors : Alexander Clemm
Jan Medved
Robert Varga
Nitin Bahadur
Hariharan Ananthakrishnan
Xufeng Liu
Filename : draft-ietf-i2rs-yang-network-topo-13.txt
Pages : 35
Date : 2017-06-21
Abstract:
This document defines an abstract (generic) YANG data model for
network/service topologies and inventories. The model serves as a
base model which is augmented with technology-specific details in
other, more specific topology and inventory models.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-13
https://datatracker.ietf.org/doc/html/draft-ietf-i2rs-yang-network-top
o-13
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-network-topo-13
Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
.
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
.
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
