RE: Moving forward with VCAT/LCAS...

["Stephen Shew" <sdshew@nortel.com>]

Greg, I support these requirements.  In transport architecture, layers
are separated and this allows a business separation of service.  The
relationship between the client layer (VCAT in this case) and server
layer should be policy driven.  That is, the setup/teardown of server
layer LSPs in response to client layer requests, should not be
automatically coded in a protocol/implementation, but be subject to a
policy decision.

An additional requirement that's similar to (a), would be to be able to
use an existing LSP in response to a VCAT setup.

Stephen

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Greg Bernstein
Sent: January 8, 2008 12:28
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