Subject: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

From: Alia Atlas <[email-masked]>
Date: Wed, 6 Nov 2013 21:23:17 -0500

I'd really like to start a conversation about the differences between a
topology IM model that is network-centric vs. device-centric.  Clearly the
WG has strong and different opinions about it.

Since many people are here in Vancouver, focused on IETF and not their
day-jobs, this seems like a good time to get it rolling...

Alia

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 7 Nov 2013 05:11:39 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alia Atlas
> Sent: Wednesday, November 06, 2013 6:23 PM
> To: [email-masked]
> Subject: [i2rs] topology info model - what makes it a "network" model
> vs. a "device" model
> 
> I'd really like to start a conversation 

...ok...so go ahead. :)

> about the differences between a
> topology IM model that is network-centric vs. device-centric.  
> Clearly
> the WG has strong and different opinions about it.

Are there really differences of opinion about what the difference is between a network model and a device model?  A network is a plurality of devices, and a network model is something which deals with a system resulting from the use of more than one device.  (ok, yes, a network of one node is a corner case blah blah handwave...).  I don't see how there could be any real debate around this, but if there is I'm quite interested in what it might be.

It feels like the real question is whether i2rs should have network models in scope.  

If Yes: ok, cool.  But between link properties (that is, at least some kind of topology view), counter dumps, debugs, routing, MPLS, and LAG member rebalancing, show me what's *not* in scope.  

If Not: what problems arise that would be solved by having a network model, do we need one, and where would it come from if not i2rs?  

eric

---

From: "Russ White" <[email-masked]>
Date: Thu, 7 Nov 2013 01:16:12 -0500

> Are there really differences of opinion about what the difference is
between
> a network model and a device model?  A network is a plurality of devices,
> and a network model is something which deals with a system resulting from
> the use of more than one device.  (ok, yes, a network of one node is a
corner
> case blah blah handwave...).  I don't see how there could be any real
debate
> around this, but if there is I'm quite interested in what it might be.

Agreed--both seem necessary, but different beasts (see the discussion on
sdnrg right now --same problem, different names). 

> It feels like the real question is whether i2rs should have network models
in
> scope.

Right...

I think network models at this point in the game might be useful to make
certain we are getting all the information we need from the models at the
protocol and device levels... In other words, there are things the network
model cares about that a device model isn't going to care about. In other
words, if we only look at protocol level use cases, we might miss some
pieces of information we'll eventually need for building network topologies,
or that sort of thing.

> If Yes: ok, cool.  But between link properties (that is, at least some
kind of
> topology view), counter dumps, debugs, routing, MPLS, and LAG member
> rebalancing, show me what's *not* in scope.

This is the problem on the other end, however... It's better, IMHO, to start
with a single small set of problems and solve them in a way that
specifically allows extensions to solve other problems. If we try to model
every possible problem, to make certain we have accounted for every possible
situation, well, we'll never actually do anything but describe problems. I'm
pretty familiar with the "describing problems all the time" process, as I
have kids... :-) (Oh, I'm glad they don't read this list, because they'd
really be mad at me about now!).

So I think it's valuable to describe these network models, and think about
them. OTOH, I'm really concerned we're going to get bogged down in them, and
take up a lot of time reading and accounting for them, which could well
divert us (even more!) from picking a small set of well-defined problems and
solving them in an extensible way. I think that's the point Joel was trying
to make at the mic today, btw...

:-)

Russ

---

From: Nikolay Milovanov <[email-masked]>
Date: Thu, 7 Nov 2013 09:17:52 +0200

Hi,

I might be completely wrong but from a brief overview of the Topology API
Use Cases my guess would be.

The topology data model will be an undirected graph with nodes, edges with
certain properties representing part of the network topology  and the
device centric model will be something hierarchical with a root object the
network device its interfaces, their IPs, the protocols working on them and
the neighbor devices learned dynamically by those protocols.

Most likely the network-centric topology models coming from each of the
devices will have to be merged by the network topology manager in order the
rest of the applications to be able to benefit from a complete model of the
entire network topology.

In my opinion either of the models will be extremely useful for all kinds
of OSS applications related to network service provisioning and
fulfillment. Currently is quite difficult to build any of them by means
such as CLI parsing and SNMP. Netconf is not bad but still an API will be
much better :)

BR,
Nikolay Milovanov

Network Engineer
[email-masked]

