Subject: VCAT/LCAS

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 22 Dec 2005 00:27:09 -0000

Hi,

In Vancouver there was clear support in the room that a group wanted to
work on this topic.

draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October and
provides a fair summary of the problem space in sections 1 and 2.

The draft fades out in section 3 "Possible Extensions to GMPLS to support
additional VCAT/LCAS scenarios" as it starts to identify the specific
requirements to extend GMPLS protocols.

I suggest that the authors should:
- gather a group of interest parties to work on this
- keep in mind that protocol extensions are done in support of
  implementations (that is, not for completeness, but because someone
  is building product)
- beef up section 3 to list the requirements
- write a new section for the solutions

I think that we will be able to adopt this work as a WG draft, but we
should not do that until we have seen a first stab at the protocol
extensions.

If the authors could let us know their progress and plans, that would be
great.

Thanks,
Adrian

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 22 Dec 2005 06:57:04 -0800 (PST)

I support this work.
   
  Igor

Adrian Farrel <[email-masked]> wrote:
  Hi,

Thanks,
Adrian

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: "Vishal Sharma" <[email-masked]>
Date: Thu, 22 Dec 2005 07:50:05 -0800

Hi Adrian,

I've had occasion to look at this work, and think it is a useful
work item, and support it.

-Vishal 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Adrian Farrel
Sent: Wednesday, December 21, 2005 4:27 PM
To: [email-masked]
Subject: VCAT/LCAS

Hi,

In Vancouver there was clear support in the room that a group
wanted to work on this topic.

draft-bernstein-ccamp-gmpls-vcat-lcas-01 was submitted in October
and provides a fair summary of the problem space in sections 1
and 2.

The draft fades out in section 3 "Possible Extensions to GMPLS to
support additional VCAT/LCAS scenarios" as it starts to identify
the specific requirements to extend GMPLS protocols.

  implementations (that is, not for completeness, but because
someone

I think that we will be able to adopt this work as a WG draft,
but we should not do that until we have seen a first stab at the
protocol extensions.

If the authors could let us know their progress and plans, that
would be great.

Thanks,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 22 Dec 2005 17:24:32 +0100

Hello Adrian,

> In Vancouver there was clear support in the room that a group wanted to

Yes, and I still support it.

> - gather a group of interest parties to work on this

A small group already started, maybe others would like to join.

> - write a new section for the solutions

OK, thansk for the advise.

> If the authors could let us know their progress and plans, that would be

After the Holidays we know more.

Cheers, Huub.

-- 
================================================================
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 22 Dec 2005 10:26:05 -0800

Hi Adrian, we've gathered a group of folks together that includes the 
original authors and anyone else who has so far expressed interest. 
Anyone else who is interested just send an e-mail to any of the authors 
to get involved.

The  plan is roughly as follows:
(a) Survey of current GMPLS WG drafts that have may have mechanisms 
usable for VCAT/LCAS operation. List mechanisms (generally objects and 
such added to signaling or routing).  Adrian your supplemental website 
with the up to date listing of CCAMP is either broken or the link from 
the IETF website is broken :-<  Can you fix or send the right link?
(b) Analysis of these mechanisms for applicability to base VCAT/LCAS 
scenarios.
(c) Write up additional enabled applications with walk throughs for each 
mechanism adopted, e.g., make before you break...

However, we've currently been dealing with the note from the last IETF 
meeting that claimed that this effort was "strictly for the diverse 
path" case.  One of the basic VCAT/LCAS scenarios is dynamic bandwidth 
adjustment (whether co-routed or not).  GMPLS VCAT connection bandwidth 
modification (even in co-routed) seems different from the MPLS case in 
the sense we'd need to either add or delete member connections (not just 
modify connection bandwidth parameters at each node). We're not sure  
that this important case can be currently handled in the co-routed case 
without modification. So we've also added this analysis to our list of 
ToDo's (volunteers for a complete write up on this?)

That said look for activity again after the holidays!

Greg

--------------------------------------------------
Greg Bernstein, Grotto Networking

---

From: Dan Li <[email-masked]>
Date: Fri, 23 Dec 2005 16:08:41 +0800

I support this work.

When we consider the requirements in section 3, do we also need to consider the scenario which the Ethernet service is supported by Xc or by the combination of Xc and Xv?

Another scenario is if we have the optional Xc and Xv flexible adapatations at both ends, does the signaling need to support the selection?

 Dan Li

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 23 Dec 2005 15:39:00 +0100

Hello Dan,

You wrote:

> When we consider the requirements in section 3, do we also need to
> consider the scenario which the Ethernet service is supported by Xc
> or by the combination of Xc and Xv?

Contiguous concatenation Xc and virtual concatenation Xv
cannot be combined (there is only one exception: an STS-3c can
be virual concatenated)

> Another scenario is if we have the optional Xc and Xv flexible
> adapatations at both ends, does the signaling need to support the
> selection?

A selection is certainly needed to match the transport capability
with the required bandwidth. A selection can be:
- a single VC-n
- a single VC-n-Xc
- a VC-n-Xv which provides additional flexibility if LCAS
    is supported.

Cheers, Huub.

---

From: [email-masked]
Date: Fri, 23 Dec 2005 15:51:25 +0100

adrian -

would it be possible to take into account compatibility with RFC3946 when 
addressing the following point you mentioned here below 

"I think that we will be able to adopt this work as a WG draft, but we
should not do that until we have seen a first stab at the protocol
extensions."

much thanks,
- dimitri.

"Adrian Farrel" <[email-masked]>
Sent by: [email-masked]
22/12/2005 01:27
Please respond to "Adrian Farrel"
 
        To:     <[email-masked]>
        cc: 
        Subject:        VCAT/LCAS

Hi,

Thanks,
Adrian

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 23 Dec 2005 16:14:34 +0100

Hello Dimitri,

You suggested:

> would it be possible to take into account compatibility with RFC3946 
> when addressing the following point you mentioned here below
> 

Thanks for your help, I already had this RFC on the list of
RFCs to check.

Cheers, Huub.