> > o Making topology and addressing separate subsystems. This
> > may allow highly optimized topology management and
> > discovery without constraining the addressing structure or
> > physical topology in unacceptable ways.
> >
> >Do you mean here to have one address which indicates the topology
> >point of attachment for a device, and another address which
> >identifies the device? How do you propogate topology information
> >without assigning some identifier to topology elemnts and
> >propogating those identifiers?
>
> This is simply an item to stir up the little gray cells.
Okay--but it seems reasonable to make this requirement explicit
in a requirements doc, I think. :-)
> Also, if you presuppose a certain type of topology then the
> problem gets easy. But that means that for an architecture to
> work, someone will have to tell _all_ the ISPs in the world
> to redesign their networks, connectivity, peering, and so on.
> I will _not_ be the one to do that :-)
Hmmm.... I can see where you are trying to assume that networks
will not be built out of small pieces which can be combined into
bigger pieces, but it seems to me that some assumptions, such as
this one, probably need to be made for the document to say
anything that a protocol designer could take to heart and make
use of. :-)
As long as the network can be built out of small pieces, if
addressing is done right, aggregation will be possible, and even
desirable. This is actually the way networks are built today,
kindof, so it wouldn't be a major change, nor something that
people would (probably) have a major problem with.
> > The Architecture MUST NOT prevent individual host-to-host
> > communications sessions from being secured (i.e. it cannot
> > interfere with things like IPSEC).
> >
> >The counter to this is that mechanisms which secure
> >communications between the attached hosts must not rely on
> >topology point of attachment information to provide security in
> >any way. This is a layering violation, and as such, is a bad
> >thing.
>
> Well, that's a part of it. I think that our wording is more
> what we want. Your text says that security can not rely on
> topology. But there are other possible interactions that
> would kill security. Suppose, for example, that one would
> propose an architecture that required looking at the payload
> of the packets (this is hypothetical - I have no idea what
> kind of architecture this is!). You could not encrypt your
> packets if this architecture is in place. Our text eliminates
> this type of solution, yours would not.
I think you've stated one half of the problem--that the
architecture can't prevent security--but not the other--that
security concerns should not ruin the architecture. It seems that
the second piece is what we are missing today, in some form or
another. I'm just waiting for the end-to-end principle to be
extended to the data link layer. It would solve all the problems
except that little pesky routing nonsense....
> > 4.5 IP Prefix Aggregation
> >
> >This section seems to contradict the earlier section which states
> >that the system must be scalable. :-)
>
> We're just saying that if you can come up with a way to scale
> without aggregating prefixes, that is just fine...
Ummm.... Yes, well, good luck. A distributed database that
handles billions of entries and converges in milliseconds to
support voice, and does not have a constrained interconnection
model.... Well, maybe with a four deminsional model, where we can
simply calculate the required routes and transport the results
back in time through the routing system....
Further, this contradticts with the requirement that routers not
be infinitely upgraded, in some way, I think.
:-)
Russ
__________________________________
riw@cisco.com CCIE <>< Grace Alone
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT