Following up on this thread, I also think restricting
the work here to the existing approaches would not be correct.
Second, for each forwarding method, there are multiple
forwarding state creation techniques, and hence, routing plane
approaches. It's a multidimensional space of solutions. A value
on one axis does not necessarily define values on others.
E.g., explicit routing does not mean MPLS...
Now, each spot in this space will have a different vector of
complexity (and therefore scalability) characteristics.
The goal is to eventually come up with a solution that gives
us "good enough" complexity assessment in as many components
as possible.
So, on the one hand, we should not preclude alternative forwarding
models, on the other, if any of the existing ones does not give us
desirable characteristics provided by others (potentially completely
new), we should not hesitate to kiss it good bye---the cost of
migration to the new architecture follows the size of the Internet,
so I'm afraid we can't settle for a tmp patch...
As for the discussion of whether changes to the forwarding
model will get in the way of practical deployment... First, I think
it is obvious that the new architecture will need to support the
current one as a special case, so islands of the current Net
will [have to] continue working as they do now. Second, I thought
I saw an explicit statement of "clean slate" in the doc.
Third, try to imagine what our telephone system would be now if
new developments were restricted to protocols understood by
rotary mechanical switches... how about human-based ones? ;)
The above is not to say that code change minimization should
not be an optimization criterion, though.
-- Alex ZininMonday, January 14, 2002, 12:11:57 PM, Olivier Bonaventure wrote:
> Dear All,
>> I have to take the opposite view. >> Without saying that MPLS is "the answer", requiring that we restrict our >> work to only the current hop-by-hop view restricts what is possible >> significantly. It is reasonable to say taht we have to allow the current >> behaviors. But it is not reasonable to say taht we should ONLY allow >> current behaviors. If we allow "path setups" or "flow setups" or ... there >> are things that become possible with IP that are extremely difficult >> otherwise (I hesitate to say impossible only because folks find ways to >> twist the tools to get what they want even if we could not see a way to do >> so. But the cost is often quite high.)
> I agree with Yakov, Radia, Joel and others' position that, at least within this > working group, we should not restrict ourselves to the traditionnal IP > routing paradigms. We should at least allow, and perhaps encourage, researchers > to explore other routing paradigms, be they based on *MPLS or anything else.
> Since this is a research working group, we are not restricted to develop > solutions that are deployable within O(six month) as in traditional > IETF working groups. Clearly, the timeframe for a possible deployment > of the solutions discussed within this group is O(few years)
> I hope that this working group can remain a research working group...
> Olivier
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT