On Wed, 2006-05-10 at 11:37 +1200, Alastair Johnson wrote:
Joe Abley wrote:
On 9-May-2006, at 08:29 , Alastair Johnson wrote:
200 : customer 175 : private peering 170 : public peering 150 : domestic transit 130 : international transit
When building a list like this it can sometimes be useful to consider what happens to a route which (through configuration error) avoids receiving the standard import policy, e.g. through a session that is missing a route-map.
Very good point, Joe. I hadn't thought of that, but it does make sense.
Of course, we're all using standard peer profiles and group definitions which would NEVER allow this to happen, right?
Well I guess that's the point. Not necessarily standards, but some discussion for sure. Another thing I've also been thinking about is community attributes. Using it to turn on remote blackholing with upstreams is useful, and we saw at NZNOG the approach to communicate enhancements or variations of that. But lowest common denominator suggests that using an agreed set of community attributes (which works for everyone) to convey stuff is something that should be worked on first. So, combining an agreed set of local_pref's and some community attributes might be the basis of building a broader, and faster exchange between participants. Community String Attributes 1000 Route is locally-originated, and should be exported 1000 Route is locally-originated, but should be suppressed towards peers 1002 Route is a blackhole route 1100 Route was learnt from a customer 1200 Route was learnt from a peer 1300 Route was learnt from a backbone 1400 Route was learnt from a transit provider (domestic/international) Local Preference Values 130 - locally-originated 120 - customers 110 - peers 90 - backbone 85 - domestic 80 - international here: http://www.occaid.org/routingpolicy.php Is a really scary example of how carried away one could get, but some of the ideas are interesting.. Especially the geographic stuff. anyway...There's probably a gazillion variations that one could adopt, but one question I have is how much pain would it be for other operators to implement a common convention? I can't recall this sort of thing being discussed on the NOG. cheers jamie