Subject: Re: [i2rs] topology info model - what makes it a "network" model vs. a "device" model

From: Alia Atlas <[email-masked]>
Date: Thu, 5 Dec 2013 12:02:38 -0500

Joel,

On Thu, Nov 7, 2013 at 11:15 AM, Joel M. Halpern <[email-masked]>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-masked] <mailto:[email-masked]>>
>>
>> Date: Wednesday, November 6, 2013 11:59 PM
>> To: Nikolay Milovanov <[email-masked] <mailto:
>> [email-masked]>>
>> Cc: Russ White <[email-masked] <mailto:[email-masked]>>, "[email-masked]
>> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "Eric
>> Osborne (eosborne)" <[email-masked] <mailto:[email-masked]>>
>>
>> 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-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
>>
>>
>>
>>
>>
>>         On Thu, Nov 7, 2013 at 8:16 AM, Russ White <[email-masked]
>>         <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
>>
>>             https://www.ietf.org/mailman/listinfo/i2rs
>>
>>
>>
>>
>>         --
>>         BR,
>>
>>         Nikolay Milovanov
>>         Network Engineer
>>         Email: [email-masked] <mailto:[email-masked]>
>>
>>
>>
>>
>>
>> _______________________________________________
>> i2rs mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 5 Dec 2013 12:20:15 -0500

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-masked]>wrote:

>
>
>   From: Alia Atlas <[email-masked]>
> To: Nikolay Milovanov <[email-masked]>
> Cc: Russ White <[email-masked]>, "[email-masked]" <[email-masked]>, "Eric
> Osborne (eosborne)" <[email-masked]>
> Subject: Re: [i2rs] topology info model - what makes it a "network" model
> vs. a "device" model
>
>   Hi,
>
> 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.
>
> 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?
>
>

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.

> better off focusing on an interface-focused IM (whether that is a device
> model or an interfaces model or...)?
>

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.

> 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.
>
>
> 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 don't understand what you mean - can you please explain?

Please see my other summarizing email.

> 'network-centric' IMs - it talks merely about 'topology information'. Can
> you define what 'device-centric' and 'network-centric' is?  Would
> 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.

> 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-masked]>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-masked]
>>
>>
>>
>>
>>  On Thu, Nov 7, 2013 at 8:16 AM, Russ White <[email-masked]> 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
>>> > 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
>>>  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
>>> 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
>> Email: [email-masked]
>>
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 05 Dec 2013 13:34:24 -0500

Being able to combine information from multiple protocol models is 
clearly necessary if this is going to work.

But as far as I can tell, that really means making sure that the 
identifiers correlate.

Yes, all the models will have links and nodes.  But in fact trying to 
extract the commonalities is rather challenging.  BGP does not actually 
model network links at all.  It models reachability and AS abstract 
connectivity.
Similarly, RIP models very differently from OSPF or IS-IS.

So I am very concerned that spending time on the aggregation model will 
actually interfere with our ability to get teh protocol models.

And arguably the most important relationship is between the protocol 
network models and the RIB model.

After that, the next most important aspect of the protocol network 
models is their policy modeling.

Yours,
Joel

On 12/5/13 12:02 PM, Alia Atlas wrote:
> Joel,
>
> On Thu, Nov 7, 2013 at 11:15 AM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     information models, then trying to design a protocol independent
>     topology model for use with the network elements would seem applicable.
>
>
> resolving different data in LSDBs.  We also need additional
> functionality for IGP IMs beyond the topology.
>
>     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.
>
>
> 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
>
>         From: Alia Atlas <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>         To: Nikolay Milovanov <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>__>
>         Cc: Russ White <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>, "[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>" <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>, "Eric
>         Osborne (eosborne)" <[email-masked]
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>>
>
>         easy-to-model/difficult-to-__model, easy-to-use/difficult-to-use,
>         easy-to-extract/difficult-to-__extract? IOW, what kind of
>         topology IM
>              <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>__>
>         wrote:
>
>                  Hi,
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>
>
>
>
>                  On Thu, Nov 7, 2013 at 8:16 AM, Russ White
>         <[email-masked] <mailto:[email-masked]>
>                  <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>                      > 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
>                      > It feels like the real question is whether i2rs
>         should have network models
>                      in
>                      > scope.
>
>                      Right...
>
>                      _________________________________________________
>                      i2rs mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>         https://www.ietf.org/mailman/__listinfo/i2rs
>         <https://www.ietf.org/mailman/listinfo/i2rs>
>
>
>
>
>                  --
>                  BR,
>
>                  Nikolay Milovanov
>                  Network Engineer
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>
>
>
>
>
>         _________________________________________________
>         i2rs mailing list
>         https://www.ietf.org/mailman/__listinfo/i2rs
>         <https://www.ietf.org/mailman/listinfo/i2rs>
>
>

---

From: "Russ White" <[email-masked]>
Date: Thu, 5 Dec 2013 14:59:13 -0500

> After that, the next most important aspect of the protocol network models
is
> their policy modeling.

Agreed -- which is why the RIB model is so important to get right the first
time.

:-)

Russ