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

From: [email-masked]
Date: Wed, 15 Apr 2015 17:46:42 -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 Working Group of the IETF.

        Title           : A Data Model for Network Topologies
        Authors         : Alexander Clemm
                          Jan Medved
                          Robert Varga
                          Tony Tkacik
                          Nitin Bahadur
                          Hariharan Ananthakrishnan
	Filename        : draft-ietf-i2rs-yang-network-topo-00.txt
	Pages           : 26
	Date            : 2015-04-15

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's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-00

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 (alex)" <[email-masked]>
Date: Thu, 16 Apr 2015 00:55:25 +0000

Hi,

we have just posted the general topology draft as a Working Group document.  Thank you all for your support so far, including the topology design team, our working group chairs, Sue, Jeff, and our area director, Alia.  There are a few minor updates over the previous version, mostly to bring this into alignment with IETF guidelines for YANG modules (such as ensuring descriptions for all the YANG nodes etc.).  There have been no changes to the overall structure.  

Kind regards
--- Alex (on behalf of the coauthors)

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, April 15, 2015 5:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-00.txt

Abstract:

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.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Apr 2015 08:23:08 +0200

> we have just posted the general topology draft as a Working Group document.  Thank you all for your support so far, including the topology design team, our working group chairs, Sue, Jeff, and our…

I like to repeat the question I asked in Dallas: Why is the generic
topology model split into two modules? This adds some significant
namespace overhead while I assume that most topology extensions need
both modules. My proposal is to merge ietf-network and
ietf-network-topology into a single module named ietf-network-topology.

I think some thought should also be given to simplify the references.
Right now, in order to refer to a termination point, I have to use a
triple (network-ref, node-ref, tp-ref). Have you considered using an
instance-identifier with require-instance instead? One option would be
to define proper typedefs such as

   typedef tp-ref {
     type instance-identifier { require-instance }
     description
       "An instance identifier refering to a termination point."
   }

and then things can be collapsed. One would likely do the same for
other model elements, that is introduce typdefs for node-ref, link-ref
network-ref. This will make the tree much more compact.

/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: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Apr 2015 09:02:32 +0200 (CEST)

> network-ref. This will make the tree much more compact.

There are two drawbacks with this scheme.  First, the model is less
precise.  An instance-identifier can refer to anything, and there is
not formal constraint in the model to restrict it to a termination
point.  Second, even if the data model becomes more compact, the
instance data with an instance-identifier is more verbose and maybe
harder to read for an operator (less "direct").

(BTW, I noticed that the intended status of this document is
Experiemental.  Is that intentional?)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Apr 2015 09:15:47 +0200

On Thu, Apr 16, 2015 at 09:02:32AM +0200, Martin Bjorklund wrote:
> point.

Hence you wrap it in a typedef with an appropriate description clause.
And by using the typedef, the model actually becomes more readable.

> Second, even if the data model becomes more compact, the

I love to hear from operators that they find

  /nt:network[foo]/nt:node[bar]/nt:termination-point[baz]

more complicated than this:

  <nt:network-ref>foo</nt:network-ref><nt:node-ref>bar</nt:node-ref><nt:termination-point>baz</nt:termination-point>

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Apr 2015 09:24:24 +0200

>   <nt:network-ref>foo</nt:network-ref><nt:node-ref>bar</nt:node-ref><nt:termination-point>baz</nt:termination-point>

Oops, I got it wrong:

    /nt:network[network-id="foo"]/nt:node[node-id="bar"]/nt:termination-point[tp-id="baz"]

    <nt:network-ref>foo</nt:network-ref><nt:node-ref>bar</nt:node-ref><nt:tp-ref>baz</nt:tp-ref>

Anyway, if I count characters, the instance-identifier is still shorter.

/js

PS: If the argument is that operators can't understand instance identifier,
    then NACM is horribly operationally broken. ;-)

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Apr 2015 09:31:15 +0200 (CEST)

> And by using the typedef, the model actually becomes more readable.

I think you get the same effect (readable model) by using groupings.

>   <nt:network-ref>foo</nt:network-ref><nt:node-ref>bar</nt:node-ref><nt:termination-point>baz</nt:termination-point>

This would be (XML):

  /nd:network[nd:network-id="foo"]/nd:node[nd:node-id="bar"]/nt:termination-point[nt:tp-id="baz"]

Compared with:

  <network-ref>foo</network-ref>
  <node-ref>bar</node-ref>
  <termination-point>baz</termination-point>

Or in JSON:

  /ietf-network:network-id[network-id="foo"]/node[node-id="bar"]/ietf-network-topology:termination-point[tp-id="baz"]

Compared with:

  "network-ref": "foo",
  "node-ref": "bar",
  "termination-point": "baz"

But yes, which one is easier to read and write is subjective.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Apr 2015 09:32:48 +0200 (CEST)

>     then NACM is horribly operationally broken. ;-)

No the argument is not that operators can't understand instance
identifiers.  The argument is that leafrefs are more precise and might
be easier to read and write than i-is.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 16 Apr 2015 13:37:34 +0200

> be easier to read and write than i-is.

Yes, instance-identifiers do not support a path restriction (I do not
recall why we did not consider to have this in YANG - but that does
not matter here).

I personally find a single 'pointer' value way easier to deal with
than a triple of values that together act as a single 'pointer' value.

/js

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 16 Apr 2015 22:47:15 +0000

Hi Juergen, Martin,

thank you for your comments!  Couple of brief responses.

-re: intended status experimental.  This is clearly a mistake/oversight.  Will fix this.

- re: dividing the model into two modules.  I agree it is possible to put them into one module - this is what we had in an earlier revision in fact together.  The reason why they were separated was to allow for a common umbrella for network inventory and topology - you could use the network module also for a network inventory (contained in the nodes), without additional topological information.  This is how Open Daylight chose to use it.  I share your sentiment that in general both will be implemented together, and you could still integrate inventory with a combined module (even without populating the topology portion - links, TPs - if so desired).  Ultimately, both are viable options; it's a design decision and it would be interesting to hear more feedback on this; as mentioned there is implementation precedent in ODL.  

- re: the identifier/referencing scheme, and potential use of instance-identifer as alternative.  The requirement is to express the constraint that  the references are to instances in the proper "underlay",  e.g., a supporting-node of a node needs to be in a supporting-network, which was reason for navigate the paths. 

--- Alex

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: Thursday, April 16, 2015 4:38 AM
To: Martin Bjorklund
Cc: Alexander Clemm (alex); [email-masked]
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-00.txt

> be easier to read and write than i-is.

Yes, instance-identifiers do not support a path restriction (I do not recall why we did not consider to have this in YANG - but that does not matter here).

I personally find a single 'pointer' value way easier to deal with than a triple of values that together act as a single 'pointer' value.

/js