Re: [GSMP] ReturnReceipt and events

Georg Kullgren <> Mon, 22 September 2003 11:42 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id HAA10859 for <>; Mon, 22 Sep 2003 07:42:56 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1A1P5M-0006ht-Rs for; Mon, 22 Sep 2003 07:42:33 -0400
Received: (from exim@localhost) by (8.12.8/8.12.8/Submit) id h8MBgWrk025782 for; Mon, 22 Sep 2003 07:42:32 -0400
Received: from ([] by with esmtp (Exim 4.20) id 1A1P5M-0006hl-MW for; Mon, 22 Sep 2003 07:42:32 -0400
Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id HAA10839 for <>; Mon, 22 Sep 2003 07:42:25 -0400 (EDT)
Received: from localhost.localdomain ([] by with esmtp (Exim 4.20) id 1A1P4q-0006gC-Jz; Mon, 22 Sep 2003 07:42:00 -0400
Received: from ([] by with esmtp (Exim 4.20) id 1A1P4H-0006et-44 for; Mon, 22 Sep 2003 07:41:25 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id HAA10777 for <>; Mon, 22 Sep 2003 07:41:15 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 1A1P4E-0005wU-00 for; Mon, 22 Sep 2003 07:41:22 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 1A1P43-0005vJ-00 for; Mon, 22 Sep 2003 07:41:11 -0400
Received: from ( []) by (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8MBdGq19091; Mon, 22 Sep 2003 12:39:17 +0100 (BST)
Received: from ( []) by with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1P33WTA; Mon, 22 Sep 2003 12:39:17 +0100
Message-ID: <>
Date: Mon, 22 Sep 2003 13:39:10 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Georg Kullgren <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Avri Doria <>
Subject: Re: [GSMP] ReturnReceipt and events
References: <>
In-Reply-To: <>
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by id h8MBdGq19091
Content-Transfer-Encoding: quoted-printable
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: General Switch Management Protocol WG <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable

Avri Doria wrote:
> Hi Georg,
> On måndag, sep 22, 2003, at 18:07 Asia/Seoul, Georg Kullgren wrote:
>> Avri Doria wrote:

>> I can't see why Return Receipt is needed, but if there is a requirement
>> for it...
> Well if there is an event that the switch must make sure is reliably
> conveyed (because the Controller has configured it to do so), there is
> no way to do that, that i can see, without requiring an ack, i,.e. a
> return receipt.

Yes, I agree that this is the way to do it if the event has to be
reliably transmitted. What I don't get is why it has to be reliably

On the other hand, if we allow it we at least won't end up with a
crippled protocol if when we discover there is a need for reliable events...

>> This is where I got confused concerning Return Receipts.
>> If the switch should be satisfied after receiving the first receipt,
>> this should be clearly stated in the draft.
> Well that is the indeed the question i am trying to clear up.  The
> current spec is ambiguous on this.  And I agree with you that the spec
> should not be ambiguous on this.


>> And, if we require this amount of communication between multiple
>> controllers then I don't see the reason for the Adjacency Update Event.
> The adjacency is just to let the controllers know that there are
> others.  While it is isn't for the switch to coordinate their
> activities, it seems to make sense that there should at least be an
> indication that one has either come or gone.  This can be especially
> important when one of the adjacencies is lost as there may be no other
> way for the controllers to discover that otherwise.


>> One transaction should be handled by one controller. When the
>> transaction is complete the other controllers will be updated with the
>> new information (don't know how. Not in our scope.).
>> Events are a different but I would prefer to require each controller to
>> respond to a ReturnReceipt.
> I am fine with this option, though it does require a more complicated
> arrangement, e.g timers and retransmission, keeping track of who has
> responded, etc..

Yes, but I don't think this will have a big impact on the
implementation. The timers and retransmission part is already there in
case no controller returns a receipt. Keeping track of who has responded
is added though, but that should be easy to add.

> Also with the flow control mechanisms it is possible that one or more of
> the controls might indicate they don't want to receive the events.  This
> is allowed and could be due to controller specialization.  So making
> sure that all except those who don't care about the event is more
> complicated.  And I don't know if and why it would be necessary.

Still, I don't think it is much different from checking that the receipt
is for the right event. Only difference is that we now also have to
check the transaction id.

Georg Kullgren            Nortel Networks AB
Systems Architect         S:t Eriksgatan 115 A  Tel:   +46-8-50 88 36 18
Routing Architecture Lab  SE-113 85 Stockholm   Mobile: +46-703-14 36 18
ATI Strategic Protocols   Sweden                Fax:   +46-8-50 88 35 01

GSMP mailing list