Subject: Re: GSMP Questions

From: Peter Newman <[email-masked]>
Date: Tue, 05 Jun 2001 10:05:02 -0700

I have copied this message to the list in case anyone wishes to comment:

The timer was introduced into GSMP version 2 because in version 1.1 there 
was no definition of loss of adjacency. It was felt necessary to define 
loss of adjacency and also to define a procedure to apply in that case.

I assumed that the value of the timer is a constant. My assumption is that 
the value is latched when synchronization is achieved and that this value 
is used for the duration of the session. You are correct that this should 
be stated explicitly in the protocol. I can think of no reason to make this 
value a variable. I would suggest its value be ignored by the receiver 
after being latched at synchronization.

On the matter of original SYN, okay -- initial SYN, I can only comment on 
versions 1.1 and 2.0. The spec (v1.1 and 2.0) is not explicit but it seems 
to assume that both master and slave have been configured to know over 
which interface to expect GSMP messages. This was certainly the case for 
our implementation. There was no suggestion that either master or slave 
would discover it's peer via the adjacency protocol, merely achieve 
synchronization.

Your suggestion makes sense -- for dynamic discovery of slave devices it 
does not make sense for the master to send SYN messages on all possible 
interfaces. It would make sense for the slave to be configured to know over 
which interfaces to expect GSMP and to send SYNs. As you say the master 
could wait until it notices the arrival of a SYN on one of its interfaces. 
I do not think the protocol covers dynamic discovery. Perhaps this should 
be made explicit. I do not know if this was discussed for version 3.

Regards

--Peter

At Wednesday 5/16/2001, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi, Peter-
>
>I'm working with Glenford Mapp on a research switch. I saw an
>exchange of e-mails between you and Glenford in March, where
>you expressed a willingness to answer questions about GSMP.
>
>I'm wondering if I could take you up on your offer.
>
>I'm doing a cleanroom GSMP implementation, and am currently
>working on the adjacency protocol. The immediate confusion
>I'm having is with the role of the timer. Am I correct in
>thinking that each side maintains its own timer, in contrast
>to (for example) the version number?
>
>If that's the case, when should the receiver latch the sender's
>timer? Should it be latched as part of the Update Peer Verifier
>operation? (Unless I am missing a point, it seems to me that
>this is a question which should be addressed by the RFC.)
>
>(A minor issue: the draft is silent about what the receiver
>should do if the timer value in a received message is different
>from the value in an earlier message. Perhaps the same might
>be said about the version number, especially since the draft
>says "all other messages will use the agreed version.." but
>at least it's clear that the version number is negotiated and
>when it's to be latched.)
>
>A second question: it's unclear to me whether it's valid for
>either the master or slave to avoid sending out an initial SYN.
>In our application, where switches can be added to or removed
>from the system at any time, I'm not sure that it makes any
>sense for the master to send out an initial SYN.
>
>Can you clarify the intent of the draft here? I infer that the
>draft expects each side to be sending out timer SYNs continuously
>to every conceivable counterpart as soon as it comes out of reset,
>but the draft leaves this unsaid. Again, for our purposes, I
>believe it makes more sense if the master waits until it's been
>contacted by the slave when the slave comes out of reset, and
>similarly that the master stop sending timer SYNs once the slave
>has been unresponsive for some significant time.
>
>Thanks for your time.
>
>                                         Jim Snyder
>                                         [email-masked]
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 6.5.8
>
>iQA/AwUBOwKdq8d4VGAH324LEQI3CACcCI2E5CRs8+l0lGaq0Al1eZ7eoWsAn3FC
>cvxn3GKIqvSOqsXyiX2vRtzK
>=PWh0
>-----END PGP SIGNATURE-----

---

From: Hans Sjostrand <[email-masked]>
Date: Wed, 6 Jun 2001 09:24:16 +0200

Some comments on what we have considered as configuration. One of
the differencies from v1.1/v2 and v3 is that v3 is specified also by its
mib.
The gsmp mib defines the behaviour of both timer and discovery.

> after being latched at synchronization.

The timer is configured when configuring the GSMP entities and
is constant for the duration of a GSMP session. The default value of
1 second is clarified in the new revision of the mib.

> be made explicit. I do not know if this was discussed for version 3.

I has been discussed briefly and we decided to not allow for dynamic
discovery.
The configuration is statically-specified in the mib on both master and
slave side,
specifying explicitly where to send/expect SYNS.

Regards
/// Hasse

---

From: Peter Newman <[email-masked]>
Date: Wed, 06 Jun 2001 10:08:58 -0700

Thanks very much. Sorry I couldn't have been with you for version 3. 
Questions on GSMP still come my way. I try to do what I can and generally 
also copy the list.

--Peter