> 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
