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 protected] [mailto:[email protected]] On Behalf Of Alia Atlas Sent: Thursday, November 07, 2013 2:59 AM To: Nikolay Milovanov Cc: Russ White; [email protected]; Eric Osborne (eosborne) 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. 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 On Thu, Nov 7, 2013 at 2:17 AM, Nikolay Milovanov <[email protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]> On Thu, Nov 7, 2013 at 8:16 AM, Russ White <[email protected]<mailto:[email protected]>> wrote: > 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 _______________________________________________ i2rs mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/i2rs -- BR, Nikolay Milovanov Network Engineer Email: [email protected]<mailto:[email protected]>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
