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

From: "Aaron Daubman" <[email-masked]>
Date: Fri, 14 Dec 2007 10:33:30 -0500

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
- 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

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.

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?

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?

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.

Thank you,
     Aaron

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 14 Dec 2007 08:38:19 -0800

Hi Aaron, see comments below.

> - A member that was not previously part of a VCG may be hitlessly added to a VCG
Yes.
> VCG and added to another as demand dictates
Yes.
> '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.
> 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.
> 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.
> functionality which would allow a new member to be added to a VCG - am
--> GMPLS can set up connections. LCAS is used to add them to a group.
> 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.

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

---

From: "Trevor Wilson" <[email-masked]>
Date: Fri, 14 Dec 2007 17:05:47 -0000

Aaron,

Please see my responses in-line below; annotated by [TW on/TW off]

Regards,

Trevor

Trevor Wilson
Nortel Networks (UK)
Tel:    +44 2890 363701
ESN:  751 3701
E-mail:   [email-masked]

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
message.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Aaron Daubman
Sent: 14 December 2007 15:34
To: [email-masked]
Subject: Question on draft-ietf-ccamp-gmpls-vcat-lcas and VCG Member
Sharing

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
[TW on]
Correct
[TW off]
- A member of another VCG (presumably IDLE) may be removed from that VCG
and added to another as demand dictates
[TW on]
Correct
[TW off]
- 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
[TW on]
Hmmm....
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.
[TW off]

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.
[TW on]
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.
[TW off]

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?
[TW on]
Allocation of a member to a VCG is a management function and not part pf
the LCAS protocol.
[TW off]

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].
"""
[TW on]
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.
[TW on]

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?
[TW on]
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
command.
[TW off]

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.
[TW on]
Correct]
TW off]

Thank you,
     Aaron

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 14 Dec 2007 17:07:50 +0100

Hello Aaron,

> - 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.

> 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.

> '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.

> 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.

> 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).

>    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.

> functionality which would allow a new member to be added to a VCG - am

[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.

> 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...