Re: [GSMP] proposed solution for recovery

Avri Doria <avri@acm.org> Thu, 18 September 2003 06:06 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 CAA22792 for <gsmp-archive@odin.ietf.org>; Thu, 18 Sep 2003 02:06:31 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zrvc-0004qb-Kp for gsmp-archive@odin.ietf.org; Thu, 18 Sep 2003 02:06:08 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I668p2018634 for gsmp-archive@odin.ietf.org; Thu, 18 Sep 2003 02:06:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zrvc-0004qT-3s for gsmp-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 02:06:08 -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 CAA22252 for <gsmp-web-archive@ietf.org>; Thu, 18 Sep 2003 02:06:00 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zrvY-0001Hb-00 for gsmp-web-archive@ietf.org; Thu, 18 Sep 2003 02:06:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zrvY-0001HY-00 for gsmp-web-archive@ietf.org; Thu, 18 Sep 2003 02:06:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zrvX-0004pu-UM; Thu, 18 Sep 2003 02:06:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zruw-0004o5-4m for gsmp@optimus.ietf.org; Thu, 18 Sep 2003 02:05:26 -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 CAA21616 for <gsmp@ietf.org>; Thu, 18 Sep 2003 02:05:18 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zrus-0001HB-00 for gsmp@ietf.org; Thu, 18 Sep 2003 02:05:22 -0400
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19zrus-0001H8-00 for gsmp@ietf.org; Thu, 18 Sep 2003 02:05:22 -0400
Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.22) id 19zrus-0004yo-Gy for gsmp@ietf.org; Thu, 18 Sep 2003 06:05:22 +0000
Date: Thu, 18 Sep 2003 15:04:19 +0900
Subject: Re: [GSMP] proposed solution for recovery
Content-Type: multipart/alternative; boundary="Apple-Mail-16--341486061"
Mime-Version: 1.0 (Apple Message framework v552)
From: Avri Doria <avri@acm.org>
To: gsmp@ietf.org
In-Reply-To: <4B8BDDF0-E993-11D7-A1FA-000393CC2112@acm.org>
Message-Id: <F14C95C8-E99D-11D7-A1FA-000393CC2112@acm.org>
X-Mailer: Apple Mail (2.552)
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>

On torsdag, sep 18, 2003, at 13:48 Asia/Seoul, Avri Doria wrote:

>
> On torsdag, sep 18, 2003, at 13:13 Asia/Seoul, passjay wrote:
>
>> We have already proposed one of recovery support solutions in optical 
>> spec.
>>
>> Would you like to examine section 4.1, 5.1 9.1, and 9.2 in optical 
>> spec.
>
>
>

I have a general question, not only for you as for the group.  One of 
the implication of your proposed changes to the reservation messages 
where you associate multiple (port,label) pairs with a connection 
reservation is that all recovery links will have the same (i assume) 
service attributes and traffic parameters.  one of the things that 
concerned me was the generality of the solution.  Is it the case that 
all recovery links for any technology would have the same service and 
traffic attributes.   While i have been  assuming they would have the 
same adaptations, i have been assuming that they would not necessarily 
have the same attributes in all cases.  This is one reason i have taken 
a different approach, i.e for greater flexibility.

Another question I have, and this applies to the proposal in the 
optical support draft as well as the one that will show up soon in the 
base draft.

Can one connection have connections (a,b,c) in its recovery set  while 
another has connections (b,c,d)?

a.