Hi Alex,
On 27/06/2017 22:09, Alexander Clemm wrote:
Hi Robert,
We will add it to the draft.
This will presumably also affect the l3-topo draft, to augment the
–state with its own –state tree.
Yes, I would think so.
You mention tooling that can automatically generate this. Can you
please point me to such a tool? (If not, no problem, will update
manually.)
Not that is robust enough at the moment, it needs some more work.
Will investigate use of grouping and uses statements. In that case
the –state module could simply use the grouping defined in the
NMDA-compliant module.
Groupings can sometimes be shared, but I think that gets more complex,
so life is easier if you don't try and optimize them.
I think that the conversion steps are:
1) Take a copy of the NMDA module and add "-state" to the name of the
module, and also in the namespace.
2) Add "-s" to the prefix.
3) Delete any typedefs/identities and import from the original NMDA
module instead.
4) Fixup up augments to augment the "-state" module path instead of the
NMDA config tree, and add any required imports.
5) Check xpath expressions. Paths that are relative and internal to the
module should be fine, absolute paths may need to be updated to use the
equivalent -state module (if it exists).
Thanks,
Rob
Thanks
--- Alex
*From:*Robert Wilton [mailto:rwil...@cisco.com]
*Sent:* Tuesday, June 27, 2017 2:50 AM
*To:* Alexander Clemm <alexander.cl...@huawei.com>; 'Xufeng Liu'
<xufeng_...@jabil.com>; i2rs@ietf.org
*Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
Hi Alex,
If you need to represent learned topologies before NMDA compliant
implementations are available then you need the extra -state module
(i.e. a copy of the NMDA compatible I2RS topology module, but with
name appended with -state and all nodes set as config false). This
could be generated via tooling, put into github, or added in an
appendix to the draft.
Without this, then the existing I2RS topology module can only be used
to represent configured topologies on non NMDA compliant
implementations (specifically any implementations that don't expose
the operational state datastore).
For NMDA compliant implementations the network topology module in
draft -13 works well.
Thanks,
Rob
On 26/06/2017 18:52, Alexander Clemm wrote:
Hi Rob,
Inline <ALEX>, below
Thanks
--- Alex
---------- Forwarded message ----------
From: "*Robert Wilton*" <rwil...@cisco.com <mailto:rwil...@cisco.com>>
Date: Mon, Jun 26, 2017 at 1:53 AM -0700
Subject: Re: [i2rs] I-D Action:
draft-ietf-i2rs-yang-network-topo-13.txt
To: "Alexander Clemm" <lud...@clemm.org
<mailto:lud...@clemm.org>>, <i2rs@ietf.org
<mailto:i2rs@ietf.org>>, "'Nitin Bahadur'"
<nitin_baha...@yahoo.com <mailto:nitin_baha...@yahoo.com>>, "'Russ
White'" <r...@riw.us <mailto:r...@riw.us>>, "'Xufeng Liu'"
<xufeng_...@jabil.com <mailto:xufeng_...@jabil.com>>,
<h...@packetdesign.com <mailto:h...@packetdesign.com>>, "'Jan
Medved (jmedved)'" <jmed...@cisco.com <mailto:jmed...@cisco.com>>,
<robert.va...@pantheon.sk <mailto:robert.va...@pantheon.sk>>,
"'Susan Hares'" <sha...@ndzh.com <mailto:sha...@ndzh.com>>, "Kent
Watsen" <kwat...@juniper.net <mailto:kwat...@juniper.net>>,
"Martin Bjorklund" <m...@tail-f.com <mailto:m...@tail-f.com>>
Hi Juergen,
On 24/06/2017 14:17, Juergen Schoenwaelder wrote:
> On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote:
>> 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.
>>
> Rob,
>
> the less we have of those transient "-state" trees, the better it is.
> For LMAP (in auth48) we did not do this. These extra "-state" trees
> should ideally only be used in very rare cases, I think existing code
> already works with a single tree (at least this is what I understood
> from the OpenDaylight discussions).
I completely agree with you in general, but for the topology module I
think that the -state tree is required to represent topologies that
exist but have not been configured (e.g. perhaps those learned from a
dynamic routing protocol).
Also copying Kent and Martin, since they were very both very involved in
the discussions on the I2RS alias discussing the structure of the I2RS
network topology module.
My interpretation is from Xufeng was it is needed for the TE YANG
modules, but if it turns out that it is not actually needed, then that
is also good with me ;-)
<ALEX>
The need to represent topologies that are learned is certainly
there. It is not exclusive to TE, and I would be surprised if TE
YANG modules have an extra need for a separate state tree.
Probably the best person to comment here is Xufeng, but it sounds
to me, also per Juergen’s comments, that an extra state tree will
_/not/_ be needed.
</ALEX>
Thanks,
Rob
>
> /js
>
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs
