Subject: draft of draft-ietf-gsmp-msf-response-00.txt

From: [email-masked]
Date: Sat, 14 Aug 1999 00:25:41 +0300

Hi,

Enclosed is the draft response to the MSF requirements for WG comment.
As was agreed in the WG meeting, this response was to be reviewed by 
the WG before being passed on to the MSF.  We need to contribute these
comments to the MSF Switch control Working Group by Wed 18 Aug. since
their next meeting is the week after, 24-26 Aug..

Please send any technical comments to the list as soon as possible.
Editing comments are also welcome, but should probably be sent directly
to the authors.  We would like to make this as good and complete a
document as we can in very short time. 

Thanks for your review and help.

Ken, Avri
co-chairs

-----------------------------------
avri doria
+1 617 678 9402

---

From: Joachim Buerkle <[email-masked]>
Date: Sat, 14 Aug 1999 18:26:45 -0400

Dear GSMP WG,

to start a further discussion, I want to ask some additional questions (Q) and make
some statements (St). I hope that I get feedback from the WG even if this
Mailing-List is very quiet. (ever since the MSF was founded)

>>Requirement #68:       Support for Circuit Emulation Service
>>GSMPv3 compliance:     NS. requirement believed not to be satisfied. CE Service is
not supported in GSMPv3.

St: Since I expect, that the capability to transport CES via the VS is one of the
major issues in the MSF, we should answer in a different way.
In my view we should make a general statement, that the GSMP concept does not prevent
the support of CES, since somebody can define in addition further extensions to
support this service like we want to do it in future e.g. for diffserv (see current
draft).

>>Requirement #18:       dynamic/statistical partitioning
>>GSMPv3 compliance:     PS. requirement believed to be partially supported. While
physical resources can be statistical shared among partitions, there is no support
for dynamic partitioning.

Q: May be I am not familiar enough with the MSF terms and architecture, but is the
support of statistic and dynamic partitions not a issue of the separate management of
the partitioning. I don't see where GSMP prevent that somebody defines a way to
dynamically partition the switch resources, if he ensures that the CAC and Routing
for a new connection is done on the base of (in this moment) fix VS partition
resources. Or are there some other issues which I don't see in the moment?

>>Requirement #80:       The SCI shall provide a standard mechanism for inclusion of
vendor-proprietary extensions
>>GSMPv3 compliance:     PS. requirement believed to be partially supported. GSMP
today allows proprietary extensions in the end of the message, that is, everything
after the last "GSMP message field" is considered as proprietary. There is a question
on whether this is enough or whether an extra bit field that flags for additional
information such as records, objects or TLV's should be included.

Q: If this is not enough can we then reserve a message type for proprietary
solutions?

>>Requirement #6:        It shall be possible for the VSCEs that make up a VSC to run
on physically separate platforms and to access the VS over separate physical paths
(links).
>>GSMPv3 compliance:     NS. requirement believed not to be satisfied. There is
currently no support for redundant controllers in [3]. In order to fulfill this
requirement proposals are needed.

Please compare with the GSMP WG answer for Requirement 8# (see below).
Q: Are there really other issues beside a new adjacency?
St: In my view the function for the switchover (between VSCs or VSCEs) should not
make further additions to the SCI at least in the case where:
- the second VSC or VSCE is running as hot-standby and
- the VSCs or VSCEs are running in parallel because of loadsharing etc.
(The second case is not supported by the GSMP but in my view this has no impact to
this requirement, since as soon the multiple-VSCEs-to-one-VS-relationship is
supported by GSMP this requirement is supported also)

>>Requirement 8#:        The SCI shall not restrict the switch redundancy scheme and
must allow for m:n hardware level redundancy in the switch (e.g., Card level
redundancy, other component level switching, APS on interfaces).
>>GSMPv3 compliance:     PS/E. requirement believed to be partially satisfied. There
are no mechanisms in GSMPv3, which restrict hardware level redundancy.  There are
also no mechanisms, which support such redundancy.  This requirement needs further
clarification in order to understand whether such a passive lack of restrictions
meets the requirement.

