[ppml] getting converts to V6

[Owen DeLong]

>> in the IPng wars, many folks asserted that without a solution to the
>> routing problem, adding more address bits would both fail to solve
>> existing problems and also make existing problems worse and also  
>> cause
>> new problems.  as you can see, those folks lost the war.  ("too
>> little,
>> too soon." --tli)
>
> Sorry, what problem?  I've been told "just build bigger routers" so
> many times now, maybe a million lemmings might not be wrong.
>
The lemmings are wrong.  There is no feasible way to scale a routing  
solution
that continues to overload the end system identifier and routing  
locator onto
the same number. In the end, even the telcos have abandoned this idea,
and it is long past the time when IP should have in the IDR world.
>>> There's more than one way to handle a problem.  Why must PI always
>>> be the
>>> answer?  (because the other is harder? takes more time? more
>>> collaboration?
>> because it's the knob we have, on the mechanism we have, rather
>> than the knob
>> we wish we had on the mechanism we don't have.
>
> Given the state of affairs, namely:
>
> - all RIRs are liberalizing PI allocation policies.
> - many believe there is no problem in routing that can't be solved by
> throwing bigger/faster (although they admit, not necessarily cheaper)
> boxes at it.

No... What many of us believe is that until the routing problem is made
meaningful again, it won't get worked on.  We also believe that the  
existing
hacks are no longer tolerable.  Finally, at least in the US, Sarbanes  
Oxley
virtually guarantees that an increasing number of organizations MUST
use provider independent addressing to meet auditing criteria.

> - the IETF appears to have gone into navel gazing wait state.

This is not a meaningful difference from the IETF engineering state over
the development of IPv6. Of about 3 primary concerns placed on the plate
of IPNG working group, they solved only one.  The one they solved was
adequately solved by TUBA, but, they chose, instead, to implement a more
complex solution in the name of solving the other 2. Then, they  
abandoned
the other 2 as "too hard".

The three:
	1.	Need a bigger address space.
	2.	Need a scalable routing solution.
	3.	Need to make renumbering easy if we want to keep the PA
		model viable.

What was actually accomplished was:

	1.	Bigger address space.
	2.	No effort whatsoever was made in this area.
	3.	They attempted to ram a non-viable PA model down the track
		thinking that no-one in operations would dare defy the all
		powerful IETF.  I dared, and, apparently the community agreed
		with me, at least to some extent.

>
> It is difficult for me to envision a future where there will be any
> significant change to IPv6 architecture that might permit realistic
> site-wide renumbering.  But we have time yet...
>
Right.  As such, I think, instead, we should focus on fixing routing.
That is possible. Here's how:

Using options, the destination AS of a packet headed to a non-local
prefix (non-local being defined as orginating from an external ASN)
can be encoded in the packet by a router prior to its departure from
the local AS. Then, all transit AS can forward the packet strictly based
on the destination AS without ever even looking at the prefix.

The lookup to map Prefix->origin AS can be done in a distributed
fashion similar to DNS, and, since it can be moved relatively close
to the edge, it can scale fairly reasonably.

At that point, the EBGP state information required is reduced to
AS Paths, next hops, and metrics.  IBGP would contain the EBGP
AS Path/Next Hop/Metric information and may need to include
the local Prefix data (but, probably not, that can probably be
handled by a parallel IGP).

This could be implemented incrementally and modularly, although
the EBGP savings could not be realized until deployment was
sufficiently widespread that the BGP table no longer has to haul
around prefixes.

This can be done strictly with software upgrades to existing routers,
although there may be some platforms where new ASICs would
be required to achieve full speed forwarding with this method.

The first step, however, is to agree upon a method.

If we fix routing, then, we no longer need to solve renumbering
because renumbering becomes unnecessary and PI for everyone
becomes feasible.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070517/c4c93f9b/attachment.p7s>