Subject: Response to OIF on OSPF ENNI

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Fri, 28 Jul 2006 16:08:34 -0500

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-ev
al-03.txt
<ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-e
val-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:

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

---

From: "Jim Jones" <[email-masked]>
Date: Sun, 30 Jul 2006 07:54:38 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Brungard, Deborah A, ALABS
Sent: Friday, July 28, 2006 4:09 PM
To: Jim Jones
Cc: [email-masked]; 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.

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,

CCAMP co-chairs