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 11:46:32 -0500

Sorry for the late response, but to summarize...

What I am hearing is several things:

a)  We definitely need a device's perspective of topology - to include at
least the IGP's LSDB and probably local interfaces.
b)  There is a strong desire for a network-wide topology-model - even
though any protocol (north-bound, etc) to use that is definitely NOT in
scope for I2RS.   A key additional complexity for this is correlating the
data from multiple devices' perspectives - and to get this right we should
do both the device's perspective and the network-wide perspective in
combination.  However, it is not clear that any complex correlation logic
would be in scope.
c) As per the charter, writing topology is out of scope.
d) Filtering of topology information by the I2RS agent for extraction would
be very useful.
e) Topology information is only PART of the IGP IM (whether we have an OSPF
IM and an ISIS IM or...)

I think that part of what we are running into is the need for indirection
between different IMs - so that an IGP IM can express its LSDB based from a
generic links-and-nodes model - but that may still have more information
than a network-centric model would keep.

It would also be useful to discuss what else should be in the IGP IM...

While we've had a good discussion, is anyone (other than Jan, Alex, etc on
(b)) specifically planning on working on any of the topology related IMs as
I described above?

In reference to my earlier comment about "I'm also not comfortable on
having only one IM for basing all our requirements off of.", what I meant
is that I2RS is rapidly progressing towards gap-analysis for both
data-modeling languages and protocols  (I'd love to see drafts soon) - and
the reasoning for the requirements come from the architecture (fairly
baked), the RIB IM (in good shape), various suggested use-cases (need work)
and possibly Jan's network-centric topology IM (under serious discussion).
  I realize that
draft-rfernando-i2rs-protocol-requirements<http://trac.tools.ietf.org/id/draft-rfernando-i2rs-protocol-requirements-00.txt>-00
and draft-swhyte-i2rs-data-collection-system<http://trac.tools.ietf.org/id/draft-swhyte-i2rs-data-collection-system-00.txt>-00
also give some requirements and guidance - but they are also not yet WG
drafts.

We do need to get moving :-)

Alia

On Tue, Nov 12, 2013 at 1:56 PM, Edward Crabbe <[email-masked]> wrote:

> With my chair hat off:
>
> Any 'device-centric' model must be composable into a 'network-wide'
> model, otherwise it's not particularly useful.
> So yes, +1 and agree with Shane.
>
> with my chair hat on:
>
> I believe *this specifically* is in charter.
>
>
> On Thu, Nov 7, 2013 at 11:12 AM, Shane Amante <[email-masked]>
> wrote:
> >
> > On Nov 7, 2013, at 9:15 AM, Nikolay Milovanov <[email-masked]>
> wrote:
> >
> > In the end to build a network centric info/data model out of this the
> > network topology manager will have to collect and transform information
> > gained from many network devices.
> >
> >
> > +1.
> >
> > I believe I may be observing a tension between the traditional IETF view
> of
> > "how do I make two devices communicate together", i.e.: what's the
> protocol
> > that allows that communication to occur robustly, vs. an operator view of
> > "Sure, I need protocols to make two devices talk to each other, but
> what's
> > more critical for my business is to look at the whole network, which is a
> > collection of devices".  A Network Topology Information Model would
> assist
> > operators with having a cohesive view of the overall "network as a
> system",
> > because that's the foundation upon which _services_ are delivered ...
> both
> > within the data-path between various NE's and on top of various NE's.
> >
> > So, +1 to network-centric topology IM model.
> >
> > -shane
> >
> >
> >
> > _______________________________________________
> > i2rs mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/i2rs
> >
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 5 Dec 2013 11:50:01 -0500

Hi Eric,

On Thu, Nov 7, 2013 at 3:51 PM, Eric Osborne (eosborne)
<[email-masked]>wrote:

> If you want to get the link state for an entire network there are two ways
> to do it:
>
> 1) the i2rs client fetches each node's link state info from that node, and
> plugs them together to make a network,
> 2) the i2rs client fetches the entire LSDB from one node.
>
> IMO either one is OK, and #2 makes the most sense.  In any case it's a
> read-only thing so it doesn't really matter how it gets done.
>