On Thu, Nov 7, 2013 at 8:16 AM, Russ White <[email-masked]> wrote:

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

-- 
BR,

Nikolay Milovanov
Network Engineer
Email: [email-masked]

---

From: Alia Atlas <[email-masked]>
Date: Thu, 7 Nov 2013 02:59:15 -0500

Hi,

Yes - so what I'm really trying to do is elicit what the points of concern
and different options are as far as modeling the topology information from
a device.   draft-medved-i2rs-topology-im has changed only minimally since
last IETF - and in ways that don't seem to address any of the disagreements
or concerns.

We need to be sure to bite off the right-sized first chunk to do.

If we have a device-centric model showing interfaces and so on, then
there's not a good way to express the learned IGP topology.  Would we then
need a different IM - perhaps as part of an IGP-specific IM - to
communicate the topology learned via the IGP?  Would that be preferable?

Given that the active IGP topology can be learned via BGP-LS, are we better
off focusing on an interface-focused IM (whether that is a device model or
an interfaces model or...)?

I'd really like to make significant progress in understanding the
perspectives and thoughts of the WG on this.   I understand that all these
things may be useful but in our usual ocean-boiling-avoidance method, we've
got to prioritize.

I'm also not comfortable on having only one IM for basing all our
requirements off of.

So - more thoughts?

Alia

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Thu, 7 Nov 2013 08:04:59 +0000

Hi Alia,

Thanks for starting the conversation :-)

IMO, the lines between 'network-centric' and 'device-centric' are a little blurred. For the sake of argument, let me agree with Joel that the I2RS WG's scope should be limited to a single routing system. Let me ask a few questions then:

  *   Is an OSPF router or an IS-IS router a 'routing system', as defined in the WG charter? If yes, would its LSDB be considered 'topology information' as defined in the WG charter?  And if the the answer to the latter question is yes, would reading the LSDB information from the router via a tbd. I2RS protocol be considered 'extraction of information about topology from the network', as defined in the WG charter?
  *   Is a BGP Router Reflector a routing system, as defined in the WG charter of the WG? If yes, would the LSDB information (potentially collected from multiple IGP areas) in RR's BGP-RIB be considered 'topology information' as defined in the WG charter? And if the the answer to the latter question is yes, would reading the LSDB information from the RR be considered 'extraction of information about topology from the network', as defined in the WG charter? And if the BGP RR implements BGP-LS, would extracting the LSDB information from the RR be in scope of the WG? Could BGP-LS actually be considered a candidate for an I2RS protocol  that would  be 'extracting information about topology from the network'?

Thanks,
Jan

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 6, 2013 6:23 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

I'd really like to start a conversation about the differences between a topology IM model that is network-centric vs. device-centric.  Clearly the WG has strong and different opinions about it.

Since many people are here in Vancouver, focused on IETF and not their day-jobs, this seems like a good time to get it rolling...

Alia

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Thu, 7 Nov 2013 08:51:02 +0000

From: Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, November 6, 2013 11:59 PM
To: Nikolay Milovanov <[email-masked]<mailto:[email-masked]>>
Cc: Russ White <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Eric Osborne (eosborne)" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

Hi,

Yes - so what I'm really trying to do is elicit what the points of concern and different options are as far as modeling the topology information from a device.   draft-medved-i2rs-topology-im has changed only minimally since last IETF - and in ways that don't seem to address any of the disagreements or concerns.

If we have a device-centric model showing interfaces and so on, then there's not a good way to express the learned IGP topology.  Would we then need a different IM - perhaps as part of an IGP-specific IM - to communicate the topology learned via the IGP?  Would that be preferable?

If we decide that topology learned via the IGP is indeed in scope WG to go, then the IGP-specific IMs are already defined in draft-medved-i2rs-topology-im.

Given that the active IGP topology can be learned via BGP-LS, are we better off focusing on an interface-focused IM (whether that is a device model or an interfaces model or...)?

The same topology I'm model would apply to BGP-LS and to IGPs.

I'd really like to make significant progress in understanding the perspectives and thoughts of the WG on this.   I understand that all these things may be useful but in our usual ocean-boiling-avoidance method, we've got to prioritize.

