> As mentioned elsewhere, I tend to perceive I2RS's impact on the network as > being similar to that of a routing protocol. If I want something I do to a given > device to propagate, the state that is injected must either be suitable for > injection into another routing protocol (redistribute into BGP, or IGP, e.g.) or > must be fully local. > > We will have cases for both. > > For Sri's point, if I inject state in to router A and it overlaps with state in > router B, it better be because that state had arrived via a routing protocol. In > such a case, the interaction between I2RS and the protocol would already be > defined.
This is the correct way to see this problem -- we don't want to inject complex and fancy "stuff" into I2RS to handle every conceivable overlap/conflict/etc. We are injecting routing information into a local RIB which is then distributed through normal routing -- there are already rules in place to handle overlapping information coming from two different routing protocols on every platform that runs more than one routing protocol. Devices from different vendors running multiple routing processes already interoperate on today's networks. Let's not invent new solutions to a problem that has already been solved with real deployed code. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
