Subject: [GSMP] upcoming changes to specs

From: avri <[email-masked]>
Date: Mon, 16 Jun 2003 12:15:59 +0900

I recommend that anyone who is planning to submit a draft by the
deadline, submit a note discussing the changes they are making
in the document this week.  Of course if it is a new document (e.g.
a mib or pib on partitioning - anyone?  or maybe the tdm spec?)
then an abstract would help.  We are scheduling for an hour so we
want to plan.

And as an author who is planing to submit an update before the
deadline (barely) i will go first.

---- changes to draft-ietf-gsmp-v3-base-spec

After some discussions withe the team working on the Optical
draft, it was determined that I had not yet generalized enough
of the messages; i.e. that a lot of message content was still
very packet switch oriented.  I am therefore in the process of
doing more generalization.  Specifically:

- event flags - a notation that 8 event flags (8-15)
are reserved for technology specific definition

- addition of a technology specific block to msg 64
(switch configuration message)

-msg 65 - the porttype specific data needs generalization.

-msf 67  capability set definition needs generalization

- i am not sure if i will have a chance to do some of the
required changes in the optical reqs spec which has just
been submitted to the iesg.

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

-I have had some discussions with Jonathan Sadler on the best
way to designate  the port specific adaptations.
We have tentatively decided to add a block to the port configuration
message.  Jonathan is, hopefully, going to be putting out a
doc on this issue.  I don't know if I will get this in on this pass.

So, for all the folks who spoken to me in the privately, I have two
requests;

- correct me if i left out one of the changes i agreed to make
- please discuss issues on the list so more people can voice
their opinions.

thanks
a.

_______________________________________________
GSMP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gsmp

---

From: avri <[email-masked]>
Date: Fri, 20 Jun 2003 12:03:36 +0900

As promised a specific message on header compression.

> optical burst switching - i will send a specific message to the

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

anything else?   and is this still too big?

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?

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.

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

---

From: Kenneth Sundell <[email-masked]>
Date: Mon, 23 Jun 2003 14:06:34 +0200

hi avri,
comments are inline.

>                                use a bulk mechanism for other add-resv 

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.

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

> 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

---

From: avri <[email-masked]>
Date: Mon, 23 Jun 2003 21:38:21 +0900

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

[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:

>>                                use a bulk mechanism for other 
>> add-resv uses
>
> 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.
>
>>
> 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?
>>

---

From: tom worster <[email-masked]>
Date: Wed, 25 Jun 2003 12:03:58 -0400

> So, what do people think?

can someone perhaps explain the problem as the optical burst switching
people see it? i'm not sure that i understand why gsmp packets in
particular, as opposed to all the other long packets in the world, need to
be made shorter.