North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: consistent policy != consistent announcements

  • From: Jessica Yu
  • Date: Fri Mar 14 17:35:25 1997

Excuse me for responding myself here.  Just like to clarify my previous 
message a bit. 

The note below does not intend to solve Randy's problem for his chosen
policy.  It rather intends to describe a different policy used by many 
ISPs which won't run into the same problem.  
IMO, ISPs who are engaging in the 'hot potato' routing practice have the 
obligation to announce consistent routes to its peers at different peering
points.  It may require an ISP to change it's internal policy to achive 
this with reasonable maintance work (like the one described below) or to
excercise whatever internal policy it decide but do more work (configuration
management,etc) to fulfill the obligation.
                                                   speaking for myself. 
Date:    Fri, 14 Mar 1997 12:48:49 EST
To:      [email protected]
cc:      [email protected], Sean Donelan <[email protected]>, [email protected]
From:    Jessica Yu <[email protected]>
Subject: Re: consistent policy != consistent announcements
Return-Path: [email protected] 
Sender:  [email protected]
Content-Type: text
Content-Length: 5173
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.

- - - - - - - - - - - - - - - - -