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

[Greg Bernstein <[e-mail]>]

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]