Senthil,
-> I am also sceptical of the following issues:
->
-> - scalability: Since you are maintaining multiple Routing
-> tables, doing at line rate is pretty difficult and hence
-> doesnt scale well.
I agree with you here. Yes! there are performance and
scalability problems if we go for DiffRouting in a
hop-by-hop fashion. Then you have to maintain
different route tables, line rate forwarding issues etc etc.
That is why we went for source routing (using MPLS-TE).
That effectively solved the problem of maintaining
multiple routing tables. Connection-less to connection-oriented
move (with small fixed length label lookup) solved the
problem of line rate forwarding (directly or indirectly).
Now we are moving towards MPLS-TE with DiffServ.
Source routing also has scalability issues. This is yet to
be solved!
-> - complexity: This work increases the complexity at per
-> router level. Some people complain of increase in complexity
-> for just adding three more lines in the original forwaring algo
-> (to include RED features.) I dont know how much complex
-> the router becomes because of diffrout.
Weight complexity with performance.
-> - end to end: Diffserv is defined only for edge to edge. How will
-> diffrout behave when considering end to end is still open.
Yes! This is what I am concerned about.
-- Venkata.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT