Liaison statement
Response to Liaison on GMPLS Signaling for VCAT/LCAS
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
State | Posted |
---|---|
Submitted Date | 2008-02-01 |
From Group | ccamp |
From Contact | Adrian Farrel |
To Group | ITU-T-SG-15-Q14 |
To Contacts | 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> |
Response 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 |
Deadline | 2008-03-05 Action Taken |
Attachments | (None) |
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 |