Liaison statement
GMPLS Signaling on VCAT/LCAS

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