Subject: Draft GSMP Minutes

From: "Avri Doria" <[email-masked]>
Date: Fri, 06 Apr 2001 19:43:18 -0400

Hi,

Here are the draft minutes for the two meeting held during IETF50.

As they need to be submitted by the 13th, please comment early.

Thanks.

a.
-- 

Avri Doria
+1 401 663 5024

GSMP WG Meeting 50th IETF, Minneapolis, MN

There were two GSMP WG sessions this time; one for GSMP issues and one 
joint GSMP/ForCES meeting. 

Session I: GSMP WG Session I at IETF 50 Notes
Monday March 19 0900-1130

The GSMP working group held a meeting at IETF50. The meeting was
chaired by Kenneth Sundell and Avri Doria, and notes were taken by Hans
Sjöstrand.

1. Agenda Review

The agenda was presented, bullet about words from the ADs where added,
There where no proposed changes from the floor on the agenda. The next
session will be together with ForCES on Thursday.

1½. Words from the ADs

Scott Bradner and Bert Wijnen presented themselves. GSMP is pushed into
the new temporary sub-IP area, Scott and Bert are area directors in
addition to their other commitments. They will maintain Allison Mankin
as day to day director and technical advisor for GSMP. The sub-IP area
will maybe last for a year or two, hopefully closer to one than two
years.

The area is doing work for sub-IP technologies, or also referred to as
the underside of IP, and will be some sanity check for that.

2. Charter Update

The goals and milestones from the charter page were presented by Avri.
The ones listed from 99 are still being worked on. These documents are
in the process of going through last calls and IESG reviews.

The purpose of the Thursday meeting is to make sure the point "Apr 01
Analyse role of GSMP for control element separation and make
recommendation as to a separate WG for extending GSMP for this"

This meeting will decide whether the partitioning draft presented here
will be the basis for the point " May 01 Document requirements for
control of switches supporting optical, TDM and other CCAMP features".

Regarding the point " Aug 01 Submit GSMPv3 extensions to include
control of switches supporting optical, TDM and other CCAMP features
and any updates of the base spec for Proposed Standard", we want to
discuss if those goes into the current spec or in an extension spec.

The stuff on switch partitioning mib isn't a charter item yet. The most
important thing is the requirement process. If it shows up to be the
right thing, we will ask for a charter extension to cover also switch
partitioning.

There where no comments from the floor on the charter.

Allison made a clarification, she noted noticed for the meeting on
Thursday that it's not meant to work on the ForCES charter, but how
GSMP WG can help the ForCES WG. Avri pointed out that she didn't know



about any decision that ForCES is a WG. Allison agreed that it was not
the case.

3. Document Status & Review of IESG comments

- GSMP V3 and GSMP Packet Encap.

Kenneth Sundell presented that the specs went through the WG last call
last year and there were many comments. It is now in IESG last call
with comments from the RFC editor and IANA so far, mostly about
references. The IANA consideration page is totally changed. We are
still waiting on IESG comment on the spec as a hole. Some editorial
changes received by implementers are made in the meantime.

Avri noted that we must think if these changes require a second last
call, if the changes are more than editorial. Allison commented that
the changes are most probably to be only editorial.

- GSMP MIB

Hans Sjöstrand presented the updates on the mib. There has been an IESG
review and there are quite a few updates. Except for lots of editorial
updates there are a list of minor changes presented
- Section added on concepts of GSMP and GSMP config.
- IF-MIB 2233 replaced, now RFC 2863
- Notification OIDs updated with less overhead
- Removed trap from Notification names
- Handling of rows created outside SNMP clarified.
- Clarified when objects can be changed in active state
- gsmpSessionStatUptime changed to TimeStamp and renamed to
  gsmpSessionStartUptime
- gsmpEventLabel now of GsmpLabelType (new TC based on
  octet string).
- Added SYNTAX clauses to inet-address objects compliance.
- GsmpVersion TC changed from enumerated to Unsigned32

There where also a few major changes that needs WG approval
- Adopt to the recommended scheme to infer the {gsmpSessionThisSideId,
gsmpSessionFarSideId} from the oids, thereby removing the
gsmpSessionThisSideId, gsmpSessionFarSideId helperobjects agreed to in
Pittsburgh.
- The addition of storagetype.
There where no objections against those proposed changes.

Then there are a few issues that needs WG input
- Any new GSMP encapsulation types in near future and should we make
headroom already now for that in the mib...

