Re: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing

[Huub van Helvoort <hhelvoort@chello.nl>]

Hello Aaron,

See my replies in-line [hvh]:

> I have been looking over draft-ietf-ccamp-gmpls-vcat-lcas-03, as well
> as G.707 and G.7042, and have not been able to reconcile how the
> member sharing functionality would be accomplished.
>
> Am I understanding this feature correctly:
> - A member that was not previously part of a VCG may be hitlessly added to a VCG

[hvh] an LSP only becomes member of a VCG if it is assigned to that
particalar VCG by the management system (usinf ASON/GMPLS).
When assigned it will have the IDLE state.

> - A member of another VCG (presumably IDLE) may be removed from that
> VCG and added to another as demand dictates

[hvh] actually this will involve two steps:
- remove (= unassign) the member from one VGG by mamnagement
- add (= assign) the member to (another) VCG by management
You are right in assuming that only IDLE members should be
removed, although the LCAS protocol is robust enough to
withstand removal of NORM/EOS?DNU members.

> - There could be a pool of provisioned but IDLE members of some
> 'shared' VCG that can be added to or removed from others as necessary

[hvh] right, if you mean that the path is provisioned

> If the above is (basically) correct, what functionality would carry this out?

[hvh] the management sytem, note that this has to be perfromed at both
ends (source AND sink) of the VCG. Note also that the (un-)asignment is
NOT supported by the LCAS protocol.

> I assume that one would have to modify the GID of such members on the
> fly... and LCAS doesn't seem to currently maintain this functionality.

[hvh] No, as soon as an LSP bcomes a member of a VCG the GID will be
inserted automatically by the termination function, it does not have
to be provisioned. Added members will always have the IDLE state.

> Would this be left up to the implementation of the NMS if it supports
> GMPLS, or are (portions) of these features being added to LCAS?

[hvh] as mentioned above (un-)assignemnt is initiated by mangement
the LCAS procedure does the hitless delete/add of a member (payload).

> In particular, I am wondering what signaling in G.7042 would allow the
> addition of a new member to an existing VCG as stated below:
> """
>    Following the addition of the new label to the LSP, LCAS may be used
>    in-band to add the new label into the existing VCAT group.  LCAS
>    signaling for this function is described in [ITU-T-G.7042].
> """

[hvh] this is the last step, the LCAS function takes care of the hitless
addition by synchronising source and sink.

> As far as I have been able to tell, LCAS currently can only modify
> pre-existing members of a VCG.  I have not been able to identify any
> functionality which would allow a new member to be added to a VCG - am
> I missing something?

[hvh] the assigning of an LSP to a VCG is management reponsability
it will then become member of that VCG. The addition/removal of a
member for active participation in the VCG is initiated by management
and finished by the LCAS protocol.

> Perhaps I am misunderstand LCAS' ADD functionality.  It is my
> understanding that an LCAS ADD does not actually add a new member to a
> VCG, but merely sets an IDLE member of a VCG to become active in the
> VCG (e.g. NORM/EOS). Regardless of whether a VCG member is IDLE or
> in-use, it will share the same GID as all other members of the VCG.

[hvh] your understanding is right.

> Any clarification would be much appreciated.

I hope I did, if you need more clarification you can find it
on the site below.

Cheers, Huub.

--
================================================================
                  http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...