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

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

This liaison was referring to version 04, before the introduction of
CALL_ATTRIBUTES in the draft, exactly where the problem is.
 
In the laison 429, the ITU-T agrees to one call per VCG. That is the
VCAT call (not addressed in the draft right now).
 
As far as member calls, members could be in same or different calls
based on application (for diverse routing -> could be same call, for
protection/restoration -> could be different calls). That is the member
call used in the draft. 
 
The problem is that CALL_ATTRIBUTES is carried in member call signaling
when it pertains to the VCG, i.e. VCAT call. 
 
Evelyne
 
 
 
 

________________________________

From: Greg Bernstein [mailto:[e-mail]] 
Sent: Thursday, December 10, 2009 11:16 AM
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, I'll add some text to the requirements section to clarify
"common pool" per your request.
The "call concept" usage and "member sharing scenario" have been
previously discussed, liaised, and resolved with ITU-T. 

https://datatracker.ietf.org/liaison/415/

It includes:
ITU: "Per Question 5:  We understand that this draft is only addressing
the
constituent server layer call; i.e., not the ASON multilayer call
supporting call construct. However, we suggest that you do not preclude
extensions to use a call in the VCAT layer.

CCAMP response: As noted above, this is not precluded. We look forward
to
future communication from you as you progress this work."

Q14 later responded saying they were satisfied with the one call
construct:
https://datatracker.ietf.org/liaison/429/
Greg

Evelyne Roch wrote: 

	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]
	
	  


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