There where a comment from the floor that the mere uncertainty about if
there could be another encap could be enough. Also, SCTP has been
mentioned as possible candidate. Avri noted that there where two voices
for an extendible approach. Hans frowned.

There is also an issue if we should have the NotificationMap or just
rely on the std SNMP filter application (RFC2573)? If none object or
speaks up the notification map will stay.



There has also been a question about if scoped Ipv6 addresses makes
sense in a GSMP. Allison noted that it's probably a requirement from
IESG that we have support for scoped Ipv6 addresses.

Avri asked if these changes needed another last call round, Allison
responded that she has seen changes of this kind without a new round of
WG last call. Anyway, Hans will make the updates that's agreed, put a
new revision 05 out soon after the meeting and the WG could give it's
input on the changes. Then there will be a IESG re-review and then to
the RFC editor for publishing.

4. Requirements for optical switching
   draft-doria-gsmp-req-olsr-01.txt

Stephen Shew presented the draft. The motivation is a result of the
interest in IP and optical worlds converging. Either way you approach
it there is a need for separation of control functions and data
switching.

Unlike the original L2 switch fabrics, optical XCs have some unique
properties, even though those come in several varieties.

The requirements are Label Types, Port and Label Management,
Configuration Service Model, Encapsulation and the Transaction Model.

Regarding the transaction model, TL-1 interfaces are liked and used in
the optical world, these people are used to TL-1. It has command
response and  the processing environment is often serial. GSMP must
convey this to avoid e.g. to flood with add branch, Also, add a bulk
message.

Known issues today are Support for SONET/SDH concatenated payloads
(virtual or continuous) and Support for bundles

Stephen asked if the draft is adopted as a WG document. Avri asked if
there are any objections.

One question was made from the floor that are you tracking what happens
in CCAMP. Avri responded Yes, definitely, that's e.g. the primary label
target, and that's why its not discussed so much in this presentation.

Another remark was made, even thought it was no real objection, that
there are overlaps with ODSI. Avri responded that ODSI primarily
defines a client to network interface, this is a controller to fabric.
It was argued that we should look on them instead of do everything from
scratch.

Dimitri said that he would first like to have his presentation and then
the question could be asked again.

Allison wanted to stress a very close cooperation with ccamp, the draft
could look very very different next time and people shouldn't be
surprised by that.

5. Further Requirements for GSMP - Dimitri Papadimitriou



Dimitri made a presentation on further requirements for GSMP.
Performance monitoring is important. Also, there should be logical
grouping of interfaces, in order to have more interfaces. Like the
bundling in CCAMP. Even it was a rough idea that was proposed, there
could be more consistency between the GSMP and GMPLS.

There could be new encapsulation, the question was if it was needed.
It's also done ITU.

The presentation also contained some very technical part, that Dimitri
wanted to do it in Forces. Avri clarified that it was better to take it
here, because there are no time allocated in the ForCES/GSMP meeting.

Avri clarified that the encap GSMP has nothing to do with encap of IP
in optical. Dimitri said that that at least if we wanted to do it, we
should be aligned.

It was asked from the floor if it is expected that a single controller
controls several switches. Avri responded, yes, it's already in the
GSMP framework. But how does the controller know who to talk to. Avri
answered that it's an adjacency established.

The requirements document is the base document to build on. We should
work together with Dimitri and whoever wants to be involved.

Avri asked if there where any objection to make it a WG doc, there
where no objections.

6. Label extensions for Optical, Sonet/SDH, TDM and spatial switching
   draft-sadler-gsmp-tdm-labels-00.txt

Jonathan Sadler presented the TDM labels draft. It's based on GMPLS
draft in CCAMP. The original reason with TDM in GSMP was to handle ATM
CES, but a more contemporary need on GMPLS control / element
separation. This offers a mechanism to offload the already deployed
switches from GMPLS control plane.

We need primitives to create TDM cross connects, multiplexing and to
express directionality. We are dealing with G.707 multiplexing
structures and the other plesiochronous services PDH. This introduces 9
new labels, port/lambda label, Sonet/SDH, ANSI PDH, ETSI PDH and the
Inverse multiplex concatenated label. We are using label stacks as TDM
Hierarchy.

Next steps are; to adopt the draft as working group document; Reconcile
ETSI labels and to complete the definition of traffic parameters.

