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]>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] > > > > > On Thu, Nov 7, 2013 at 8:16 AM, Russ White <[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] >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > > -- > BR, > > Nikolay Milovanov > Network Engineer > Email: [email protected] >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
