Liaison statement
Response to Liaison on GMPLS Signaling for VCAT/LCAS

The CCAMP Working Group thanks you for your liaison of September 2007 (Q12-14
Interim meeting - LS 005).

Here are our responses to the issues in your liaison:

Per Question 1: We provide here further clarification regarding our previous
comment re protocol extensibility to encompass technologies other than
SONET/SDH.  An example technology of interest to the community was provided
regarding the usage of virtually concatenated ODUs for carriage of IEEE 802.3
HSSG proposed 100 Gbit/s over an existing OTN infrastructure.  How this is
accomplished is not defined at this time and might not be using VCAT. A
technology neutral approach (i.e., one not dependent upon VCAT over
SONET/SDH-unique parameters) would avoid the need for developing a series of
specialized solutions.

Our response: As we noted previously, it is certainly our intention that
functionality and any protocol extensions that we develop should be easily
extensible to support other than SONET/SDH technology, especially technologies
covered by GMPLS (e.g. OTN). This is the basis of GMPLS and GMPLS call
functionality development. If you have identified any specific concerns with
the current approach, we would appreciate your input.

Per Question 2: VCAT group signaling relates closely to multi-layer call
modeling, and it is our understanding that the draft is only addressing the
constituent server layer call. We plan to perform further work to clarify the
interlayer call relationship in terms of the ASON multilayer "call supporting
call construct".

Our response: Noted. We look forward to further communication from you.

Per Question 3:   We agree that connections are not moved between calls; the
ASON "call supporting calls" construct is consistent with not moving
connections between calls. Rec. G.7041 and G.7042 are only concerned with
membership of the VCAT group, and not with the use of a member that has been
removed (it is assumed to simply go back into the pool of resources, where it
can be drawn upon for other purposes). Thus G.7041 and G.7042 do not support
the direct movement of a connection from one VCAT group to another. Changing
the association of a server layer call/connection to a VCAT group does not
necessarily result in removal/deletion of that call/connection.

Our response: Noted.

Per Question 4: We appreciate your clarification of the use of a single call.
However we suggest that you do not preclude extension to use multiple calls.
This is useful for example in diverse routing applications.

Our response: As noted in our previous liaison, the call construct as proposed
in this draft is used to coordinate the (single type) server layer connections
for the VCAT functionality. This does not preclude use of RFC 4974 in support
of G.8080 call functionality. To ensure that we understand correctly your
request, can you provide additional information regarding using multiple calls
in support of diverse routing applications?

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.

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

Per Question 6:  We understand that GMPLS only supports the IP address format,
and that the actual addresses may be different in each layer. We believe it
would be useful to clarify the difference between addresses used in regards to
delivering messages to a control component, and identifiers used for the
forwarding plane resources themselves.

Our response: Please refer to RFC 4990. This draft does not modify existing
procedures. If you have any questions with regard to GMPLS addressing, we
welcome informal dialogue on the CCAMP exploder and, of course, you may also
ask via Liaison.

Per Question 7:  Thank you for the clarification which confirms that the VCAT
layer Call Controllers are assumed to be adjacent from a control plane
perspective.

Our response: Noted. To ensure that we understand your comment on "direct
signalling connectivity" and "adjacent": to be precise, it is assumed that the
Call Controllers can exchange call control messages. This does not require that
they be adjacent.

Per Question 8:  Thank you for the clarification.

Our response: Noted.

Per Question 9:  Based upon your observation, we view that a protocol
independent definition of the call ID should be abstracted from G.7713.2, where
it is expressed in protocol specific terms; the most appropriate Recommendation
for this definition would be G.7713.

Our response: Thank you for the clarification. Please keep us informed as you
make this change.

Per Question 10:  Your interpretation of G.8080 is correct regarding E-NNI
reference points and adjacent call controllers. There is no reference to RSVP
sessions in G.8080; it was used as an example of the consequence of using
different protocols in different domains. It is our understanding from the
discussions that concatenated GMPLS RSVP-TE connections (homogenous signaling
protocol) that are part of the same end-to-end network connection do not need
to change the session object, and policy could be applied at a transit
(inter-domain) hop. Please confirm that our understanding is correct.

Our response: Your understanding is correct that even though one session is
used, policy may be applied by any processing node (call controller) of the
call message, and RFC4974 supports multiple call managers along the path
between ingress and egress. Please refer to RFC 4974. Note, the RSVP signaling
protocol model allows for the application of local policy by any processing
node of the request (regardless if a connection or call).

The latest version of this work can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-03.txt

A new version is expected relatively soon. The latest versions of all CCAMP
Internet-Drafts can always be found at the CCAMP charter page
http://www.ietf.org/html.charters/ccamp-charter.html

We welcome any further comments.

Best regards,
Adrian Farrel and Deborah Brungard
IETF CCAMP working group co-chairs