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:-).
A correction: the peer individual is definitely not a native Californian,
though he does reside there.
As best I can tell, we present consistant routes to all of our peers. How do
I know this? Because I set up test routers to peer with our public interconnect
points and run periodically run my consistancy checker against them.
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.
From our point of view, we aren't seeing any route which can be used for
shortest-exit to your multi-homed customers. Why? Probably because we don't
peer with the other ISP which serves those customers. The result is that we
have to backhaul traffic to other interconnect points, something which is
expensive for us and inconsistant with our normal peering policy.
I can see why you present inconsistant routes to us but I'm not sure that I
understand why you'd prefer a customer prefix via a direct connection to them
at one point in your network but via a connection to another provider at a
different point in your network. That would seem internally inconsistant to
me. Is this deliberate behavior to do shortest-exit within your network toward
your customer?
--Vince