Liaison Statement
Source: CCAMP WG, IETF
To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q.14/15
Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q.12/15
Cc: Scott Bradner, IETF-ITU-T Coordinator
Alex Zinin, IETF Routing Area Director
Bill Fenner, IETF Routing Area Director
Approval: CCAMP WG
For: Action
Deadline: March 31, 2004
Dear Mr. Lam,
This liaison is in response to your recent liaison and communication requesting comments on potential issues with G.7713.2 and your request for IETF to use as a base the extensions defined in G.7713.2 for CCAMP’s ASON work.
Kireeti Kompella & Adrian Farrel,
IETF CCAMP WG Chairs
1.
G.7713.2 removes both ResvErr and ResvTear messages,
which are basic RSVP messages defined in RFC 2205. The removal of these
messages translates into G.7713.2 not supporting certain operational and error
handling cases. Appendix III of G.7713.2 on ResvTear: "This message is not
used as part of connection-oriented release procedures. The PathErr (with
Path_State_Removed flag) is used to support destination-initiated release”.
Regarding ResvErr: "Respond to a Resv connection setup request (when
encountering problems with setup); however, note that in the GMPLS
implementation where a connection setup error requires releasing the
connection, and since ResvErr does not remove Path states, the PathTear is used
for GMPLS connection-oriented networks to remove Path states, i.e., ResvErr is
not used during setup and release." G.7713.2 does not provide any
justifications for these modifications, nor does it address compatibility
issues with RFCs 2205 and 3473.
An example of the consequences of removing basic RSVP messages is that G.7713.2 does not allow application of Section 2.3.1 of RFC 3473 in response to operational difficulties with a received label: “The recipient of a Resv message containing a Generalized Label verifies that the values passed are acceptable. If the label is unacceptable then the recipient MUST generate a ResvErr message with a "Routing problem/MPLS label allocation failure" indication." This message and related procedures are critical to service establishment in certain real-world operational scenarios within optical transport networks. Sending a PathTear instead of a ResvErr has different (and undesirable) semantics. Another example is dealing with suggested labels. G.7713.2 makes use of the suggested label procedure, without support of Section 2.5 of RFC 3473 (which needs the ResvErr message), leading to incorrect operational behavior.
2. G.7713.2 uses objects not defined in standard RFCs and also modifies RSVP-TE standard objects. G.7713.2 lacks specific procedures for the processing of these non-standard objects. G.7713.2 also lacks specific procedures for the modified RSVP-TE mechanisms. These omissions allow for different interpretations, which can result in incompatible implementations as well as additional divergence from RFC3473 standard implementations.
3. G.7713.2 uses objects not defined in standard RFCs to support capabilities already provided by standard objects. The non-standard objects and objects modifeid by G.7713.2 cannot be supported by standard RSVP-TE implementations. Use of non-standard RFC messages and objects requires documented procedures to describe when and how they are to be sent, received, processed and responded to by a standard RFC 3473 entity. This is the responsibility of the user of non-standard objects and non-standard mechanisms (regardless if the user is an individual or Standards organization). Additionally it is the user’s responsibility to ensure the non-standard objects and non-standard mechnaisms do not adversely impact the standard. Refer to items below for additional discussion.
4. G.7713.2’s
SESSION objects (specified as mandatory) are not aligned with RFC 3473. A standard GMPLS node receiving a G.7713.2
message with one of these objects will reject the connection establishment,
thus rendering G.7713.2 incompatible with standard GMPLS RSVP-TE nodes.
Furthermore, G.7713.2’s SESSION object contains the address of the next node,
rather than that of the session destination. This, in combination with an ERO,
can also result in the rejection of a connection request.
5. There is terminology confusion between G.7713.2 and RFC 3473. Per G.7713.2, the EGRESS_LABEL and SPC_LABEL := <Logical Port ID, Label>. The closest mapping is Logical Port ID = component link id. Also as the TNA only supports numbers, only numbered bundles are supported. This is a restriction in terms of numbering schemes allowed by RFC 3473 (i.e. unnumbered TE Links shall be supported).
6. G.7713.2 defines an incompatible and redundant addressing mechanism with RFC 3473 to support IPv4, IPv6, and NSAP addresses. RFC 3473 is part of a GMPLS protocol suite based on use of IPv4 and IPv6 addresses. The use of NSAP addresses with RFC 3473 is supported by established procedures defined in RFC1884 "IPv6 Addressing Architecture", and only requiring support by border entities (e.g., DNS). Any other support for NSAP addressing is redundant with IETF supported procedures. G.7713.2 provides no guidance on the operational aspects resulting from this modified procedure which uses a non-standard object, the Generalized_UNI object, to support. Use of the GENERALIZED_UNI object requires every entity to support multi-address family resolution, e.g., for ERO processing, and in the case of multi-region path setup. Requiring multi-address family resolution at all entities severely impacts performance, scaling, and introduces unnecessary complexity for operations. This limitation is well recognized, e.g. G.7713.2 use in demos has been limited to only IPv4 prefixes with preconfigured mappings.
7. G.7713.2 defines support of SPC using a non-standard and redundant object. As RFC3473 already defines SPC support, G.7713.2’s definition is unnecessary and incompatible with an already standardized and deployed method.
8. The RSVP paradigm is one end-to-end session per connection (or connection segment). This paradigm has been maintained by MPLS RSVP-TE (RFC 3209) and by GMPLS RSVP-TE (RFC 3473); however, G.7713.2 violates this paradigm. This violation is not only incompatible with the definition of RSVP, but will make any interworking function of GMPLS RSVP-TE and G.7713.2 very difficult, both from a protocol point of view (connection establishment, and capabilities such as make-before-break, fast reroute, etc.), as well as operational interworking. Please review the GMPLS RSVP-TE based UNI [G-UNI], which describes how this paradigm can be maintained across a User-Network Interface.
Discussion on the CCAMP mailing list suggests that there is diversity in what is meant by G.7713.2 being ‘compatible’ with GMPLS RSVP-TE. It would be useful for Q14/15 to define their view of what this compatibility means, and to give details on how it is to be achieved. For contrast, [G-UNI] and [ASON-RSVP-TE] are transparently compatible with GMPLS RSVP-TE [RFC 3473]: no interworking function is needed, nor are message translations. The only changes are to procedures local to the ‘network’ node, and these have been clearly spelled out. This is a much simpler approach, both operationally and procedurally; it would be useful for Q14/15 to review and comment on this approach.
The above describes comments identified to date. We will keep you informed as we identify additional items during future review.
Per your request to consider G.7713.2 as a basis of IETF’s ASON GMPLS signaling work, unfortunately, as discussed above, G.7713.2 uses non-standard objects for capabilities which are already supported, and its protocol definitions are incompatible with RFC 3473 (GMPLS RSVP-TE), RFC 3209 (RSVP-TE), and RFC 2205 (RSVP). G.7713.2 specifies fundamental modifications to the protocol operation defined in these references. Therefore G.7713.2 as currently specified cannot be considered as a basis for IETF’s ASON GMPLS signaling work.
We wish to inform Q14/15 of a recent draft submission to CCAMP’s November meeting, which recognizes the incompatibility of RFC3473 and G.7713.2. The document, draft-ong-ccamp-3473-3474-iw-00.draft, proposes defining an interworking function between G.7713.2 and RFC 3473. Interworking functions raise serious network architecture issues and operational issues, even if all the protocol issues are addressed.
Additional information on the above comments is contained in Attachment 1 to this liaison: Appendix 1 of [ASON-RSVP-TE]. Note, this Appendix was created in response to questions asked by Q14/15 participants at the June meeting (and similar questions on the CCAMP mailing list) on the use of G.7713.2 with GMPLS (RFC3473).
As reported in the CCAMP status update at the June meeting, CCAMP is progressing with its work on GMPLS signaling extensions for ASON. CCAMP would like to inform Q14/15 that the draft (WD36) submitted for Q14/15 review has been revised based on input at the meeting and further input by CCAMP. The document “draft-ietf-ccamp-gmpls-ason-reqts-05” is a CCAMP WG document. It is the intention of the CCAMP WG to progress draft-ietf-ccamp-gmpls-ason-reqts-05 to RFC status. We would, therefore, appreciate any feedback on this draft before the end of this year. Comments can also be made during the CCAMP last call of the document, or at any time on the CCAMP mailing list, ccamp@ops.ietf.org.
A comment over the CCAMP mailing list identified it would be useful for Q12/15 review of this document. Considering the Q12/15 Rapporteur presence and multiple Q12/15 participants presence at the June meeting and that no one suggested this, and none of your previous liaisons with us suggested it, we were unaware of this need. If you feel it appropriate, please include Q12/15 on this and future liaisons.
We hope that these comments will assist you in your work. Further, IETF believes that it is in our joint interest and the industry to ensure that ITU-T Q14/15 work incorporating the use of IETF GMPLS protocols aligns with the protocol as specified. CCAMP strongly recommends that Q14/15 make the appropriate modifications to G.7713.2 to address our concerns. Any remaining non-alignment needs to be clearly identified as a modification of IETF standards, regardless of the intention of use (e.g. External Network Node Interface). A standard that re-uses the name and references another group’s standards, but is incompatible, will cause confusion for the users of ITU-T and IETF standards. We believe that it is possible to reconcile these incompatibility issues with the existing G.7713.2 and we would like to actively support your efforts. We look forward to ongoing collaboration with you regarding the use of IETF signaling and routing protocols. As we informed you on a previous liaison, CCAMP has on-going work on supporting ASON requirements for routing.
References
RFC 1884 "IP Version 6 Addressing Architecture." R. Hinden, S. Deering, Eds.. December 1995.
RFC 2205 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification." R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin. September 1997.
RFC 3209 " RSVP-TE: Extensions to RSVP for LSP Tunnels." D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow. December 2001.
RFC 3471 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description." L. Berger, Ed.. January 2003.
RFC 3473 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions." L. Berger, Ed. January 2003.
ASON-RSVP-TE “Generalized MPLS (GMPLS) RSVP-TE Signalling in support of Automatically Switched Optical Network (ASON)”, Drake et al, draft-ietf-ccamp-gmpls-rsvp-te-ason-00.txt (work in progress).
G-UNI “GMPLS UNI: RSVP Support for the Overlay Model”, Swallow et al, draft-ietf-ccamp-gmpls-overlay-02.txt (work in progress).