Subject: Minutes from GSMP editing session in New Orleans

From: "Kenneth Sundell" <[email-masked]>
Date: Fri, 11 Feb 2000 15:29:38 +0100

All,
these are the minutes from the GSMP editing session Feb 2 in New
Orleans.

cheers,
Ken

--

GSMP Editing session, New Orleans 2/2/00

   The editing session was co-chaired by Simon Crosby of
   CPlane and Avri Doria of Nokia.  Kenneth Sundell of Nortel
   Networks took notes.

1.  Comments relating to draft-sydir-cplane-gsmp-enhancements

   draft-sydir-cplane-gsmp-enhancements-00.txt was presented
   during IETF46 held in Washington. There were comments
   during the meeting and arrangements were made to discuss
   the issues on the GSMP list during the following 3 weeks.
   The conversations were to be initiated by the authors, with
   an email on each of the outstanding issues of concern and
   including proposals that responded to the WG's issues.
   Balaji Srinivasan of CPlane sent out several of the issues
   on Dec 30. These issues were considered during a meeting of
   the GSMP spec editors. The results of that meeting were
   announced on the GSMP list and the GSMP spec was updated.
   Several of the author's critical issues were not resolved
   in this process and were discussed during this meeting.

1.1  Addition of Label Length parameter

   Is E bit, used for label stacking, also useful for longer
   labels? There was no evidence that one would need labels
   "longer" than 28 bits. The 28-bit label field is fixed
   length in GSMP. The label field is an abstraction and does
   accommodate ATM, FR and generic MPLS labels. There may have
   been misunderstanding regarding the purpose of the E-bit.
   The semantics of the E bit are not intended to describe
   longer labels, but are intended for indicating label
   stacks. Tom Worster, Ennovate Networks,  asked the audience
   whether anybody needed labels exceeding 28 bits.  There was
   a consensus in the group that labels longer then 28 bits
   were not required.

   The method for doing label stacking and use of the E bit
   will be further described in the GSMP spec by Tom.

1.2  Changes to the Post Session Number updates

   Simon proposed that the "Port Session Number" should not be
   changed in case of link status changes. Several people
   thought that eliminating this protection could be
   dangerous.  It was felt that the link layer configuration
   (e.g. internal thresholds) should take care of short breaks
   such as temporary loss of carrier, but that anything else
   should force the port session update. There was a consensus
   that this should be sufficient and no further changes to
   the protocol were warranted.

1.3  Port Configuration and All Ports Configuration messages

   There were several issues relating to this:

1.3.1  Separate VPI and VCI connections

   This is already supported and no longer an issue.

1.3.2   Multiple discontiguous label ranges.

   Kenneth will provide text for support of multiple disjoint
   label ranges

1.3.3  Labels for multi-point

   Specific label ranges for multi-point requested by Simon.
   Tom indicated that modelling multicast constraints is
   difficult and proposed adding suitable information to the
   failure response messages as an alternative. Another
   alternative mentioned by Avri was to use the remaining
   label field with the addition of another flag to indicate
   the multicast label range.  Avri will explore this
   possibility and report to the list.

1.3.4  Incoming and Outgoing Labels

   Simon proposed adding specification of ranges for outgoing
   labels. The issue is about policing misbehaving
   controllers. Currently GSMP does nothing to prevent such
   actions and does not know anything outside its dedicated
   partition. It is the responsibility beyond GSMP, preferably
   dealt with at the control plane. GSMP informs the
   controller about the input label only. The GSMP editor
   solicited the group for opinions on this topic. Tom is
   going to solicit this on the email list

1.4  Synchronization

   Simon withdrew this issue since it is already fixed in
   GSMPv3 by the addition of event acknowledgements.

2.  Comments related to MSF00.014 - Proposed Changes to GSMP
   connection messages

   Clint Bishard of MCI/Worldcom presented a MSF contribution
   that proposed changes to the connection management
   messages.

