On Jun 5, 2012, at 7:44 AM, Jeroen Massar wrote:
> On 2012-06-04 23:06, Owen DeLong wrote:
>>
>> On Jun 4, 2012, at 6:11 PM, Jeroen Massar wrote:
>>
>>> On 2012-06-04 17:57, Owen DeLong wrote: [..]
If you're going to redesign the header, I'd be much more
interested in having 32 bits for the destination ASN so that IDR
can ignore IP prefixes altogether.
>>>
>>> One can already do that: route your IPv6 over IPv4 IPv4 has
>>> 32bit destination addresses remember? :)
>>>
>>> It is also why it is fun if somebody uses a 32-bit ASN to route
>>> IPv4, as one is not making the problem smaller that way. ASNs are
>>> more used as identifiers to avoid routing loops than as actual
>>> routing parameters.
>>>
>>> Greets, Jeroen
>>
>> While this is true today (to some extent), it doesn't have to always
>> be true.
>>
>> If we provided a reliable scaleable mechanism to distribute and cache
>> prefix->ASN mappings and could reliably populate a DEST-AS field in
>> the packet header, stub networks would no longer need separate ASNs
>> to multihome and IDR routing could be based solely on best path to
>> the applicable DEST-AS and we wouldn't even need to carry prefixes
>> beyond the local AS border.
>
> The problem here does not lie with the fact that various of these
> systems (LISP comes to mind amongst others) have been well researched
> and implemented already, but with the fact that the general operator
> community will not change to such a new system as it is not what they
> are used to.
>
> Greets,
> Jeroen
LISP et. al requires a rather complicated deployment and would be even
more complex to troubleshoot when it fails.
What I am proposing could, literally, be deployed with the existing system
still running as it does. The difference would be that for packets containing
a dest-as field, we would (initially) have the option of routing to destination
based on that field and ignoring the prefix.
Later, the distribution of prefixes in BGP could be deprecated, but that would
be several years off.
What I am proposing is much much simpler to implement and much closer
to what operators are used to than the map/encap solutions proposed to
date.
What I am proposing, however, requires us to add fields to the packet
header (at the source), so it will take a long time to get implemented even
if it ever did. Deploying it would require code updates to every router and
end host and would require a new IP version number.
However, the code changes at the host level would be pretty minor.
Add some bits to the header and set them all to zero.
The first router with "full" routing information and access to a populated
cache or the ability to resolve dest-as for the destination prefix would
populate the dest-as field. From that point until it arrived at the actual
destination AS, the packet would be routed based on the best path
to the AS in question.
True, this would mean operators would have to revert to using an ASN
to represent a common routing policy, but at most that would require
some larger operators to deploy a few more ASNs.
ASNs would no longer be required for what are now stub AS.
It's truly unfortunate that IETF chose to drop the ball on this when IPv6
was being developed.
Owen
