Re: [GSMP] ReturnReceipt and events

Georg Kullgren <geku@nortelnetworks.com> Mon, 22 September 2003 11:42 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10859 for <gsmp-archive@odin.ietf.org>; Mon, 22 Sep 2003 07:42:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1P5M-0006ht-Rs for gsmp-archive@odin.ietf.org; Mon, 22 Sep 2003 07:42:33 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MBgWrk025782 for gsmp-archive@odin.ietf.org; Mon, 22 Sep 2003 07:42:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1P5M-0006hl-MW for gsmp-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 07:42:32 -0400
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10839 for <gsmp-web-archive@ietf.org>; Mon, 22 Sep 2003 07:42:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1P4q-0006gC-Jz; Mon, 22 Sep 2003 07:42:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1P4H-0006et-44 for gsmp@optimus.ietf.org; Mon, 22 Sep 2003 07:41:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10777 for <gsmp@ietf.org>; Mon, 22 Sep 2003 07:41:15 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1P4E-0005wU-00 for gsmp@ietf.org; Mon, 22 Sep 2003 07:41:22 -0400
Received: from h1s128a211n47.user.nortelnetworks.com ([47.211.128.1] helo=znsgs01r.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1A1P43-0005vJ-00 for gsmp@ietf.org; Mon, 22 Sep 2003 07:41:11 -0400
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8MBdGq19091; Mon, 22 Sep 2003 12:39:17 +0100 (BST)
Received: from nortelnetworks.com (47.163.50.99 [47.163.50.99]) by zwcwc012.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1P33WTA; Mon, 22 Sep 2003 12:39:17 +0100
Message-ID: <3F6EDF5E.1030000@nortelnetworks.com>
Date: Mon, 22 Sep 2003 13:39:10 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Georg Kullgren <geku@nortelnetworks.com>
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 <avri@acm.org>
CC: gsmp@ietf.org
Subject: Re: [GSMP] ReturnReceipt and events
References: <60171E20-ECE5-11D7-903D-000393CC2112@acm.org>
In-Reply-To: <60171E20-ECE5-11D7-903D-000393CC2112@acm.org>
X-Enigmail-Version: 0.74.3.0
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 znsgs01r.nortelnetworks.com id h8MBdGq19091
Content-Transfer-Encoding: quoted-printable
Sender: gsmp-admin@ietf.org
Errors-To: gsmp-admin@ietf.org
X-BeenThere: gsmp@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gsmp>, <mailto:gsmp-request@ietf.org?subject=unsubscribe>
List-Id: General Switch Management Protocol WG <gsmp.ietf.org>
List-Post: <mailto:gsmp@ietf.org>
List-Help: <mailto:gsmp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gsmp>, <mailto:gsmp-request@ietf.org?subject=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
transmitted.

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.

Ok.

> 
>> 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.

Ok.


>> 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.


Regards
/Georg
-- 
------------------------------------------------------------------------
Georg Kullgren            Nortel Networks AB    geku@nortelnetworks.com
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
GSMP@ietf.org
https://www1.ietf.org/mailman/listinfo/gsmp