Russ, On Feb 26, 2013, at 2:10 PM, Russ White <[email protected]> wrote: >> Thanks for the clarifications. I am still a little fuzzy about what you mean >> by "...B to represent modifications to the policy the >> routing process uses to choose which route to present to the RIB." To use an >> example from BGP, maybe this could mean configuring an inbound prefix list >> or other type of policy filter. If so, then B is an interface to change the >> configuration of the routing protocol rather than the data (e.g., Adj-RIB-In >> contents), right? Of course, this type of configuration change affects not >> only what the protocol sends to the RIB, but may also affect what the >> protocol readvertises to its neighbors. > > Communities within BGP, for instance, or the metric on an OSPF route. > Yes, link state protocols would have fewer of these than BGP would --but > I think a good bit of the BGP policy model Shane wants would fit here... > (?).
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. Good examples of this, (which have been discussed in the use-cases drafts), are: a) placement of aggregate/tie-down/summarization/flow-spec routes, (at certain routers at certain places in the topology); b) "route filters" applied to, for example, eBGP neighbor sessions inbound & outbound i) One example of the above is placement of RT-constraint-like filters on a per-neighbor basis in Route Reflectors, because 'downstream' PE software does not (likely, will never?) support RFC 4684. ii) Another example is application of "routing policy" at the border of your AS to filter what you receive and, at the same time, manipulate BGP attributes of those routes that are accepted, e.g.: set BGP communities, set LOCAL_PREF, etc. Likewise, applying and outbound routing policy to filter what is allowed (intended!) to be announced to your neighbors. FWIW, I believe that most, if not all, of the above use cases are discussed in: <http://tools.ietf.org/html/draft-keyupate-irs-bgp-usecases-01>[1] and, potentially, your draft as well. 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. 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 carries out associated action(s) (on I2RS'es behalf) which will manipulate the state of routing information carried by that process, e.g.: filtering incoming/outgoing routes, manipulating LOCAL_PREF, setting/stripping communities, etc. And, of course, I2RS must do this is a completely transparent manner so that operators understand I2RS initiated this change vs. I2RS doing something "under the covers" that is non-obvious (or, worse, not visible) to operators. Thanks, -shane [1] We missed the deadline to post an updated version of the draft with the updated "I2RS" WG name, but I promise we will do so when the I-D submission queue reopens. We do not, at the moment, have plans to change the content of the draft, so please read through it now if you, or other WG members, have not already. [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. :-( > :-) > > 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
