[ppml] Fw: IRS goes IPv6!

[Tony Hain]

Thomas Narten wrote:
> > The only reason why each one of these small allocations
> > would need a slot in the routing table is because ARIN allocates
> > them more-or-less at random, first come, first served. If, however,
> > ARIN would allocate such addresses in a way that they could be agregated
> > into a smaller number of routing table slots and still maintain
> > routability, then the policy problem is solved.
> 
> In order for these prefixes to be aggregated, you'd have to convince
> ISPs to aggregate them and carry traffic for the aggregates. Smells a
> bit like ARIN telling ISPs what to do.
> 
> You are also reinventing geographical addressing (or metro, or
> whatever variant it is). Again, this is an old horse, on which the
> community does not have agreement that it solves the problem. Or
> rather, agreement that ISPs would ever agree to adopt such an
> approach.

There is a business model change that will have to happen to resolve the
brokenness caused by filtering no matter what allocation approach is used.
There is no agreement on making this business model change, but that should
not preclude allocation policy from setting the stage for when it becomes
necessary. Random allocations will be difficult to resolve in any case, so
going down the first-come path should be avoided. I don't really care where
we end up, but the approach in draft-hain-ipv6-pi* allows filtering
whenever, wherever, and on whatever scale makes sense. The filtering does
not have to be done globally, but wherever there is filtering there will
need to be different business models than are used in current practice.

> 
> Saying it obviously solves the problem, when others continue to point
> out serious issues with actually deploying such an approach, isn't
> helpful.

The 'serious issues' generally boil down to 'we don't want to change
business practice' because everyone wants the ability to have a global
impact. 

> 
> > Of course a bloated routing table would not serve the public
> > but it also does not serve the public when ISPs pretend that
> > the routing technology used today is unable to solve this
> > problem. The problem IS SOLVABLE and if customers demand it
> > then ISPs will solve it.
> 
> You are much more optimistic than I. I'd prefer to actually see a
> viable approach (or outline of an approach) than just assume "we'll
> figure it out somehow." Been there, done that.

The problem is not with the routing technology, it is in its use. The
continuing fantasy about a single DFZ does not help people sort through the
issues either. BGP has evolved considerably to deal with just about every
topology we know how to build. What it doesn't do is deal with the case
where details are filtered when the business process and interconnects are
not in place to make sure the traffic gets delivered. 

Stepping back and looking at the problem in a technology independent way ...

1) keeping the cost of routers within reason requires limiting the amount of
global topology detail
2) actually delivering packets requires explicit topology detail by the set
of providers directly connected to the recipient 
3) traffic engineering projects the delivery detail on a wider scale than
the directly connected providers
4) a traffic engineering policy that sorts between equal paths uses less
detail for closest to source and more detail for closest to destination
5) private interconnects and exchange points allow providers that need the
explicit detail to interact without the rest of the world having to know

There is probably more to this list but it covers enough for the discussion:

PA based allocations are nothing more than filtering that is strictly
aligned with the provider business unit. 

PI of any flavor forces providers into the unnatural act of acknowledging
that they can not meet all of their customer's needs. 

Access providers want more outgoing detail so they avoid handling the
incoming traffic until it gets near their destination customer, and less
incoming detail to dump outgoing traffic as quickly as possible.

Transit providers want less detail for scale reasons, though they will flip
between more and less to achieve the highest revenue to bit-mile ratio.

Exchange points exist globally, though by current business practice they are
not considered to be transit providers between access and long-haul transit
providers. The neutral regional interconnect between access providers is an
important aspect to maintain, but bolting on a transit AS to aggregate all
the non-traffic engineered PI would solve the business related complaints
about any geo approach. That step is not one the existing provider community
is ready to take. Despite their reluctance to go down that path we should be
setting the stage through PI allocation policy because it appears to be the
only way to sort between traffic-engineered PI and simple
redundancy/independence PI. Traffic-engineered PI will always take up global
routing slots, other uses don't need to.

Tony