[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed response to OIF on OSPF ENNI
jonathan & lyndon
o) During Dallas CCAMP meeting, IETF 66, we have had the following
discussion (extracted from the meeting minutes)
"Kireeti: What would make me happy is not to have extensions defined in
IAs
Work has been done in the IETF. Instead, we will have objects in
the specs and IAs
Putting the extensions in an informational appendix is still
confusing, especially
as vendors have implemented them for demos
I would prefer that you just point to IETF so as extensions
evolve in the IETF, you
stay coordinated
Jim: We [the OIF] don't think that differently
One of our goals is to align and converge.
We understand we are using experimental codepoints"
so, it is rather unclear why there is so much hubub when IETF proposes to
achieve this objective ? if i well understand your opinion is that IETF
should not target this objective ? let's assume this is the case, it still
does not allow OIF to bypass the MPLS-GMPLS change process
o) concerning the alignment of IETF vs G.7715 and G.7715.1, from the IETF
liaison webpage you will see that a set of exchanges between bodies has
been conducted to ensure such alignment; however, as ITU should be
defining ASON routing requirements your statement "I cannot say that they
are aligned with the requirements of the OIF" is totally unclear to me.
Does OIF has its own requirements or are OIF requirements not fully
aligned with ITU G.7715/.1 ? This question should be reflected in the
liaison to OIF - as a CLEAR response from OIF will surely help sorting the
present situation
o) what is the real "issue" by pointing to the addressing i-d, the latter
just provides recommendation in case of 1:1 corr. between data and control
plane entities; i thought ASON was looking at larger scope - so what's the
point beside trying to mis-use any IETF production to corroborate the
GMPLS OSPF digression of Section 4.1 of the OIF IA ?
o) the tone of the OIF IA is its first sections is totally inappropriate
and misleading - so requires major revision - by reading one got the
impression by reading that a) OIF puts premises of a new protocol
recommendation while also stating it is a demo code reporting for a single
level - this must be seriously revisited b) OIF has apparently discovered
major holes and flaws, while issue is limited to unnumbered links with
overlapping ID space per TE Router ID (as detailed in section 5.7 of the
eval doc) - alignment on these aspect(s) is also more than recommended
imho
o) at the end, the major concern is that it is totally unclear what the
purpose of the OIF IA OSPF extensions are, if the intention of OIF is to
push them outside OIF demo scope (which seems to be the case since the
document passes through OIF ballot process and thus will be openly
available after this phase), then de-facto it is an OIF dutty to ask IETF
for in-depth revision and full alignment before publication
ps: to achieve a standard you need running code, but not any running code
becomes a standard even informational (hopefully);
-d.
"Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>
Sent by: owner-ccamp@ops.ietf.org
24/07/2006 22:31
To: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ong,
Lyndon" <Lyong@Ciena.com>, <ccamp@ops.ietf.org>
cc: "Adrian Farrel" <adrian@olddog.co.uk>
Subject: RE: Proposed response to OIF on OSPF ENNI
Hi Deborah, Lyndon, et al,
Some additional comments:
- The hierarchical model discussed in the draft IA liaised may be
supported without any modifications to OSPF. As discussed in earlier
emails, it can be implemented solely through the import/export of
information described in Appendix I of G.7715.
- The draft IA also recognizes namespace issues exist between Router ID
and the IP Address that messages are sent to (ITU calls this the RC PC SCN
address). This issue is also discussed in
draft-ietf-ccamp-gmpls-addressing.
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
============================================================