Re: LCAS and GMPLS

["Adrian Farrel" <adrian@olddog.co.uk>]

Dimitri,

Agreed.

A potential issue with the use of the Session object is that the
destination might be different. I don't know enough about VCAT to know if
this is possible. (Note, this is not simply a difference in incoming
interface/port on the egress node, but would be a difference in egress
node itself.)

This is why I would really like to get the requirements written down (in
an I-D) so that we can select a solution and move on.

Cheers,
Adrian
----- Original Message ----- 
From: <Dimitri.Papadimitriou@alcatel.be>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: "Stephen Shew" <sdshew@nortel.com>; "ccamp" <ccamp@ops.ietf.org>
Sent: Wednesday, June 15, 2005 1:33 PM
Subject: Re: LCAS and GMPLS


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