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

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

Richard,
 
The ASON architecture is defined in ITU-T Recommendation G.8080,
available free of charge, at the following URL:
http://www.itu.int/rec/T-REC-G.8080/en
 
Evelyne

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Richard Rabbat
Sent: Thursday, December 10, 2009 11:18 PM
To: Roch, Evelyne (CAR:Q840)
Cc: Greg Bernstein; CCAMP
Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08


Evelyne,
which specific rfc's are you concerned the draft is not compliant with?
Richard.


On Thu, Dec 10, 2009 at 11:22 AM, Evelyne Roch <[e-mail]> wrote:


	Greg,
	 
	The dependency is problematic in networks that follow the ASON
architecture because of the administrative boundaries. I would like to
see implementations that are compliant with this draft and the ASON
architecture. 
	 
	Evelyne

________________________________

	
	From: Greg Bernstein [mailto:[e-mail]] 
	
	Sent: Thursday, December 10, 2009 2:10 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, why is this dependency problematic? What are you
trying to do and what it the context?
	
	Greg
	
	Evelyne Roch wrote: 

		Greg, 
		 
		There is a problem in the architecture because the
CALL_ATTRIBUTES is carrying group info in the member call, creating a
dependency on the members to achieve VCAT signaling. That dependency is
problematic in a network with administrative boundaries.
		 
		Evelyne

________________________________

		From: Greg Bernstein
[mailto:[e-mail]] 
		Sent: Thursday, December 10, 2009 1:29 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, version 04 published in February of 2008
contained a "Call_Data_Object", with a TLV containing exactly the
information and utilizing the same procedures that we are now using with
the CALL_ATTRIBUTES object. 
		It was recommended by the WG chairs to use the
CALL_ATTRIBUTES object as defined in the MLN-Extensions work rather than
defining another "Call_data_object". None of of the procedures were
changed from 04. 
		Is there a problem with functionality? We worked very
hard to find a technique utilizing existing mechanisms to give some
support forthe member sharing scenario. We do not preclude other
techniques being used in the future.
		
		Greg
		
		Evelyne Roch wrote: 

			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 (510)
573-2237
			
			  


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


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

	_______________________________________________
	CCAMP mailing list
	[e-mail]
	https://www.ietf.org/mailman/listinfo/ccamp