Steve,
> Steve Deering wrote:
>
> Alex,
>
> That is incorrect.
You missed a component my argument. We are in fact talking about apples
and oranges.
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.
> A router can aggregate flows by encapsulation
> (similar to, but more powerful than, label stacks), and therefore
> not need to rewrite flow IDs.
>
"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.
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.
Additionally, the costs of building such functions add to the costs of a
fast forwarding engine.
> A system that rewrites flow IDs to do aggregation is unable to
> efficiently *de*aggregate at the other end of the aggregating path.
>
> Steve
I disagree. De-aggregation of forwarded traffic based on the 'flow-id'
of tunnel packets is not necessarily more efficient than de-aggregation
of forwarded traffic based on "destination address" of original
(non-tunnel) packets. Here is why:
1. - A tunnel packet "flow-id" based de-aggregation, requires
- a forwarding of the tunnel packet,
- decapsulation, and
- a forwarding of the original packet.
2. - An original packet "destination address" based de-aggregation
requires
- a forwarding of the original packet
This has implications on the costs of building a fast engine.
Alex
S/MIME Cryptographic Signature
