We thank you for sending us the OIF ENNI document in response to our request. While we appreciate the document being provided for information, it is concerning that this document has not been previously shared with CCAMP or the OSPF WG considering the document contains significant modifications to the operation of OSPF and reflects OIF work over the last several years. CCAMP has been cooperating on GMPLS ASON with ITU-T’s SG15 for several years and our Design Teams included OIF participants. Even though a reply was not requested, we are replying, as we strongly recommend that the document not be published for public information in its current form.
Of most concern to CCAMP is that it does not appear to be aligned with ITU-T’s and CCAMP’s cooperation on RFC 4258 (Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)) or the to-be-published document, ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt, which is the basis for our on-going routing solutions work. Considering notable OIF participants are authors of both these IETF documents (and the same participants are contributors and the Editor for the OIF document), the non-alignment is perplexing. We use the term “appear” as after much discussion over the CCAMP mailing list, we could not determine the relationship with CCAMP’s documents. OIF’s Liaison to CCAMP, Lyndon Ong, did re-affirm the statement in the document, on OIF’s intention to provide Implementation Agreements based on ITU-T and IETF’s Standards. In the interests of avoiding divergence, we advise not to have duplicate requirements documents. If you do have the need for an OIF document, we suggest in the interests of time for the three groups, IETF, ITU-T, and OIF, that you directly reference our ASON work in the corresponding GMPLS OSPF evaluation sections of your document. If any questions on the interpretation of IETF’s work, we recommend that you either utilize the CCAMP mail exploder or send a communication.
Specific comments include:
What is the intent of this document? Will it be published as an
Implementation Agreement (IA)?
The title indicates it will be an Implementation Agreement on GMPLS OSPF extensions, but the main body of the document is a list of issues with GMPLS OSPF. Further, your communication to us stated the document was requirements on and use of OSPF-TE at the ENNI. These three views seem to be inconsistent.
2. The list of changes from the previous version (listed under the Table of Contents) includes “removed “intra-carrier” limitation” and the inclusion of Figure 1 showing the OSPF ENNI for use between vendor domains and between carrier domains. GMPLS OSPF-TE already supports inter-vendor operations. IETF’s GMPLS ASON routing focus has been on the use of a link-state based protocol to support a hierarchical routing architecture (G.7715.1) within a carrier’s domain. Requirements for using a link state protocol as an inter-domain protocol between carriers are significantly different. We strongly disagree if you intend to publish this document suggesting it can be used as an inter-carrier OSPF ENNI Implementation Agreement. Regardless of OIF inter-carrier demonstrations using this protocol, it is technically misleading, both to your member carriers and the industry, to suggest using an IETF IGP protocol as an inter-carrier ENNI. The title of the document and the introduction need to be correctly scoped.
3. While OIF’s UNI is based on an Informational RFC, RFC3474, which was not a Standards Track Document, any new extensions to IETF protocols now need to be reviewed by IETF under the (G)MPLS process. The OSPF protocol elements in Appendix 1 (as noted in the document) are experimental. If OIF sees a need for such extensions, OIF needs to bring the requirements to the IETF. In the interests of a cooperative relationship between our organizations, we advise against publication and public demonstrations of experimental extensions to IETF protocols, based on presumed issues with IETF protocols, with no review by IETF.
4. Section 4.1/Table 1 and the statement under the table identifying issues with GMPLS identifier namespaces are not correct. GMPLS identifier namespaces do meet ASON requirements for namespace separation of the transport plane and control plane (Section 5.2 and 5.3/Evaluation). As you also identified in your liaison that the key area needing review was the support of independence of functional component to physical location, this appears to be a key area of misunderstanding on GMPLS by OIF. While some pre-standard vendor implementations do not support this separation, it is unfortunate if this has been guiding your ASON work as a GMPLS issue and resulting in divergence on solutions. Discussion on the CCAMP exploder highlighted a participant’s misinterpretation. We recommend reviewing RFC3945 (GMPLS Architecture) to understand that the key architecture difference between GMPLS and MPLS is the decoupling of the transport plane and control plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mapping to ITU terminology which may be helpful reading. To avoid these misunderstandings, we encourage you to share your requirements with us in as early of a stage as possible to allow us to work towards a standards track solution.
5. Concern was raised that even though the codepoints in the Appendix carry the disclaimer that they are for private and experimental use, the text in Section 1.2 positions the identified extensions as stable (and verified in the demos) and only the encoding is subject to discussion. As OIF has not initiated any GMPLS Change Process on these extensions, this is very presumptuous. Again, we would recommend against publication of this document in the public domain.
We request an additional round of communication of this document to the IETF before OIF approval to allow us to work with you to improve convergence between OIF and IETF work which, we believe, will be in the best interests of our groups and the industry.