Re: LCAS/VCAT

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

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