Liaison statement
GMPLS Signaling on VCAT/LCAS

Submission date 2008-02-29
From ITU-T SG 15 (Greg Jones)
To IETF CCAMP WG (adrian@olddog.co.uk, dbrungard@att.com)
Cc sob@harvard.edu, rcallon@juniper.net, dward@cisco.com, lberger@labn.net, ccamp@ops.ietf.org, yoichi.maeda@ntt-at.co.jp, sjtrowbridge@alcatel-lucent.com
Response contact tsbsg15@itu.int
Technical contact hklam@alcatel-lucent.com
Purpose For action
Deadline 2008-09-15 Action Taken
Attachments LS222 - body text in pdf
Body
Q14/15 thanks you for your liaison of 1st February 2008
(https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=415, which
is TD515 (WP3/15)).
Here are our comments to the responses provided in your liaison:
a)	Regarding your response to Question 1 on protocol extensibility to
encompass technologies other than SONET/SDH, we notice that the recent I-D
(draft-ietf-ccamp-gmpls-vcat-lcas-04.txt) limits the number of VCGs per call
to one. We support this position and consider this to be a VCAT call.

b)	Regarding your response to Question 4 on multiple calls support, 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. In retrospect, a single call is sufficient for diverse routing as it
can hold details of both connections so that they don¡¦t use the same
resources.
An example where multiple server calls associated with one VCAT call would be
useful is when all VCAT connections are to be protected.  Here, rather than
one call maintain the knowledge of all working/protection pairs, it is simpler
to have multiple calls each of which only maintains one working/protection
pair.  This is even more convenient when restoration behavior is applied when
the protection connection fails.

c)	Regarding your response to Question 6 on IP address format in GMPLS, we
suggest the I-D clarifies that there are different name (or identifier) spaces
even though they may all use the same IP address format, e.g. 
ƒ{	Control component
The identifiers used to identify the entities that perform the control plane
functions, such as route computation, signaling, control plane message
delivering, etc.
ƒ{	Transport resource
The identifiers used to identify transport resource when they are referred to
in the control plane messages. Note that these identifiers may not be the same
as those referred to in the management plane messages.
ƒ{	SCN
The addresses used to deliver control plane messages
Examples of a similar address format in use in two different name spaces can
be seen in the OSPF routing protocol, where router ID (control and transport
link scope) and IP address (used by the forwarder) do not have to be the same.


Regarding your liaison response on GMPLS Calls
(https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=414, which
is TD516 (WP3/15)), thank you for your response.  We do not have any further
reply at this time and appreciate the invitation for future input to CCAMP.
An electronic copy of this liaison statement is available at:
ftp://ftp.itu.int/tsg15opticaltransport/COMMUNICATIONS/index.html