Question from the floor; What's are you referring to with ETSI labels.
Answer; The label format is following the ones in CCAMP, but CCAMP
doesn't go as low as we need with E1 in E3 etc.
Yes, PDH labels is a good idea, could be an extension of GMPLS, but why
have label stack? You don't need to?
Jonathan acknowledged that in the simple case you don't need to, but
e.g. when you operating on a Sonet port, you may have an E3 phy in one
side and E1 in others, there could be a benefit to reuse what's already



bee negotiated on the other side. Also, DSOs within the DS3s, the sonet
world doesn't have that granularity.

Avri asked if there are any issues or objections to make it a WG doc,
there where no objections.

7. Requirements for Dynamic Partitioning
   draft-anderson-req-dyn-part-00.txt

Todd Anderson presented the draft. In static partitioning the manager
is using a mib to define the partitions, and than don't change these
configurations. If you want to re-partition you need to down the device
and restart. Dynamic partitioning removes that downtime. This is the
set of requirements on dynamic partitioning, based on discussion some
time ago on the list on the requirements.

The involved are partition manager, the controller and a network
element. The network element is always a slave to the controller, it
never acts or asks from the controller to release resources. The
partitioning manager may release resources in the NE, NE are then
allowed to inform the controller that the resources have been changed
from the partition manager.

Avri commented that in this draft we have discussed more issues than
what has been reflected in requirements. So, it's not by far finished.
E.g. the discussion of a frozen partition.

Stephen Shew commented that in the diagram you could have multiple
controllers. The partition manager has the trust, the burden to
coordinate controllers lands on the partition manager. Notice that the
partition manager is operated by the owner of network, the set of
controller may be operated by other owners. How do you handle the level
of trust, pre-emption etc?

A comment from the floor that there are now connection with the
partitioning, and the GSMP. But that is not necessary. E.g. the ForCES
discussion, if you partition these resources as well. Answer that, no
it's not meant to be specific, should be more general. E.g. a partition
could be a native controller for the SDH switch.

Avri pointer out that there are always an invitation to people to
contribute to the document.

Avri asked if the draft should be made a WG doc, there where no
objection.

8. Paritioning MIB
   draft-anderson-gsmp-swpart-mib-00.txt

Avri started by pointing out that we can't make this a WG doc, because
it's not within our charter. It's still a pending issue if we should go
forward with it. We have the charter to investigate and look on the
requirements.



Allison Mankin stated that we should really stay out of the solutions
phase. Really not reference it from the requirements doc. We should
just do the requirement list. She also stresses the fact that we don't
want to have very specific regulatory requirements, that we should be
focused on technical requirements.

Todd Anderson presented the mib. The mib started in mib format in MSF,
was then made into pib format and presented in Pittsburgh IETF. Now
it's back in mib format.

The mib satisfies the requirements so far in the requirement draft.
Creating virtual network elements. It maps physical ports to Virtual
Network Elements. You could have several VNE assigned the same physical
port. It also configures how control protocols will talk to VNE and
defines how physical switch resources (bandwidth, buffers,
label/forwarding table space) are allocated to VNEs

What's new since Pittsburgh, some tables are added for the partition
manager to create synthetic ports to relay packets between the VNEs,
not having to waste a real link. Also allow partition manager to locate
connected controllers.

The mib doesn't cover optical, and may possibly cover the ForCES case
with IP. We are not sure where to go with this. We have been issuing
the mib. There are a lot of open issues. It was posted to the mailing
list, some comments came in.

Hans Sjöstrand asked what MSF has said about the mib since it's been a
work item there for a long time. Todd responded that there have been
comments from MSF to make it more general. There has been work in MSF
that optical should be added, and also to add the TDM partitioning.

Meeting adjourned by Avri Doria.

--

Session II: GSMP/ForCES Joint Session at IETF 50 Notes
Thursday March 22 1300-1500

Co-chairs: Avri Doria, David Putzolu
Note takers: Alan Crouch, Craig Rodine, Kenneth Sundell

[Comments attributed where possible]

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

1. Agenda
   - Agenda Bashing - David Putzolu, Avri Doria
   - Setting the Stage/Meeting Goals
   - ForCES Overview and Requirements Update
   - ForCES Work
     - ForCES Work Structuring Proposal - Tom Worster
     - ForCES Work Defiition - David Putzolu
   - ForCES Relationships to GSMP
   - Discussion and Wrap-Up

2. Setting the Stage

