Subject: Re: LCAS/VCAT

From: Dan Li <[email-masked]>
Date: Mon, 04 Dec 2006 16:21:13 +0800

Hi,

I am interested in this work and think it's a useful functionality, but also have some questions on this draft:
1) In section 3.2, four scenarios have been described. Is there any requirement for the VCAT/LCAS capabilities for each scenario? or there is no such relationship between the scenarios and the VCAT/LCAS capabilities?
2) In section 4.2, for diversely routed VCG, what I understand is separately setup a set of LSPs which have same Ingress and Egress nodes, and associate these LSPs as a VCG at both Ingress and Egress nodes.  Could you elaborate how to manage/use the VCG? i.e. how to use the VCG to support the required service? I think at both ends of the VCG, the same signal adaptation should be required.

Thanks,

Dan

----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, November 30, 2006 7:56 PM
Subject: LCAS/VCAT

> Hi,
> 
> In San Diego Richard presented the current status of 
> draft-ietf-ccamp-gmpls-vcat-lcas-01.txt and suggested that the work is 
> nearing completion.
> 
> A quick show of hands indicated that very few had read the draft. This may 
> be because it is a very narrow niche that only a few are interested in 
> (i.e., all of the key people have read it), or may be because more people 
> need to have a look.
> 
> If you are interested in this work, could you please find some time 
> relatively soon to have a look at the draft and send your comments to the 
> list.
> 
> If you have or are planning an implementation could you drop me a private 
> (confidential!) email.
> 
> Thanks,
> Adrian 
> 
> 
> 
>

---

From: "Evelyne Roch" <[email-masked]>
Date: Mon, 11 Dec 2006 09:47:56 -0500

I read the draft and have the following comments:

1- The draft is missing support for creation and deletion of VCG with
diversely routed signals without LCAS. This is because the procedure
that is used to setup the components does not provide information about
the VCAT layer, i.e. it is missing the total number of components that
are part of the same VCG. In a liaison from ITU-T SG15, Q14/15
https://datatracker.ietf.org/documents/LIAISON/file394.doc, the 2nd
figure of Attachment 2 shows a multi-layer setup of an Ethernet call
over VCAT/LCAS. Although the Ethernet layer is not relevant to the
draft, it should be noted that a portion of the diagram includes an
Aggregate NCC (Network Call Controller) that provides the missing
functionality in the draft to provide the number of components that form
the VCG. This is based on G.8080, in which the VCAT layer has its own
controller. The functions performed by the Aggregate NCC are required
whether or not LCAS is available. They allow both ends of the VCG to
know the overall status of the VCG and the number of components it
contains. It should also be noted that the call and connection states
for each constituent must be kept separately from the state of the VCAT
call.

2- The draft is missing support for the creation of the various
components in a separate phase than the creation of the VCAT group. In
general, it should be possible to create, for example, several VC-4
connections and to add them to a VCG at a later point to create, for
example, a VC-4-4v. This can only be achieved if an Aggregate NCC
exists.

3- I would prefer to use the call ID to correlate the diversely routed
signals instead of the Association Object. In my opinion, the call id is
a better choice because it is better aligned with the ASON architecture
(G.8080).

Regards,
Evelyne Roch
Metro Ethernet Networks, Nortel
Phone: +1 613 763 6492 (esn 393-6492)
e-mail: [email-masked]  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Thursday, November 30, 2006 6:57 AM
To: [email-masked]
Subject: LCAS/VCAT

Hi,

A quick show of hands indicated that very few had read the draft. This
may be because it is a very narrow niche that only a few are interested
in (i.e., all of the key people have read it), or may be because more
people need to have a look.

If you are interested in this work, could you please find some time
relatively soon to have a look at the draft and send your comments to
the list.

If you have or are planning an implementation could you drop me a
private
(confidential!) email.

Thanks,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 14 Dec 2006 16:46:01 -0000

Hi Dan,

> I am interested in this work and think it's a useful functionality,
> but also have some questions on this draft:
>
> 1) In section 3.2, four scenarios have been described. Is
> there any requirement for the VCAT/LCAS capabilities
> for each scenario? or there is no such relationship between
> the scenarios and the VCAT/LCAS capabilities?

I think that is a reasonable question for investigation and maybe for
documentation.

But I note that the authors are stating that all four scenarios SHOULD be
supported, so I don't suppose it will make much difference if we assign
smaller requirements to the different scenarios as we will still need to
satisfy all of the requirements.

So, if there is an easy way for the authors to show which requirements
belong to which scenarios, that would be helpful, but I don't think such a
change is essential for the document to progress.

> 2) In section 4.2, for diversely routed VCG, what I understand
> is separately setup a set of LSPs which have same Ingress and
> Egress nodes, and associate these LSPs as a VCG at both
> Ingress and Egress nodes.  Could you elaborate how to
> manage/use the VCG? i.e. how to use the VCG to support the
> required service? I think at both ends of the VCG, the same
> signal adaptation should be required.

I think that the coordination of VCG members is largely outside the scope of
GMPLS (which is really a set of protocols). GMPLS does not deal with how
many LSPs are needed, and how to map the service to the LSPs. GMPLS does
care about how to setup the LSPs, and may be used to pass information for
coordinating and using those LSPs.

One mechanism that may be required is a way to exchange the interface and
adaptation capabilities, and the VCAT/LCAS potential of the interfaces on
the end-points of the LSPs. This would ensure (for example) that LSPs in a
single VCG were all terminated on interfaces that could allow the group
members to really be concatenated. Whether this is achieved through routing,
connection (i.e. LSP) signaling, or call signaling would be up for
discussion.

As currently expressed, this function is out of the scope of the current
I-D. It could be brought into scope (so that we have one I-D for the whole
package) or we could recognise that in many cases this function is not
needed (because of the topology of the network, the capabilities of the
hardware, and the pre-existing configuration tools) and let the main
signaling piece go forward, with the other elements added as a secondary I-D
if and when needed. We should certainly have some discussion on this (i.e.
when to do the work).

Cheers,
Adrian