adrian -
independently of LCAS or not LCAS, the question of grouping VCs (that can be diversely routed) and that belong to a given a VCG (VC group) is an open point since now more than four years -
from this the key question is indeed whether the Session object is enough or not however the question should not be answered as "can it do the job" because potentially it can (example among other using the Extended Tunnel ID) but positioning this as follows is there 1) requirement that would not be met and interference 2) implementation and/or usage practices of the Session object sub-fields if such approach would be used and 3) what would be required from this object in order to deliver this functionality and evolution (it would be really harmful to select that solution and mandate at some point in time modification of the Session object processing to continue supporting functional needs)
"Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
06/15/2005 13:22
Please respond to "Adrian Farrel"
To: "Stephen Shew" <sdshew@nortel.com>, "ccamp" <ccamp@ops.ietf.org>
cc:
bcc:
Subject: Re: LCAS and GMPLS
Thanks Stephen,
Helpful input.
So if I read you right, GMPLS does not need to be aware of or help with
LCAS signaling.
This means that we do not need to worry about mechanisms for removing an
LSP without disrupting the service, because LCAS will be used to negotiate
the correct behavior at the end points before the LSP teardown is
triggered.
We still have the question about deciding whether LCAS is in use at all.
But I assume that there are already mechanisms for handling this in the
absence of GMPLS signaling (for example, in manually provisioned
connections) so that extensions to GMPLS are also not required.
I *think* this means that the LCAS/VCAT requirements on GMPLS collapse to
a way of identifying that a set of LSPs apply to a single VCAT group. As
you point out, grouping of LSPs are needed for a variety of reasons when
providing a service. Nothing special about VCAT here as far as I can tell
(but it would be good to confirm that).
All that remains is to pick a way of associating the LSPs. Will Session
do, or do we need to use the Association object?
Cheers,
Adrian
----- Original Message -----
From: "Stephen Shew" <sdshew@nortel.com>
To: "ccamp" <ccamp@ops.ietf.org>
Sent: Tuesday, June 14, 2005 10:10 PM
Subject: RE: LCAS and GMPLS
> In considering the use of LCAS, it is important to note that there are
> separate requirements here:
> 1. Having multiple LSPs participate in a single service. This is not
just
> limited to virtual concatenation but is also useful for 1:1 and other
> restoration mechanisms.
>
> 2. If LSPs can be added/removed from a common service after they have
been
> set up.
>
> 3. What effects LSP addition/removal are allowed to have on the common
> service.
>
> Putting these together, one could envision a requirement to offer a
service
> whose bandwidth requirements are met with a service in a transport
network
> that uses multiple LSPs for bandwidth efficiency. Further this service
> allows changes to be signalled and the bandwidth change is to be
> non-disruptive.
>
> Mechanisms to accomplish such a service could consist of VCAT and LCAS.
> Note that LCAS has its own "in-band" signalling. I think that the
service
> associated with the VCAT adaptation is the one that should be LCAS
aware,
> not the individual LSPs.
>
> Stephen
>
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> > Sent: Tuesday, June 14, 2005 14:48
> > To: Greg Bernstein <gregbern; Diego Caviglia
> > Cc: yhwkim; ccamp
> > Subject: Re: LCAS and GMPLS
> >
> <snip>
>
> > Nevertheless, before completing on the solutions discussion,
> > we still have to sort out the issues above. I am most
> > concerned about the "layering" issue. That is:
> > a) Is the LCAS component on the egress started by management,
> > by a trigger in some communication between LCAS components,
> > or by a trigger in GMPLS signaling?
> > b) Do the LCAS components converse through GMPLS signaling
> > or by other (existing?) means?
> >
> > > [dc] My initial idea was to use Call_ID to identify the LSP that are
> > part of the
> > > same VCAT/LCAS set and a bit in the profile filed to inform
> > the other
> > and
> > > that LCAS protcol has bo enabled.
> >
> > Understood. I think we have moved on a little from that
> > suggestion. Presumably you will not be unhappy with any
> > solution that is functional and not over-complex.
> >
> > I would suggest that Greg and Diego start an I-D. Call it
> > something like "Applicability Statement for Operating LCAS
> > and VCAT with GMPLS LSPs".
> > Include:
> > - Simple overview of VCAT and LCAS (no more than a page, please)
> > - Simple statement of how LSPs fit into the picture (about
> > half a page)
> > - Statement of the requirements on GMPLS signaling (about a page)
> > - Mechanisms and procedures (two or three pages)
> >
> > It may be that we need to define a new bit somewhere in which
> > case we will drop "Applicability Statement for" from the name
> > of the I-D.
> >
> > I would be very happy to discuss the solutions component with
> > you before publication so that we avoid thrashing.
> >
> >
> > Anyone who is interested in this topic should contact Diego
> > and Greg to offer help.
>