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

[Greg Bernstein <[e-mail]>]

Hi Evelyne see comments below.

Greg

Evelyne Roch wrote:
> -- snip --
>
> I would make a stronger statement and say that the VCG is an association
> between VCAT endpoints to support VCAT services and the VCG is a call:
>   
--> The way we are trying to use the existing GMPLS call mechanisms, I'm 
not sure we can say that the "VCG is a call"
from a GMPLS point of view.
A VCG is an association between VCAT endpoints.
> - There is an association between the VCAT endpoints and that is a VCAT
> call.
>   
---> I'm not sure that we have calls of calls in GMPLS. At the time this 
was written this wasn't deemed desirable.
> - There is also an association between the member endpoints and that is
> the member call. 
>   
---> This is true.
> I have big problems with section 4.2.1 bullet 4 stating that the VCG
> identifier can be used to identify a particular VCG separately from the
> call ID so that call members can be reused.
>   
---> These are what you call  "member call IDs".
> Based on section 4.2.1 bullet 4 (and text 4.4), the call that is
> signaled in the draft is NOT a VCAT call but rather a member call (which
> may contain multiple members). The members are "added/removed" from the
> VCG using the Notify message. But the Notify message is ALSO used to
> signal the VCG as it contains the number of members, whether LCAS is
> required and the VCG ID. That is why I state that this not provide a
> clean separation of VCAT control from member control. 
>   
---> Maybe Lou or other GMPLS signaling experts have a strong opinion on 
this issue. At the time of writing
we wanted a solution that met the requirements and made use of 
existing/emerging GMPLS mechanisms. I also recall that
no alternative implementations were offered. My co-authors and I were 
most interested in providing GMPLS support
for VCAT/LCAS and used mechanisms as suggested by the working group and 
working group chairs.
> Looking at it from a management's perspective, how does one manage its
> VCAT service? Normally, one would expect a VCAT service to be associated
> with a VCAT call and be identified by its call id. In the draft, that is
> not possible as there is no VCAT call ID. The only way to identify the
> call is by the combination of the VCG ID and session.
>   
--->  We made sure the draft supported the "member sharing case" but as 
you point out this can require some management intervention, i.e.,
management would initiate changes to VCG membership, rather that a 
higher "VCAT level" signaling message to initiate the change.
One the desired VCG membership change is known we proved automated 
signaling support for that.
For most member sharing services, this seemed adequate, since a simpler 
to provide "member sharing" like functionality with
signaling is just to tear down are re-setup connections. So it was hard 
to convince folks to allow us to do "calls of calls" specific to this 
applicatio

