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

["Evelyne Roch" <[e-mail]>]

According to RFC4974:
"In certain networking topologies, it may be advantageous to maintain
   associations between endpoints and key transit points to support an
   instance of a service.  Such associations are known as Calls."

In draft-ietf-ccamp-gmpls-vcat-lcas-08, section 4.2:
"To support a VCG with multiple co-signaled VCG members sets requires 
   being able to identify separate control plane LSPs with a single VCG 
   and exchange information pertaining to the VCG as a whole. This is 
   very similar to the "Call" concept described in [RFC4974].
   We can think of our VCAT/LCAS connection, e.g., our VCG, as a higher
layer 
   service that makes use of multiple lower layer (server) connections 
   that are controlled by one or more control plane LSPs.  "

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:
- There is an association between the VCAT endpoints and that is a VCAT
call.
- There is also an association between the member endpoints and that is
the member call. 

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.

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. 

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.

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