Hi Jan, I think many of these have already been addressed in my other emails, but here are responses to the rest.
On Thu, Nov 7, 2013 at 3:51 AM, Jan Medved (jmedved) <[email protected]>wrote: > > > From: Alia Atlas <[email protected]> > Date: Wednesday, November 6, 2013 11:59 PM > To: Nikolay Milovanov <[email protected]> > Cc: Russ White <[email protected]>, "[email protected]" <[email protected]>, "Eric > Osborne (eosborne)" <[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. > Yes, part of that information is - but, for instance, knowing the LSA that the data came from for reconciling differences isn't there. That's just data that is needed for the device-perspective vs. a network-wide resolved-perspective. Also, as said elsewhere, it isn't just topology that comes from the IGPs. > 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. > Again - the pieces for reconciliation are missing. I do think that we also want an interface-focused IM but that can have more/different information than what is in the IGP IMs or BGP-LS IMs. > > 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. > Oh, it's certainly not small - and I don't think that we have to bite off all of it at once. I think we need a bottoms-up device-centric approach AND the top-down network-centric approach to be sure that each has the necessary details. > 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? > Please see my other summarizing email. > 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'? > I think that device-centric is what a single device would know - which can and does include information learned via routing protocols. > 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? > I certainly hope that we are considering those types of criteria! Regards, Alia > > > Alia > > > Thanks, > Jan > > > 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
