Subject: Moving forward with VCAT/LCAS...

From: Greg Bernstein <[email-masked]>
Date: Tue, 08 Jan 2008 09:27:59 -0800

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 8 Jan 2008 14:23:17 -0500

Hi Greg,

As you might expect, I support adding these as requirements for the
VCAT/LCAS
work.

Cheers,

Lyndon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Bernstein
Sent: Tuesday, January 08, 2008 9:28 AM
To: [email-masked]
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.

Regards

Greg B.

---

From: "Diego Caviglia" <[email-masked]>
Date: Thu, 10 Jan 2008 10:28:24 +0100

Hi Greg,
        I think are good requirements and should be included on the ID may be not as mandatory requirements.

BR

Diego

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Greg Bernstein
> Sent: martedì 8 gennaio 2008 18.28
> To: [email-masked]

---

From: "Stephen Shew" <[email-masked]>
Date: Thu, 10 Jan 2008 10:04:55 -0500

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Bernstein
Sent: January 8, 2008 12:28
To: [email-masked]
Subject: Moving forward with VCAT/LCAS...

Regards

Greg B.

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 10 Jan 2008 17:56:12 +0100

Hello Greg,

You wrote:

> 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:
> 

If there are more such members would they have a relation with
each other? e.g. a "pool" of member LSPs for a single VCG or for
multiple VCGs that exist between the same end-points.

> (b) “Member” LSPs (data plane and control plane) can exist after a
> VCG using them has been removed.

Will they be returned to the "pool" (if the previous answer is yes).

> 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.

Cheers, Huub.

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 10 Jan 2008 09:21:30 -0800

Hi Huub, I think you hit the crux of the issue.  We (well I) outlined a 
possible solution to a particular "member sharing" scenario in the 
draft. Whether that is the right scenario and solution seems to be the 
discussion.  See below for more comments.

Cheers
Greg B.

> multiple VCGs that exist between the same end-points.
--> The solution that we (okay I'll take the blame) outlined in the 
draft assumes that we know ahead of time that we are going to do such a 
thing and we setup a "call" that can contain multiple VCGs and then can 
throw all the "pool LSPs" into that call to be shared amongst the 
different VCGs under control of a modified Notify message (we didn't 
furnish details, just sketched how this could be done if someone really 
wanted to do this...)  Some folks find the notion of multiple VCGs per 
call somewhat objectionable...
> Will they be returned to the "pool" (if the previous answer is yes).
--> I don't know.  I guess that they could be used for other things.  In 
the member sharing case that we (okay I) outlined in the draft they 
could be either returned to the pool or torn down (i.e. the pool size 
could change).

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 11 Jan 2008 02:33:39 -0000

Stephen,

In this architecture, can a connection exist outside a call and then be 
designated as a connection that fulfils the service identified by the call?

Thanks,
Adrian
----- Original Message ----- 
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 10, 2008 3:04 PM
Subject: RE: Moving forward with VCAT/LCAS...

Stephen

-----Original Message-----

Regards

Greg B.

---

From: "Stephen Shew" <[email-masked]>
Date: Thu, 17 Jan 2008 12:08:15 -0500

Sorry about the delay in responding, I don't check this list daily.

A connection can't exist outside of a call.  However, if you mean can a
server call (with associated connection) exist outside of a client (in
this case VCAT) call, the answer is yes.  The model I'm responding from
assumes that a VCAT call contains only one VCG, and that it has a
relationship with one or more server layer calls where those server
layer calls contain a connection or connections.  It's a more general
model for inverse mux. The server layer call could exist ahead of time,
and then be allocated to a client call.

The client could also disassociate itself from a server layer call and
it is an independent decision as to whether that server layer call then
releases its connection(s) and terminates.  If it stays up, it could be
associated with a different client call at a later time.

Stephen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: January 10, 2008 21:34
To: [email-masked]
Subject: Re: Moving forward with VCAT/LCAS...

Stephen,

In this architecture, can a connection exist outside a call and then be
designated as a connection that fulfils the service identified by the
call?

Thanks,
Adrian
----- Original Message -----
From: "Stephen Shew" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, January 10, 2008 3:04 PM
Subject: RE: Moving forward with VCAT/LCAS...

Stephen

-----Original Message-----

Regards

Greg B.