The Routing Over Large Clouds Mailing List Archive by date

[Jim Luciani <luciani@lobster.BayNetworks.com>]

Eric,

> 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).
Reasonable.  Same for SGID as well.  Also, some kind of dynamicity in SGID
allocation needs to exist for the LAG model anyway.

> -       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.
First, anytime anyone says the word "trivial", alarms, bells, and whistles go off
in my head so I shant be using that word ;-)  What might need saying is a re-definition
of what it means to be a DCS... e.g., active-DCS and passive-DCS, where active
DCS sends/receives updates and passive DCS only sends updates.

> ================================================================================
> 
> 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.
Clarification, where useful is always a good thing :-)


> ================================================================================
> 
> 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.
> --------------------------------------------------------------------------------
I will change the wording to reflect that a policy may be in place which
gives the LS discretionary behavior in this case.

> 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).
This is incorrect.  If you are on a LIS with multiple NHS/routers, you must
currently register with each NHS (or have a designated NHS to respond for the
entire LIS) so that when an NHRP Resolution request hits the edge of the LIS
(i.e., hits "one of the routers/NHSs" on the LIS), the NHS looks into its database
and sees that the client exists.  Rather than register with every NHS in the LIS
it is much much easier on the client to register with one NHS and have
that NHS synchronize will all other routers/NHSs on LIS.  Note that I used
the term router here a little loosely; it could in fact be that an NHS is 
colocated with a route server, etc...

> 
>     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.
When you purge an entry, you want that information to be synchronized with 
every NHS on the LIS.  The NHS does not go off and tell every synchronized NHS
on the LIS without SCSP.  The only pertinent information kept in the database
was about who requested a resolution for that client.

>     3) Timing out and refreshing of Internetworking address to NBMA address
>        bindings is defined using query/response mechanisms and purge.
Yes.  And you want to synchronize that information with the other NHSs on the LIS.
That is, if you upate a cache entry then you tell the other synchronized NHSs.

> 
> 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).
Sorry... Could not parse this.


> ================================================================================
> NITS -
> 
> First paragraph of setion one - third sentence - "undo" should be "undue".
Duene.

> In the first paragraph in section 2, you may want to delete "the" between "from"
> and "link" in the third sentence.
Done..  sorry IS-IS folks...

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

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

Regards,
--Jim Luciani
__________________________________________________________________________
James V. Luciani                                   luciani@baynetworks.com
Bay Networks, Inc.                                  voice: +1 508 439-4734
3 Federal St., BL3-04                               fax:   +1 508 670-8153
Billerica, MA 01821