Re: A historical aside

From: RJ Atkinson (rja@inet.org)
Date: Tue Dec 18 2001 - 16:13:52 EST


        Frank's comments below seem entirely reasonable to me and
capture the essence of what I was trying to observe.

        And when fibre is available inexpensively in all places
on all continents (yes, including Antarctica, which does have
regular IPv4 service, thank you) than I'm happy to shut up and
go away about needing to select paths thoughtfully in some networks
-- hence the capability I outlined ought be considered in (and
ought not be prohibited by) any new routing architecture.

        (Backbone operators who are reading carefully will note that
none of the above, the below, or what I've said before implies that
they'd have to do anything special in their portion of the world --
if they don't care to do so.)

Cheers,

Ran

At 14:16 18/12/01, Kastenholz, Frank wrote:
>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