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

[Greg Bernstein <[e-mail]>]

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 [phone]
>>
>>   
>
> -- 
> ===================================================
> Dr Greg Bernstein, Grotto Networking [phone]
>
>   

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