Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

["Evelyne Roch" <[e-mail]>]

Greg,
 
Normally, I would expect the requirements section to be clear enough
that it helps define a proper solution mechanism and clearly sets the
scope, not the other way around (i.e. you need to read the mechanism to
understand how the requirements should be interpreted).
 
My main concern is how the "call concept" is being used with the member
sharing scenario, as I mentioned earlier in this thread. The calls (in
the draft) are really member calls, not VCAT group calls. But the call
attributes contain VCAT group information. I don't want the  member call
to attribute carry call information for the entire VCAT group.
 
Evelyne

________________________________

From: Greg Bernstein [mailto:[e-mail]] 
Sent: Wednesday, December 09, 2009 5:34 PM
To: Roch, Evelyne (CAR:Q840)
Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08


Hi Evelyne, the common pool is a set of potential member signals that
have been set up using the mechanisms defined in the draft, particularly
the VCAT call procedures. The draft allows these to be "shared" amongst
different VCGs over time. Note that at any given point in time a member
signal can belong to only one VCG. Note that by the nature of VCAT that
these are signals that have the same source and destination. The
procedures section makes this fairly clear.

Greg



Evelyne Roch wrote: 

	Greg,
	 
	First, I think we need to further clarify the requirements as
I'm not sure all the readers will interpret the requirements the same
way. What exactly does it mean to be "in a common pool"?
	 
	Evelyne

________________________________

	From: Greg Bernstein [mailto:[e-mail]] 
	Sent: Tuesday, December 08, 2009 1:04 PM
	To: Roch, Evelyne (CAR:Q840)
	Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
	Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
	
	
	Hi Evelyne, the main focus on this work was to support VCGs with
diversely routed routed members. We were asked to include the member
sharing scenario and formulated a method to accommodate it without
significantly increasing the complexity of the messages involved.  It
seems to us that the solution included in this draft provides sufficient
functionality to meet the requirements in the document. Is there a
scenario you think is within the scope of the draft that is not
addressed?
	
	Greg
	
	Evelyne Roch wrote: 

		Greg, see below.
		
		  

			-----Original Message-----
			From: Greg Bernstein
[mailto:[e-mail]] 
			Sent: Friday, December 04, 2009 4:09 PM
			To: Roch, Evelyne (CAR:Q840)
			Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
			Subject: Re: [CCAMP] Working group
			    

		lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
		
		<snip>
		
		  

			I'm not sure that we have calls of calls in
GMPLS. At the time this
			was written this wasn't deemed desirable.
			    

		
		The model of calls being supported by calls is clearly
support by ASON,
		whether at the same layer (see G.8080 section 6.7) or
different layer
		(section 6.6). I find it highly desirable.
		
		<snip>
		
		Evelyne
		
		
		  


	-- 
	===================================================
	Dr Greg Bernstein, Grotto Networking [phone]
	
	  


-- 
===================================================
Dr Greg Bernstein, Grotto Networking [phone]