[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] RRG process clarification
- To: rrg <firstname.lastname@example.org>
- Subject: Re: [RRG] RRG process clarification
- From: Lixia Zhang <lixia@CS.UCLA.EDU>
- Date: Fri, 2 May 2008 08:52:06 -0700
We've been told that the process that we're trying to execute is
still not clear. Here's an attempt to clarify things.
Our ultimate goal is to deliver a recommendation for a routing
architecture. Please note that our goal is NOT to deliver a wholly
complete, fleshed out routing subsystem implementation, complete
with protocols, specs, and running code. Those are all non-goals.
Although one can potentially learn a great deal from running
implementations, they are more useful in improving designs than
fundamental architecture. What we should be doing is trying to
reach consensus on the various pieces of the architecture.
There is a very broad solution space at hand, and we need to
understand the breadth of it. Yes, we could simply pick one
solution and go with that, but we would not be performing our due
diligence. The community has placed in us the responsibility to
understand the whole of the solution space, partition it, and select
the best path through it. Without exploring the solution space at
least a bit, we won't have done a credible job of thinking about all
of the ways that we could architect the system.
Further, once we have surveyed the solution space, we need to
develop rough consensus on the approach through the solution space.
Arguing about 'incremental deployment', for example, doesn't help
this at all. We need to first come to some agreement on the very
highest level branches in the decision tree (e.g., do we do map-and-
encap or translation or ???), and not worry about the detailed
leaves. That is up to the IETF to wrestle with.
Getting a consensus on this very highest level branches is a
difficult task, as it requires a good understanding of multiple
important factors as well as their interplays, perhaps with the
mapping system design as a centerpiece. Again, our job is to deliver
an architecture, thus we must first reach such a consensus.
it's been exactly 2 weeks since the above msg was posted. There was an
initial exchange of msgs on this thread, mainly expressing agreement
with the proposed direction together with clarifications on several
specific issues. However that exchange stopped shortly after, as
opposed to continue on to articulate and propose what should be our
decision on that very highest level branches in the decision tree. In
fact the list has been uncharacteristically quiet this week:)
To (re)start that very much needed discussion, I thought a useful
starting point is to first reach a shared understanding of exactly how
many branches we face at that highest level branching point. Below is
a strawman list (extracted from the taxonomy draft Scott Brim and I
put out in late March). this by no means any position, but sole for
the purpose to get a discussion started.
- the shared goal of all the proposals so far: making the routing
system scalable by routing on topologically (read: ISP) aggregatable
- alternative ways to get there (branches)
#1 Using only aggregatable addresses throughout in the Internet
The essence of this approach is that a multihomed site will have
multiple address prefixes.
Example approaches under this category:
- SHIM6, with a shim layer between IP and transport to hide the multiple
IP addresses from transport
- A proposal by Mark Handley, which pushes all multiple IP addresses
all the way up to transport layer to handle
(NOTE: I mention these examples for the sake of illustrating what this
branch means; by no means we should get into specific proposal debate
#2 Routing on aggregatable addresses only inside the global transit
core (the place that faces scalability challenges today), but do not
push these provider-based addresses into user sites.
The essence of this approach is that a mapping layer must exist at the
interface between user sites and the transit core.
(the word "layer" is meant an insulation boundary between parts of the
net; please do not confuse it with "protocol layer". I simply could
not find another word at the moment)
Example approaches under this category:
- map-n-encap, which uses IP-in-IP tunneling at the boundary
- GSE, which uses IP address rewrite at the boundary
Some people prefer to separate out IP-address-rewrite to a 3rd
category, and I would be happy to go that way as well.
Does the above miss any other branches at the top level design tree?
PS: I do owe Robin a reply with regard to what are the steps towards
the decision (i.e. whether RRG needs a depth-first search to reach a
decision), but I want to make clear that the above question is
orthogonal to that debate.
to unsubscribe send a message to email@example.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