RE: Moving forward with VCAT/LCAS...

[Alex Conta <aconta@optonline.net>]

Greg,
 
From the perspective of the "users" of a VCG - applications or clients
of the VCG  which are the layers above the VCG (above both VCG client
and server). -  the awareness, the information about the VCG members,
and furthermore, their presence before, or after VCG creation or tear
down, does not really seem relevant, or directly useful. 
 
From a "management/provisioning" perspective, setting up the components,
independently from the client layer - as a first setup step - and then
converting/transforming these elements into VCG members, once a VCG
group (and client) has been set up - as a second setup step - and then
at tear down, after VCGs tear down, keeping the server elements around,
seem to be reducing the number of subsequent setup operations, if those
elements can be and are reused with subsequent newly created VCGs.
 
It can be argued though, that in a case - a VCG application - in which
existing server elements CANNOT  be reused, a one step creation or
tearing down of VCGs - in which client and server elements are
created/setup, or torn down together, instead of a two step, and keeping
server layer elements around - is more appropriate. 
 
So the preferred "default" behavior may depend on the type of VCG
applications, and could be best left as a choice for the system
developer to make. 
 
Regards,
Alex Conta
 

-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com] 
Sent: Friday, January 11, 2008 11:03 AM
To: Alex Conta
Subject: Re: Moving forward with VCAT/LCAS...


Nice analysis/summary Alex.  I like the "looser coupling" + policy
(default behavior) approach that you put forward.
Let me know if you've got solution preferences (on or off the list).

Regards

Greg B.

Alex Conta wrote: 
Supporting the two requirements makes sense.

A VCG member (server) has some basic functionality that is similar to
non-VCG members, and the mechanisms to setup that functionality is
usually similar/same (for instance, setting up the DS3 functionality of
the DS3 members of a VCG is similar to setting up non-VCG DS3s.) 

Transforming a non-VCG member into a VCG member, and vice-versa, a VCG
member into a non-VCG member, is just a matter of additional setup - VCG
setup (through management, control plane, policy driver, etc...)

An implication of the support of these two requirements seems to be a
choice of behavior of the implementation of the VCG tear down functions.


1. provide the function of terminating all functions and tearing down
all VCG members (servers) at the time of tearing down their VCG
(client).

2. provide the function of terminating only the "VCG member" functions,
transforming VCG members into non-VCG members, and thus have the non-VCG
functionality of the server layer entities survive the tear down of the
VCG (client).

An implementation may have a choice of "default behavior", which could
be mentioned in the draft. 

Regards,
Alex Conta

  
-----Original Message-----
From: owner-ccamp@ops.ietf.org 
[mailto:owner-ccamp@ops.ietf.org] On Behalf Of Greg Bernstein
Sent: Tuesday, January 08, 2008 12:28 PM
To: ccamp@ops.ietf.org
Subject: Moving forward with VCAT/LCAS...


Hi CCAMPers, at the Vancouver meeting the status of the 
VCAT/LCAS draft 
was discussed and there seemed to be two possible additions to the 
requirements section of the draft. From the slide 
presentation these were:

(a) Be able to set up member LSPs (and data plane LSPs -- server 
connections) prior to creation of VCG (Virtual Concatenation Group).
(b) "Member" LSPs (data plane and control plane) can exist 
after a VCG 
using them has been removed.

For those interested in VCAT/LCAS what is your opinion on these 
additional requirements? This is a WG draft so polling of the list is 
required (right Adrian?). I'll clean up the language if there is a 
desire to add these to the current draft. Note that these 
requirements 
may break or require rework of the current "multiple 
co-signaled member 
sets" solution in the draft.

Regards

Greg B.

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237