2.1   Separate formats for input and output

   A change is proposed in the connection management message
   to allow specification of parameters for each port in a
   given connection separately instead for doing it for the
   connection as a whole. A next generation switch doesn't
   have to be, e.g. ATM specific, but could be heterogeneous
   supporting different port types. The input port for a
   certain connection could be of Port Type frame relay while
   the output port could be of Port Type ATM. The desire is,
   in an independent way, to convey the parameters appropriate
   to each of the ports.  That is, how doe we map (IF.type1,
   resource.type1) to (IF.type2,resource.type2).  It may also
   be necessary to specify parameters related to policing
   separately form parameters related to resource management.

   The proposal is accepted in general but the input and the
   parameters should be semantically separated. These separate
   parameters need to be described (maybe in the traffic
   parameter block input as well as output). Exactly how the
   semantics would be described should be further discussed on
   the GSMP email list.

2.2  Input and Output Encapsulation Methods

   Is Input/output encapsulation needed in the connection
   message? It is possible to add a 32 bit GSMP opaque field
   (with a 50/50 split for input/output) which corresponds to
   predetermined encapsulation methods to be used for
   experimental use.  The definition of formal encapsulation
   types could then be resolved in a later version of GSMP,
   e.g. GSMPv4.

   Tom will take Clint's proposal, reshuffle it, and post an
   I-D together with Clint before the next IETF meeting.

3.   Other issues / Open areas

3.1  CES Labels, support of TDM interfaces

   The current draft does not yet include support for CES and
   TDM interfaces. Clint will, with support from Kenneth work
   on adding this support. There are quite a lot of things
   that needed to be added to the GSMP spec to support CES
   labels and services. The specification will need to define
   CES labels, label ranges and TDM Port Types.  It will also
   need to specify the relevant CES traffic and QoS parameters
   in chapter 9 of the GSMP spec.

3.2  Is an FEC a label or something that should be internally
    mapped to a label?

   There have been misunderstandings about whether a FEC can
   be used as a Label or not. A FEC is related to IP address
   prefixes together with optional QoS constraints. The issues
   were not addressed during the meeting though and need to be
   discussed further on the list.

3.3  Introduction of input/output move branch message

   Avri raised the issue that Joachim Buerkle of Marconi at
   the last ietf meeting presented draft-buerkle-gsmp-move-
   branch-message-00.txt in which he proposed adding
   functionality to move the input branches of a multipoint to
   point connection

   Avri proposed that instead of modifying the current move
   branch, the message should be replaced by a pair of
   messages; a move input branch message and a move output
   branch message.  This is similar to what was already done
   by replacing the delete branch with a delete input branch
   message and a delete output branch message. This proposal
   was accepted and will be implemented in GSMPv3.

3.4  Xbind issues

   No one from Xbind was in attendance and since no one in
   attendance came prepared to represent their issues, those
   issues were not covered during the meeting.

3.5  Error Messages

   No suggestions were given during the meeting due to time
   constraints. The GSMP editors have to deal with issue
   before the next revision of the GSMP draft.

--
Kenneth Sundell
Nortel Networks
Routing Architecture Lab
S:t Eriksgatan 115 A, PO Box 6701
113 85 Stockholm, Sweden
phone: +46 8 5088-3538, mobile +46 70 665-7838
e-mail: [email-masked]

---

From: "Buerkle Joachim (UC-ON/EMY2) *" <[email-masked]>
Date: Mon, 14 Feb 2000 11:18:37 +0100

Thank You Ken,

	>>functionality to move the input branches of a multipoint to

The proposal is to move output branches to other input branches.
"This draft shows that the support of such application results in a
 extended move branch concept of GSMP to be able to move the Output
 branch of a connection not only to another port but also between
 connections with the same QoS."

	>>was accepted and will be implemented in GSMPv3.

I'm happy to here that the Group accepted to add the move output branch
message.
And a corresponding move input branch message is also fine for me.

c.u.
Joachim

- - - - - - - - - - - - 

Marconi Communications GmbH
Gerberstrasse 33,  D-71522 Backnang,  Germany
Phone: +49 (0)7191 13 - 4602, Fax: +49 (0)7191 13 - 64602
Email: [email-masked]

- - - - - - - - - - - - 

> -----Ursprüngliche Nachricht-----
> Von:	Kenneth Sundell [SMTP:[email-masked]]
> Gesendet am:	Freitag, 11. Februar 2000 15:30
> An:	gsmp-list
> Betreff:	Minutes from GSMP editing session in New Orleans
> 
> 
> All,