>
Some additional decomposition ideas, with additional comment at the end.
> > From: Curtis Villamizar <curtis@workhorse.fictitious.org>
>
> >> 1) Topology element naming.
> >> 2) Topology information distribution.
a. Topological element discovery (failure discovery
may or may not be part of the same process)
b. Topological information distribution
c. Policy constraints on distribution
d. Policy information distribution
e. Topological and policy authentication
> >> 3) Path computation.
> >> 4) Path setup.
a. IP
b. Sub-IP
> >> 5) User packet forwarding.
>
>[snip hopefully friendly setup]
> > Not all architectures use a path setup before path forwarding and
> > it is arguably a bad idea in many cases.
The flavor here is of setting up RIBs and FIBs. Resource reservation
at the IP and sub-IP levels have been afterthoughts to existing
routing.
>
>First, let me point out that path setup may not be triggered by "reception of
>user data packet"; some may happen at system startup, to provide "default"
>forwarding for all destinations, so that "best-effort" packets just use those
>pre-setup paths. In other words, "best-effort" packets can be handled by the
>system *without* any path setup.
>
>Second, all routing architectures do these steps - it's just that they may
>intermingle some of them. E.g. even our old pal BGP, there is a "setup" phase
>(in which routing table entries are created), it's just that it happens at the
>same time as 2 and 3 above (and in a distributed way). Those "classical"
>routing table entries form a (hopefully :-) tree-structured set of paths
>toward the destination. So the only question is not whether you will do path
>setup, but only whether it will be done as a separate, visible (and
>potentially user-accessible) step.
>
>
> > For example, path setup before a single DNS UDP packet to port 53
> > is not part of the current architecture and would be inefficient.
>
[snip]
>I think my "list of subsystems" is *the* fundamental model of how all
>routing systems more or less have to work. Of course, some designs have
>lumped more than one phase together in a single mechanism (all DV/PV
>systems mingle 2, 3 and to some degree 4) - but those elements are all
>still there.
>
>Perhaps I'm wrong, and one of the steps can be decomposed further. If so, I'd
>dearly love to hear about it (really).
>
>(I should point out that some of these "top-level" subsystems have some
>further internal divisions; e.g. the entire subject of topology information
>distribution is a world in and of itself. However, I don't consider those
>sub-divisions to be on the same level, in architectural terms, as the ones I
>listed.)
>
> Noel
I agree, Noel, that topology information distribution has subsystems,
and some of what I list above could be viewed as subsystems. Policy
information distribution for scoping topological information
distribution, whether it be "in-band" ala ORF or demand lookup in a
repository, have not been.
-- Howard C. Berkowitz hcb@gettcomm.com 703-998-5819 Chief Technology Officer, GettLab/Gett CommunicationsUsual disclaimers -- on odd days I can't set policy and on even days I can. Or is it the other way around?
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT