consistent policy != consistent announcements

Fri Mar 14 17:48:49 UTC 1997

If a provider/AS does not have the policy of dumping hot potatos to other 
peers for the traffic to its customers who happen to multihome to those peers.
Then there is a simple way to do it.  They can have policy of always favor 
its own customer routes over the routes learned from other peers.  This will 
avoid the inconsistent announcement by eliminating the cases that some part 
of the AS favors routes M from it's customer and other part favors M from 
another peer, thus announce consistent routes to other peers.   

It's very easy to manage this policy.  Just assign lower (less favored)  
local_pref to routes learned from peers than those learned from customers.
It's AS based.  By using the default local_pref value, one only need to
assign a lower than default local_pref value to the peer AS at border routers.

A good side effect of this policy is that your customers routes will be 
protected from being blackingholed from careless ISPs leaking/advertising your 
customers routes but have no way to reach them.
							--Jessica 

------- Forwarded Message

Message-Id: <v03101919af4e08805b01@[152.160.213.42]>
In-Reply-To: <CMM.0.90.2.858281493.vaf at valinor.barrnet.net>
References: Your message of Thu, 13 Mar 1997 10:46:06 -0500 (EST)
Mime-Version: 1.0
Date: Thu, 13 Mar 1997 16:41:41 -0500
To: Vince Fuller <vaf at valinor.barrnet.net>
From: "John G. Scudder" <jgs at ieng.com>
Subject: Re: consistent policy != consistent announcements
Cc: Sean Donelan <SEAN at sdg.dra.com>, nanog at merit.edu
Sender: owner-nanog at merit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Length: 2715

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

------- End of Forwarded Message