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