IMHO, it is actually easier to define the base network topology IM than the device IMs from which a network topology can be 'stitched together'. The base network topology IM is simple: it's a directed graph with nodes, links and termination points. The base network topology IM can be easily augmented (extended) to cover L1-L3 networks, VPNs, etc. On the other hand, there is a variety of information (in devices and in other systems) that can (must be) be used to 'stitch' together a network topology: dynamically learned neighbor info (LLDP for example for L2, IGP neighbor info for L3, for example), statically configured neighbor info in device configurations, IGP LSDB, IGP configurations, inventory systems, interface data (interface type, speed, …), LAGs, etc. Trying to model all of this can turn out to be quite a chunk to bite off.

I'm also not comfortable on having only one IM for basing all our requirements off of.

I don't understand what you mean - can you please explain?

So - more thoughts?

The charter does not say anything about 'device-centric' or 'network-centric' IMs - it talks merely about 'topology information'. Can you define what 'device-centric' and 'network-centric' is?  Would 'device-centric' be information that a client could get from a single routing system device, without a third party data aggregator, such as the Topology Manager or a Controller? Or would 'device-centric' be strictly information about the device, in which case an LSDB (or even neighbor info) would not be in scope? How would you define 'network-centric'?

Could we also consider IM criteria such as useful/useless, easy-to-model/difficult-to-model, easy-to-use/difficult-to-use, easy-to-extract/difficult-to-extract? IOW, what kind of topology IM would be most useful to apps, relatively easy to model (and where an initial model could be expanded for different use cases), and relatively easy to obtain from the network?

Alia

Thanks,
Jan

On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I might be completely wrong but from a brief overview of the Topology API Use Cases my guess would be.

The topology data model will be an undirected graph with nodes, edges with certain properties representing part of the network topology  and the device centric model will be something hierarchical with a root object the network device its interfaces, their IPs, the protocols working on them and the neighbor devices learned dynamically by those protocols.

Most likely the network-centric topology models coming from each of the devices will have to be merged by the network topology manager in order the rest of the applications to be able to benefit from a complete model of the entire network topology.

In my opinion either of the models will be extremely useful for all kinds of OSS applications related to network service provisioning and fulfillment. Currently is quite difficult to build any of them by means such as CLI parsing and SNMP. Netconf is not bad but still an API will be much better :)

BR,
Nikolay Milovanov

Network Engineer
[email-masked]<mailto:[email-masked]>

between
corner
debate

in

Right...

kind of

:-)

Russ

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

--
BR,

Nikolay Milovanov
Network Engineer
Email: [email-masked]<mailto:[email-masked]>

---

From: "Russ White" <[email-masked]>
Date: Thu, 7 Nov 2013 09:21:38 -0500

> If we have a device-centric model showing interfaces and so on, then
there's
> not a good way to express the learned IGP topology.  Would we then need a
> different IM - perhaps as part of an IGP-specific IM - to communicate the
> topology learned via the IGP?  Would that be preferable?

Yes, you are going to need different network models for different protocols,
services, etc. There's not going to be any way to combine such models into a
"coherent whole."

On the other hand, all of these various models must meet in the interface to
individual devices, and hence the model of the individual device and any
protocols used to communicate with those individual devices. For the moment,
the most useful thing I think we can take from these models is to
understand, and plan for (if not incorporate immediately), the information
they need to gather from individual devices in order to actually be built.
So use cases are interesting in this space, though I'm still very concerned
about the split or balance between "now" work and "building the foundation
for later work." I consider network models "building the foundation for
later," work, with the caveat that we need to make certain there is
flexibility enough in the individual device model to accommodate the
information needed to build a network model.

If that makes sense. It's early, and I'm in a different time zone, so...

:-)

Russ

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Nov 2013 15:53:47 +0100

> services, etc. There's not going to be any way to combine such models into a

Data models for different protocols such as OSPF or BGP have so far
been done in WGs that care about those protocols and this has
generally worked well as far as I can tell. We are now moving towards
YANG models for configuration and state data and a general framework
for YANG routing models has been defined in the NETMOD WG [1] (the
next update of this document will go to WG last call). We expect that
BGP, OSPF, ... specific extensions of this core routing model will be
produced and we envision that this work takes place in the routing
area, e.g., in WGs maintaining these routing protocols. Of course,
we first need concrete proposals to start from.

I think what I am saying is that (a) there is work going on outside of
I2RS and we better avoid overlapping activities and (b) I like to
remind you that work can be split and it is not necessary that I2RS 
creates all data models on its own.

/js

[1] http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-11

-- 
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: "Russ White" <[email-masked]>
Date: Thu, 7 Nov 2013 10:13:53 -0500

