Subject: GSMPv3 review

From: "Kenneth Sundell" <[email-masked]>
Date: Thu, 20 Jan 2000 16:44:48 +0100

Hi,

This is a review of the work currently being done
on the GSMPV3 Specification.  We are working down
to the last minute trying to get as many of the
changes in before the editing session in New Orleans
on Week 5.  It is our intention to submit the current
version to the IETF I-D editor and the MSF repository
on 24 Jan.

Review of document status:

- Re: Reservations.  Support for reservations is being
added and will be available for review in New Orleans.

- Re: Changing the method of listing label stacks as
well as the addition of specific operations for pushing
and popping labels onto the stack.  This will remain
unchanged in the next version of the spec.  It is not
clear that the current method is insufficient; the
current chaining techniques allows for as deep a stack
as may be desired.  Also the operations of push and pop
are implicit in that in cases where the number of input
labels is greater than the number of output labels you
have a push, and in cases where the number of output
labels is greater then the number of input labels, you
have a pop.

- Re: Addition of a service selector to the input label.
This has been added to connection messages.  However,
this change will require further discussion, and will
probably cause changes to the default service model
capability set definitions.  This should be discussed
both on the list and at the editing session.

- Re: Addition of label length and a sub-message number
field to all messages other then the adjacency message.
This is being added in the current version.

- Re: Changes to Delete All to support a distinction for
connection that originate, that terminate or both.  This is
being added in this version.  It is, however, recommended,
that while the protocol should support this, that only
deletion of all connection originating on the port be
required.

- Re: Addition of the label length as suggested by Cplane.
This is not being included in this version of the spec.  The
editors did not have a clear understanding of which supported
label types required a length larger then 28 bits.  Thus,
we did not see a reason to incur the extra processing
required to support the length field for labels.

- Re: Changes to the the Port Event Alarm, i.e. not incrementing
the session id for some events.  This is not being included in
this version.  The editor's felt that this would be risky.
In the example of transition from carrier to no carrier and back
to carrier, it seems that this could be an occasion where a
cable was unplugged and another cable was subsequently
plugged in to the same port.  Assuming that this was still the
same session could be problematic.  It seems safer to force
the controller to determine what the cause of the event was, as
opposed to just ignoring the event in all cases.

- Re: Changing the default behavior for traps.  Changes in support
of this proposal are being included in the next version.  I.e.
the default will changed so that all traps are sent unless the
controller has explicitly requested that no traps of a particular
variety be sent.

All other items are still pending discussions and should be
discussed at the interim editing session and on the list.

Regards,
Avri, Tom, Fiffi and Kenneth

---

From: Balaji Srinivasan <[email-masked]>
Date: Sun, 30 Jan 2000 08:21:36 -0800 (PST)

Hi Everyone,
I just read the new GSMP draft and here are some of my comments.

> This is being added in the current version.

I assume instead of label length u meant to say message length.  The
only addition that we would like to make is in the first PDU of a
multiple PDU message the total length of all the data elements of all
the sub-messages should be mentioned. Also the number of sub-messages
to follow. This would allow an efficient implementation of reading in
all the sub-messages and then parsing them as a complete buffer. This
can be achieved by setting the result flag to indicate that its the
first message and then the sub-message number field can have the total
number of submessages.  The total length of all the messages can be a
2 byte field immediately after the length field. This field is present
only on the first message.

> required to support the length field for labels.

I beleive that even though most labels might not extend 28 bits it
might be better to have a 8 bit or 4 bit label length (which indicates
the label length in bytes (the labels can be padded with 0s if the
label length is not a multiple of bytes) This makes it so that the
controller/switch does not have to check bit masks to see if there is
an extended label and then collecting all of them and then decoding
what the label means.

> opposed to just ignoring the event in all cases.

How about a way for the controller to tell the switch not to
change the port session numbers in case of a carrier/noCarrier
event? That way connection request messages that have been sent
need not fail with an invalidPortSession number code if the controller
does not want it to. This can be implemented in the negotiation phase
where the controller tells the switch whether it wants to receive all 
events or flow control the events.

Apart from this the whole of section 3 of
draft-sydir-cplane-gsmp-enhancements-00 has not been considered. This
section allows the controller to rapidly synchronize with the switch
as far as port status and events that happened in the time during
which communication between switch and controller was down. This
section also outlines the way in which multiple label ranges can be
specified in the port configuration response. This is essential for
partitioned networks. This draft is available at 
http://www.ietf.org/internet-drafts/draft-sydir-cplane-gsmp-enhancements-00.txt

Thanks a lot for all the hard work
balaji