I really don't see much utility in the proposed function. We
have the OSPF area types and ranges to aggregate and filter on area
boundaries. These were carefully designed to prevent routing
loops and blackholes. Additionally, some vendors have implemented
flooding filters that can be carefully applied in certain
topologies to limit flooding, link state database size, and
route table size within an area. These must be applied at
natural boundaries within an area in order provide an additional
level of hierarchy. I'm not sure I can think of a good reason
to advertise route filters for OSPF routes within an
area (the argument being that filtering on an ABR boundary
is not sufficient).

Thanks,
Acee

Don Goodspeed wrote:
> Furthering Alex's thoughts, I'd say this is what an "OSPF import"
> or "OSPF Acceptance" route-policy would normally be handling.
>
> Different organizations have different ways in how they accomplish
> distributing these policies to their various routers, be it via
> configuration files or management applications.
>
> Also, route filtering applies to routing protocols other than
> OSPF, so while OSPF could be used to transport this information
> (via Opaque LSAs), it should not be the sole controller or user
> of this information.
>
> Others might be able to contribute more to this chain of thought.
>
> Cheers,
> Don
>
> --- On Tue 03/12, Alex Zinin <azininNEXSI.COM> wrote:
>
>>Innokenty,
>>
>> I'd like to hear whether other people believe that
>> such a mechanism would be interesting and why, but here's
>> my first thoughts on what's been discussed:
>>
>> 1. Architectural concern: one of the reasons why people
>> use route filtering is to decrease the amount of
>> state maintained by routers and the CPU load on them.
>>
>> A mechanism discussed here would not decrease state
>> (all LSAs are still flooded and maintained), but in
>> fact would even increase it (we have new LSAs ensuring
>> consistent decisions). The same can be said about
>> the CPU load (see below).
>>
>> 2. Technical concern: During calculation of SPT over
>> the topology graph, Dijkstra has no idea of prefixes,
>> i.e., it produces the SPT from a given node to all
>> other nodes. Note that the SPT is shared among all
>> prefixes. Regardless of which method is used to address
>> this, we'll finaly end up spending more CPU and memory,
>> which goes back to the architectural question.
>>
>> Perhaps we should first answer the question "what is the real
>> problem we're trying to solve here?" :)
>>
>> Regards.
>>--
>>Alex Zinin
>>
>>
>
>
> <hr>
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]