Ok - then what you are describing as policy going in at point B is what I've been thinking of as data to the protocol (not quite at A - changing the data) - such as dynamically attaching a prefix to the local router or changing a local link metric. If you think of those as policy, that's ok and helps reconcile.
I think we're in emphatic agreement that i2rs MUST NOT mess with the data a protocol receives from its peers and the router itself does not own. Alia On Tue, Feb 26, 2013 at 1: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... > (?). > > :-) > > 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
