consistent policy != consistent announcements

Randy Bush randy at psg.com
Thu Mar 13 07:14:00 UTC 1997


[ Most of this work was done by Andrew ]

A normal condition of peering between consenting adults is that the peers
have consistent policy across all points where they peer.  This is to allow
hot potato, whereby I can get rid of my packets destined for a peer at my
nearest exit to them.

A naive assumption we make is that this means that the peers will be making
the same announcements to each other at all points.  This turns out to not
always be the case.

I have customer A who connects to multihomed site M.  I also have customer B
who also connects to M.  I will see M as either "A M" or "B M", equal length
AS paths. depending on whether I am closer to A or B.

So in some portions of my network, I will prefer to get to M via A and in
others I will prefer to go via B.  Thus I will announce to my peers in some
locations "A M" and in others "B M".  The result is that I do not give the
same announcements to my peers at all locations, yet I have a consistent,
simple, and seemingly reasonable policy.

In another example, I have a peer P who connects to multihomed site M.  I
also have a customer C who connects to the multihomed site M.  I will see M
as either "P M" or "C M" - again equal length AS paths.  If I follow the
'normal' BGP path selection rules (and don't always prefer customers over
peers), then in some portions of my network, I will prefer M via P and in
others I will prefer M via C.

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.

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. ]

randy





More information about the NANOG mailing list