> I think what I am saying is that (a) there is work going on outside of
I2RS and
> we better avoid overlapping activities and (b) I like to remind you that
work
> can be split and it is not necessary that I2RS creates all data models on
its
> own.

Of course! The first point seems to be to decide what models are needed, the
second to decide where that work should be done, or if there is work that
already fits what needs to be done. I'm more concerned about where and how
these models are useful for the moment, not from the perspective of how they
can be used, but rather from how the impact the models needed to "make I2RS
go." IE, what do these models tell us about protocol and device model
requirements?

:-)

Russ

---

From: Ken Gray <[email-masked]>
Date: Thu, 7 Nov 2013 15:51:27 +0000

While the question of WHERE the models finally get submitted is reasonable (a fact I made to the preliminary discussion around creating NETCONF/Yang models in the ONF for everything the wire protocol didn't easily cover), the fact that the models are being developed (as mentioned below) is more accidental than planned, IMHO.  

That's the fundamental point - for me.  Without THIS WG's mandate to do create such models and do so in an agreed upon and cohesive manner (which is what Jan is going on about - "here's the BASE model, and examples of how to extend it ... that's topology, let's use this as a method for the other shite on the list"), you're going to have either a very incoherent/potentially-chaotic result OR an eventual return to the entropy that has stifled innovation for years prior.

So, IMHO, I'm happy to hear that work is going on in other WGs but worried about whether it is being tracked toward a common goal and (ultimately) forms a cohesive model in the whole - be it for network/topology or device.

I'd add as well that other SDO-like organizations are considering doing some of this modeling in the gold-rush to create a "NorthBound API" for SDN, motherhood and apple-pie.  So, if we keep on our current vector (providing no oversight and expecting things to organically blossom where interest lies) we may end up with a different result than any of us are contemplating.
________________________________________
From: [email-masked] <[email-masked]> on behalf of Juergen Schoenwaelder <[email-masked]>
Sent: Thursday, November 07, 2013 9:53 AM
To: Russ White
Cc: 'Eric Osborne (eosborne)'; [email-masked]; 'Nikolay Milovanov'; 'Alia Atlas'
Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

/js

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 07 Nov 2013 11:15:42 -0500

If I thought we could get away with not having protocol specific 
information models, then trying to design a protocol independent 
topology model for use with the network elements would seem applicable.

But, as it stands, even if we had such a model, we would still need 
protocol specific models, which would be having to manipulate many 
aspects related to the common model.

The argument that an abstracted model is useful when you are northbound 
from the topology manager is very understandable and attractive.  But 
northbound from the topology manager is not our working space.

Yours,
Joel

On 11/7/13 3:51 AM, Jan Medved (jmedved) wrote:
>
>
> From: Alia Atlas <[email-masked] <mailto:[email-masked]>>
> To: Nikolay Milovanov <[email-masked] <mailto:[email-masked]>>
> Cc: Russ White <[email-masked] <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "Eric
> Osborne (eosborne)" <[email-masked] <mailto:[email-masked]>>
>     Yes - so what I'm really trying to do is elicit what the points of
>     concern and different options are as far as modeling the topology
>     information from a device.   draft-medved-i2rs-topology-im has
>     changed only minimally since last IETF - and in ways that don't seem
>     to address any of the disagreements or concerns.
>
>     there's not a good way to express the learned IGP topology.  Would
>     we then need a different IM - perhaps as part of an IGP-specific IM
>     - to communicate the topology learned via the IGP?  Would that be
>     preferable?
>
>
> If we decide that topology learned via the IGP is indeed in scope WG to
> go, then the IGP-specific IMs are already defined
> in draft-medved-i2rs-topology-im.
>
>
>     Given that the active IGP topology can be learned via BGP-LS, are we
>     better off focusing on an interface-focused IM (whether that is a
>     device model or an interfaces model or...)?
>
>
>     perspectives and thoughts of the WG on this.   I understand that all
>     these things may be useful but in our usual ocean-boiling-avoidance
>     method, we've got to prioritize.
>
>
> IMHO, it is actually easier to define the base network topology IM than
> the device IMs from which a network topology can be 'stitched together'.
> The base network topology IM is simple: it's a directed graph with
> nodes, links and termination points. The base network topology IM can be
> easily augmented (extended) to cover L1-L3 networks, VPNs, etc. On the
> other hand, there is a variety of information (in devices and in other
> systems) that can (must be) be used to 'stitch' together a network
> topology: dynamically learned neighbor info (LLDP for example for L2,
> IGP neighbor info for L3, for example), statically configured neighbor
> info in device configurations, IGP LSDB, IGP configurations, inventory
> systems, interface data (interface type, speed, …), LAGs, etc. Trying to
> model all of this can turn out to be quite a chunk to bite off.
>
>
> The charter does not say anything about 'device-centric' or
> 'network-centric' IMs - it talks merely about 'topology information'.
> Can you define what 'device-centric' and 'network-centric' is?  Would
> 'device-centric' be information that a client could get from a single
> routing system device, without a third party data aggregator, such as
> the Topology Manager or a Controller? Or would 'device-centric' be
> strictly information about the device, in which case an LSDB (or even
> neighbor info) would not be in scope? How would you define
> 'network-centric'?
>
> Could we also consider IM criteria such as useful/useless,
> easy-to-model/difficult-to-model, easy-to-use/difficult-to-use,
> easy-to-extract/difficult-to-extract? IOW, what kind of topology IM
> would be most useful to apps, relatively easy to model (and where an
> initial model could be expanded for different use cases), and relatively
> easy to obtain from the network?
>
>
>     Alia
>
>
> Thanks,
> Jan
>
>
>     On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi,
>
>         I might be completely wrong but from a brief overview of
>         the Topology API Use Cases my guess would be.
>
>         The topology data model will be an undirected graph with nodes,
>         edges with certain properties representing part of the network
>         topology  and the device centric model will be something
>         hierarchical with a root object the network device its
>         interfaces, their IPs, the protocols working on them and the
>         neighbor devices learned dynamically by those protocols.
>
>         Most likely the network-centric topology models coming from each
>         of the devices will have to be merged by the network topology
>         manager in order the rest of the applications to be able to
>         benefit from a complete model of the entire network topology.
>
>         In my opinion either of the models will be extremely useful for
>         all kinds of OSS applications related to network service
>         provisioning and fulfillment. Currently is quite difficult to
>         build any of them by means such as CLI parsing and SNMP. Netconf
>         is not bad but still an API will be much better :)
>
>         BR,
>         Nikolay Milovanov
>
>         Network Engineer
>         [email-masked] <mailto:[email-masked]>
>
>
>
>
>             [email-masked] <mailto:[email-masked]>
>         Email: [email-masked] <mailto:[email-masked]>
>
>
>
>

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Thu, 7 Nov 2013 16:49:19 +0000

