On Mon, 26 Jun 2006 06:28:41 +0000 (GMT), "John
Smith"
<jsmith4112003 yahoo.co.uk> said:
[snip]
>
> > There isn't a facility in bgp to tell a neighbor
more than one possible
> > aspath... or not one that most network folk use
currently.
> >
> > I suppose for a subset of routes you might hack up
some community based
> > solution, but it'd be a horrible hack, and it'd
cause you to keep churning
> > your router configs on a very regular basis as
things up stream changed.
> >
> > If the downstream has a connection only to you
does it matter where they
> > send packets? everything has to go through your AS
to get anywhere...
> > right? If they have a multihomed solution (you and
another isp) they are
> > going to have to decide on some other internal
metric (interal to them
> > based perhaps on non-routing-table information,
like 'john has a oc-12 to
> > provider-Y, Jim only has a T1.... send to John!')
whete to send traffic.
>
> I dont think its as simple as this. In the simplest
case, assume that my
> downstream peer has a policy to reject all routes that
traverse AS 20.
> Now i am splitting all load across AS 10 and AS 20,
while i tell him that
> i'll be only sending the traffic through AS 10. This
can create problems
> for my downstream peers, and in the worst case can lead
to
> blackholes/loops.
If an AS is balancing traffic outbound in weird ways that's
only a
problem for their customers if it doesn't work. Customers
do otherwise
not see any details beyond the ability to filter based on
AS-paths they
receive, so outbound there's no potential for
"blackholes" with current
standards which specify that only the best (one) path is
announced.
For inbound traffic you'd only have a problem if every
packet did
carry a recorded traversal path and there were equipment
around that
could make decisions based on such information.
What you're asking for simply doesn't exist in today's
network.
Those who want to the ability control path-selection
globally
should participate in IETF workshops to get such
functionality
included in future network-architectures ;)
//per
--
Per Heldal
http://heldal.eml.cc/
|