Subject: Draft Liaison Response "Response to Liaison on GMPLS Signaling for VCAT/LCAS"

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 17 Jan 2008 16:00:20 -0600

CCAMP,

Here's a proposed response to ITU's Liaison:

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

Any comments?

Thanks,

Deborah and Adrian

====

Title: Response to Liaison on GMPLS Signaling for VCAT/LCAS

Purpose: For Action

Body:

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

Here are our responses to the questions in your liaison:

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

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

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

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

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

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

Your 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 question 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.

Your Question 8:  Thank you for the clarification.

Our response: Noted.

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

Your 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 (manager) 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

We welcome any further comments.

Best regards,

Adrian Farrel and Deborah Brungard

IETF CCAMP working group co-chairs

Attachment(s): No document has been attached