Subject: advanced refine usage

From: Philippe Strauss <[email-masked]>
Date: Fri, 25 Aug 2000 09:27:36 +0200

Hello RPS users,

I've beed diving into advanced RPSL topic lately (and avoided drowning for
now :) for fullfilling the need of a customer.

Reading and rereading RFC2622 about the refine operator, I first tought
it was possible to use such a chained refine construct to fit in all
routing policy we need:

aut-num:	AS1234
import: {
#
# Reject 'martians' routes and our own routes from any incoming 
# routing information
#
	from AS-ANY
	accept ANY AND NOT AS1234:RS-MARTIANS AND NOT AS1234:RS-PROVIDER;
#
#	NB: at this stage we treat ALL routes obviously
#
	} refine {
	#
	# Upstreams first
	#
		from AS1234:AS-Upstream
		action pref=30; community.append(1234:6100);
		accept <^PeerAS*>;
	#
	# Zero cost peers
	#
		from AS1234:AS-Peer
		action pref=20;
		accept <^PeerAS*>;
	#
	# Customers
	#
		from AS1234:AS-Customer
		action community.append(1234:6000);
		accept <^PeerAS*$>;
#
#	NB: Here too we consider ALL routes
#
	} refine {
	#
	# We assign different local-pref on various peerings for
	# balancing purpose of outbound traffic (eBGP traffic engineering)
	#
		from AS1234:AS-PeerSwiss
		# 1234:6202 will be tagged on swiss peers, including private ones.
		action pref=10; community.append(1234:6202);
		accept <^PeerAS*>;
#
		from prng-cixp
		action pref=11; community.append(1234:6238);
		accept <^PeerAS*>;
#
		from prng-linx
		action pref=21; community.append(1234:6232);
		accept <^PeerAS*>;
#
		from prng-amsix
		action pref=20; community.append(1234:6233);
		accept <^PeerAS*>;
#
		from prng-decix
		action pref=21; community.append(1234:6234);
		accept <^PeerAS*>;
	#
	# Customer ability to tweak local-pref applied to their routes
	# in our network.
	# 
		from AS1234:AS-Customer
		action pref=5;
		accept community.contains(1234:1);
#
		from AS1234:AS-Customer
		action pref=6;
		accept community.contains(1234:2);
#
#	NB: Here we only focus on IXP's and some customer routes
#
	} refine {
	#
	# Tuning, peering with higher/lower local-pref than usual,
	# mostly for load-balancing purpose.
	#
		from AS786 195.xx.xx.xx at linx.blahblah.net
		action pref=19;
		accept ANY;
#
		from AS5401 195.xx.xx.xx at decix.blahblah.net
		action pref=20;
		accept ANY;
#
#	NB: Here we only focus on a sparse set of routes
#
	}

The first statement prevent route polution, the second segregate route
type, the third refine peering point local-pref and customer local-pref
tweaking, the fourth used only for short-term tuning.

My mistake was to chain refine on such different set of routes, I mean the
cartisian product will end up considering only the common set for each
refine (left or right) handside, narrowing down to the sparse set of
routes of AS786 and AS5401.

Would it be wise/wrong/discouraged/ugly/convoluted to use a:

from AS-ANY
accept ANY

statement at the end of statement 3 and 4, the one not focusing on
all routes, and let the order precedence rule do the rest?
I'm not sure of the resulting cartisian product of hum, such a mess :)

an other good solution is to use one import per route-type, ie having 3
import in this case, one for upstream, one for peer, one for customer.
hence the peering set in rightmost refine will always be contained in
the leftmost statement, but the route pollution preventing need to be
duplicated. I can live with this redudancy, but would like some feedback
to 'feel' better the refine operator.

some comment about the RFC:
the 'nested' word may be somewhat confusing for the refine statement.
chained would be better IMHO.

I'm sure there is a good reason for evaluating nested or chained statement
for both except and refine from right to left, but no insight is given.
I missed that one at first.

Otherwise, I'm impressed by the fine granularity of RPSL. will like to
see the world switching to it :)

Regards.

-- 
Philippe Strauss, Telecom Consulting
email: <[email-masked]>

Psychiatrists say that one out of four people are mentally ill.  Check
three friends.  If they're OK, you're it.
--

---

From: Cengiz Alaettinoglu <[email-masked]>
Date: Fri, 25 Aug 2000 16:01:40 -0700 (PDT)

> tweaking, the fourth used only for short-term tuning.

Even though the 4 levels, your policy is very readable thanks to
comments and good names. Nice example.

> routes of AS786 and AS5401.

That is correct.

> I'm not sure of the resulting cartisian product of hum, such a mess :)

Yes, you need this. The resulting cartasian product may have some
extra stuff, but that is OK.

> to 'feel' better the refine operator.

I think the first solution is cleaner.

> see the world switching to it :)

I have included this in my todo list. When we next revisit the RFC, I
will make these clarifications. Thank you.

> Regards.

Cengiz

-- 
Cengiz Alaettinoglu           Packet Design Inc.