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

["BRUNGARD, DEBORAH A (ATTLABS)" <[e-mail]>]

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:

https://ops.ietf.org/lists/ccamp/ccamp.2008/msg00741.html

 

 Several liaisons were with ITU covering your comments, including:

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

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: [e-mail] [mailto:[e-mail]] 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

 

 

________________________________

From: [e-mail] [mailto:[e-mail]] 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:[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]] 
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]] 
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]] 
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]
 
  

 

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

 

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