RE: Response to OIF on OSPF ENNI

["Jim Jones" <[e-mail]>]

Dear Deborah and Adrian,
 
Thank you for the detailed reply. I will upload this as a contribution to
the OIF website so we may discuss it in our upcoming meeting.
 
Best Regards,
Jim Jones
OIF Technical Committee Chair

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Brungard, Deborah A, ALABS
Sent: Friday, July 28, 2006 4:09 PM
To: Jim Jones
Cc: [e-mail]; Adrian Farrel; Ross Callon; Fenner, William C
(Bill), ALABS
Subject: Response to OIF on OSPF ENNI


Dear Jim,

 

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>
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-0
3.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:

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

 

Best regards,

Adrian Farrel and Deborah Brungard,

CCAMP co-chairs