[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] What do we have consensus on?
On May 21, 2008, at 8:28 PM, Robin Whittle wrote:
Hi Tony and Lixia,
Can you list what decisions the RRG has achieved consensus on?
Hi Robin,
instead of replying to each of your bullets below, here is what I
thought where we are at this time: recall the discussions we started
in April following the message on RRG process clarification:
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 ???)
Towards the above goal, one step is to first reach a shared
understanding of exactly how many branches we face at that highest
level branching point.
I offered a strawman list of the branches: (really just 2 main 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
Tony suggested 3 branches:
- Transport: this falls with #1 in the above
- Map-n-encap: this is #2 in the above
- Translation: I did not get exactly what this one is, if it is
not the GSE rewrite.
there was a debate between Tony and Brian at the time about whether
SHIM6 is translation. I dont think I fully understood Tony's argument
on why SHIM6 is a translation; may be Tony could try one more time here.
Lixia
I think clarity on these points would help us reach consensus on
whether to keep open discussions about solutions in the
"Translation" and "Transport" areas of the total possible solution
space.
For instance, is there broad consensus that will the RRG have done
its job if we propose a solution which only works with IPv6?
The RRG Design Goals only mention IPv4 once and do not mention IPv6
in the body of the text. There is no IPv6 scaling problem and won't
be one for many years - until the adoption level rises well beyond
the current state, which would take a decade or more at current
growth rates. I assumed we were trying to solve the IPv4 routing
scaling problem, with an eye to doing something similar for IPv6 -
although perhaps not with the same urgency.
Do we have consensus that it is acceptable for our solution to
require host changes to all hosts which participate in
communications which involve the new techniques? For instance if a
host-based solution doesn't provide scaling benefits when
communicating with a non-upgraded host.
Do we have consensus that if the host-based solution by its very
nature makes it impossible for the network administrator to control
multihoming, portability etc. via central routers, that such an
approach provides suitable benefits to the routing system and to
those who must adopt it that is likely to be widely enough adopted
to make sufficient difference to the routing scaling problem?
- Robin
--
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