Re: [GSMP] Shorter msg for add reservations

avri <avri@apocalypse.org> Mon, 23 June 2003 12:40 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18281 for <gsmp-archive@odin.ietf.org>; Mon, 23 Jun 2003 08:40:36 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NCe8C28002 for gsmp-archive@odin.ietf.org; Mon, 23 Jun 2003 08:40:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQcC-0007HZ-0C for gsmp-web-archive@optimus.ietf.org; Mon, 23 Jun 2003 08:40: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 IAA18275 for <gsmp-web-archive@ietf.org>; Mon, 23 Jun 2003 08:40:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UQcA-0001qE-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 08:40:06 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19UQc5-0001qB-00 for gsmp-web-archive@ietf.org; Mon, 23 Jun 2003 08:40:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQc5-0007F8-NX; Mon, 23 Jun 2003 08:40:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UQbr-0007Eb-1r for gsmp@optimus.ietf.org; Mon, 23 Jun 2003 08:39:47 -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 IAA18262 for <gsmp@ietf.org>; Mon, 23 Jun 2003 08:39:44 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UQbp-0001pz-00 for gsmp@ietf.org; Mon, 23 Jun 2003 08:39:45 -0400
Received: from relay5.kornet.net ([211.48.62.165]) by ietf-mx with esmtp (Exim 4.12) id 19UQbf-0001pK-00 for gsmp@ietf.org; Mon, 23 Jun 2003 08:39:35 -0400
Received: from [220.89.170.14] (avri@apocalypse.org) by relay5.kornet.net (Terrace Internet Messaging Server) with ESMTP id 2003062321:38:20:071118.11462.21 for <gsmp@ietf.org>; Mon, 23 Jun 2003 21:38:19 +0900 (KST)
Date: Mon, 23 Jun 2003 21:38:21 +0900
Subject: Re: [GSMP] Shorter msg for add reservations
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v552)
From: avri <avri@apocalypse.org>
To: gsmp@ietf.org
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <3EF6ED4A.1080308@nortelnetworks.com>
Message-Id: <92A35AA1-A577-11D7-9101-000393CC2112@apocalypse.org>
X-Mailer: Apple Mail (2.552)
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 <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

i definitely think any new msg. should be in
the base spec.

so this could be a trigger reservations msg.
it would only work for triggering reservations
that had been made with full label info etc..
(i.e. non 0 value for label)

btw, i go the msg wrong in my previous msg.,
i left out the port session id.

msg: triggered add

[vers, sub, msg type, result, code]
[partition id, transaction id]
[I, submsg, length]
[port session id]
[reservation id]

codes would include one for rejecting the trigger
if the reservation was not complete.

opinions?
is it useful in general?
does it satisfy the burst switch requirements?


btw, on the subject of changing messages.
there will be several changes, perhaps not for
this problem, but with adding support for
protection.  i am still trying to figure out the
minimum possible change that will support
the variety of possibilities.  email on this
tomorrow - i hope.

.



On måndag, jun 23, 2003, at 21:06 Asia/Seoul, Kenneth Sundell wrote:

>
> hi avri,
> comments are inline.
>
> avri wrote:
>
>> As promised a specific message on header compression.
>>
>> On Monday, Jun 16, 2003, at 12:15 Asia/Seoul, avri wrote:
>>
>>>
>>>
>>> - there has been an issue concerning the size of the gsmp
>>> message header brought up by the folks working on
>>> optical burst switching - i will send a specific message to the
>>> list on this issue.
>>>
>>
>> So, what do people think?
>>
>> Should there be a general mechanism inserted similar to the
>> short headers we removed over 2 years ago?  Some new sort
>> of header compression?
>>
>> Should there be a new mechanism related solely to reservations.
>> I.e. a new add-reservation message is created that includes only
>>
>> [vers, sub, msg type, result, code]
>> [partition id, transaction id]
>> [reservation id]
>> [I, submsg, length]  or is this needed - though we may be able to
>>                                use a bulk mechanism for other 
>> add-resv uses
>
> I think it makes sence. I would prefer not to change existing messages 
> for two reasons; existing implementations are using the messages and 
> secondly, there is no room for additional flags in the headers. I 
> would suggest to add a message type for the purpose. If the new 
> message type is believed to be usable for other switch types as well i 
> would propose putting it into the base spec.
>
>>
>> anything else?   and is this still too big?
>
> I can't see how to make it smaller if we should keep using the general 
> headers.
>
>>
>> And does the reservation message need to  changed
>> to allow for these complete reservations.  What, if anything needs
>> to be added to the reservation message?
>
> The reservation management message is specified to allow reservation 
> of resources before the labels (to be coupled to the resources) are 
> known, e.g. in the case of MPLS downstream on demand label 
> distribution. I think that message type serves its purpose already and 
> doesn't need to be modified. I think a new msg type should be added.
>
>>
>> Opinions?  suggestions?
>>
>> Please, speak up. As an editor, I am am working on the
>> update for the upcoming meeting at the moment, and need
>> guidance.
>>
>> As a co-chair, I would like to know if there is consensus on making
>> such a change.
>>
>> I encourage the Optical draft team to discuss their rationale and 
>> needs
>> on the list in response to this message.
>
> Will this change be helpful to the optical design team? I would be 
> interested in hearing their opinion.
>
> Cheers,
> Ken
>
>>
>>
>> a.
>>
>> note: since i am functioning as a co-chair and editor, any process
>> issues that may arise from this dual role will be handled by the other
>> co-chair
>>
>>
>>
>> _______________________________________________
>> GSMP mailing list
>> GSMP@ietf.org
>> https://www1.ietf.org/mailman/listinfo/gsmp
>>
>
>



_______________________________________________
GSMP mailing list
GSMP@ietf.org
https://www1.ietf.org/mailman/listinfo/gsmp