Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

From: [email-masked]
Date: Wed, 21 Jun 2017 22:02:39 -0700

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-topo-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/

---

From: "Alexander Clemm" <[email-masked]>
Date: Wed, 21 Jun 2017 22:29:40 -0700

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-masked]] On Behalf Of
[email-masked]
Sent: Wednesday, June 21, 2017 10:03 PM
To: [email-masked]
Cc: [email-masked]
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.

Abstract:

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Robert Wilton <[email-masked]>
Date: Thu, 22 Jun 2017 11:44:00 +0100

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:
> .

---

From: "Alexander Clemm" <[email-masked]>
Date: Fri, 23 Jun 2017 09:26:44 -0700

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?

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-masked]] On Behalf Of Robert Wilton
Sent: Thursday, June 22, 2017 3:44 AM
To: Alexander Clemm <[email-masked]>; [email-masked]
Cc: 'Nitin Bahadur' <[email-masked]>; 'Russ White' <[email-masked]>;
'Xufeng Liu' <[email-masked]>; [email-masked]; 'Jan Medved
(jmedved)' <[email-masked]>; [email-masked]; 'Susan Hares'
<[email-masked]>
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:
> 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
> removed; other than that the structure of the model can remain exactly 
> the same.  The text has been updated accordingly to provide the
explanations.
> 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.

---

From: Robert Wilton <[email-masked]>
Date: Fri, 23 Jun 2017 17:37:16 +0100

Hi Alex,

Good questions, please see inline ...

> 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

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 26 Jun 2017 17:52:47 +0000

Hi Rob,
Inline <ALEX>, below
Thanks
--- Alex

---------- Forwarded message ----------
From: "Robert Wilton" <[email-masked]<mailto:[email-masked]>>
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" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Nitin Bahadur'" <[email-masked]<mailto:[email-masked]>>, "'Russ White'" <[email-masked]<mailto:[email-masked]>>, "'Xufeng Liu'" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Jan Medved (jmedved)'" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Susan Hares'" <[email-masked]<mailto:[email-masked]>>, "Kent Watsen" <[email-masked]<mailto:[email-masked]>>, "Martin Bjorklund" <[email-masked]<mailto:[email-masked]>>

Hi Juergen,

On 24/06/2017 14:17, Juergen Schoenwaelder wrote:

> On Thu, Jun 22, 2017 at 11:44:00AM +0100, Robert Wilton wrote:

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jun 2017 21:12:38 +0200

Hi,

someone needs to explain why the base topology model done in i2rs is
good enough NMDA style while the TEAS extension of it is not. Note
also that people are actively working on NC and RC extensions.

/js

-- 
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: Igor Bryskin <[email-masked]>
Date: Mon, 26 Jun 2017 19:22:57 +0000

Hi  Jorgen,
The reason is that TE topologies (e.g. anstract TE topologies) could be (re-)configured by a client, while I2RS topologies could not.
Igor

From:Juergen Schoenwaelder
To:Alexander Clemm,
Cc:Robert Wilton,'Xufeng Liu',[email-masked],
Date:2017-06-26 15:13:16
Subject:Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Hi,

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jun 2017 21:27:30 +0200

> The reason is that TE topologies (e.g. anstract TE topologies) could be (re-)configured by a client, while I2RS topologies could not.

What is 'client' and what is 'reconfigured' and why does that not
apply to i2rs topologies?

/js

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 26 Jun 2017 19:39:47 +0000

TE  topology model client is a client application that talks netconf/restconf with the server application implemting one or more TE topologies.
In contrast to I2RS topology server, which only exposes topologies (learnt for example via IGP) as state information,  TE topology model client can configure TE Topologies with all the implications, such as intended/applied, etc.

Igor
From:Juergen Schoenwaelder
To:Igor Bryskin,
Cc:Alexander Clemm,[email-masked],[email-masked],[email-masked],
Date:2017-06-26 15:27:49
Subject:Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Jun 2017 22:49:51 +0200

Perhaps you are right that I2RS never intends to configure topology,
this is what RFC 7920 and 7921 talk about. That said, the base
topology model clearly supports configured topologies (following the
NMDA approach) but then it seems for TEAS this is not workable.

Note that RESTCONF and NETCONF protocol extension proposal I-Ds are in
the making and the NETCONF charter is meanwhile in place with a target
date for this work in Nov 2017. Sure, we all know that it is difficult
to predict WG timing but creating a -state subtree may be something to
regret in a year from now.

/js

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 26 Jun 2017 22:51:22 +0000

Juergen,

Honestly, I don't even understand why I2RS topology model needs CONFIG=TRUE elements. Topology model is a network wide model. You do not configure physical topological elements (nodes and links) using topology model, they are discovered and passed to the client as data state.

