Subject: Re: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08

From: "Evelyne Roch" <[email-masked]>
Date: Wed, 2 Dec 2009 17:01:47 -0500

Lou,

I think this document fails to address some important requirements for
VCAT signaling. As we described in draft-roch-ccamp-gmpls-inv-mux-00,
there are requirements for VCAT signaling to be performed independently
from the member signaling in certain conditions when business
relationships do not permit the provider of the members to carry VCAT
signaling on its behalf, due to policies or existence of statically
configured connections. I would prefer to see a signaling approach that
allows for independent VCAT signaling and does not require the members
to carry information related to the VCAT services. 

Regards,
Evelyne Roch
e-mail: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lou Berger
Sent: Friday, November 20, 2009 3:25 PM
To: CCAMP; [email-masked]
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Wed, 2 Dec 2009 16:47:06 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Friday, November 20, 2009 2:25 PM
To: CCAMP; [email-masked]
Subject: [CCAMP] Working group last call: draft-ietf-ccamp-gmpls-vcat-lcas-08

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)

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 02 Dec 2009 16:48:56 -0800

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

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: <[email-masked]>
Date: Thu, 3 Dec 2009 12:36:58 +0100

Hi all.

Jonathan, both documents you refer to are out of scope here:
- draft-jenkins-mpls-tp-bt-requirements is entitled "BT Requirements..."
and explicitely express an individual's view;
- OIF's carrier requirements are interesting information for IETF but do
not reflect any IETF consensus either.

Furthermore, I do not see why the solution defined in
draft-ietf-ccamp-gmpls-vcat-lcas would preclude you from covering your
specific case. I assume your client nodes have 2 things to handle:
- the VCAT group, which can be configured by a Notify message,
- the STS-m/VC-n termination points, configured by a Path message.
If you consider a kind of overlay operation (not to be confused with an
"overlay architecture" glued to network layers), you can limit the
latter signaling to the end nodes, i.e. your client network. Then, if
the server layer have its STS-m/VC-n configured by RSVP-TE, you can get
2 things:
- the level of (in)dependancy you need so as to connect to the client
termination points by using the identifiers you like,
- the solution defined in the current draft as it is.
A bit tricky you might say, but I prefer to see tricky solutions for
corner cases than making the mainstream solution tricky.

Regards,

Julien

-----Original Message-----
Of Sadler, Jonathan B.

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.

Jonathan Sadler

-----Original Message-----

Thank you,
Lou (and Deborah)

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Thu, 3 Dec 2009 13:46:43 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Bernstein
Sent: Wednesday, December 02, 2009 7:49 PM
To: Sadler, Jonathan B.
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] Working group last
call:draft-ietf-ccamp-gmpls-vcat-lcas-08

Regards

GB

Of Lou Berger

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Thu, 3 Dec 2009 14:25:52 -0500

(my chair hat off)

Jonathan,

As the independent scenario for supporting pre-establishment of server
layer connections was already added to the document (section 4.5.2) and
as you are saying a customer premise, you are concerned on the UNI
scenario when the CE has the VCAT functionality?

Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sadler, Jonathan B.
Sent: Wednesday, December 02, 2009 5:47 PM
To: Lou Berger; CCAMP; [email-masked]
Subject: Re: [CCAMP] Working group last call:
draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi all,

Jonathan Sadler

-----Original Message-----

Thank you,
Lou (and Deborah)

---

From: "Evelyne Roch" <[email-masked]>
Date: Thu, 3 Dec 2009 15:34:15 -0500

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: [email-masked] [mailto:[email-masked]] 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,

Deborah 

-----Original Message-----

Regards

GB

Of Lou Berger

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Thu, 3 Dec 2009 16:50:25 -0500

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:[email-masked]] 
Sent: Thursday, December 03, 2009 3:19 PM
To: BRUNGARD, DEBORAH A (ATTLABS)
Subject: RE: [CCAMP] Working group

Deborah,

Evelyne

-----Original Message-----

Hi all,

Deborah 

-----Original Message-----

Regards

GB

Of Lou Berger

---

