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