The Routing Over Large Clouds Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1996-Feb> msg00030



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Server synchronization draft

  • From: James Luciani <luciani@nexen.com>
  • Date: Mon, 26 Feb 1996 11:09:42 -0500

Curtis,
> This seems like a clone of the OSPF support for broadcast or NBMA.
> The problem with this as size of the LIS grows is that traffic and
> server performance hot spot created by having everything redistributed
> by the DR.  (In other words, I agree with what Joel said).

You did NOT read the spec.  SCSP does NOT depend on the DS to redistribute 
anything.  Read it again.  SCSP works with an arbitrary topology.
The DS is a nicety for some things.  As I said in my note to Joel,
I have no problems making the use of the DS a MAY rather than a MUST
because it is NOT integral to the working of the protocol.

> The rumblings at Dallas were toward go with something like OSPF
> flooding, as a special case of the distributed database algorithms in
> the RFC1577++ draft where the number of adjacencies to inform was
> equal to the number of adjacencies (rather than allowing them to be
> less than the number of actual adjacencies and creating the potential
> for incomplete flooding).  This would involve modeling the mesh of
> servers very much like a mesh of OSPF ptp virtual links.  There would
> be no advertisement of adjacencies and SPF calculation.  The
SCSP has NO SPF calculation at all and the Hello is a way to know if your
neighbor is alive and that's it.  Again, read the spec.

> information being flooded would be analogous to OSPF AS external (ASE)

This is very close to exactly what SCSP does.

> routing information and simply collected rather than used in
> conjunction with the results of an SPF.

There is NO SPF calculation.