Innokenty,

I am not sure what you mean by

> Whether the filtering policy conveyed
> in the LSA applies or not will depend on whether a particular route (from
> the perspective of the calculating router) goes through the corresponding
> interface of the router on which the policy is applied.

Are you talking about the path to destination D going thru the calculating
router interface or just the nexthop? Please describe the exact policy you
intend to make and the exact info you want to send?

Let me make some things clear to you again. If you are applying a particular
policy to some routers and not to others, it could lead to routing
loops/blackholes. If you use the second best route(which could result if the
best path traverses thru the filtering interface) on some routers it too
will lead to routing loops.

Thanks,
Vishwas

-----Original Message-----
From: Innokenty Rudenko [mailto:irudenkoHOTMAIL.COM]
Sent: Tuesday, March 12, 2002 3:05 AM
To: OSPFDISCUSS.MICROSOFT.COM
Subject: Re: route filtering

Manral,

>
>1. Dijakstra should have the same topology at all nodes to make a loopfree
>and blackhole free paths to destination.

The topology should be the same as all the LSAs are flooded without any
changes. In addition though, a new "filtering" LSA also needs to be
flooded. The only purpose of this new LSA is to propagate the filtering
policy.

Regarding Dijkstra. I'm not sure at all if the filtering should take place
during the Dijkstra calculation. What should happen however is that if a
route that Dijkstra calculates as the shortest does go through a router,
which is configured with the filtering policy that "denies" the route's
network prefix, then the route must not be installed in the router's
routing table. This is very similar to a route filtering in distance-vector
protocols.

>2. Because flooding is so done that all the routers in an area have the
same
>topology, so all routers behind R1/R2 in the samae area too would get that
>"filtering" LSA.

Yep. And that's what I think should happen.

>3. If you are doing filtering(aggregation) it is best to do it at the ABR,
>as you cannot have half the area have one set of LSA's and the other
another
>set. So any filtering anywhere would result in the same filtering in the
>whole area.

I'm not proposing to filter LSAs. What I'm proposing is to filter routes as
they are installed in the routing table. For example Cisco allows
configuring an OSPF "inbound distribute-list" for an interface, which works
as follows: if OSPF is to install a route for a certain network prefix
pointing to the interface on which the distribute list assigned, the router
should then check if the distribute-list (ACL) "permits" the route. If it
does, OSPF will install the route. Notice, Dijkstra should've already taken
place; also, this process does not affect the integrity of the link state
database. A similar effect is achieved if a routing protocol with the admin
distance lower than that of OSPF installs a route for the same network
prefix, then OSPF won't install its own route.

>1. Do you mean we ask people to not add a particular route in their
>database(filter LSA/routes)?

The only change to the link state database that I'm proposing is this
additional "filtering" LSA.

>2. What is the exact advantage from filtering you gain in any router within
>in ur case(now that the flooding scope is the entire area)?

The effect of the proposed filtering is similar to the "distance-vector"
filtering. The advantage is that it significantly lowers the administrative
burden of configuring "local" filtering on every router as OSPF will
propagate the filtering policy and it will provide means to adequately
apply the policy.

The question is if there is a demand for this feature or not. I think there
is and that's why I'm proposing it. If someone uses a routing protocol
other than OSPF (RIP, E/IGRP, etc.) but considers migrating to OSPF, it's
typical (at least in my experience) to hear something like "well, but how
do I go about filtering? I definitely need to filter this route and that
route, and though I do understand that I can use inbound distribute lists
(if the routers are Cisco), it puts a lot of admin burden as I have to make
sure that all the routers are configured with the same ACLs in the first
place and also whenever I make a change to the filtering policy".

>3. When you talk about filtering done as part of Dijakstra, do you mean
>result of dijakstra/SPF tree?

Not the tree, but the decision of whether or not to install the calculated
shortest route into the routing table. Whether it is done during the
Dijkstra calculation or not, I'm not sure. That's a detail that needs to be
worked out.

>4. Do you intend to use some special flooding mechanism to limit the
>flooding of the LSA even within an area?

Nope, just the standard flooding. In fact, I would want every router in the
area to have the same filtering LSA. Whether the filtering policy conveyed
in the LSA applies or not will depend on whether a particular route (from
the perspective of the calculating router) goes through the corresponding
interface of the router on which the policy is applied.

Innokenty.

>
>Thanks,
>Vishwas
>
>
>-----Original Message-----
>From: Innokenty Rudenko [mailto:irudenkoHOTMAIL.COM]
>Sent: Monday, March 11, 2002 7:46 PM
>To: OSPFDISCUSS.MICROSOFT.COM
>Subject: route filtering
>
>
>I'm not sure if it was brought up before. Anyway:
>
>One of the complains I've heard about OSPF is that one cannot filter routes
>the same way as he can do in the distance-vector routing protocols.
>Obviously route filtering is available on ABRs; plus implementations often
>allow for local route filtering whereby an OSPF route won't be installed in
>the routing table if it isn't "permitted" by an ACL. The latter however
>won't have any effect on the other OSPF routers, which will install the
>route unless they are also configured to filter it out. (In DV protocols
>such a route won't be propagated to the other routers, hence won't be
>installed unless an alternative path is available.)
>
>To address the issue, why not create a separate LSA type to propagate a
>filtering policy. E.g.:
>
>
> / /
> / /
> +--+-+ +--+-+
> | R1 | | R2 |
> +-+--+ +--+-+
>Rt.Flt. / \ Rt.Flt.
>-------> / \ <--------
> / \
> .......................
> . .
> . OSPF Routers .
> . in the same area .
> . .....................
>
>In the picture above the route filter is applied on routers' R1 and R2
>interfaces leading to a group of networks in the same area shown as a cloud
>with a dotted border. R1 and R2 should then create a filtering LSA and
>flood it to the other routers in the area. The OSPF routers in the area
>when calculating their routing tables would check if a filter applies and
>if so would not install the "denied" OSPF routes into the routing table.
>
>By "filter applies" I mean if the shortest path for a network prefix
>actually goes through the router interface on which the filter is applied.
>If the filter "permits" the network prefix, the route is installed,
>otherwise it isn't.
>
>For example, if the filter "denies" some network prefix "above" routers R1
>and R2, the routers "below" in the dotted area won't install routes for it.
>
>This should ensure a "distance-vector protocol" like behavior of route
>filtering in OSPF.
>
>Any thoughts on that?
>
>Some open questions would be:
>1. Should filtering be done as a part of Dijkstra?
>2. If a route is filtered, should alternative routes be considered for
>installation in the routing table? Those routes will be longer and
>therefore may potentially create a routing loop.

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