From: Lou Berger <[email-masked]>
Date: Fri, 04 Dec 2009 10:14:04 -0500

Evelyne, Jonathan,

As Deborah and others have said in previous messages, this document has 
been stable for quite a while and is focused on a specific set of 
requirements.  These requirements are covered in section 3 of the draft. 
  With in-scope scenarios described in section 3.2.

It sounds to me like the basic point being raised by both of you goes to 
the intended scope of this document. In particular, Section 3.2 and the 
rest of the document doesn't allow for the the scenario where one or 
more members are established using a mechanism other than what is 
described in the document.  Is this correct or am I missing another 
point?

Certainly any limitations in a document with respect to the described 
technical solution to meeting the document's scope need to be addressed. 
  Albeit a bit late in the process, I also think raising points on 
requirements is valid in WG last call.  But such new requirements must 
be evaluated for inclusion and must meet a high bar to be included at 
such a late stage of the process.  In evaluating how such points are to 
be addressed, I think it is particularly important to gauge if the 
existing solution (and requirements set) handles a useful functionality 
set and if the new requirements are valid and can still be addressed 
independently or incrementally.

I think the general sentiment on the list so far has been that the 
existing document scope (VCAT signaled using the mechanisms in the 
document) is useful and that the your requirements should be explored 
independently from this document.  I think this is a reasonable position 
and doesn't preclude the WG discussing your new scenario.

Not withstanding the existing section 3 (and 3.2), I think it is valid 
that this document make its scope even clearer by highlighting the scope 
earlier in the document.   Also, any open technical points related to 
the described mechanisms also need to be run to ground as part of this 
(and any) last call.

Lou

---

From: "Evelyne Roch" <[email-masked]>
Date: Fri, 4 Dec 2009 12:10:56 -0500

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:[email-masked]] 
Sent: Thursday, December 03, 2009 4:50 PM
To: Roch, Evelyne (CAR:Q840)
Cc: CCAMP
Subject: RE: [CCAMP] Working group

Hi Evelyne,

Deborah
(chair hat on)

-----Original Message-----
From: Evelyne Roch [mailto:[email-masked]]
Sent: Thursday, December 03, 2009 3:19 PM
To: BRUNGARD, DEBORAH A (ATTLABS)
Subject: RE: [CCAMP] Working group

Deborah,

Evelyne

-----Original Message-----

Hi all,

Deborah 

-----Original Message-----

Regards

GB

Of Lou Berger

---

From: "Evelyne Roch" <[email-masked]>
Date: Fri, 4 Dec 2009 12:20:49 -0500

Lou,

I just clarified the problems I have with the draft in a response to
Deborah but I'll add another point in response to your email regarding
requirements.

To me, member sharing means that there can exist multiple members, the
members having been independently signaled. Those multiple members are
put "in a common pool" according to the draft. The criteria for being in
the "common" pool is not specified in the draft. My interpretation is
that the LSPs created for one of the elementary signal types between the
same endpoints can be put in the same VCG. It does not mean that the
LSPs have to be in the same member call. 

Evelyne

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Friday, December 04, 2009 10:14 AM
To: Roch, Evelyne (CAR:Q840)
Cc: CCAMP; [email-masked]; Sadler,
Jonathan B.

Evelyne, Jonathan,

Lou

> there are requirements for VCAT signaling to be performed 
> independently from the member signaling in certain conditions when 
> business relationships do not permit the provider of the members to 
> carry VCAT signaling on its behalf, due to policies or existence of 
> statically configured connections. I would prefer to see a signaling 
> approach that allows for independent VCAT signaling and does not 
> require the members to carry information related to the VCAT services.
>
> Regards,
> Evelyne Roch
> e-mail: [email-masked]
>
>

> 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
>

---

From: Greg Bernstein <[email-masked]>
Date: Fri, 04 Dec 2009 13:09:13 -0800

Hi Evelyne see comments below.

Greg

Evelyne Roch wrote:
> -- snip --
--> 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
---> 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
---> This is true.
> call ID so that call members can be reused.
---> These are what you call  "member call IDs".
> 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.
> 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

> to

---