Abstract TE nodes and links are different. It is typical for a client to request a particular abstract node configured in a way the client prefers to see a network domain (partially or in entirety). Consequently, not only CONFIG=TRUE elements are needed, the deltas between intended and applied configurations are quite likely.

Igor 

/js

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 27 Jun 2017 00:00:43 +0000

Igor,

Juergen is correct in that the topology model clearly needs to support both configurable as well as discovered topologies.  This is very clearly stated in the draft.  We had this decision also earlier and the conclusion was always that a read-only model that is only applicable to discoverable topologies is too narrow in scope.  

So, the topology model clearly allows for topologies that discovered and for topologies that are configured, including overlay topologies put on top of discovered underlays.  There are various use cases for that, including in the Open Daylight implementation. If we had wanted to do read-only, we would have been done a long time ago.  

Xufeng and I spoke earlier.  If we should include a -state version of the model in the appendix, we will do that, even if it feels redundant.  However, we are clearly not dropping support for configurable topology at this point.  

--- Alex

-----Original Message-----
From: Igor Bryskin 
Sent: Monday, June 26, 2017 3:51 PM
To: Juergen Schoenwaelder <[email-masked]>
Cc: Alexander Clemm <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Juergen,

>> Perhaps you are right that I2RS never intends to configure topology,
this is what RFC 7920 and 7921 talk about. That said, the base topology model clearly supports configured topologies (following the NMDA approach) but then it seems for TEAS this is not workable.

Igor 

Note that RESTCONF and NETCONF protocol extension proposal I-Ds are in the making and the NETCONF charter is meanwhile in place with a target date for this work in Nov 2017. Sure, we all know that it is difficult to predict WG timing but creating a -state subtree may be something to regret in a year from now.

/js

On Mon, Jun 26, 2017 at 07:39:47PM +0000, Igor Bryskin wrote:
> Cc:Alexander 
> Clemm,[email-masked],[email-masked],[email-masked],
> Date:2017-06-26 15:27:49

---

From: Kent Watsen <[email-masked]>
Date: Tue, 27 Jun 2017 00:39:42 +0000

Alex,

No one is asking you to drop support for configurable [overlay] topologies.  We all understand the need to be able to configure overlay topologies on top of discovered underlay topologies.

Kent

--

Igor,

--- Alex

-----Original Message-----
From: Igor Bryskin 
Sent: Monday, June 26, 2017 3:51 PM
To: Juergen Schoenwaelder <[email-masked]>
Cc: Alexander Clemm <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Juergen,

Igor 

/js

---

From: Igor Bryskin <[email-masked]>
Date: Tue, 27 Jun 2017 01:59:38 +0000

Alex,

I understand what you are saying, but are you aware of a use case in which a client of a network wouid configure topology of the network using I2RS network topology model?

Igor
From:Alexander Clemm
To:Igor Bryskin,Juergen Schoenwaelder,
Cc:[email-masked],[email-masked],[email-masked],
Date:2017-06-26 20:00:50
Subject:RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Igor,

--- Alex

-----Original Message-----
From: Igor Bryskin
Sent: Monday, June 26, 2017 3:51 PM
To: Juergen Schoenwaelder <[email-masked]>
Cc: Alexander Clemm <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Juergen,

Igor

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 27 Jun 2017 10:49:45 +0100

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:
> From: "*Robert Wilton*" <[email-masked] <mailto:[email-masked]>>
> To: "Alexander Clemm" <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] <mailto:[email-masked]>>, "'Nitin Bahadur'" 
> <[email-masked] <mailto:[email-masked]>>, "'Russ 
> White'" <[email-masked] <mailto:[email-masked]>>, "'Xufeng Liu'" 
> <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] <mailto:[email-masked]>>, "'Jan Medved 
> (jmedved)'" <[email-masked] <mailto:[email-masked]>>, 
> <[email-masked] <mailto:[email-masked]>>, "'Susan 
> Hares'" <[email-masked] <mailto:[email-masked]>>, "Kent Watsen" 
> <[email-masked] <mailto:[email-masked]>>, "Martin Bjorklund" 
> <[email-masked] <mailto:[email-masked]>>
>
> Hi Juergen,
> 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
> >

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 27 Jun 2017 13:23:38 +0000

As Alex mentioned in another email, we have discussed and agreed on the plan to move forward with both I2RS topology model and TE topology model, by adding the “-state” module. We will do it as quickly as possible.

Thanks,
- Xufeng

From: Robert Wilton [mailto:[email-masked]]
Sent: Tuesday, June 27, 2017 5:50 AM
To: Alexander Clemm <[email-masked]>; Xufeng Liu <[email-masked]>; [email-masked]
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

