[j-nsp] Community based prepends.

[Richard A Steenbergen]

On Fri, Dec 12, 2003 at 06:05:25PM -0500, Phil Rosenthal wrote:
> I want to have the capability to have my customers be able to prepend 
> to peers individually.
> Like,
> 65001:(peeras) = prepend once to (peeras)
> 65002:(peeras) = prepend twice to (peeras)
> 65003:(peeras) = prepend three times to (peeras)

This is actually a very common policy that providers implement, or at 
least want to implement very badly. Unfortunately, the only way to do it 
right now is to use a policy-statement per peer ASN.

I've been pondering this one for years now, trying to think of a better
way to do it. The goal here is to introduce specific information about the
session the policy is currently being evaluated against into the policy, 
and then allow the policy to make a decision based on it.

Introducing the above information into the policy seems straight forward
enough. You could do something like this (note I'm going to reverse your
ordering a bit, trying to keep the first 16 bits of the word
representative of the ASN in question for consistancy's sake, and god 
have mercy on my soul for using the format I am going to use :P):

some-new-command prependable-ASNs members [ "2914" "6461" "3549" ];
community prepend-once members ".*:65001";
community prepend-twice members ".*:65002";
community prepend-thrice members ".*:65003";

policy-statement common-export {
    term prepend-once {
        from {
            community prepend-once;
            some-new-compare-command $SESSION['peer-as'] prependable-ASNs;
        }
        then as-path-prepend "10458";
    }
...
}

But if you really want to have fun, you need to take this one step 
further. Allow the operator to configure their own values AND keys for 
session specific interface information they want brought into the 
policies.

Say for example:

...
    neighbor 1.2.3.4 {
        peer-as 1234;
        some-new-command "peer-as" "1234";
        some-new-command "shortname" "roque";
    }

...

prefix-list roque-prefixes {
    10.0.0.0/24 orlonger;
    10.2.0.0/23;
}

policy-statement common-import {
    term prefix-filter
        from {
            prefix-list "${SESSION['shortname']}-prefixes";
        }
        then accept;
    }
    then reject;
...
}

firewall {
    filter common-input-filter {
        term customer-filter {
            from {
                source-prefix-list "${SESSION['shortname']}-prefixes";
            }
            then accept;
        }
        /* Why the heck don't firewalls allow this like policy-statements do? */
        then discard;
    }
}

THEN you have a common firewall filter, a common policy, and the only 
thing you need to do is stick to a consistant standard for naming them. 
Useful? I sure as hell think so!

-- 
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)