From: "Evelyne Roch" <[email-masked]>
Date: Fri, 4 Dec 2009 16:27:25 -0500

Greg, see below.

>From: Greg Bernstein [mailto:[email-masked]] 
>Sent: Friday, December 04, 2009 4:09 PM
>Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP

<snip>

>I'm not sure that we have calls of calls in GMPLS. At the time this

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

---

From: Lou Berger <[email-masked]>
Date: Mon, 07 Dec 2009 15:08:08 -0500

Authors,
	I have some comments on the draft (sorry about being late), most of 
which are at the nit level.  I do have one more significant editorial 
comment:

- section 4.5 defines a fairly significant portion of this extension but 
does so without any real use of RFC2119 normative language.  I think 
this section needs to be explicit about how nodes are to process objects 
and messages and therefore should be revised to use formal normative 
language.  References to existing defined procedures are beneficial as 
well.  I'd expect this revision to translate into formalization of 
current technical details and no change in mechanisms.

The following are my other comments:

- Section 1:
You should add references for each technology referenced in this section.

It's probably worth mentioning that the scope of the document is limited 
to scenarios where all member signals are controlled using mechanisms 
defined in this document.

- Section 2:
This section should be removed.  (Generally such sections shouldn't be 
numbered so that when they are dropped all sections in the document 
doesn't get renumbered.)

- Section 3.2:
Same comment as before, not that only scenarios that use common 
mechanism are supported by this extension.

-Section 3.3:

    The type of the member signal that the VCG will contain, e.g., VC-3,
       VC-4, etc.

    The total number of members to be in the VCG. This provides the
       endpoints in both the LCAS and non-LCAS case with information on
       which to accept or reject the request, and in the non-LCAS case
       will let the receiving endpoint know when all members of the VCG
       have been established.

    Identification of the VCG and its associated members. This provides
       information that allows the endpoints to differentiate multiple
       VCGs and to tell what members (LSPs) to associate with a
       particular VCG.

Text should be indented to indicate that it's part of a list

-Section 4.1
    4.1. VCGs Composed of a Single Co-Signaled Member Set

    Note that this section is for informational purposes only.

Perhaps this should be in it's own section?

- Section 4.2.1:

    VCG Call setup information signaled via the Notify message with the
    Call management bit (C-bit) set:

Do you mean?

    VCG Call setup information is signaled a new CALL_ATTRIBUTES Object
    TLV with the following information:

-Section 4.3
    We define a new

   4.4. VCAT CALL_ATTRIBUTES TLV Object

    For use in the CALL_ATTRIBUTES object in Notify messages we define
    the following VCAT related TLV:

It looks like a section heading made it's way into the text.  Should the 
text read:

    We define a new VCAT CALL_ATTRIBUTES TLV Object for use in the
    CALL_ATTRIBUTES object in Notify messages with
    the following format:

- Section 4.5

See first comment.

- Section 4.5.3

The following aren't clear and should be rephrased:
     Given a VCAT call without an associated VCG such as that set up
    in section 4.5.2. one associates it with a VCG as follows.
and
     To take a particular VCG out of service, rather than just
     removing all its member, a special flag element is included.

- Section 6

This section should be revised to follow rfc5226.  It also looks like 
you are asking IANA to establish a registry for Signal types, is this 
correct?

Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 07 Dec 2009 18:39:09 -0500

This working group last call is complete.

Authors,
	Please update your document according to comments received.  Please 
also let the working group know how you propose to resolve each comment. 
  Please feel free to discuss proposed resolutions on the list prior to 
issuing an updated document where appropriate.

Lou

---

From: Greg Bernstein <[email-masked]>
Date: Tue, 08 Dec 2009 10:03:52 -0800

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

---

From: "Evelyne Roch" <[email-masked]>
Date: Wed, 9 Dec 2009 15:50:14 -0500

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

________________________________

Sent: Tuesday, December 08, 2009 1:04 PM

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:[email-masked]] 

	<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

---

