>
> Folks,
>
> 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.
> ......

Folks,

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  
prefixes only.

- 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  
here)

#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?

Lixia
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 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