I agree that (2) makes sense - but certainly how it gets done does matter.
 Writing isn't the only complexity.  Take another read through
draft-swhyte-i2rs-data-collection-system<http://trac.tools.ietf.org/id/draft-swhyte-i2rs-data-collection-system-00.txt>
if
you think it is :-)
For instance, I see (2) as likely being exposed as an information stream
that can be subscribed to.

Where it gets hairy is when you want to write to the network.  The question
> that kicked off this thread was along those lines, if I recall.  If you
> want to get a mutex on the network as a whole you *need* a way to lock all
> devices.  Perhaps this is best done in the client - acquire a lock on the
> config for each node in the network, make your changes, then unlock.  If
> there were a higher level way to do this with some sort of network API
> that's what it would have to do under the covers anyways.  And if you have
> locking write access to the client then you don't need a network model,
> just a router model.
>

Writing the topology is specifically out of scope.  I2RS is certainly not
expecting to do things such as lock all devices.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 5 Dec 2013 11:58:43 -0500

Hi Sri,

Sorry for top-posting.   I generally agree that understanding what
information should be including in the device perspective's topology IM in
order to resolve discrepancies is important.  I don't think that we need
to recreate IGPs' mechanisms for this - but rather include the information
in there so that resolution can be done.  For instance, with an LSA - it is
clear which is more recent.  If multiple router LSAs from the same router
are reported by different devices, then clearly the network is reconverging
- and there can be flags indicating this along with old state and new
state.  Ideally, one could associate the time that a device originated an
LSA (if that device is contributing information) as well.   For each OSPF
area, it could be marked as reconverging or stable.  I think that probably
one would have two topologies available - the "old" and the "new" where the
default would be to work with the new.

Does that make sense to you?

Alia

On Thu, Nov 7, 2013 at 4:56 PM, Sriganesh Kini
<[email-masked]>wrote:

> Hi Nikolay,
>
> On Thu, Nov 7, 2013 at 1:33 PM, Nikolay Milovanov <[email-masked]>
> wrote:
> > Hi Sri,
> >
> > I guess instead of "complete model of entire network topology"  it
> should be "a model of the network topology as visible from a particular
> device perspective".
>
> This is still a device-centric topology view. Even though it may be of
> the whole network and not just its immediate neighbors, it is still a
> device-centric view. Unless the device itself has a strong-consistency
> model of the entire network, in which case I would like to know what
> that is.
>
> > The  topology discoverer acting as an i2rs client will have to have some
> rules in order to handle differences between network models received by
> different devices.
>
> My question to the group is whether those rules are in the I2RS
> charter. Will we be designing those procedures and mechanisms in I2RS
> WG (this may be replicating a link-state IGP's db update procedures).
>
> >
> > It is interesting how the i2rs client will do the merge if some edges
> part of the model received from one network node(agent) and are missing
> from the model received by its neighbor? Shall does go into the entire
> network model or not? I guess this is an implementation detail not really
> related to the info model spec. For example in such cases there might be a
> discrepancy mechanism able to handle that. It might be configurable and
> able to do different things as per the exact network use case.
> >
>
> I don't think this is an implementation detail. A network-centric
> topology model must be recursively stackable. It must be standardized
> as to how the "discrepancies" are handled.
>
> > I have a question to the group members related to  How formal that model
> will has to be?. For example it might contain not only nodes and edges but
> also some of their key properties. It might be useful if for example some
> of the edge properties to be the local/remote interface through which the
> edge has been built also the local/remote L2/L3 network address used for
> edge building.
> > Also is interesting how to ensure that the data coming from different
> nodes in the network but related to the same node/edge will have the same
> unique ID so that the network topology manager will be able to merge it
> correctly.
>
> Seems like we are getting into a link-state advertisement discussion here
> :-)
>
> >
> > Nikolay
> >
>
> - Sri
>
> >
> > On Nov 7, 2013, at 11:11 PM, Sriganesh Kini wrote:
> >
> >> A critical question is whether the "merging of the models from each
> >> device" is within the scope of I2RS. Also note that "complete model of
> >> entire network topology" can be misleading. This may be true for small
> >> networks within a single administrative domain, but as the scope of
> >> the network increases (e.g. multiple administrative domains) there
> >> will not be a single way to get the "entire network topology", but
> >> there will be some details that will be abstracted out.
> >>
> >> - Sri
> >>
> >> On Wed, Nov 6, 2013 at 11:17 PM, Nikolay Milovanov
> >> <[email-masked]> wrote:
> >>> 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.
> >

