[j-nsp] RE: bgp config changes (was: autonomous-system N loops L)

[Richard A Steenbergen]

On Fri, Dec 12, 2003 at 02:35:28PM -0800, Pedro Roque Marques wrote:
> Richard A Steenbergen writes:
> 
> 
> > Oooh, another good point. Honk if you miss Cisco's style of having
> > prefix-lists available seperately from route-maps. I for one sure
> > do.
> 
> So... if you define a policy statement w/ just one term, which is a
> route-filter term that lists the prefixes and does accept/deny, what
> is the difference between that and prefix-lists ?
> 
> You can include it in policy statements i.e. a policy can reference
> another policy and you can include this via policy algebra in import
> statements... i.e. you can have
> 
>    neighbor 1.2.3.4 import [prefix-filter && generic-policy]
> 
> where prefix-filter is
> 
> policy-statement prefix-filter {
>     term a {
> 	from {
> 	    route-filter 10/24 orlonger;
> 	    [...]
>         }
>         then accept;
>     }
>     then reject;
> }
> 
> I see no difference between this and the cisco prefix-list behaviour.

In the short term, because it annoys the hell out of scripts which try to
automatically manage the prefix-filter policy, and its application against 
a specific neighbor. Specifically, it is difficult to use dynamic names 
and make certain that the old name is removed and the new name is inserted 
in the correct position and without serious fowlups in the event of a 
human error on the import statement before the script begins.

But in the long term, because it is messy and not well organized. Yes I
know simplicity and elegance are not usually motivating factors in the
design of routers, but why not take the opportunity to kill two birds with
one stone and add the ability to re-use the same list in a firewall term
as well?

Prefix filtering is an almost universally common task. The simple and
elegant design is to define a list of prefixes, with modifiers which
include what type of more specifics to match, and then re-use that list by
reference where appropriate throughout the configuration. If you are
*certain* that the majority of the routers out are at some point going to
prefix-filter a neighbor, why make everyone write a policy-statement to do
it and then a lot of "import [ prefix-filter && generic-policy ]" mess,
when you can just put it in a logical place like "neighbor x.x.x.x
prefix-filter"?

Wouldn't it just be all around better (not to mention easier for the Cisco
converters AND more logical) if you could define:

prefix-list dynamicname {
    10.0.0.0/24 orlonger;
    10.1.0.0/24 orlonger;
}

And then apply it with:

    neighbor 1.2.3.4 prefix-filter input dynamicname;

And match it in a firewall term with:

    from prefix-list dynamicname;

Oh and before anyone says anything about "why do you need to match the 
same list you've used in prefix-filtering in a firewall term, can't you 
just use uRPF?", one of the specific applications I have seen for this 
involves using IRR built packet filters to do source spoofing prevention 
on BGP speaking networks. You can allow the customer to register all the 
routes they will be sourcing from, even if you are not the best forwarding 
path for whatever reason, and still limit source addresses to a much much 
narrowing range than simply uRPF loose.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)