Re: [RRG] Long term clean-slate only for the RRG?

["William Herrin" <bill@herrin.us>]

On Mon, Jun 23, 2008 at 2:53 AM, Lixia Zhang <lixia@cs.ucla.edu> wrote:
> - a clean-slate way of thinking is to see the complete design space,
>  without being constrained by what is "doable" or "undoable".

Lixia,

In order to be useful, a design space is always constrained by what is
or isn't doable. The clean-slate way of thinking merely excludes
compatibility with IPv4 and IPv6 from the definition of doable.


>> You - or at least Tony - seem to be focusing on Getting It Right for
>> the long-term: forever.  This surely requires a clean-slate
>> approach, with an entirely new routing and addressing architecture.
>
> I am not sure what to make out of this statement.
> - Isn't map-encap an entirely new scheme (compared to what we have today)?
> but does it require an "entirely new addressing architecture"?

Map-encap is not, in my opinion, an entirely new scheme versus what
exists today. All we're doing is leveraging our engineering skill with
VPNs and MPLS and evolving it a little more.

There are small number of additional points to research for map-encap.
Most notably:

1. Unaggregated RIB+MAP scalability limit in a push-based system for
cases where the maximum "normal" cost for a route/map processor (or
processing cluster) is under $10,000. (Note: RIB, not FIB)

2. User-level impact of a first-packet delay.

After that, the research is done and it's time to design a test suite
so we can have an engineering shoot-out.


>> If you want the RRG to work solely on the Long Term Clean Slate
>> approach, that is fine.  While I (and I guess the other map-encap
>> developers) would have something to contribute to that project, it
>> is not an urgent project - unless perhaps you want it to be the only
>> solution, which would make it much more urgent.
>
> I failed to comprehend the above paragraph, as it seems to suggest long term
> solution and map-encap are exclusive to each other---not sure where this
> came from.

It came from the early recognition that when not constrained by what's
possible with IPv4 compatibility in mind, map-encap is a terrible
approach to solving the problem.

I'm convinced that an optimal clean-slate solution requires major
protocol differences at layer 4 and above. That optimal solution will
include some combination of topological address aggregation and
multiple addresses per host.

Static address assignment doesn't tend to lead to good topological
aggregation because the topology is dictated by changing business
relationships, demand curves and outages for which static addressing
can't adequately account. So in order to get topological aggregation,
we're talking about the routing protocol performing continuous
optimization of address assignments. That implies that the layer-3
address becomes ephemeral in nature, which in turn requires that we
decouple layer-4 and up from the addressing at layer 3.

I don't mean a hack decoupling like Shim6, I mean real redesign. Layer
3 IPv6 might survive but layer 4 surely won't.

IF we take a clean-slate approach to the problem.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin@dirtside.com bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg