> the _intent_ of the requirements as i wrote them (and as i
> think i've explained to the requirements-development-subgroup
> and having heard no dissent, make the great presumption that
> they agree :-) is that an architecture developed to meet the
> requirements
> - allow for topological "elements" (TE's)
> - allow a network owner to divide their network into TEs
> more or less however they please
> - allow TEs to be hierarchically arranged (though not necessarily
> in a strict tree, a TE can be a child of two different 'parents'
> - allow one TE to hide its rules/topology/policy/...
> from a containing-TE (and from a contained-TE)
> - if a TE has multiple parents, it can export 'stuff' about itself
i think i undersatand what you were saying. and i have no firm arguments
against.
it's just that i am not completely ready to jell to as descrete boundaries
as this implies. i am wandering around a pretty richly inter-connected
mesh, and i am not sure i see other than _administrative control_ boundaries
at more aggregation than vertices. and my view/abstraction of your mush
gets less intimate as i move further away, in terms of edge count and
richness of 'good' ways to reach you.
so it's not disagreement so much as not having made the leap to chunkier
aggregation. when i understand that policy fiefdoms simplify the design, i
will give up my vertex-granularity model without too much sighing. but, of
course, i find the internal/external stuff as historically amusing at best.
randy
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT