[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] RRG process clarification


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