Given that:
- CCAMP has a milestone to publish an ASON routing solution by Nov 2006,
- CCAMP didn’t have at the time this was liaised (doesn’t have today?)
a working group document, and
- the draft IA has been successfully implemented by more than a dozen
vendors and interop-tested many times,
I would expect that we should be looking at this as experience/text
that could be leveraged... “Running code…” and all that…
Regards,
Jonathan Sadler
------------------------------------------------------------------------
*From:* Ong, Lyndon [mailto:Lyong@Ciena.com]
*Sent:* Monday, July 24, 2006 2:33 PM
*To:* Brungard, Deborah A, ALABS; Sadler, Jonathan B.; ccamp@ops.ietf.org
*Cc:* Adrian Farrel
*Subject:* RE: Proposed response to OIF on OSPF ENNI
Hi Deborah,
Here's what I would say is in and not in the OIF document:
-- G.7715, G.7715.1 and the IETF eval and solutions draft all identify
a need to support hierarchical
routing areas for ASON, I am perplexed as to why this seems to be
viewed as a new feature.
-- the document does not specify the domain of usage and leaves this
to the carrier. This is no different
from G.7715.1 and IETF drafts that do not explicitly state whether
they are used for intra- or inter-domain
interfaces.
-- GMPLS OSPF does not support a 1:N or N:1 relationship between
routing controller and transport
node, hence extensions are felt to be required - and are proposed in
the eval solutions draft. The
conclusions are no different.
-- the document does not in fact define any standard extensions to the
protocols, and points to future work
in IETF and ITU to provide these. Therefore I cannot understand where
you say "new extensions to
OSPF are specified" and "none...align with the CCAMP's GMPLS-ASON work".
I think we're experiencing a significant miscommunication...
Cheers,
Lyndon
------------------------------------------------------------------------
*From:* owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] *On
Behalf Of *Brungard, Deborah A, ALABS
*Sent:* Monday, July 24, 2006 12:15 PM
*To:* Sadler, Jonathan B.; ccamp@ops.ietf.org
*Cc:* Adrian Farrel
*Subject:* RE: Proposed response to OIF on OSPF ENNI
Hi Jonathan, (and Lyndon),
Thanks to both of you for responding.
"Significant" was referencing:
- supports a (new) hierarchical OSPF model
- supports inter-domain (inter-carrier) OSPF (not supported by today's
OSPF)
- identifies namespace issues with GMPLS OSPF which do not exist, and
proposes extensions to "fix"
- new extensions to OSPF are specified
- none of the proposed extensions align with CCAMP's GMPLS-ASON work
Did you have another adjective to suggest? We were thinking
"significant" was rather soft considering the above. Though if it's
just ITU-speak differences, why does the OIF liaison state it reflects
several years of work including testing? Any insight (alignment
mapping to CCAMP's work) which you or Lyndon can provide would be
helpful. The divergence is baffling to us.
Deborah
------------------------------------------------------------------------
*From:* Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]
*Sent:* Friday, July 21, 2006 11:34 AM
*To:* Brungard, Deborah A, ALABS; ccamp@ops.ietf.org
*Cc:* Adrian Farrel
*Subject:* RE: Proposed response to OIF on OSPF ENNI
Hi Deborah and Adrian,
I haven’t seen much discussion of the OIF E-NNI Routing document on
the CCAMP list. Can you tell me what parts of the document are
“significant modifications to the operation of OSPF”?
Thanks,
Jonathan Sadler
------------------------------------------------------------------------
*From:* owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] *On
Behalf Of *Brungard, Deborah A, ALABS
*Sent:* Friday, July 21, 2006 9:38 AM
*To:* ccamp@ops.ietf.org
*Cc:* Adrian Farrel
*Subject:* Proposed response to OIF on OSPF ENNI
Hi,
We had a communication from OIF on their OSPF ENNI specification. You
can see the original files on http://www.olddog.co.uk/ccamp.htm.
Having assembled comments from several people and our discussions in
Montreal, we have put together the following response.
Please comment on the list in the next week.
Thanks,
Adrian and Deborah
= = = = = = = = = =
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 working
on GMPLS ASON for several years and our Design Teams include 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 is not aligned with RFC 4258
(Requirements for Generalized Multi-Protocol Label Switching (GMPLS)
Routing for the Automatically Switched Optical Network (ASON)) or the
to-be-published:
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt.
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. Considering
the IETF document is ready for publication, we suggest in the
interests of time, that you align your document with the IETF
document. If any questions on the interpretation of the 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.
The 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 as an inter-carrier OSPF ENNI
Implementation Agreement claiming alignment with IETF RFCs without
review (or agreement) by any of the IETF Working Groups.//
3. 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). Perhaps you are confusing OSPF and GMPLS OSPF? 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.
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.
We request an additional round of communication of this document to
the IETF before approval to allow us to work with you to produce
convergence between OIF and IETF work which, we believe, will be in
the best interests of the industry.
Best regards,
Adrian Farrel and Deborah Brungard,
CCAMP co-chairs
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================
============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================