I've been reading this thread with some interest.
Some observations
The goal of the group's effort is a new routing/addressing model.
This means that it is not just for high-speed-deep-core environments.
There are places in the net that go substantially slower than 2.5gbit,
there are even places in the net that go substantially slower than
2.5mbit... So to say that something is/is-not required for 2.5gb
nets (or faster) is interesting, probably true, but simply not
relevant.
As to the specific requirement that Ran alluded to (use the 'tos'
byte as a part of path/next-hop-selection, basically)... There
are two cases here. In the first case, there are multiple paths
from A to B. Attributes could be assigned to links/topological-
entities/paths/etc and the algorithms that determine the paths
(and the resulting next-hops in the forwarding tables in the
routers) could build multiple paths with the different paths
supporting different attributes. The "tos" (aka diffserv/...) byte
_could_ be used to select the desired path.
A fair argument can be made that this work is within the realm of
"routing" and therefore is something relevant to our work. That said,
section 4.4(?) says that QOS is a non-requirement (non-requirement
can be taken to mean "MAY", it is most emphatically != "MUST-NOT").
But we do not define exactly what is meant by QOS... Anyway, I have
always felt (and I think it's in the document someplace) that the
architecture
- MUST have the ability to assign 'attributes' to the 'things'
that make up the net (links, topological-entities, paths, whatever)
- MUST support multiple paths from A to B,
- MUST be able to build paths that have different attributes, and
- therefore the forwarders could select paths based on some "stuff"
in the packets.
So it seems to me that this would satisfy Ran's requirement. Yes?
The other case is when there is only one path (such as an ISP-to-
single-homed-customer link). In this case, the only thing that can
be done is to select behavior _internal_ to a router (such as
which queue to place a packet on).
I claim that this, second, case is not a part of "routing" and is
therefore not within the scope of the work we're trying to do.
Frank Kastenholz
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT