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 Return-Path: owner-nanog@merit.edu Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by cannes.aa.ans.net (8.8.5/8.8.3) with SMTP id QAA24798 for <jyy@cannes.aa.ans.net>; Thu, 13 Mar 1997 16:58:11 -0500 (EST) Received: by interlock.ans.net id AA25369 (InterLock SMTP Gateway 3.0 for regional-techsers@ans.net); Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-5); Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-4); Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-3); Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 13 Mar 1997 16:57:00 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 13 Mar 1997 16:57:00 -0500 Message-Id: <v03101919af4e08805b01@[152.160.213.42]> In-Reply-To: <CMM.0.90.2.858281493.vaf@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@valinor.barrnet.net> From: "John G. Scudder" <jgs@ieng.com> Subject: Re: consistent policy != consistent announcements Cc: Sean Donelan <SEAN@sdg.dra.com>, nanog@merit.edu Sender: owner-nanog@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@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