asymmetric routing

[Matthew Lehman]

Concerning multiple uplinks to different providers; when you use the
word customer, I am assuming you mean an entity with provider dependent
addressing (Some people will have customers with provider independent
addressing).

It is a common scenario to want provider diversity to guard against
transit provider failure or to implement different policies by service
(i.e. Content Delivery Networks, bulk vs. interactive traffic, etc.).
This does not seem to be limited to IPv4.  There's a draft on this at:
http://www.ietf.org/internet-drafts/draft-ietf-multi6-v4-multihoming-00.
txt

-Matthew

> -----Original Message-----
> From: Pim van Pelt [mailto:pim@ipng.nl]
> Sent: Monday, January 28, 2002 7:56 AM
> To: Sandy Wills
> Cc: ipng@uni-muenster.de; 6bone
> Subject: Re: asymmetric routing
> 
> 
> Regarding my statements on asymmetric routing at IPng, Christian
(JOIN)
> reasoned:
> | > Yes, one could filter all but those prefixes a customer holds, but
> then the
> | > customer has to name all his providers/prefixes. You can't force a
> customer
> | > to do so, because that information might be confidential.
> 
> Sandy said:
> |    Isn't this reasoning flawed? Customer #1 has prefix A.  You let
that
> | traffic through.  Customer #2 has prefixes X, Y and Z - but he
doesn't
> | want you to know about Z because he's afraid that you won't like
him.
> | So, you let through traffic with prefixes X and Y.  Stop Z.  Traffic
Z,
> | if any, will go through some other provider, or it won't go through.
> | You're not forcing anyone to do anything.
> |    What am I missing?  You can limit the prefixes you allow to those
> | your customers tell you about.  Your customers can have more than
one
> | feed, and he doesn't have to tell you everything.
> Well it's not really BGP we were talking about. In the BGP world we
can
> filter updates from downstream customers, which means we will not
route
> traffic to them. But what if the customer, with prefix B, sends
traffic
> originating from B via my networks (and I am prefix aggregator A).
Then
> I will inject traffic into the 6BONE that should not be coming from my
> routers.
> This can no longer be taken care of by BGP prefixlist filters, but the
> need
> for ACL based filtering arises. The customer with a desire to be
> multihomed,
> should respect aggregation policies and not send provider A traffic
that
> comes
> from prefix B, when A does not advertise B's prefixes into the default
> free
> zone.
> In practice, unless you deliberately deop the traffic, customers will
send
> you any and all traffic they please. Being passive makes you break
rules.
> This is why I brought my first post to the list. But I think we made
that
> point already ;-)
> 
> |    You're not forcing anyone to do anything.  He is forcing himself
to
> | pay for routers and network people which can direct his traffic out
the
> | proper cables, and HE is the one who suffers if HE screws it up.  He
> | does NOT have the right to force you to enable routing loops because
his
> | routers got confused.
> This is a very harsh point of view. In real life, the customer pays
you to
> handle his traffic, and I can very well understand him wanting more
than
> one
> uplink to different providers, .. , in the ipv4 world this is very
normal.
> However, with IPv6, you (the provider) cannot simply handle any
traffic
> given
> to you by your customers. This breaks the multihomedness we know and
use
> in
> IPv4 networking.
> 
> About dual uplinks and load balancing. These are not layer3 decisions,
and
> can be taken care of at a lower level, eliminating the need of
disjunct
> sets
> of IPv6 addresses (eg, more than one prefix). Does anybody have info
on
> situations where a customer would want more than one AS to uplink to ?
And
> please look at the future when reasoning, not at the present IPv4
> situation.
> 
> groet,
> Pim
> --
> ---------- - -    - - -+- - -    - - ----------
> Pim van Pelt                 Email: pim@ipng.nl
> http://www.ipng.nl/             IPv6 Deployment
> -----------------------------------------------