[GSMP] proposed solution for recovery

Avri Doria <avri@acm.org> Thu, 18 September 2003 03:12 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 XAA11436 for <gsmp-archive@odin.ietf.org>; Wed, 17 Sep 2003 23:12:23 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zpD7-0000kE-Uo for gsmp-archive@odin.ietf.org; Wed, 17 Sep 2003 23:12:02 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I3C1U5002858 for gsmp-archive@odin.ietf.org; Wed, 17 Sep 2003 23:12:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zpD7-0000k1-Qw for gsmp-web-archive@optimus.ietf.org; Wed, 17 Sep 2003 23:12:01 -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 XAA11430 for <gsmp-web-archive@ietf.org>; Wed, 17 Sep 2003 23:11:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zpD5-0007TY-00 for gsmp-web-archive@ietf.org; Wed, 17 Sep 2003 23:11:59 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zpD5-0007TU-00 for gsmp-web-archive@ietf.org; Wed, 17 Sep 2003 23:11:59 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zpD6-0000jX-Eh; Wed, 17 Sep 2003 23:12:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zpCV-0000j3-Rm for gsmp@optimus.ietf.org; Wed, 17 Sep 2003 23:11:23 -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 XAA11425 for <gsmp@ietf.org>; Wed, 17 Sep 2003 23:11:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zpCS-0007TQ-00 for gsmp@ietf.org; Wed, 17 Sep 2003 23:11:20 -0400
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19zpCR-0007TN-00 for gsmp@ietf.org; Wed, 17 Sep 2003 23:11:19 -0400
Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 19zpCQ-000GsT-Vi for gsmp@ietf.org; Thu, 18 Sep 2003 03:11:19 +0000
Date: Thu, 18 Sep 2003 12:10:16 +0900
Mime-Version: 1.0 (Apple Message framework v552)
Content-Type: multipart/alternative; boundary="Apple-Mail-12--351929748"
From: Avri Doria <avri@acm.org>
To: gsmp@ietf.org
Message-Id: <A060059E-E985-11D7-A1FA-000393CC2112@acm.org>
X-Mailer: Apple Mail (2.552)
Subject: [GSMP] proposed solution for recovery
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>

>>
>> In order to support the function, we need to modify connection 
>> management, port configuration message, event message, failure 
>> response message, and so on.
>
> Yes, indeed, we need some change, but we as a group have not arrived 
> at an agreement of what level of support we need.

While not a complete solution yet, i am currently working on doing the 
following.

1. Add the capability to include protection information in add, move 
and delete messages. This is as opposed to the previous solution i 
proposed that only allowed protection by doing a second add.  I do not, 
however, plan to remove the ability to add a 1+1 protection link by 
doing a second add - unless of course there is consensus that i should 
do

2. Continue using reservations to  establish recovery channels.  This 
still means that, except in the case of the second add method, 
reservation channels would need to be reserved before being assigned.  
Each reservation would still require its own message.

3. Add a msg for grouping several reservation ids into a reservation 
set with an reservation set id.  I plan to use a flag in the 
reservation field to differentiate between a reservation set id and a 
single reservation id.

4. Add a bulk transaction msg for grouping regular messages (all 
messages except adjacency, switch configuration and bulk) including 
reservations into a single transaction.  The bulk message would be 
designated for either sequential process or non-ordered process.  In 
the sequential process, if one message failed, the others would not be 
processed.  In the non-ordered bulk each message would succeed or fail 
without affecting other messages in the bulk bundle. (any preferences 
for which should be the default type?  and are there any other 
processing modes I should include?) The bulk message would include a 
count of included messages and the bulk response would include failure 
and success count info.

(I have not thought much about the event messages for reservations yet 
and of course plan to include bunches of failure responses, though i am 
sure i will originally miss some failure possibilities)

Part of the reason I am taking this approach is that I still would like 
the protocol to have a relatively simple commands and though that using 
this approach might contribute to that.  And I would like to change 
existing messages ass little as possible.

I am still working out the message details and will float a new copy of 
the draft for review as soon as I do - hopefully before next week.    
There are also still open dealing with how restoration is dealt with 
between the controller and the switch, but I think these messages will 
provide the basis for resolving those issues.

As always, I would be interested in comments on the list.  No need to 
wait for the draft.

a.