Please respond to "Adrian Farrel" <adrian@olddog.co.uk>
Sent by: owner-ccamp@ops.ietf.org
To: "Greg Bernstein <gregbern", "Diego Caviglia" <Diego.Caviglia@marconi.com>
cc: "yhwkim" <yhwkim@etri.re.kr>, "ccamp" <ccamp@ops.ietf.org>
Subject: Re: LCAS and GMPLS
Hi Diego, Greg,
[CUT]
> Why? (a) To more be able to full "extract
> bandwidth from a mesh" via inverse multiplexing. (b)
> To provide for graceful degradation in the case of
> failure, e.g., one of the disjointly routed components
> fails.
> [dc] Agreed
> --> I hear now that Call_ID isn't appropriate (thanks
> Jonathan and Hi!),
> [dc] This is not clear to me, so what is supposed to be the purpose of
the
> Call_ID? Can someone clarify this better?
I, too, think that the Call_ID object (RFC3474) is not appropriate for
this task.
RFC3474 is informational. It documents code point assignments for the
protocol documented by the ITU-T in Recommendation G.7713.2 for use at the
UNI and E-NNI reference points.
If you wanted to use that code point for coordinating VCAT LSPs then you
could, but you would need to have this conversation in the context of the
ITU-T (probably Study Group 15) and not here. A consequence of the use of
the Call_ID object would be that you would:
a) possibly need to implement the ITU-T's UNI before you could exercise
this function
[dc] Actually you can use Call_Id also for SPC circuits, usage of Call_Id is not restricted to to UNI.
b) need to disambiguate the Call function in G.7713.2 from the new VCAT
function.
[dc] My view of the Call concept is something that bundle a set of connections (LSPs) into a service. This seems to fit to the VCAT/LCAS scenario.
On the other hand, a distinct mechanism would allow more easy
interpretation and applicaiton in a GMPLS context.
[dc] Ok I see your point, and even if for me the Call_ID is a good choice for this job, I don't want to start an holy war for this.
> but that there is an Association object (thanks Adrian) of
> some sort that might be appropriate.
> [dc] hmmm I need some time to read the RFC 2746 at a first glance seems
> that the RFC address different problems.
Whoah Diego, I don't mean the Session_Association object of RFC 2746. That
mechanism is applicable to RSVP over tunnels and is, I think, not relevant
here.
[dc] ah ah ah ah this is very funny I've looked to the IANA and I've find that object.
I am refering to the Association object in section 16 of
draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt
[dc] Ok this sounds more in the scope of the discussion ;-)
In order to solve the problem at hand (which seems quite simply to be that
we wish to be able to associate two or more LSPs that have the same
ingress and egress) we need first to answer the question: why is it not
enough to rely on the fact that the LSPs all come from the same Session?
In draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt there is a
requirement to associate a subset of the LSPs that support a service by
coming from the same Session. This is so that a service may be supported
by more than one working LSP, and each working LSP may be protected by one
or more backup LSPs. The association is between a working LSP and its
backups.
But, for your requirement, it may be enough simply to use the Session to
identify all of the LSPs in the same VCAT group. if it is not enough, then
the Association object gives you the function you need.
> (2) LCAS can be used to add disjointly routed
> components to a group in a hitless fashion after it
> has been set up via GMPLS. Initiation of the LCAS
> "add" procedure requires some type of management
> command.
> --> I'm not sure if I have a requirement here since I
> could default my end system behavior to automatically
> issue the "add" LCAS commands from both ends after the
> GMPLS procedure completes. Diego or Jonathan, are
> their other situations where this wouldn't be
> appropriate?
> [dc] Yes but how you know that you have to enable LCAS?
> The LSP could be part of a 'simple' VCAT.
I'm also not sure that there is a GMPLS requirement here.
How do you know to use LCAS in management-established LSPs? Or any other
type of connection? Seems like this is a generic LCAS propblem.
So, there MIGHT [RFC2119] be a requirement to signal in GMPLS that the
egress should enable LCAS.
[dc] Yes that was what I meant.
This is relatively easy to perform if we have to.
I would suggest using draft-ietf-mpls-rsvpte-attributes-05.txt.
[CUT]
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?
[dc] I would like to triger it via GMPLS signalling.
b) Do the LCAS components converse through GMPLS signaling
or by other (existing?) means?
[dc] Hmmm not sure that LCAS needs to be aware of the GMPLS.
> [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.
[dc] Yes you are right.
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.
[dc] Ok no problem for me. May I ask to Greg to be the editor of this? For sure his english is better than mine. I promise that next time we have to write a doc in Italian I'll be the editor ;-)
I would be very happy to discuss the solutions component with you before
publication so that we avoid thrashing.
[dc] Of course will be a pleasure, as usual, to discuss this with you.
Anyone who is interested in this topic should contact Diego and Greg to
offer help.
Thanks,
Adrian
> --- Adrian Farrel <adrian@olddog.co.uk> wrote:
>
> > Hi Greg,
> >
> > Let me come in a bit heavy here, please.
> >
> >
> > > Hi all, thanks for the update Diego and Adrian.
> > Where
> > > we stand seems to be:
> > > (1) We've got an agreed method using the Call_ID
> > to
> > > identify (VC-3/VC-4) component belonging to a VCAT
> > > group. In particular, the Call_ID along with
> > source
> > > and destination addresses uniquely identifies the
> > VCAT
> > > group in the network?
> >
> > No. We do not have agreement on this.
> > We have a vague statement of requirements that a
> > group of LSPs need to be
> > associated. Until we see the requirements fleshed
> > out and written up it
> > would be wrong to pick one solution. For example, we
> > have an Association
> > object that is part of mainstream GMPLS that could
> > be used for this
> > purpose.
> >
> > So, let's see the requirements written up, please.
> >
> > > (2) I can use GMPLS to setup/tear down one or more
> > > VCAT group components at a time. (we've had this
> > for a
> > > while).
> > > (3) Once we set up via GMPLS a new component
> > > (VC-3/VC-4) of a VCAT group we want LCAS to
> > hitlessly
> > > add the new component to the group.
> > > (4) To remove (hitlessly) the component from the
> > VCAT
> > > group we need LCAS to remove it before we
> > actually
> > > tear down the component connection via GMPLS.
> >
> > So it seems to me that you have decided that LCAS is
> > a GMPLS application.
> > That is, LCAS is an end-to-end protocol that
> > triggers the establishment of
> > LSPs by making requests to GMPLS.
> >
> > This sounds reasonable, but please write it up.
> >
> > > Now the thing that seems a bit tricky to me about
> > (3)
> > > and (4) is that LCAS does things unidirectionally,
> > in
> > > the sense of adding/removing components, (not in
> > the
> > > sense of a protocol which has a handshake
> > mechanism).
> > > All add or remove commands come from the source
> > end
> > > and since we generally setup/teardown
> > bi-directional
> > > connections that would leave us with a bit of
> > > coordination. Is this what you are thinking
> > Diego?
> > > LCAS experts chime in too :-)
> >
> > Nothing to stop you having unidirectional LSPs if
> > you need to support a
> > service that controls LSPs in a unidirectional way.
> >
> > Cheers,
> > Adrian
> >
> >
>
>
>
>
> __________________________________
> Discover Yahoo!
> Get on-the-go sports scores, stock quotes, news and more. Check it out!
> http://discover.yahoo.com/mobile.html
>
>
>
>
>
>
>
>
>