Cheers Greg B. Huub van Helvoort wrote:
--> The solution that we (okay I'll take the blame) outlined in the draft assumes that we know ahead of time that we are going to do such a thing and we setup a "call" that can contain multiple VCGs and then can throw all the "pool LSPs" into that call to be shared amongst the different VCGs under control of a modified Notify message (we didn't furnish details, just sketched how this could be done if someone really wanted to do this...) Some folks find the notion of multiple VCGs per call somewhat objectionable...Hello Greg, You wrote:Hi CCAMPers, at the Vancouver meeting the status of the VCAT/LCAS draft was discussed and there seemed to be two possible additions to the requirements section of the draft. From the slide presentation these were:(a) Be able to set up member LSPs (and data plane LSPs -- server connections) prior to creation of VCG (Virtual Concatenation Group).If there are more such members would they have a relation with each other? e.g. a "pool" of member LSPs for a single VCG or for multiple VCGs that exist between the same end-points.
--> I don't know. I guess that they could be used for other things. In the member sharing case that we (okay I) outlined in the draft they could be either returned to the pool or torn down (i.e. the pool size could change).(b) “Member” LSPs (data plane and control plane) can exist after a VCG using them has been removed.Will they be returned to the "pool" (if the previous answer is yes).
For those interested in VCAT/LCAS what is your opinion on these additional requirements? This is a WG draft so polling of the list is required (right Adrian?). I'll clean up the language if there is a desire to add these to the current draft. Note that theserequirements may break or require rework of the current "multiple co-signaled member sets" solution in the draft.Cheers, Huub.
-- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237