Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

[Owen DeLong <[e-mail]>]

> On Nov 13, 2015, at 11:21 , Gert Doering <[e-mail]> wrote:
> 
> Hi,
> 
> On Fri, Nov 13, 2015 at 10:54:31AM -0800, Owen DeLong wrote:
>>> On Nov 13, 2015, at 10:41 , Gert Doering <[e-mail]> wrote:
>>> 
>>> On Fri, Nov 13, 2015 at 09:39:35AM -0800, Owen DeLong wrote:
>>>> I believe that an extra 32-bit field in the IPv6 header could have provided a significant step towards solving this problem by encoding the destination transit AS in the packet at the first router capable of resolving that information and then routing on that basis in the IDR realm. In that case, stub networks (non-transit autonomous systems) would not need to be visible in BGP and we would not need to track prefix state beyond the closest transit ASNs. A separate map of Prefix->Candidate Transit ASNs could be maintained through a mechanism somewhat similar to DNS.
>>> 
>>> So you're in the LISP "we noticed that route caches do not scale, but we
>>> try again and again" camp now?
>> 
>> Who said anything about a route cache?
> 
> So you want to do the map lookup every time a packet traverses one of
> these routers?  Or should the Prefix->Candidate Transit ASNs map be
> distributed everywhere, like, with BGP, so all these routers get to hold
> 100M map entries all the time?

There’s a difference between caching part of a  map in RAM for active flows and
having to cache an entire routing table for all possible destinations with full path
information and multiple alternatives.

One is a very large data structure for each possible path.

Also, the lookup doesn’t have to be performed by every router in the path, just the
first IDR capable router in the path.

So this is very different from the LISP approach.

Owen