> Evelyne
>
>
>
> -----Original Message-----
> From: BRUNGARD, DEBORAH A (ATTLABS) [mailto:[e-mail]] 
> Sent: Thursday, December 03, 2009 4:50 PM
> To: Roch, Evelyne (CAR:Q840)
> Cc: CCAMP
> Subject: RE: [CCAMP] Working group
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Hi Evelyne,
>
> There may be confusion between the previous GMPLS support of VCAT and
> this document version. This document added procedures to support this
> independence (section 4.2-4.5) - this is why the VCG call layer was
> added. Section 4.5 provides procedures for different scenarios of
> independence with the VCAT call and the LSPs. As Greg noted, there was
> an effort to respond on the mail exchange and include clarifications in
> the document (e.g. section 4.5). Can you describe your remaining concern
> wrt to the draft - clarifications for section 4.2/missing scenario in
> 4.5/etc.?
>
> Deborah
> (chair hat on)
>
>
> -----Original Message-----
> From: Evelyne Roch [mailto:[e-mail]]
> Sent: Thursday, December 03, 2009 3:19 PM
> To: BRUNGARD, DEBORAH A (ATTLABS)
> Subject: RE: [CCAMP] Working group
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Deborah,
>
> In the link you included referring to the correspondence sent to OIF,
> the following requirements are worth discussing further as the draft
> doesn't address them adequately:
>
> - Clean separation of VCG (VCAT Group) control from the control of VCG
> members
> - Supports the ability to create and modify the VCG independent of its
> members 
>
> To me, these requirements imply that the call control for VCAT group and
> VCG members is independent. In other words, a VCAT call exists
> independently from a VCG member call. This method was mentioned in a
> previous message
> http://www.ietf.org/mail-archive/web/ccamp/current/msg09711.html. 
>
> Evelyne
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of BRUNGARD, DEBORAH A (ATTLABS)
> Sent: Thursday, December 03, 2009 1:47 PM
> To: Greg Bernstein; Sadler, Jonathan B.
> Cc: CCAMP
> Subject: Re: [CCAMP] Working group
> lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Hi all,
>
> As Greg notes, this draft has been stable for a long time, it has a
> dependency on the MLN-ext work and it was waiting for it to complete.
>
> We did consider (and respond to) OIF on their requirements, including:
> https://ops.ietf.org/lists/ccamp/ccamp.2008/msg00741.html
>
>
> I'm not sure, myself, Jonathan (and Evelyne) on your concerns, I'll send
> a separate mail (with my chair hat off) to try to understand.
>
> Deborah 
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Greg Bernstein
> Sent: Wednesday, December 02, 2009 7:49 PM
> To: Sadler, Jonathan B.
> Cc: CCAMP; [e-mail]
> Subject: Re: [CCAMP] Working group last
> call:draft-ietf-ccamp-gmpls-vcat-lcas-08
>
> Hi folks, this draft has been very stable for a very long time.
> The last major revision was to put in some advanced features requested
> by Jonathan and Evelyn. Adrian and I worked out a solution to providing
> those features over two years ago. I don't work on MPLS-TP and didn't
> know that this was a topic covered by that. Is it?
> I haven't seen any specific textual changes requested just vague
> assertions that this draft cannot do everything and anything somebody
> could think of.
> VCAT/LCAS is a fairly general technique applying to PDH, SDH, and G.709
> technologies. This draft was intended to cover those and was approved as
>
> a working group document over four years ago. Unless there is something
> specifically technically wrong I'm not sure that we need to start all
> over again with this.
>
> Regards
>
> GB
>
> Sadler, Jonathan B. wrote:
>   
>> Hi all,
>>
>> As mentioned in the CCAMP working group meeting, this draft has a
>>     
> dependency on a control plane operating in the STS-n/VC-n environment,
> and that control plane carrying the CALL information used for
> configuring the VCAT group.
>   
>> Given carrier requirements to not extend a carrier's control plane to
>>     
> the customer premise (e.g. draft-jenkins-mpls-tp-bt-requirements-00, and
> the carrier requirements document liaised by the OIF), this dependency
> is not acceptable.  Instead, a mechanism needs to exist where the STS-n
> connections can be named and signaled for incorporation into a VCAT
> group independent of the out-of-band network or process used to setup
> the STS-n/VC-n connections.
>   
>> Hence, further work on this draft is needed before it can progress.
>>
>> Jonathan Sadler
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>>     
> Of Lou Berger
>   
>> Sent: Friday, November 20, 2009 2:25 PM
>> To: CCAMP; [e-mail]
>> Subject: [CCAMP] Working group last call:
>>     
> draft-ietf-ccamp-gmpls-vcat-lcas-08
>   
>> As discussed in last week's session, it's time for the working group
>>     
> to 
>   
>> last call draft-ietf-ccamp-gmpls-vcat-lcas-08.txt
>>
>> http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-vcat-lcas
>>
>> Please send your comments to the list or the authors&chairs before the
>>     
>
>   
>> last call closes in two weeks, on December 4, 2009.
>>
>> Thank you,
>> Lou (and Deborah)
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>   
>>     
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking [phone]
>
>
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>   

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