From: Greg Bernstein <[email-masked]>
Date: Wed, 09 Dec 2009 14:33:55 -0800

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:
> 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:[email-masked]]
> *Sent:* Tuesday, December 08, 2009 1:04 PM
> *To:* Roch, Evelyne (CAR:Q840)
> *Cc:* BRUNGARD, DEBORAH A (ATTLABS); CCAMP
> *Subject:* Re: [CCAMP] Working group 
> 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.
>>
>>

---

From: "Evelyne Roch" <[email-masked]>
Date: Thu, 10 Dec 2009 10:52:13 -0500

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

Sent: Wednesday, December 09, 2009 5:34 PM

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

	
	Greg
	
	Evelyne Roch wrote: 

		Greg, see below.

			-----Original Message-----
			From: Greg Bernstein

		<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

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 10 Dec 2009 08:16:25 -0800

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:
> 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
>
> *Sent:* Wednesday, December 09, 2009 5:34 PM
> 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,
>>

---

From: "Evelyne Roch" <[email-masked]>
Date: Thu, 10 Dec 2009 11:47:34 -0500

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

Sent: Thursday, December 10, 2009 11:16 AM

It includes:

CCAMP response: As noted above, this is not precluded. We look forward
to
future communication from you as you progress this work."

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

	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

		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

			<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

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 10 Dec 2009 10:29:23 -0800

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:
> 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
>  
>  
>  
>  
>
> *Sent:* Thursday, December 10, 2009 11:16 AM
>> 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
>>
>> 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 
>>> 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.
>>>>
>>>>

---

From: "Evelyne Roch" <[email-masked]>
Date: Thu, 10 Dec 2009 13:52:22 -0500

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

Sent: Thursday, December 10, 2009 1:29 PM

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. 

	Evelyne

	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. 

	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."

	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

		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,

			Evelyne

			From: Greg Bernstein

			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

				
				<snip>

				
				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 (510)
573-2237

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 10 Dec 2009 11:10:09 -0800

Hi Evelyne, why is this dependency problematic? What are you trying to 
do and what it the context?

Greg

Evelyne Roch wrote:
> *Sent:* Thursday, December 10, 2009 1:29 PM
> It was recommended by the WG chairs to use the CALL_ATTRIBUTES object 
> as defined in the MLN-Extensions work rather than defining another 
> member sharing scenario. We do not preclude other techniques being 
> used in the future.
>
> Greg
>
> Evelyne Roch wrote:
>>> 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).
>>>  
>>>> diversely routed routed members. We were asked to include 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.
>>>>>
>>>>>

---

From: "Evelyne Roch" <[email-masked]>
Date: Thu, 10 Dec 2009 14:22:06 -0500

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

Sent: Thursday, December 10, 2009 2:10 PM

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

	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: 

		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

		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. 

		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

			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

				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

				
				<snip>

				
				
				<snip>
				
				Evelyne

				-- 
	
===================================================
				Dr Greg Bernstein, Grotto Networking
(510) 573-2237

			--

---

From: Richard Rabbat <[email-masked]>
Date: Thu, 10 Dec 2009 20:18:07 -0800

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 <[email-masked]> 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
>
>  ------------------------------
> *Sent:* Thursday, December 10, 2009 2:10 PM
>
> Hi Evelyne, why is this dependency problematic? What are you trying to do
> and what it the context?
>
> Greg
>
> Evelyne Roch wrote:
>
> Greg,
>
> 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:[email-masked]<[email-masked]>]
>
> utilizing the same procedures that we are now using with the CALL_ATTRIBUTES
> object.
> 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:
>
> 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.
>
>  ------------------------------
> *From:* Greg Bernstein [mailto:[email-masked]<[email-masked]>]
>
> The "call concept" usage and "member sharing scenario" have been previously
> discussed, liaised, and resolved with ITU-T.
>
> 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).
>
> 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:[email-masked]<[email-masked]>]
>
> 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:[email-masked]<[email-masked]>]
>
> 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.
>
>
>
> From: Greg Bernstein [mailto:[email-masked] <[email-masked]>]

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Fri, 11 Dec 2009 13:49:17 -0600

Hi Greg,

