Re: [nznog] Community Attributes
Perhaps a good place to start would be to get APE and WIX to implement a common policy, and then those that peer at those locations are likely to follow suit. -----Original Message----- ... 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 ...
On 12-May-2006, at 05:09, Philip D'Ath wrote:
Perhaps a good place to start would be to get APE and WIX to implement a common policy, and then those that peer at those locations are likely to follow suit.
Surely the APE and WIX are layer-2 services. What policy could they implement that would have any effect on individual participants' import policies? Joe
Surely the APE and WIX are layer-2 services. What policy could they implement that would have any effect on individual participants' import policies?
Their route servers run bgp and peering with them is them easiest way to get up and running, so if there are agreed local pref/community strings set to routes advertised to the RS, much goodness results...theoretically
On 12-May-2006, at 16:49, Jonathan Woolley wrote:
Surely the APE and WIX are layer-2 services. What policy could they implement that would have any effect on individual participants' import policies?
Their route servers run bgp and peering with them is them easiest way to get up and running, so if there are agreed local pref/ community strings set to routes advertised to the RS, much goodness results...theoretically
Without an objective, this is a solution looking for a problem. Joe
Joe Abley wrote:
On 12-May-2006, at 16:49, Jonathan Woolley wrote:
Surely the APE and WIX are layer-2 services. What policy could they implement that would have any effect on individual participants' import policies?
Their route servers run bgp and peering with them is them easiest way to get up and running, so if there are agreed local pref/community strings set to routes advertised to the RS, much goodness results...theoretically
Without an objective, this is a solution looking for a problem.
Somewhat suprised to get an answer at 2:20am on a sat morning - my beer is wearing off early tonight! Yes - true, it is a solution looking for a problem. One possible application would be (or would have been) to stop smaller isp's from "stealing" TCL and TNZ's national bandwidth by peering solely at APE (or WIX) and expecting them to route traffic to _their_ customers all the way down in Dunedin out of the kindness of their hearts. *dry snigger* The time for this has long since passed but I'm sure many other problems could be found for this solution =)
participants (3)
-
Joe Abley -
Jonathan Woolley -
Philip D'Ath