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 protected]> wrote: > 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 protected] <mailto:[email protected]>> >> Date: Wednesday, November 6, 2013 11:59 PM >> To: Nikolay Milovanov <[email protected] <mailto: >> [email protected]>> >> Cc: Russ White <[email protected] <mailto:[email protected]>>, "[email protected] >> <mailto:[email protected]>" <[email protected] <mailto:[email protected]>>, "Eric >> Osborne (eosborne)" <[email protected] <mailto:[email protected]>> >> 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? >> >> >> 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 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 >> >> _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
