On Fri, Mar 1, 2013 at 10:20 AM, Russ White <[email protected]> wrote: > >> I would hope more folks in the WG want that too. :-) >> >> On a more general note ... first, thanks for putting this diagram >> together. At least now we have a decent picture to start a >> discussion. >> >> I think you've mostly (?) been focused on routes being received by >> and processed by a router that, ultimately, are distilled into a >> FIB. That's certainly important, but I think that we also need to >> look in the other direction, namely: routes that get /exported/ from >> one, or more, routers into an IGP or BGP. > >> a) >> placement of aggregate/tie-down/summarization/flow-spec routes, (at >> certain routers at certain places in the topology); > > I would think of this as inserting information through the normal > peering process, or through a "static route," (which is just another > routing process) + the policy needed to import/redistribute that route > into BGP. So, assuming B in the diagram is bidirectional, setting up the > policy for what the routing process receives from the RIB as well as > what the routing process presents to the RIB. > >> b) "route >> filters" applied to, for example, eBGP neighbor sessions inbound & >> outbound > > This is where I think the diagram needs another "policy cloud," showing > a policy insertion point between "Peering" and the "local database." > >> 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. > > Yep. > >> In summary, although I think you chose your words carefully when >> describing "A" by proposing that I2RS avoid (forbid?) "direct >> injection of information [in]to a routing process", I think there's >> an important point we should not miss here. Namely, I2RS can do >> that, but only _when_ I2RS informs the routing process, which then > > Or rather when I2RS uses the "normal, front door," APIs provided by the > routing process to interact with those local databases. What we don't > want is the ability to inject a route into the BGP table that just > overwrites other routes, no matter what other policy might be > implemented within the BGP process itself.
I guess I'm having a hard time following all this. If you move the routing process policy cloud and "B" (bidirectional now) up between the peering and local database, similar to what you said above, you'd get this clean front-door requirement for I2RS<->routing protocol interactions, and I2RS<->RIB interactions would remain at "C". What am I missing? -Scott > > I expect there will always be some way to say, "this route must win," > such as weight in IOS, or admin distance, but we don't want to bypass > these sorts of things, we want to work with them. > >> [2] While we're here, I'm not sure where (if it all) you intended >> for routing protocol redistribution to be illustrated in your >> diagram. Given that different vendors have vastly different >> models/ideas of how this is accomplished in their code, I'm not sure >> such a thing is even practical or possible. :-( > > See above, about the bidirectional nature of B in the diagram... I think > that would cover the redistribution case. You might have to include D, > as shown, in the process of redistribution as well (for instance, > redistribution in a particular implementation might be a push from the > RIB process to each impacted routing process --so we need to account for > both push and pull models here). > > :-) > > 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