---

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

Hi Jan,

Sorry for being so long in replying - but to answer your questions
finally...

On Thu, Nov 7, 2013 at 3:04 AM, Jan Medved (jmedved) <[email-masked]>wrote:

>  Hi Alia,
>
>  Thanks for starting the conversation :-)
>
>  IMO, the lines between 'network-centric' and 'device-centric' are a
> little blurred. For the sake of argument, let me agree with Joel that the
> I2RS WG's scope should be limited to a single routing system. Let me ask a
> few questions then:
>
>    - Is an OSPF router or an IS-IS router a 'routing system', as defined
>    in the WG charter? If yes, would its LSDB be considered 'topology
>    information' as defined in the WG charter?  And if the the answer to the
>    latter question is yes, would reading the LSDB information from the router
>    via a tbd. I2RS protocol be considered 'extraction of information
>    about topology from the network', as defined in the WG charter?
>
> Yes - absolutely - but the LSDP is not the only information that needs to
be in an OSPF/ISIS IM.

>
>    - Is a BGP Router Reflector a routing system, as defined in the WG
>    charter of the WG? If yes, would the LSDB information (potentially
>    collected from multiple IGP areas) in RR's BGP-RIB be considered 'topology
>    information' as defined in the WG charter? And if the the answer to
>    the latter question is yes, would reading the LSDB information from the RR
>    be considered 'extraction of information about topology from the
>    network', as defined in the WG charter? And if the BGP RR implements
>    BGP-LS, would extracting the LSDB information from the RR be in scope of
>    the WG? Could BGP-LS actually be considered a candidate for an I2RS
>    protocol  that would  be 'extracting information about topology from
>    the network'?
>
> Reading the topology info collected by BGP-LS would qualify.   I am torn
about having BGP-LS being considered an I2RS protocol.  We certainly
started I2RS with the idea of being inclusive of multiple protocols that
could provide the desired functionality.  Since then, I think that the WG
has been more focused on a single protocol - though with the potential for
"off-loading", such as requesting information but having it delivered via
IPFIX or possibly a "log-file" via SCP.  BGP-LS, of course, has some of the
desired performance characteristics, but certainly isn't quite a data-model
driven protocol.

What I'd like to see in this space would be an IM for BGP-LS with a mapping
to the data in BGP-LS.  Then, one could either use I2RS to request the data
and information stream or one could simply implement BGP-LS and listen.  I
say "simply" but I've been given to understand that implementing BGP, even
as just a listener, is adding a non-trivial burden for network
applications.  Of course, how relevant that is for just getting something
going or for a model with an I2RS broker is another question.

Regards,
Alia

>  Thanks,
> Jan
>
>
>   From: Alia Atlas <[email-masked]>
> Date: Wednesday, November 6, 2013 6:23 PM
> To: "[email-masked]" <[email-masked]>
>
> Subject: [i2rs] topology info model - what makes it a "network" model vs.
> a "device" model
>
>   I'd really like to start a conversation about the differences between a
> topology IM model that is network-centric vs. device-centric.  Clearly the
> WG has strong and different opinions about it.
>
>  Since many people are here in Vancouver, focused on IETF and not their
> day-jobs, this seems like a good time to get it rolling...
>
>  Alia
>
>