There have been a number of different liaisons from ITU that have talked about the separation of control plane instances on a layer-by-layer basis and the limits this places on what signaling information can be carried by the other instance.  Three that are quite pertinent to this discussion are as follows:

  https://datatracker.ietf.org/documents/LIAISON/file537.pdf - states "VCAT is viewed as a layer of its own and has its own call controller. As per the interlayer architecture in G.8080 section 6.6, the VCAT call would be associated with a server layer call or calls, each of which would have/own one or more server layer connections.  It is these connections that are part of the VCG. "
  https://datatracker.ietf.org/documents/LIAISON/file419.doc - states "signalling messages are always scoped to a specific layer - the information elements in the server layer signalling messages are specific to the server layer (e.g. containing only server layer resources in the ERO) and the information elements in the client layer signalling messages are specific to the client layer (e.g. containing only client layer resources in the ERO)."
  https://datatracker.ietf.org/documents/LIAISON/file432.doc - states "if two layers are under different administrative domains because they belong to two different providers, the amount of information that can be shared between the two domains is more limited than in the case where a single provider network provides resources at all layers"

As pointed out by Evelyne, the MLN/MRN drafts/RFCs place the CALL_ATTRIBUTES object in the server layer (i.e. STS/VC) signaling messages, while it is being used to carry client layer (i.e. VCAT) detail.  This is the piggybacking issue (i.e. carrying client layer data in the server layer signaling) that I referenced in the comment I made earlier.

Why is this not good?  Well, if the client layer and server layer are in different control contexts, it becomes unsafe to assume what service the other control context will provide.  For example:

 - the client layer could be using a control plane protocol while the server layer is being manually/statically configured

 - the client layer doesn't have access to the information being exchanged by a server layer control plane instance

 - the server layer network utilizes a control plane protocol other than one specified by the IETF

 - the server layer network's policy is to not allow the passing of arbitrary data in its control plane

In all of these cases, the CALL_ATTRIBUTES object would not make it between the endpoints, causing the VCAT to not be established.

This sort of separation information has been provided in other IETF protocols (e.g. T-LDP used for PW setup - it's separate from the RSVP-TE setup done in for the Tunnel LSP) - we're just looking for the same sort of separation to be provided for inverse multiplexing configuration mechanisms.

Jonathan Sadler

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Evelyne Roch
Sent: Thursday, December 10, 2009 1:22 PM
To: Greg Bernstein
Cc: CCAMP
Subject: Re: [CCAMP] Working group lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

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:[email-masked]]
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:[email-masked]]
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:[email-masked]]
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.

It includes:

the

construct:

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:[email-masked]]
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:[email-masked]]
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-----

<snip>

<snip>

Evelyne

--

--

--

--

--

---

From: "Evelyne Roch" <[email-masked]>
Date: Mon, 14 Dec 2009 09:55:29 -0500

Richard,
 
The ASON architecture is defined in ITU-T Recommendation G.8080,
available free of charge, at the following URL:
http://www.itu.int/rec/T-REC-G.8080/en
 
Evelyne

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Richard Rabbat
Sent: Thursday, December 10, 2009 11:18 PM
To: Roch, Evelyne (CAR:Q840)
Cc: Greg Bernstein; CCAMP
Subject: Re: [CCAMP] Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Evelyne,

	Greg,

	Evelyne

	

	Hi Evelyne, why is this dependency problematic? What are you
trying to do and what it the context?
	
	Greg
	
	Evelyne Roch wrote: 

		Greg, 

		Evelyne

		From: Greg Bernstein

		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

			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. 

			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
				Sent: Wednesday, December 09, 2009 5:34
PM

				Greg

				Evelyne Roch wrote: 

				Greg,

				Evelyne

				From: Greg Bernstein

				Greg
				
				Evelyne Roch wrote: 

				Greg, see below.

				-----Original Message-----
				From: Greg Bernstein

				
				<snip>

				
				<snip>
				
				Evelyne

				-- 

				-- 

			--

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Mon, 14 Dec 2009 14:57:18 -0500

Jonathan and Evelyne,

As Greg has noted, this discussion is repeating previous discussions
both on the mailing list and liaisons. The conclusion was as Greg has
already noted  - the scenarios below are outside the scope of this
document.

