On Tue, Feb 26, 2013 at 11:24 AM, Russ White <[email protected]> wrote: >> I would argue I2RS shouldn't be inserting stuff at A. I don't know of a >> use case to insert stuff at C, but that could be because I'm not > > E, not C here... Sorry for the typo.
Ok that's helpful :) I'd find it helpful if we could agree to use Alia's terminology from draft-atlas-i2rs-problem-statement-01, specifically "Policy Database" and "RIB Manager", or clarify what's wrong with that terminology. Then we could eliminate the need to define "normal", and cast the goals of I2RS in terms of it's "local process's" interaction with the local "Policy Database Manager" and the local "RIB Manager", using Joel's meaning of "local process". Suggested text: I2RS uses standardized APIs on a routing element to accept and process messages, constructing input to the policy database manager and RIB manager as needed. It is not intended to replace these local managers, although an implementation of a router using I2RS without them would be valid, at least from the I2RS perspective. Although at this point I'm not clear where this would go :) -Scott > > :-) > > Russ > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- panem et circenses - a winning strategy for over 2000 years! _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