Hi Juergen

>creates all data models on its own.

I2RS is not chartered to develop data models  - it's chartered to develop
*information models*. Not that I agree or disagree, I am just pointing out
a subtle difference, which however has a practical impact: for example,
for the topology model, we first developed a yang data model which was
presented in the netmod WG. Then we also created a corresponding
information model which was presented in the i2rs WG. For the I2RS RIB
information model, there is a corresponding RIB yang data model, where we
worked with Lada and aligned it with [1]. We would want to present it at
the next IETF.

So, there are no overlapping activities - the way the I2RS charter is
defined, the WG operates at a different level. It has yet to decide what
data modeling language should be adopted for i2rs, or whether data models
would be developed in the WG.

Thanks,
Jan

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 7 Nov 2013 12:05:54 -0500

Given the discussions in the other thread, I would assume that nothing in I2RS is network centric, it is only device centric
and interface between client and agent pair, anything beyond that is, out-of-scope, right??

/Himanshu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, November 06, 2013 9:23 PM
To: [email-masked]
Subject: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

Alia

---

From: Nikolay Milovanov <[email-masked]>
Date: Thu, 7 Nov 2013 19:15:34 +0200

Isn't it a case that we will have a device information model which will contain information also about a topology view as seen from the perspective of the particular device. 

In the end to build a network centric info/data model out of this the network topology manager will have to collect and transform information gained from many network devices. 

Nikolay

---

From: "Fedyk, Don" <[email-masked]>
Date: Thu, 7 Nov 2013 17:59:45 +0000

Hi,

>From an IM standpoint a network wide view is useful to "scope" the view.

Then you could map various views of the device with ever increasing scope:
1) What is contained on the device (local configured)
2) What is contained on the device in the RIB/interfaces etc(local operational state: Interface, connection/MPLS LSP etc)
3) What is contained in the various IGP/EGP databases etc , (local from 2 put in Device LSAs/TE etc).
4 )What is contained in the various IGP/EGP databases etc (Local and neighbor view).

