draft gsmp minutes

Hi,

attached are the minutes from the last gsmp wg meeting in atlanta.
Please review and comment so we can make any adjustments before 
submitting them further.

Regards,
Ken

General Switch Management Protocol (gsmp)

Thursday, November 21 at 1300-1500
==================================

CHAIRS: Avri Doria <avri <at> sm.luth.se>
        Kenneth Sundell <ksundell <at> nortelnetworks.com>

Scribes: Jonathan Sadler and Scott Bradner.

Agenda bashing: nothing changed

WG Status:
----------
Kenneth went through the WG Status. The two requirement drafts have
been processed through last call. The RFC3292 has been split into
a number of drafts since it turned out to be too complex containing
all label and interface types. The division was agreed on at the 

fyi - IETF Sub-IP area: request for input

IETF SUB-IP area

 The IESG announced in November of 2000 that a new SUB-IP temporary
 pseudo-area would be formed as a part of an effort to develop a 
 "systematic approach to dealing with what we used to describe as 
 "sub-IP" technologies." At the time the IESG said:

 "Over the years the boundary between 'wires' and IP protocols has 
 become harder to define and the interaction has become more intertwined. 
 For example, what appear as 'wires' or 'circuits' in a virtual network 
 may in fact be routed datagrams in an underlying IP network. The 
 topology of dynamic underlying networks such as ATM and soon switched 
 optical networks can interact with IP-level traffic engineering and 
 routing. Additionally, with IETF technologies such as MPLS we are  
 defining a whole new class of 'wires'." 
 (http://www.ietf.org/IESG/STATEMENTS/new-area.txt)

 After the December 2000 IETF meeting and taking into account the 
 discussion at that meeting the IESG formed a "temporary" SUB-IP Area. 
 IN the announcement of this action the IESG said:

 "It is temporary because the IESG believes that this concentrated 
 sub-IP effort will likely be of short duration, on the order of a year 
 or two. We feel that much of the work will be done by then, and the 
 working groups closed. Any working groups that have not finished when 
 the IESG determines that the area should be closed will be moved into 
 existing the IETF areas where they seem to have the best fit." and "The 
 IESG expects to review the development process and charters, however; 
 if we conclude that this expectation is incorrect, we will need to make 

2nd WG Last Call for GSMPv3 Requirements

As discussed previously on this list and in the WG meeting in Atlanta,
Requirements For Adding Optical Support To GSMPv3, is ready to
go through a second WG last call.

This last call is scheduled to end 20 Dec.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-gsmp-reqs-04.txt

Please send comments to the list.

Thanks
a.
--

-- 
Avri Doria
http://www.sm.luth.se/~avri/

2nd WG Last Call for draft-ietf-gsmp-dyn-part-reqs

As discussed previously on this list and in the WG meeting in Atlanta,
Requirements for the Dynamic Partitioning of Switching Elements,
draft-ietf-gsmp-dyn-part-reqs-03.txt
is ready to go through a second WG last call.

This last call is scheduled to end 20 Dec.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-gsmp-dyn-part-reqs-03.txt

Please send comments to the list.

Thanks
a.
--

-- 
Avri Doria
http://www.sm.luth.se/~avri/

RE: 2nd WG Last Call for draft-ietf-gsmp-dyn-part-reqs

Hi,

I apologize if the questions/comments herein reflect
ignorance of preceding WG discussions...I decided to
take a look at the draft at this last call stage....

1.  I don't understand the rationale for this limitation
of PMs and SEs (from the Introduction section):

"There is a one-to-many relationship between PMs and SEs."

...Especially in light of the many-to-many relationships
between PMs and Controllers and Controllers and Partitions.

...And additionally in light of the following two statements
referring to multiple PM considerations (from Intro and
Security, respectively):

"Likewise, there may be multiple partition managers
running on a single management workstation."

"Only authorized PMs MUST be allowed to dynamically
repartition a SE."

2.  How is the "one-to-many" PM to SE relationship
enforced in the protocol?

3.  The Security Considerations section is actually quite
good in the sense of identifying some important protocol
issues (which is something you don't always see).  However,

RE: 2nd WG Last Call for draft-ietf-gsmp-dyn-part-reqs

> 1.  I don't understand the rationale for this limitation
> of PMs and SEs (from the Introduction section):
> 
> "There is a one-to-many relationship between PMs and SEs."

PM is a logical entity.  We decided that _logically_ a single
PM would be responsible for a SE.  To say that multiple logical 
PMs could configure a SE would imply the need for some sort of
policy enforcement between them on the SE.  To avoid this, we
say that a single logical PM controls the SE and this logical
entity may be coresident with other PMs on the same physical
management station or in a very strange and rare case spread
across multiple physical management stations.  However, I don't
expect that this latter case would ever happen.

> ...Especially in light of the many-to-many relationships
> between PMs and Controllers and Controllers and Partitions.

These many-to-many relationships are derived naturally from
the ability to partition a SE and have each partition be
controlled by a different controller.

> ...And additionally in light of the following two statements
> referring to multiple PM considerations (from Intro and
> Security, respectively):
> 
> "Likewise, there may be multiple partition managers
> running on a single management workstation."

This is just describing a likely physical manifestation

Re: a personal opinion on what to do about the sub-ip area

if you have an opinion on the future of the sub-ip area and want
to express it - please send that opinion to the ietf <at> ietf.org &/or 
the iesg <at> ietf.org lists

for my current opinion (whatever that is worth) please see
http://www.ietf.org//mail-archive/ietf/Current/msg18465.html

thanks

Scott