Subject: RE: draft response #18 - dynamic/stat partitioning

From: [email-masked]
Date: Sun, 15 Aug 1999 18:47:04 +0300

> -----Original Message-----
> From: EXT Joachim Buerkle [mailto:[email-masked]]
> Sent: 14 August, 1999 6:27 PM
> To: [email-masked]; [email-masked]
> Subject: Re: draft of draft-ietf-gsmp-msf-response-00.txt
> 
> >>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?
> 

I think that the capability they are looking for is the ability to
dynamically or statistically adjust the partitions,  via GSMP commands
during a session.  Currently, partitioned resources are statically
allocated to the partitions before the adjacencies are made.  There are
no mechanisms for a VSC to request a different set of resources.

a.

---

From: [email-masked]
Date: Fri, 20 Aug 1999 19:05:54 +0300

Hi,

I think I agree with your statements, but I don't think I want to change the
statement in the response to the MSF at this point. Perhaps the issue will
get clarified in the meeting.

Additionally, I look forward to the draft on reservation mechanisms.  It has
become clear that we need a reservation mechanism to support MPLS.  Several
of us start talking about such a mechanism but did not come up with a
proposal yet.

regards,
a.

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

> Sent: 20 August, 1999 8:35 AM
> To: [email-masked]
> Subject: Re: FW: draft response #18 - dynamic/stat partitioning
> 
> 
> [email-masked] wrote:
> 
> > > * Requirement #18:       dynamic/statistical partitioning
> > > * GSMPv3 compliance:     PS. requirement believed to be
> > > partitions, there is no support for dynamic partitioning.
> > >
> architecture, but
> > is the
> > > support of statistic and dynamic partitions not a issue 
> of the separate
> > management of
> somebody defines a way
> > to
> 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?
> > >
> >
> Hi Avri,
> if it is in this way, than it is definitely not how I want to have the
> architecture.
> 
> I got told that in the earlier discussions MSF wanted this, 
> but at the last MSF
> Meeting somebody introduced a Switch Management Interface 
> (SMI) and that at the
> next meeting (next week?) there will be further discussion 
> about it, i.e. it
> seems that they want to make a distinction between Switch 
> Control and Switch
> Management respectively between Switch Control Interface and 
> Switch Management
> Interface.
> 
> My view is still that GSMP is and shall be independent from *how* the
> partitioning is done.
> My view is still that applications just want to control the 
> switch resources
> which are currently allocated by them. They don't care for 
> the resources which
> are left in the switch. They are requesting with a connection 
> setup further
> resources, but then it is the task of the CAC (part of the 
> Switch,  compare to
> <draft-mceachern-gsmp-scireq-00.txt>, section 2.2., point (l) 
> ) to tell them
> whether in their partition are some resources left to do this 
> connection setup)
> 
> 
> With this explanation it is may be now also more clear why I 
> requesting in my
> Questions and Comments to <draft-ietf-gsmp-01.txt> that GSMP 
> provides in
> addition the possibility for a two step connection  setup: 1. 
> reserve the
> resources for connections and 2. make the connection.
> This can be done for e.g. with the current Connection 
> Management Message by
> using the spare (x) bit in the Message:
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |M|B|x|E|                  Input Label                          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> I started to write a draft which will propose this.
> 
> 
> Regards
> Joachim
> 
> 
> 
> 
> 
>