Re: consistent policy != consistent announcements
Therefore I will not announce any route to M to my peers in some locations, as I don't announce peers to other peers, and in others I will announce "C M". Again, I do not make identical announcements to my peers, yet I have a consistent policy.
Yep, policy filters run up against the policy of only announcing the single, best route. I've been thinking with policy filters and variable weighting, should it be changed to announcing the 'best' route that meets policy, even if it is the second or third 'best' route you know about.
Am I being unfair to my peers? Would they be justified in making a stronger requirement than 'consistent' policy? What requirement would be reasonable? [ note that, in the first example, the common policy of preferring customer routes over peer routes will not change my announcements. ]
Fairness by what measure, and to which peers? My first concern is the loss of information when the route to M isn't announced. This causes unfairness when traffic ends up taking the 'long' route. Since we don't have a full-mesh among peering partners, the unfairness of the long route could be considered a normal part of today's Internet, like asymetrical routing. More than likely your peer is doing the same thing unto you. The second effect of M's route not being announced happens when traffic is blocked because no 'longer' path shows up anywhere else due to different route weightings and policy filters across various combinations of ASs. I consider this possibility the more serious problem. As the peering mesh becomes sparser, expect more missing in action paths, even if the physical connections exist the 'best' path may not be announced. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
My first concern is the loss of information when the route to M isn't announced. This causes unfairness when traffic ends up taking the 'long' route.
My peer fears that and would like me to fix it. I don't understand how I can do that in a simple maintainable fashion.
More than likely your peer is doing the same thing unto you.
Quite possibly, but they won't 'fess up to it. And I don't want to whine at them unless I know how to constructively address the opportunity (the peer is a Californian:-).
The second effect of M's route not being announced happens when traffic is blocked because no 'longer' path shows up anywhere else due to different route weightings and policy filters across various combinations of ASs. I consider this possibility the more serious problem. As the peering mesh becomes sparser, expect more missing in action paths, even if the physical connections exist the 'best' path may not be announced.
If my peer does not agree that my policy is reasonable and a consequence of current tools, their reaction may be to reject inconsistent announcements thereby increasing the likelihood that no path is propagated. randy
Yep, policy filters run up against the policy of only announcing the single, best route. I've been thinking with policy filters and variable weighting, should it be changed to announcing the 'best' route that meets policy, even if it is the second or third 'best' route you know about.
Unless I misunderstand what you mean by "variable weighting", this would not be a good idea. It's a BGP design point for a router to only announce the route(s) that it is actively *using*. In your comment above, a. If a router has a route it believes is "best", why isn't it using it? b. Regardless of the answer, the router should announce the route it is using for its own forwarding. To do otherwise would be to lie about the path which traffic will take to the advertised destination. If policy forbids it from announcing the route it is using, so be it. (Or, if that's not acceptable change the policy.) By the way, this general fact about BGP (external announcements are governed by internal route selection) also means that for Randy to always announce the same route to his peer, he would have to change his own, internal routing policy to do cold-potato routing to one of the two candidate paths. This doesn't seem like a reasonable thing for a peer to demand he do. Regards, --John
participants (3)
-
John Scudder
-
randy@psg.com
-
Sean Donelan