These are ever increasing subsets of the complete Network information model but they are not the complete Network model. And each level does not contain the level below but may only see a summary/partial view.
In my view you could stop at 3 and still get a complete Network model by extracting up to 3 on every device.  Whether you included below 3 which is not really visible to routing is also a question.
Including 4 would seem to be a cross check of what is in 3 but it has increasing temporal issues.

I'd argue for 3.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Thursday, November 07, 2013 2:59 AM
To: Nikolay Milovanov
Cc: Russ White; [email-masked]; Eric Osborne (eosborne)
Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

Hi,

So - more thoughts?

Alia

BR,
Nikolay Milovanov

Network Engineer

between
corner
debate

in
Right...

kind of

:-)

Russ

--
BR,

Nikolay Milovanov
Network Engineer

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 7 Nov 2013 10:31:55 -0800

> would be developed in the WG.

	Spot on. 

	--Tom

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 7 Nov 2013 19:39:54 +0100

> would be developed in the WG.

Yes, I am aware of the difference. The point, however, is that
creating consistent data and information models that provide a
reasonable coverage is a huge task and it either requires very tight
coordination between WGs running at different speeds or a kitchen sink
WG that tries to get all done in one place. Both options are very
difficult to implement in the IETF. At the end of the day, it is not
useful for running networks if information models and data models
developed within the IETF are not consistent.

So from a larger perspective, there is an interesting scoping and
coordination challenge here that we need to manage somehow.

/js

---

From: Shane Amante <[email-masked]>
Date: Thu, 7 Nov 2013 11:12:14 -0800

> In the end to build a network centric info/data model out of this the network topology manager will have to collect and transform information gained from many network devices. 

+1.

I believe I may be observing a tension between the traditional IETF view of "how do I make two devices communicate together", i.e.: what's the protocol that allows that communication to occur robustly, vs. an operator view of "Sure, I need protocols to make two devices talk to each other, but what's more critical for my business is to look at the whole network, which is a collection of devices".  A Network Topology Information Model would assist operators with having a cohesive view of the overall "network as a system", because that's the foundation upon which _services_ are delivered ... both within the data-path between various NE's and on top of various NE's.  

So, +1 to network-centric topology IM model.  

-shane

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 07 Nov 2013 15:39:15 -0500

> If Not: what problems arise that would be solved by having a network model, do we need one, and where would it come from if not i2rs?

I think it is useful to have a network-wide topology model that is 
accessible at a device level.  Meaning, topology could be distributed 
into the network and retrievable either as a whole network or in parts 
based on filters.  For example, given an I2RS Agent, give me the Agent 
plus two routed hops.  This would be very useful, for example, in the 
support case where we need to understand what a network looks like in 
order to help troubleshoot problems.

But, I could also ask this same Agent to give me the whole routed 
network from a given instance.  This would give me the graph (edges, 
nodes) of that topology.

Joe

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 7 Nov 2013 20:51:32 +0000

If you want to get the link state for an entire network there are two ways to do it:

1) the i2rs client fetches each node's link state info from that node, and plugs them together to make a network,
2) the i2rs client fetches the entire LSDB from one node.  

IMO either one is OK, and #2 makes the most sense.  In any case it's a read-only thing so it doesn't really matter how it gets done.

Where it gets hairy is when you want to write to the network.  The question that kicked off this thread was along those lines, if I recall.  If you want to get a mutex on the network as a whole you *need* a way to lock all devices.  Perhaps this is best done in the client - acquire a lock on the config for each node in the network, make your changes, then unlock.  If there were a higher level way to do this with some sort of network API that's what it would have to do under the covers anyways.  And if you have locking write access to the client then you don't need a network model, just a router model.

eric

> From: Joe Clarke (jclarke)
> Sent: Thursday, November 07, 2013 12:39 PM
> To: Eric Osborne (eosborne); Alia Atlas; [email-masked]
> > If Not: what problems arise that would be solved by having a network
> model, do we need one, and where would it come from if not i2rs?
>

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 7 Nov 2013 13:05:06 -0800

On Nov 7, 2013:12:39 PM, at 12:39 PM, Joe Marcus Clarke <[email-masked]> wrote:

> I think it is useful to have a network-wide topology model that is accessible at a device level.  Meaning, topology could be distributed into the network and retrievable either as a whole network or in parts based on filters.  

	That is definitely the right way to go here, and is indeed explained in the topology-related architecture.  The idea is much along the lines of a network service that lets say has a ReSTful interface whereby you specify various filtering options in a GET request and are returned a subset of the topology. Asking for just devices, hops, links, etc... is just one option we definitely envisioned. 

	--Tom

> For example, given an I2RS Agent, give me the Agent plus two routed hops.  This would be very useful, for example, in the support case where we need to understand what a network looks like in order to help troubleshoot problems.
> 
> But, I could also ask this same Agent to give me the whole routed network from a given instance.  This would give me the graph (edges, nodes) of that topology.
> 
> Joe
> 
> --

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 7 Nov 2013 13:11:58 -0800

A critical question is whether the "merging of the models from each
device" is within the scope of I2RS. Also note that "complete model of
entire network topology" can be misleading. This may be true for small
networks within a single administrative domain, but as the scope of
the network increases (e.g. multiple administrative domains) there
will not be a single way to get the "entire network topology", but
there will be some details that will be abstracted out.

- Sri

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 7 Nov 2013 21:32:31 +0000

Ultimately, many of the I2RS applications concern what you want to do with the network, and having a model that represents an abstraction of the network as a whole (as opposed to individual devices) seems to be core of what a controller needs to do.  I think there is therefore no question that a topology model is needed.  The question that is debatable concerns whether the interface that is exposed northbound of a controller (which will include a topology model) is within scope.  Even if the interface is not in scope (there is certainly validity to the scope creep argument), retaining the model by itself in scope makes sense: as a "use case" and a source of requirements (as it needs populating), and as a way to capture topology information as it is understood by the devices themselves.  
--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Thursday, November 07, 2013 12:52 PM
To: Joe Clarke (jclarke); Alia Atlas; [email-masked]
Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

eric

> ----------------------------------------------------------------------
> --
> ----

---

From: Nikolay Milovanov <[email-masked]>
Date: Thu, 7 Nov 2013 23:33:12 +0200

Hi Sri, 

I guess instead of "complete model of entire network topology"  it should be "a model of the network topology as visible from a particular device perspective". 
The  topology discoverer acting as an i2rs client will have to have some rules in order to handle differences between network models received by different devices. 

It is interesting how the i2rs client will do the merge if some edges part of the model received from one network node(agent) and are missing from the model received by its neighbor? Shall does go into the entire network model or not? I guess this is an implementation detail not really related to the info model spec. For example in such cases there might be a discrepancy mechanism able to handle that. It might be configurable and able to do different things as per the exact network use case. 

I have a question to the group members related to  How formal that model will has to be?. For example it might contain not only nodes and edges but also some of their key properties. It might be useful if for example some of the edge properties to be the local/remote interface through which the edge has been built also the local/remote L2/L3 network address used for edge building. 
Also is interesting how to ensure that the data coming from different nodes in the network but related to the same node/edge will have the same unique ID so that the network topology manager will be able to merge it correctly. 

Nikolay

---

From: Andy Bierman <[email-masked]>
Date: Thu, 7 Nov 2013 13:50:21 -0800

Hi Joel,

I agree with you that the network-wide view of topology that a controller
might
provide is out of scope.  I do not see the value of even defining a standard
info model for this network-wide view unless/until there is a standard
northbound
protocol to expose this data to applications.

IMO topology is a big enough problem to have its own WG, especially if
there needs to be a framework and protocol-specific models developed,
plus standard mechanisms to correlate NE data into a canonical view
of network topology.

Andy

On Thu, Nov 7, 2013 at 8:15 AM, Joel M. Halpern <[email-masked]> wrote:

> information models, then trying to design a protocol independent topology
> model for use with the network elements would seem applicable.
>
> protocol specific models, which would be having to manipulate many aspects
> related to the common model.
>

---

From: Sriganesh Kini <[email-masked]>
Date: Thu, 7 Nov 2013 13:56:23 -0800

Hi Nikolay,

> I guess instead of "complete model of entire network topology"  it should be "a model of the network topology as visible from a particular device perspective".

This is still a device-centric topology view. Even though it may be of
the whole network and not just its immediate neighbors, it is still a
device-centric view. Unless the device itself has a strong-consistency
model of the entire network, in which case I would like to know what
that is.

> The  topology discoverer acting as an i2rs client will have to have some rules in order to handle differences between network models received by different devices.

