The Routing Over Large Clouds Mailing List Archive by date

[James Luciani <luciani@nexen.com>]

Joel,

> While much of this draft is a good translation of the OSPF mechanisms 
> over to the server synchronization problem, I have one serious concern
> with this document.
> 
> The draft includes a "Designated Server".
> "The DS is the contact point within the SC for off-SG stations wishing to
>  query the state of the SG."
> 

> Since the only kind of query is an NHRP query, 
What does this mean?  SCSP was intended for multiple protocols and that
was stressed throughout the draft.  I used NHRP packets in the Appendix
because that was the protocol to which I was closest.  You'll note that 
I also left Appendices for packet formats for MARS, ATMARP, and LECS
synchronization.

They were not filled out because I thought it better to get consensus
on the approach rather than write a bunch of things that would only need
to be altered later.  I did think that one example would be desirable so,
like I said, I chose NHRP because I was closest to it.

>                                                this appears to say that
> the DS is the only station that is supposed to receive NHRP queries from 
> outside the SG.  This is clearly not true, as a router (supporting NHRP)
No.  This was not the intent at all.  The DS was intended to be an entity
that could be used for the querying of caches of non-cut-through 
technologies such as ATMARP.  But I see why that was not clear now.  
It would be highly desirable to be able to query a cache in such a case.
This could aid in the cases where an entire LIS is ATMARP only since several
protocols use the existence of a cache entry in an address resolution server 
as reachability information.

> Also, this "designated Server" mechanism is completely unnecessary and
> introduces undesirable complexities into the mechanism.
Complexity is a relative term.  This is about 100 lines of code and the 
functionality is very well specified.  I agree that the DS concept is 
not necessary to the functioning of SCSP and would be quite happy to make this
a MAY vs. MUST.  Other folks have brought this point up too.

> It is possible that the draft intends the server group to be a subset of
> the LIS/LAG, and that somehow this is intended to automatically create
> the "mesh-tree" of connected subgroups. 
I don't understand this.  Mesh-tree?  SCSP can be used on an arbitrary
topology as long as it spans the server set in the SG.  I did recommend
that one limit the diameter of the SG to 3 by making each non ES
connect to atleast one ES and each ES connect to all other ESs in a full mesh
but that was my preference (not a MUST) to keep latency of updates low.
One can, of course, go with a full mesh if you want though.

> Now, for some minor comments:
> 1) I am not sure it is worthwhile to have "Cache Alignment Summary" records.
>     There is only one piece of information omitted from said "summary".
>     It seems to me we might be better off paying the small price in bytes 
>     for reducing the number of mechanisms.
Well... I disagree on this since the stated objectives (like the WG chairs)
were to be able to have N x 10,000 clients supported for ATMARP alone 
(see Mark L. note of Sun 21 Jan 1996).

> 2) The hello mechanism uses a hello/hello reply to confirm communication
>     between two servers.  I certainly understand why such confirmation is
>     sought.  In other recent protocol work, we observed that if the hello
>     has both the local and remote identities (with zero for the remote
>     identity if none has been received), it is easy to maintain up-state
>     with only one message instead of two.  You do not even need a sequence
>     number.  Again, this is a matter of simplification.
Both PNNI and OSPF do as you say.  I will make this change in the next revision.

Regards,
-- Jim Luciani
__________________________________________________________________________
James V. Luciani    Ascom Nexion                    voice: +1 508 266-3450
luciani@nexen.com   289 Great Rd., Acton MA 01720   FAX: +1 508 266-2300