At 2:20 PM -0500 11/17/00, Alex Conta wrote:
>You missed a component my argument. We are in fact talking about apples
>and oranges.
I wasn't responding to your argument. (Debating the the pros and cons
of MPLS, though one of my favorite topics, is out-of-scope for this
mailing list). I was responding to your statement:
>If flow IDs are used for fast forwarding, without the ability to rewrite
>them, it seems to me that a router will not be able to aggregate flows.
and pointing out that you were mistaken.
>Tunneling flows means creating COMPLETELY NEW flows, with completely
>different characteristics than the original flows: source, destination,
>etc..., with an important impact on the classification criteria that can
>be applied.
Of course. An aggregate of flows usually has different properties
than its component flows (like bandwidth, for one), so it makes sense
to think of them as separate flows (big pipes with little pipes running
through them, like the classic diagrams of ATM virtual circuits inside
of virtual paths). It's a feature to be able to classify them separately.
>"More powerful" is relative: for routers that implement both, and for
>forwarding within the routing domains were both are supported, one could
>argue that it does not apply.
I was using "more powerful" in the sense of being a more general mechanism
than can accomplish more than just what MPLS does. Sure, if all you
care about is what you can do with MPLS, that extra "power" will not
interest you, but it might be of interest to others.
>Tunneling is more expensive and less efficient -- packet size issues,
>and encapsulation effort in
>terms of header pre pending. Furthermore, tunneling adds cost in terms
>of header processing, that is, forwarding is performed twice, once on
>the original packet, and second on the tunnel packet.
Yes there are lots of little performance trade-offs and different people
weigh their importance differently, and there are more efficient ways of
implementing tunnel entry/exit than you imply. None of that has
anything to do with your speculation that routers simply won't be able
aggregate flows if they can't rewrite the flow ID.
>Additionally, the costs of building such functions add to the costs of a
>fast forwarding engine.
I believe IP-in-IP tunneling has become a basic tool that routers need to
support efficiently anyway, so I'd turn it around and ask if it's worth
the additional (and nontrivial) costs of including all the MPLS machinery
as well. But I won't, because as I said, it's out-of-scope for this list.
Steve
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
