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

[Greg Bernstein <gregb@grotto-networking.com>]

Hi Aaron, see comments below.

Aaron Daubman wrote:
> Greetings,
>
> Apologies in advance if it is inappropriate to pose such questions here...
>
> 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
>   
Yes.
> - A member of another VCG (presumably IDLE) may be removed from that
> VCG and added to another as demand dictates
>   
Yes.
> - 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
>   
No. The pool is of server layer connections between the same 
"endpoints", that could be put into one VCG or another.
> If the above is (basically) correct, what functionality would carry this out?
>
> 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.
>   
--> GID == Group IDentification, a pseudo random bit sequence that is 
used to identify one LCAS VCAT group from another and transmitted in the 
LCAS control packet from source to sink. This "control packet" is sent 
in overhead bytes/bits that accompany the server layer signal. It is the 
source LCAS entities responsibility to set this information not GMPLS 
signaling. After successfully establishing the lower layer connection 
via GMPLS, the internal LCAS entity at the source should be notified so 
that it can set its value. How this would be done is out of scope of the 
draft and an internal matter.
> 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?
>   
--> Either the NMS(?) software or control plane software supporting 
GMPLS would need to talk to the LCAS entity.
> 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].
> """
>
> 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?
>   
--> GMPLS can set up connections. LCAS is used to add them to a group.
> 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.
>   
--> Yes. A bit of a misunderstanding.  As you say you'd first need the 
LCAS entity to set the GID (so we know this connection should be part of 
the group) and when that's successful we should be in the IDLE state and 
from their we can issue the ADD message. The key is that LCAS can't set 
up a new connection only put an existing connection into use (we use 
GMPLS to set up the connection).
> Any clarification would be much appreciated.
>   
Hope this helps.
Greg B.
> Thank you,
>      Aaron
>
>
>   

--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237