The Routing Over Large Clouds Mailing List Archive by date

["Eric W. Gray" <gray@ctron.com>]

Jim/Joel,

        Just on the first eleven pages (excluding appendices):

********************************************************************************
********************************************************************************

GENERAL COMMENTS

-       Should say that some mechanism for assigning unique LSIDs must exist
        but that this mechanism may vary from one SCSP usage to another, e.g.,
        the mechanism used by a MARS SCSP need not be the same as a mechanism
        used by NHRP SCSP (even though the mechansim must be consistent within
        either).

-       You might want to state that - for SCSP purposes - the topology of
        servers is trivialized to a local perspective and that this trivial
        topology is determined by (as described in the third sentence of 2.1)
        knowing the NBMA addresses of all DCS and otherwise being able to
        distinguish the LS from all DCS and RS components.  Essentially - me,
        my neighbors and everyone else.  Based on this simplistic model, the
        actual topology of server connections is irrelevant to SCSP.

================================================================================

COMMENTS RELATIVE TO MASTER-SLAVE NEGOTIATION

        While I recognize that it is crucial to separate topology issues from
synchronization (and you have done a good job at this) and the LS perspective
results in skewing any underlying topology in any case, I think it is important
to note that many reasonable schemes for assigning unique LSIDs will result in
lower LSIDs toward the topological center and higher LSIDs toward the edge.
The current description of master-slave negotiation assigns the role of master
to the server with the higher LSID.  This may cause difficulties in implement-
ation as it is counter-intuitive.

        Also, this approach seems to result in slave -> master updates before
master -> slave updates.  As noted above, this would result in "outward" CSA
and CSU messages before "inward" ones - specifically counter to intuitive use
in LNNI.

        You may want to reverse the sense of master-slave negotiation.  As an
alternative, you might simply clarify these issues in the ID.

================================================================================

SPECIFIC COMMENTS -

Second paragraph of section 2.3 presupposes that a configuration of coordinated
servers does not include intentional active redundancy - i.e. it does not allow
an LS any discretionary behavior relative to forwarding CSU messages based on
specific knowledge that over-delivery would occur.  While this does not result
in looping of CSU messages - because they are only forwarded if they result in
a LS detection of state-change - it does result in twice as many CSU messages
as may be required otherwise.  I recommend the following re-wording:

--------------------------------------------------------------------------------
In the absence of other mechanisms to ensure correct delivery of CSU messages,
a CSU message is sent from an LS to each of its DCSs when the LS observes a
change in the state of one or more clients in the SG. The change in state of
a particular client is noted in a CSU message via a "Client State Advertisement"
(CSA) record within the CSU.  In this way, state change information is propa-
gated as desired throughout the SG.
--------------------------------------------------------------------------------

Also in this section, the specific NHRP examples you give do not actually seem
to require a cache synchronization protocol.  Specifically,

    1) Assuming the fabric mode for NHRP (I believe this to be the only mode),
       redundancy of NHS/Router functionality may be provided through normal
       routing (this would not be the case if you assume - as in MPOA - that
       intra- and inter- IASG/LAG/subnet/network forwarding/NHS functionality
       is decomposed; however that is not, strictly speaking, NHRP).

    2) Purge protocol requires state maintenance of where NHRP replies have
       been sent - so that they may be purged; consequently, purge protocol
       itself provides a mechansim for ensuring state updates occur.

    3) Timing out and refreshing of Internetworking address to NBMA address
       bindings is defined using query/response mechanisms and purge.

The paragraph after these examples does make the distinction suggested above
with respect to SCSP in instances where delivery may be assumed to be complete
(consistent with suggested re-wording above).

================================================================================
NITS -

First paragraph of setion one - third sentence - "undo" should be "undue".

In the first paragraph in section 2, you may want to delete "the" between "from"
and "link" in the third sentence.

In the last sentence, the first paragraph, of section 2.1 - depluralize the
word "mechanisms" (6th from last word).

In the paragraph immediately above "Conclusions" - in the last sentence - the
word "respond" appears twice in a row.

*********************************************************************************
*********************************************************************************

--
Eric Gray