---------- Forwarded message ----------
From: "Robert Wilton" <[email-masked]<mailto:[email-masked]>>
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" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Nitin Bahadur'" <[email-masked]<mailto:[email-masked]>>, "'Russ White'" <[email-masked]<mailto:[email-masked]>>, "'Xufeng Liu'" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Jan Medved (jmedved)'" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Susan Hares'" <[email-masked]<mailto:[email-masked]>>, "Kent Watsen" <[email-masked]<mailto:[email-masked]>>, "Martin Bjorklund" <[email-masked]<mailto:[email-masked]>>

Hi Juergen,

network topology module.

is also good with me ;-)

<ALEX>

</ALEX>

Thanks,

Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 27 Jun 2017 14:44:14 +0100

Xufeng,

Thanks for the confirmation.  That hadn't been clear from the previous 
emails.

When you generate the "-state" modules, I would suggest that you also 
reuse and import any typedefs that you have in the original NMDA 
compliant module, rather than redefine them.  That should make it easier 
for implementers, both now and in the future.

Thanks,
Rob

On 27/06/2017 14:23, Xufeng Liu wrote:
>
> As Alex mentioned in another email, we have discussed and agreed on 
> the plan to move forward with both I2RS topology model and TE topology 
> model, by adding the “-state” module. We will do it as quickly as 
> possible.
>
> Thanks,
>
> - Xufeng
>
> *From:*Robert Wilton [mailto:[email-masked]]
> *Sent:* Tuesday, June 27, 2017 5:50 AM
> *To:* Alexander Clemm <[email-masked]>; Xufeng Liu 
> <[email-masked]>; [email-masked]
> *Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt
>
> Hi Alex,
>
> (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).
>
>     To: "Alexander Clemm" <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, "'Nitin Bahadur'"
>     <[email-masked] <mailto:[email-masked]>>, "'Jan
>     Medved (jmedved)'" <[email-masked] <mailto:[email-masked]>>,
>     <[email-masked] <mailto:[email-masked]>>,
>     "'Susan Hares'" <[email-masked] <mailto:[email-masked]>>, "Kent
>     Watsen" <[email-masked] <mailto:[email-masked]>>,
>     "Martin Bjorklund" <[email-masked] <mailto:[email-masked]>>
>
>
>     Hi Juergen,
>
>       
>
>       
>
>     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
>
>     >
>
>       
>

---

From: Alexander Clemm <[email-masked]>
Date: Tue, 27 Jun 2017 21:09:08 +0000

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.

You mention tooling that can automatically generate this.  Can you please point me to such a tool?  (If not, no problem, will update manually.)

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.

Thanks
--- Alex

From: Robert Wilton [mailto:[email-masked]]
Sent: Tuesday, June 27, 2017 2:50 AM
To: Alexander Clemm <[email-masked]>; 'Xufeng Liu' <[email-masked]>; [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Hi Alex,

Thanks,
Rob

---------- Forwarded message ----------
From: "Robert Wilton" <[email-masked]<mailto:[email-masked]>>
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" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Nitin Bahadur'" <[email-masked]<mailto:[email-masked]>>, "'Russ White'" <[email-masked]<mailto:[email-masked]>>, "'Xufeng Liu'" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Jan Medved (jmedved)'" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Susan Hares'" <[email-masked]<mailto:[email-masked]>>, "Kent Watsen" <[email-masked]<mailto:[email-masked]>>, "Martin Bjorklund" <[email-masked]<mailto:[email-masked]>>

Hi Juergen,

network topology module.

is also good with me ;-)

<ALEX>

</ALEX>

Thanks,

Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 28 Jun 2017 11:48:34 +0100

Hi Alex,

> –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

> *Sent:* Tuesday, June 27, 2017 2:50 AM
> *To:* Alexander Clemm <[email-masked]>; 'Xufeng Liu'

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 28 Jun 2017 17:51:00 +0000

Hi Rob,

Thank you

--- Alex

From: Robert Wilton [mailto:[email-masked]]
Sent: Wednesday, June 28, 2017 3:49 AM
To: Alexander Clemm <[email-masked]>; 'Xufeng Liu' <[email-masked]>; [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Hi Alex,

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:[email-masked]]
Sent: Tuesday, June 27, 2017 2:50 AM
To: Alexander Clemm <[email-masked]><mailto:[email-masked]>; 'Xufeng Liu' <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-13.txt

Hi Alex,

Thanks,
Rob

---------- Forwarded message ----------
From: "Robert Wilton" <[email-masked]<mailto:[email-masked]>>
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" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Nitin Bahadur'" <[email-masked]<mailto:[email-masked]>>, "'Russ White'" <[email-masked]<mailto:[email-masked]>>, "'Xufeng Liu'" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Jan Medved (jmedved)'" <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, "'Susan Hares'" <[email-masked]<mailto:[email-masked]>>, "Kent Watsen" <[email-masked]<mailto:[email-masked]>>, "Martin Bjorklund" <[email-masked]<mailto:[email-masked]>>

Hi Juergen,

network topology module.

is also good with me ;-)

<ALEX>

</ALEX>

Thanks,

Rob