Re: Shorter msg for add reservations

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
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/gsmp
>>
>
>