>>Requirement #14:       The SCI shall allow for secure communication between VSC and
VS using a standards based security protocol
>>GSMPv3 compliance:     PE. requirement believed to be satisfied. The level of
security is a subject for discussion in several IETF working groups. The issue is
addressed to the IESG to be resolved. A mechanism has been suggested with the group
that may not be adequate for IETF security purposes.  It is possible that use if
IPSec will be mandated for security purposes.

Q: Can somebody please provide also a statement for the transport via ATM?

>>Requirement #39:       The SCI shall support the termination of virtual paths
(splitting a VP into VCs) as per I.311.
>>GSMPv3 compliance:     E. requirement needs further explanation.

ST: In my view GSMP supports this, since I think this is related to the following
text in
[I.311] Recommendation I.311 (08/96) - B-ISDN general network aspects
(http://www.itu.int/itudoc/itu-t/rec/i/index.html)
"When VCs are switched, the VPC supporting the incoming VC links must be terminated
first and a new outgoing VPC must be created. Cell sequence integrity is preserved as
defined in clause 2/I.150 by the ATM layer for cells belonging to the same VPC. Thus
cell sequence integrity is preserved for each VC link within a VPC."

>>Requirement #52:       The SCP shall be capable of operating over ATM
>>GSMPv3 compliance:     E. requirement needs further explanation. The GSMP protocol
uses VPI=0 and VCI=15 for ATM connections that is directly connected (data link
between controller and switch). There are not yet any methods defined for across an
ATM cloud.  If this is what the requirement indicates then suggestions for a
mechanism are required.

St: in my view the ATM Network (ATM Cloud) provider is responsible for the setup of
this connection (whether as PVC, SPVC, etc.) This is the same as in the case of a
direct connection between controller and switch.
Q: Can we add e.g. the optional use of VPI=0 VCI=33 if the ATM cloud doesn't support
the transport of VPI=0 and VCI=15?

>>3.9  Management Requirements
Q: Must the GSMP MIB support all these requirements?

>>Requirement #27:      The SCI shall allow a virtual port to be brought in to
service or taken out of service.
Q: Does somebody know what shall happen - in the view of the MSF - if a virtual port
is taken out of service? Is this just to filter out (through away) the ATM cells for
this virtual port, and the resources for the connections are still reserved?

Thanks
Joachim

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This Email includes my personal opinion and
not necessarily the opinion of Bosch Telecom
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[email-masked] wrote:

>   --------------------------------------------------------------------------------
>                                        Name: draft-ietf-gsmp-msf-response.txt
>    draft-ietf-gsmp-msf-response.txt    Type: Plain Text (text/plain)
>                                    Encoding: quoted-printable

---

From: Joachim Buerkle <[email-masked]>
Date: Tue, 17 Aug 1999 16:58:16 -0400

Dear <draft-ietf-gsmp-01.txt> authors,

Here some Questions and Comments to your current version of the draft:

[  page number in draft (version 1)
[  *DR*  Text in the draft
[  *JB*  My questions and comments

- page 6:
*DR* "In this version of GSMP switch partitioning is static and occurs prior to running
GSMP" &
*JB* Why shall we make this restriction for GSMP. The Protocol GSMP is total independent
how or
when the resources are assigned to the partition?

- page 6:
*DR* " ... the controller assumes that the resources allocated to a partition are at all
times available to
that partition"
*JB* Why is this necessary for the controller (according to [SCI requirements] the CAC
is below the
SCI). In my view the resources are maintained by the Virtual Switch. Why shall it not
possible that
if all resources of a partition are used that the Virtual Switch requests further
resources out of a
common resource pool for the his partition, and if he don't use this resources any more,
that he
gives this in addition allocated resource back to the common resource pool.

- page 8:
*DR* "encapsulated in an AAL-5 CPCS-PDU [2]"
page 106
"[2] B-ISDN ATM Adaptation Layer (AAL) Specification," International Telecommunication
Union,
ITU-T Recommendation I.363, Mar. 1993"
*JB* Please update to:
"[2] B-ISDN ATM Adaptation Layer specification: Type 5 AAL", International
Telecommunication Union, ITU-T Recommendation I.363.5, August 1996.

- page 8:
*DR* Reference to [1]
page 106
[1]  "B-ISDN ATM Layer Specification," International Telecommunication Union, ITU-T
Recommendation I.361, Mar.1993."
*JB* There is a newer version at least from 11/95.

- page 8:
*DR* "...with an LLC/SNAP header as illustrated."
*JB* Please add the reference to the [RFC1483] which gives a explanation of the LLC/SNAP

encapsulation over AAL5.

- page 9:
*DR* "The default VPI and VCI of GSMP control channel for LLC/SNAP encapsulated GSMP
messages
on an ATM date Link layer is: VPI=0, VCI=15"
*JB* The VPI and VCI shall be parameters (managed objects) in the GSMP MIB. This means
that this
channel shall be configurable.

- page 12:
*JB* Update the references in the document
- "authentication mechanism used by BGP4  [5]"      [5] is in the reference list 1987
  "RFC2385 [5] describes a TCP extension to enhance security"
- "The Key exchange mechanism will be that defined in RFC2409 [6]"   Ref. RFC2397 not
RFC2409

- page 16:
*DR* "The format of the partition ID is not defined in GSMP"
Who will do this? Is this also something for the GSMP MIB? How shall the switch know
this
format? Necessary (if not negotiated via GSMP) if the Controller and the Switch shall be

exchangeable?
*JB* This relates also to 'Invalid Message' indication.

  page 18:
*DR* N1: Invalid Partition ID
"The value given in the Partition ID field is not legal for this partition"
*JB* In my view we need in addition invalid message case which is defined for the switch
as follows:
"The value given in the Partition ID field is not legal for this switch (physical
switch)"
because in the case of ATM Encapsulation we have may be only one physical connection
between the controller and multiple virtual switches which are controlled by this
controller. This
results than also in only one virtual connection VPI=0 VCI=15. Therefore the messages
for the
virtual switches must be distinguished by the partition ID as described in the
introduction: "GSMP
controls a partitioned switch through the use of a partition identifier which is carried
in every
GSMP message." But if the given value in the Partition ID field is not legal we need the
proposed
invalid message.

- page 16:
*DR* "For event messages the transaction identifier should be set to zero."
   Page 76:
   "Event messages are not acknowledged"
*JB* Why is this prevented up front?
Why we don't use the NoSuccessAck for these cases where no Ack is expected.
An Ack is necessary especially in a case where AAL5 Encapsulation is used, since an AAL5

(respectively this Event) can be discarded because of cell loss on the way between
Controller and
Switch.
Whether the Result field is used in an Event message is not explicit stated in the
description on
page 15 and 16. But since it is closely related to Transaction ID I expect that it is
not used in the moment.

- page 16:
*DR* "When a port returns to the Available state after it has been Unavailable or in any
of the Loopback
states, ..."
*JB* In our view we need also the possibility manipulate the administrative states of a
VCC and a VPC.

- page 17:
*DR* "It is not an error for a GSMP message to contain additional data after the end of
the Message
Body. This is to support development and experimental purposes. However, the maximum
transmission unit of the GSMP message, as defined by the maximum transmission unit of
the
GSMP message, as defined by the data link layer encapsulation has been successfully
completed"
*JB* Shall this be an everytime on function? Shall this configurable via the MIB?

- page 19:
*DR* Connection Failures:
For the case where the switch is only provides VP Cross Connections we also need the
Connection Failure:
"xx1: ATM (virtual) connection switching is not supported on this input port"  and

*JB* We also need the following Connection Failure:
"xx2: ATM (virtual) connection switching is not supported on non-ATM ports. One or both
of the
requested input and output ports is not an ATM port. ATM (virtual) connection switching
is only
supported on ATM ports."

- page 23:
*DR* "Connection management messages are used by the controller to establish, delete,
modify and
verify connections across the switch."
*JB* We need also the possibility just to reserve the resources for connection, that we
can support the
two state configuration of ATM connections: i.e. 1. Step: reserve, 2. Step: finally
connect..
This results in missing possibility to maintain also the administrative states of ATM
connections
and that we have additional events in section 8 (page 76) for connections.
Can please e.g. introduce new flag which shows whether the connections resources are
just reserved or wheter the connection is connected through.

- page 23:
*JB* in all message headers of chapter 4-8 is the partition ID missing

- page 24:
*DR* "use of Multicast flag is not mandatory"
*JB* Is this configured in advance via the GSMP MIB?

- page 26:
*DR* "Q-1" where "Q" is the number of priorities
*JB* For a better understanding I suggest to use n-1 where n is the number of priorities
instead of "Q-1" =>  to get rid of the quotes "Q minus 1"

- page 27:
*DR* "Qos profiles are established by mechanism external to GSMP"
*JB* Will this be a part of the GSMP MIB discussion?
Or is this also in future out of the scope of this WG?

- page 28:
*DR* ATM Labels:
"ATM ports do not support Extension Labels so the VPI and VCI values always occupy the
28bits
following the flags in a connection management message"
*JB* This means if we want to make difference between the UNI / NNI format by using the
label range
message (page 43) capability to define the max supported VPI range per port?

- page 74-75:
*JB* For a better understanding I suggest to explain first the different sub-fields and
than there
encoding.

- page 75:
*DR* "V: VC Merge"
*JB* Refer may to an ATM Forum Definition.

- page 76:
*JB* As I pointed out above we shall have also Events for VPCs and VCCs.

- page 76:
*JB* As I pointed out above we shall have at least in the ATM Encapsulation case the
possibility to
request "Acks" for Events.

- page 76:
*DR* "The Event Message is  defined on a port bases."
*JB* Shall we also introduce a possibility of "grouping of events: e.g. remove a card
with more than one
port => x dead ports " or allowing "event filtering" in the switch.
I know that this in the moment not possible because of the way the Event sequence number
is
used.

- page 77:
*DR* "Extended Labels: There can be zero and more 32 bit words ..."
*JB* We should pointer out that "more" means still inside the max GSMP message MTU size.

- page 83:
*DR* "A controller indicates whether or not switch bandwidth allocation is requested
using a bandwidth
allocation (BA) flag in connection Management messages."
*JB* This Flag is not shown in the message format of the connection management message
on page
23. Shall this be a part of the Traffic Parameters Block?
Can we add something like this:
 "A switch may also support connection reservation function, which means allocation of
Bandwidth
as described for BA and allocation of VPI/VCI values at the input and output port of the
switch."

- page 98:
*DR* "PFLAG:
2 - Recovery Adjacency. In the case of a reset adjacency, the state of the switch will
remain, and
the Switch Controller will be responsible for confirming that the state of the switch
matches the
desired state."
*JB* You think also that this is done by the controller using Report Connection State
Message (page 54)?.

- General:
*JB* introduce an acronym list / abbreviation list e.g.:
TLV (page 11), MSS  (page 13), MSG_OOB  (page 13), TCP URG  (page 13)

- General:
*JB* The expiring day should be "Jan 9th 2000"

I am also interested in feedback from the WG in about the following question:
-  Who is using GSMP for other protocols than MPLS e.g. ATM Forum Protocols like UNI,
PNNI, ...?

Thank you
Joachim