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