My question to the group is whether those rules are in the I2RS
charter. Will we be designing those procedures and mechanisms in I2RS
WG (this may be replicating a link-state IGP's db update procedures).

> It is interesting how the i2rs client will do the merge if some edges part of the model received from one network node(agent) and are missing from the model received by its neighbor? Shall does go…

I don't think this is an implementation detail. A network-centric
topology model must be recursively stackable. It must be standardized
as to how the "discrepancies" are handled.

> Also is interesting how to ensure that the data coming from different nodes in the network but related to the same node/edge will have the same unique ID so that the network topology manager will b…

Seems like we are getting into a link-state advertisement discussion here :-)

- Sri

---

From: "Fedyk, Don" <[email-masked]>
Date: Fri, 8 Nov 2013 00:09:27 +0000

Hi Eric

Actually I don't think the 2 are equivalent.  My argument is TE as an example is only advertised as a summary (I'm sure there are other examples). So you can get more detail fetching the node by node information. (I'd agree with you if  your argument is  just limit the information to what is in the LSDB (or other routing DB)  but I think that would be limiting.) 

Cheers,
Don 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Thursday, November 07, 2013 3:52 PM
To: Joe Clarke (jclarke); Alia Atlas; [email-masked]
Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

eric

---

From: Joe Marcus Clarke <[email-masked]>
Date: Thu, 07 Nov 2013 19:29:10 -0500

On 11/7/13, 3:51 PM, Eric Osborne (eosborne) wrote:
> one is OK, and #2 makes the most sense.  In any case it's a read-only thing so it doesn't really matter how it gets done.
>
> Where it gets hairy is when you want to write to the network.  The question that kicked off this thread was along those lines, if I recall.  If you want to get a mutex on the network as a whole y

This is where I differ from what others may want.  I would like a 
network-wide topology accessible at each node, but I don't think I2RS 
needs to enforce a network-wide mutex.  Meaning, let me learn about the 
network from a node, then me (as an application) can do what is needed 
to change the network.  I may have to coordinate with other writers (as 
is stated IIRC in the architecture) to prevent conflicts from occurring.

Joe

---

From: Edward Crabbe <[email-masked]>
Date: Tue, 12 Nov 2013 10:56:10 -0800

With my chair hat off:

Any 'device-centric' model must be composable into a 'network-wide'
model, otherwise it's not particularly useful.
So yes, +1 and agree with Shane.

with my chair hat on:

I believe *this specifically* is in charter.

On Thu, Nov 7, 2013 at 11:12 AM, Shane Amante <[email-masked]> wrote:
> In the end to build a network centric info/data model out of this the
> network topology manager will have to collect and transform information
> gained from many network devices.
>
>
> +1.
>
> I believe I may be observing a tension between the traditional IETF view of
> "how do I make two devices communicate together", i.e.: what's the protocol
> that allows that communication to occur robustly, vs. an operator view of
> "Sure, I need protocols to make two devices talk to each other, but what's
> more critical for my business is to look at the whole network, which is a
> collection of devices".  A Network Topology Information Model would assist
> operators with having a cohesive view of the overall "network as a system",
> because that's the foundation upon which _services_ are delivered ... both
> within the data-path between various NE's and on top of various NE's.
>

---

From: Ken Gray <[email-masked]>
Date: Tue, 12 Nov 2013 19:15:55 +0000

+1 (can't believe we're even discussing this at this point)
________________________________________
From: [email-masked] <[email-masked]> on behalf of Edward Crabbe <[email-masked]>
Sent: Tuesday, November 12, 2013 1:56 PM
To: Shane Amante
Cc: [email-masked]; Nikolay Milovanov; Shah, Himanshu; Alia Atlas
Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

With my chair hat off:

with my chair hat on:

---

From: Michael Hallgren <[email-masked]>
Date: Tue, 12 Nov 2013 21:27:02 +0100

> I believe *this specifically* is in charter.

I need to update myself at the tail (and maybe also the head) of this
thread, but it
seems to me that looking at these things from a network graph
perspective, populated
by more or less complex nodes (maybe abstracting networks themselves)
wouldn't be
a null route path to explore. Thus

+1.

Seen from an inter-networking perspective, each node is representing
some set of
capabilities and connected to nodes able to participate in that
capability network. Then,
we'd slice view the model by abstraction level.

Thoughts?

Cheers,
mh