[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member Sharing
Please see my responses in-line below; annotated by [TW on/TW off]
Nortel Networks (UK)
Tel: +44 2890 363701
ESN: 751 3701
Confidentiality Notice: This message and any attachments may contain
information that is privileged and confidential. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, you are hereby
notified that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have reason to believe that
you are not the intended recipient or a person responsible for
delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
From: firstname.lastname@example.org [mailto:email@example.com] On
Behalf Of Aaron Daubman
Sent: 14 December 2007 15:34
Subject: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member
Apologies in advance if it is inappropriate to pose such questions
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
- A member of another VCG (presumably IDLE) may be removed from that VCG
and added to another as demand dictates
- 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
A VCG member, even in the IDLE state is still a member of ONE VCG. It
can of course be removed from that VCG and provisioned into another VCG.
This is outside the scope of the LCAS Recommendation G.7042.This
movement from one VCG to another VCG is a management action and does not
require the use of the LCAS protocol.
If the above is (basically) correct, what functionality would carry this
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.
All members of a VCG will have the same GID. If a member belongs to
another VCG it will have a different GID. Only active VCG member's GIDs
will be used at the source.
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?
Allocation of a member to a VCG is a management function and not part pf
the LCAS protocol.
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].
After a member is provisioned to the VCG it will be in the IDLE state;
thereafter it can be ADDed to the VCG active group by the ADD command.
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
No. You haven't missed anything. As stated previously in my reply:
inclusion of a member into a VCG is a management function initially put
into the IDLE state and thereafter ADDed to the active VCG by the ADD
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.
Any clarification would be much appreciated.