Joel,
On Thu, Nov 7, 2013 at 11:15 AM, Joel M. Halpern <[email protected]
<mailto:[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.
We certainly need protocol specific information included to help with
resolving different data in LSDBs. We also need additional
functionality for IGP IMs beyond the topology.
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.
Agreed - so can we have dependencies or reuse of the aspects in common?
That seems desirable for accurately describing the IMs as well as the
data-models.
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.
I agree that it is not our workspace - but being able to combine the
information from different device's into a network-wide model is
important and I don't think it will be possible without careful initial
thought and working in parallel.
Regards,
Alia
Yours,
Joel
On 11/7/13 3:51 AM, Jan Medved (jmedved) wrote:
From: Alia Atlas <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
Date: Wednesday, November 6, 2013 11:59 PM
To: Nikolay Milovanov <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>__>
Cc: Russ White <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>, "[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>" <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>, "Eric
Osborne (eosborne)" <[email protected]
<mailto:[email protected]> <mailto:[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]>
<mailto:[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]>
<mailto:[email protected] <mailto:[email protected]>>
On Thu, Nov 7, 2013 at 8:16 AM, Russ White
<[email protected] <mailto:[email protected]>
<mailto:[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]> <mailto:[email protected]
<mailto:[email protected]>>
https://www.ietf.org/mailman/__listinfo/i2rs
<https://www.ietf.org/mailman/listinfo/i2rs>
--
BR,
Nikolay Milovanov
Network Engineer
Email: [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
_________________________________________________
i2rs mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/i2rs
<https://www.ietf.org/mailman/listinfo/i2rs>
