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

[Richard Rabbat <[e-mail]>]

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]<[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]<[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]<[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]<[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] <[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]
>
>
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>