Title: Response to Liaison on GMPLS Signaling for VCAT/LCAS
Submission Date: 2008-02-01
URL of the IETF Web page:
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=415
Please reply by 2008-03-05
From: Adrian Farrel(IETF CCAMP WG) <adrian@olddog.co.uk>
To: ITU-T Q14/15(Greg Jones <greg.jones@itu.int>)
Cc: Kam Lam <hklam@alcatel-lucent.com>
Stephen Trowbridge <sjtrowbridge@alcatel-lucent.com>
Ross Callon <rcallon@juniper.net>
Dave Ward <dward@cisco.com>
Scott Bradner <sob@harvard.edu>
CCAMP Mailing List <ccamp@ops.ietf.org>
Reponse Contact: Adrian Farrel <adrian@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
Technical Contact: Adrian Farrel <adrian@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
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 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
Attachment(s):
No document has been attached