RE: Provider Independent addressing usage

[Pekka Savola <pekkas@netcore.fi>]

On Tue, 17 Jul 2001, Tony Hain wrote:
> Filtering more-specifics was an IPv4 activity 5 years ago, but the
> reality of providing the service the end customer is paying for trumps
> the 'network-centric' viewpoint every time. If a site uses
> provider-based addresses and expects those to be routable through
> another provider then the upstream table of those two providers has to
> accept the explicit entry. No amount of wishing will make that untrue.

That's not enough; every client's ISP in DFZ also has to accept the
explicit entry, at least in the case that:
 1) you want to protect from failure of your original PB ISP, or
 2) your PB ISP will not co-operate with secondary ISP, and give your
traffic to them when needed your PB-ISP link is dead.

Further, this protects against link loss toward PB-ISP, but not against
bigger failures _unless_ every router in DFZ has the explicit entry (so
return packets don't get blackholed, or sent to PB-ISP not Secondary-ISP).

When this level (really, at least 95%!) of filter-free 'ness is required,
multihomers might not see breaking the aggregates as a _working_ solution.

I don't know how IPv4 filtering was done 5 years ago, but currently I
believe many organizations in DFZ filter e.g. from /25 to up; I see this
as equivalent to filtering /48 in IPv6 world.

> The reason I say FUD is the argument appears to be ignoring the origin
> of the routing entry. If an operator is forwarding a packet toward a pop
> in the destination region, it had to get that route from somewhere. The
> only way your scenario works is if the operator is not providing service
> in the destination region and decided to make up a route to that prefix
> for internal use. If a provider does this, yes the traffic will die, but
> this is no different than making up any other prefix.

The problem here is, that unless the carrier or big ISP makes up a route
(e.g. based on assumption it has a PoP with a few customers in the area,
but no exchange nearby), e.g. with adding a static Null0 route and
redistributing that into BGP, and only uses specifics, it has to exchange
specifics with other carriers or huge ISP's and the number of these might
not be small.

But anyway.. this is perhaps kinda theoretical discussion as I doubt that
many sites would jump to use PI immediately, and the problem would be
rather unlikely to "explode" that soon.

> > Perhaps the practical requirement for IX's should be noted
> > more clearly in the draft.
>
> Please send text.

Perhaps, something like, to be included in General Considerations:

It is believed that the amount of overly-specific route advertisements can
be minimized using exchange-based aggregation in different scopes.  This
way there would be no need for non-aggregated advertisements in the
networks interconnecting different scopes.  However, setting up exchanges
is not always technically, economically or otherwise feasible; it is a
balance between the amount of full /48 prefixes ISP's operating in the
scope are willing to accept, and between forming an exchange, or some
other "neutral ground", and using provider independent aggregates.  It is
believed that when the list of overly-specific route advertisements grows
too long, some sort of traffic exchanging will be established between the
vast majority of ISP's operating in that scope.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords