Greetings all, <clip> On 26Feb2013, at 18.48, Shane Amante <[email protected]> wrote: >>> > Taking a look at (b) and looking at your diagram, it seems as though (b) > should be within the boxes you have labelled "Routing Process". More > specifically, I think you need more "clouds" ;-) sitting directly above the > "Local Database" (Loc-RIB?) that, at a minimum, represent protocol > adjacencies (e.g.: BGP neighbor adjacencies) where I2RS _should_ be allowed > to apply (BGP) policy to those routing protocol sessions, in order to permit > filtering of _and_ manipulation of attributes in those routes inbound to or > outbound from the routing protocol process, (just like we do in today's > networks). I would think that this additional cloud would represent > something like the Adj-RIB-In/Adj-RIB-Out, at least wrt a BGP Routing Process. > > With respect to (a) above, namely placement of aggregate/summarization/etc. > routes, I believe that would most likely belong inside of and/or injected > into the "policy" cloud (inside the "Routing Process" box) through "B" in > your diagram. IOW, I place a summarization route in the routing process, > which then flows two directions: i) up into the routing processes database > and outward through the routing protocol, using normal routing update > protocol mechanisms; and, ii) down to the RIB process for consideration as to > whether it should be installed in the FIB after passing through "D" and "E", > of course. > I think Shane brings up some salient points. However, I do wonder if the same could be accomplished by injecting the routes "below" the individual routing protocols policy engine/cloud and allow for the redistribution "up (in the diagram)" based on that policy engine (under the control of a system that uses I2RS, but that policy may actually be driven by another protocol (interesting point, do we want I2RS to drive policy configuration, or use something else, ala NETCONF).
As Shane says, that policy engine is different from different vendors, so I'm not sure if it would be any easier to implement policy config via a common model in I2RS v.v. NETCONF. Another option would be for I2RS to bypass the policy engine on the protocol all together and enforce policy on the I2RS "controller". In that approach, you could either bypass the policy engine in reality, or virtually, by defining a policy in the protocol engine that allowed I2RS to bypass local policy (think global "accept"). > >> :-) >> >> Russ >> >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- 李柯睿 Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc Current vCard here: https://www.asgaard.org/~cdl/cdl.vcf Check my calendar availability: https://tungle.me/cdl _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
