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 protected]> 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 protected]> > wrote: > > > > On Nov 7, 2013, at 9:15 AM, Nikolay Milovanov <[email protected]> > 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 protected] > > https://www.ietf.org/mailman/listinfo/i2rs > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