David Putzolu went over the Forces & GSMP recent events
to bring everyone in the room up to speed.  The Forces
BOF was held in San Diego with large attendance and ended
with a split vote of 150 for WG creation and 100 against.
Questions were raised in the BOF about the relationship
of Forces to GSMP and about the structuring of the Forces
work. Discussions since then on the mailing list around
the relationship to the GSMP wg and protocol were
summarized as well as discussions about a potential
Forces charter.

3. ForCES Overview and Requirements Update - Todd Anderson
   Draft = draft-anderson-forces-req-01.txt

Todd Anderson presented the revised version of his
Forces requirements document. Notable changes include
support for a variety of connection types, auto-membership
and topology discovery, and a change to the failure model.
Also identified was a requirement for a functional model of
a forwarding element, perhaps via a FE capability 
advertisement system.

Discussion followed the presentation of the requirements
document.  The idea of sharing an FE between CEs was
discussed and described as a variation of FE parititioning,
which would be a separate protocol.  A hot topic that was
identified is determining what FE functionality is and the
ordering in which it is applied to packets.  Some audience
members questioned the interest of box vendors in the
Forces approach and were answered by several attendees who
indicated interest on the part of their companies.  Avri
Doria closed the discussion with a comment indicating that
gauging vendor interest was not a goal of the current 
meeting and would be more appropriately expressed to the
IESG.

4. The ForCES context - Tom Worster

Tom Worster presented a structuring of the Forces work that
partitions it into manageable chunks.  Tom related that he
was initially skeptical about the likelihood of success for
Forces but after further reflection believed it was an
important, feasible effort.  For specific information about
the proposed structure see Tom's slides.
Mark Handley indicated that he was largely in agreement with
Tom's analysis.  He suggessted starting out with a model 
that provides strong expressive power, then limit the model
for practical purposes - i.e. don't do premature optimization.
Ravi Medikonda indicated the importance of socializing these
ideas with service providers and system vendors, which was
answered by Avri Doria indicating that many service providers
are active.  Jong Jiant indicated strong service provider
interest on his part as this would allow for rapid innovation
in services.  Russell Dietz indicate that the Forces model
made significant sense in the use case where one has a smart 
backend device and a dumb CPE device, where the CPE device is a
forwarding element for the backend device, where all of the
intelligence is concentrated.  Eric Gray raised a concern about
the term "equitable" treatment of FEs in Tom's presentation.
This was elaborated on by Tom to indicate the need for
technical balance, where the standard did not favor a 
particular implementation.  Jamal Hadi Salim closed the 
comments by urging that the functionality and expressive power
not be limited to basic forwarding and QoS.

5. ForCES Work Definition - David Putzolu

David Putzolu presented the current work definition for
Forces based on the discussions on the mailing list since
the BOF.  The most notable change was the introduction of
a formal FE model as an intermediate stage between 
requirements and protocol selection/specification.

Nabil Seddigh indicated that QoS work should be done in
parallel with other work, and that the Diffserv models
followed a similar progression.  Jon Crowcroft added that
security should be addressed from the very beginning 
rather than as an afterthought.

6. ForCES Relationship to GSMP

David Putzolu and Avri Doria kicked off this discussion
by summarizing previous questions around the Forces/GSMP
relationship.  These questions had previously been 
discussed on both the Forces and GSMP mailing lists.
Avri Doriad described how GSMP will be developed as a
result of its rechartering.  Her intuition was that GSMP 
will be applicable she believes that it is not apparent 
that its generalization would cover the scope of what's 
being considered here.  

Jamal Hadi Salim commented that he was in mild agreement but
thinks focus of ForCES is narrow with no real overlap with GSMP.
Tom Worster added that perhaps re-use will happen at the protocol 
level, but it can also happen at the "design experience" level,
referring to Fred Baker's point from the previous night's plenary
about "twice is enough." Other audience comments focused around
the scalability that Forces enables as well as a caution to not
turn Forces into a Christmas tree protocol

Allison Mankin (Transport AD) stood up to mention concern about
the reaciton to the BOF at the last IETF meeting (San Diego).
She indicated that this was not a discussion topic for today,
requesting that people please email any opinions, especially
negative ones, of ForCES work items/plan directly to the Routing 
and Transport ADs.  Allison Mankin then asked for a sense of the
room on a potential recommentation that ForCES be closely co-
ordinated with the GSMP WG.  The general room response was that
ForCES should first develop requirements and functional model and
that it was too early to be leaning towards any particular 
protocol (solution).  Once technical requirements and model are 
defined then Forces would compare them against GSMP and make 
decisions.

Meeting was adjourned by Avri.