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

[Greg Bernstein <[e-mail]>]

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 [phone]
>
>   

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