Specifically, this ccamp response to OIF covers your comments on the use
of separate signaling exchanges and your concerns on e-2-e transport of
signaling information:

 Several liaisons were with ITU covering your comments, including:

https://datatracker.ietf.org/liaison/468/

If you have specific wording proposals for this document, please provide
them so as to help the editor complete the last call revisions and
progress the document.

Regards,

Deborah

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sadler, Jonathan B.
Sent: Friday, December 11, 2009 2:49 PM
To: Evelyne Roch; Greg Bernstein
Cc: CCAMP
Subject: Re: [CCAMP]Working group
lastcall:draft-ietf-ccamp-gmpls-vcat-lcas-08

Hi Greg,

There have been a number of different liaisons from ITU that have talked
about the separation of control plane instances on a layer-by-layer
basis and the limits this places on what signaling information can be
carried by the other instance.  Three that are quite pertinent to this
discussion are as follows:

  https://datatracker.ietf.org/documents/LIAISON/file537.pdf
<https://datatracker.ietf.org/documents/LIAISON/file537.pdf>  - states
"VCAT is viewed as a layer of its own and has its own call controller.
As per the interlayer architecture in G.8080 section 6.6, the VCAT call
would be associated with a server layer call or calls, each of which
would have/own one or more server layer connections.  It is these
connections that are part of the VCG. "

  https://datatracker.ietf.org/documents/LIAISON/file419.doc - states
"signalling messages are always scoped to a specific layer - the
information elements in the server layer signalling messages are
specific to the server layer (e.g. containing only server layer
resources in the ERO) and the information elements in the client layer
signalling messages are specific to the client layer (e.g. containing
only client layer resources in the ERO)."

  https://datatracker.ietf.org/documents/LIAISON/file432.doc - states
"if two layers are under different administrative domains because they
belong to two different providers, the amount of information that can be
shared between the two domains is more limited than in the case where a
single provider network provides resources at all layers"

As pointed out by Evelyne, the MLN/MRN drafts/RFCs place the
CALL_ATTRIBUTES object in the server layer (i.e. STS/VC) signaling
messages, while it is being used to carry client layer (i.e. VCAT)
detail.  This is the piggybacking issue (i.e. carrying client layer data
in the server layer signaling) that I referenced in the comment I made
earlier.
 
Why is this not good?  Well, if the client layer and server layer are in
different control contexts, it becomes unsafe to assume what service the
other control context will provide.  For example:
 - the client layer could be using a control plane protocol while the
server layer is being manually/statically configured
 - the client layer doesn't have access to the information being
exchanged by a server layer control plane instance
 - the server layer network utilizes a control plane protocol other than
one specified by the IETF
 - the server layer network's policy is to not allow the passing of
arbitrary data in its control plane
 
In all of these cases, the CALL_ATTRIBUTES object would not make it
between the endpoints, causing the VCAT to not be established.
 
This sort of separation information has been provided in other IETF
protocols (e.g. T-LDP used for PW setup - it's separate from the RSVP-TE
setup done in for the Tunnel LSP) - we're just looking for the same sort
of separation to be provided for inverse multiplexing configuration
mechanisms.
 
Jonathan Sadler

Of Evelyne Roch

Greg,

Evelyne

Greg

Evelyne Roch wrote: 

Greg, 

Evelyne

Greg

Evelyne Roch wrote: 

Evelyne

 

 
It includes:

Greg

Evelyne Roch wrote: 

Greg,

Evelyne

Greg

Evelyne Roch wrote: 

Greg,

Evelyne

Greg

Evelyne Roch wrote: 

Greg, see below.

	-----Original Message-----
	From: Greg Bernstein [mailto:[email-masked]] 
	Sent: Friday, December 04, 2009 4:09 PM
	To: Roch, Evelyne (CAR:Q840)
	Cc: BRUNGARD, DEBORAH A (ATTLABS); CCAMP
	Subject: Re: [CCAMP] Working group

<snip>

	I'm not sure that we have calls of calls in GMPLS. At the time
this
	was written this wasn't deemed desirable.

 
<snip>
 
Evelyne