consistent policy != consistent announcements

Thu Mar 13 21:41:41 UTC 1997

At 11:31 AM -0800 3/13/97, Vince Fuller wrote:
>Well, if that "candidate path" is, in fact, one of Randy's customer, then
>I would expect him to "cold-potato" route toward it.  One would think that
>to be part of the service that his customer is purchasing.

I think that his internal routing policy and service to his customer is
really irrelevant to the question at hand, except insofar as its
side-effects affect you.

>I certainly
>shouldn't have to do "cold-potato" routing to his customer, as that customer
>isn't purchasing anything from me.

Ah, I finally see the problem.  In essence, Randy's (announcement) policy
assumes that a destination is either in the set of customer routes OR the
set of peer routes, but not both.  But in this case we have a destination
which is in both.  The side-effect ends up making you "cold-potato" route
to destinatons in the (customer + peer) intersection.

The question is, does it make sense for a destination to be considered to
be in both sets?  If "peer" is supposed to mean "not-customer" then the
answer is probably no, there is (should be) no intersection between
"customer" and "not-customer".

If this is right, the problem is that sometimes the AS path is an overly
blunt instrument to determine the customer-ness of a route.

In the case where using the AS path doesn't allow the route to be
categorized correctly, the only way *I* can see of fixing it is using
manual policy (sorry).  Presumably this could be done with a minimum of
pain by something like (assumes M should properly be categorized as
"customer"):

	(at router peering with customer C in Randy's example):
	write "customer" community onto all routes from C

	(at router peering with peer P in Randy's example):
	write "customer" community onto all routes from (P M)
	write "peer" community onto all other routes from P

	(at routers sending routes to external neighbors)
	send routes with "customer" community to all peer routers
	send routes with "peer" community to all customer routers
	send routes with "customer" community to all customer routers

The special-casing is limited to the guy who peers with P, who has to
decide to write "customer" onto (P M) routes.

Presumably one could (semi) automatically detect when a new special case is
needed by gathering routing table snapshots from border routers from time
to time, and finding routes which are colored inconsistently (identical
destinations, different communities).

Regards,

--John

--
John Scudder                        email:  jgs at ieng.com
Internet Engineering Group, LLC     phone:  (313) 669-8800
122 S. Main, Suite 280              fax:    (313) 669-8661
Ann Arbor, MI  48104                www:    http://www.ieng.com