|
Jonathan,
These statements are not only not correct, they don't make
sense considering you were involved in the work, do a refresh and go back in the
years, and you will see ITU-IETF liaisons (prior to
publication):
and:
and there are many more. My co-chair, our previous ccamp
co-chair, and Kam (ITU's Q14 Rap) have worked together over these past
couple of years to ensure the ASON work progressed - jointly. Considering the
number of cross-participants, a lack of IETF-OIF liaison can not be used
as the basis of the current confusion and duplication in work. And
anyone can participate and access IETF documents - it's an open
process.
If this OIF document is on an OSPF implementation "has been
implemented by many vendors" and the vendors intend it to be
production use (vs. experimental), then the OIF (or a vendor) needs
to follow the IETF process. That's a different subject.
The current liaison was scoped as requirements which is why
we are trying to understand it.
Lyndon has already responded saying he believes there is no
mis-alignment. Thanks Lyndon. We will go with that.
Thanks,
Deborah From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Sent: Tuesday, July 25, 2006 12:29 PM To: Brungard, Deborah A, ALABS; Ong, Lyndon; ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: Proposed response to OIF on OSPF ENNI Hi
Deborah, It seems that your
response centers on three topics: 1.
The
alignment of the IETF architecture/eval documents with the
requirements/architecture of other groups, 2.
The OIF
3.
Whether
the participants in the design teams did so in any official capacity on behalf
of other groups Regarding Topic
1: It’s too
bad that your exhibit makes my point well – that the text was NOT liaised to the
ITU for review/agreement prior to sending it for publication. If you look
at the liaison you provided: -
you will
see it says “for information”, not for action meaning there is no intent to find
out if it is aligned, and -
you will
note the email you provided states it was notifying ITU of publication. Witness
the specific text: “The CCAMP working
group is pleased to inform you of the _publication_ of RFC
4258" Again, I
state that the final IETF requirements and IETF evaluation documents were not
liaised to the ITU for review/agreement, so it is impossible to say if they are
aligned with the OIF requirements. To remove
any potential receiver confusion what this statement means, let me put in
another way: WHEREAS,
the ITU has developed a set of requirements and architecture for ASON routing
commonly known as G.8080, G.7715 and G.7715.1, and WHEREAS,
the members of the OIF are on record that the requirements and architecture
specified in G.8080, G.7715 and G.7715.1 are the requirements and architecture
to be followed by the OIF, and WHEREAS,
the IETF has been working on documents which purport to be accurate restatements
of the requirements and architecture specified by ITU for ASON routing,
and WHEREAS,
the final documents of the IETF have not been liaised to the ITU for the
purposes of review or agreement prior to publication, allowing determination
that they are accurate restatements, THEREFORE,
it cannot be said that the documents of the IETF are aligned with the
requirements or architecture specified by the ITU,
and THEREFORE,
it cannot be said that the documents of the IETF are aligned with the
requirements or architecture of the OIF. Please be
aware the reason that the OIF did NOT restate the ITU Requirements and
Architecture documents (unlike CCAMP), and instead went on record saying that
the ITU documents were the requirements and architecture documents to be
followed was to REMOVE the possibility of OIF-speak, and support convergence on
well-defined ITU-speak. This goes a long way to removing
confusion. Regarding Topic
2: The IETF
requirements and evaluation documents don’t make any specific statements about
the fitness of IETF protocols for ASON routing. The OIF document text (which
predates even the IETF requirements document) is making specific statements
about OSPF – statements that are based on Section 10 of G.8080. CCAMP has not
finished (started?) a document that makes any specific statements about
OSPF. Again I
ask, wouldn’t it be better to look at this document which has been implemented
by many vendors, and successfully interoperability tested many times over many
years to see what can be leveraged instead of starting from
scratch? Regarding Topic
3: While
Lyndon and I are participants in the ITU and OIF, we are not authorized to make
statements on behalf of either organization other than the statements authorized
by those organizations. Our participation in the design teams were not as
official representatives of the ITU or OIF. The only way for the documents
to be considered aligned would be to liaise them prior to publication to the ITU
or OIF for review/agreement and wait for the response. Again, since this
was not done, it is unclear if the documents are in
alignment. It should
also be noted that the OIF has been interested in setting up a formal OIF-IETF
liaison relationship to remove this misconception, while CCAMP has prevented it.
It seems that the confusion in the IETF would be lower if the liaison
relationship was formed. Certainly, this level of confusion does not exist
in the ITU where an OIF-ITU liaison relationship has existed for many
years. I look forward to
reviewing the new liaison text. From: Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] Hi
Jonathan, I think you meant OIF
below, as ITU and IETF work on ASON has been tightly coordinated e.g. a quick
back search: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=150 This mis-match is
always the concern when work is duplicated in other groups.For OIF
to be progressing a document identifying issues with GMPLS for
supporting ASON when already CCAMP has finished their document is not only a
misuse of people's time (both in OIF and IETF), it also causes
confusion in the industry (we now have ITU-speak, CCAMP-speak, and
OIF-speak). As the hope of the
CCAMP's ASON Design Teams was to have a representation of ITU, OIF, and CCAMP
(especially considering Lyndon is OIF's Liaison to CCAMP (and editor of the OIF
document) and you as chair), if both of you have difficulty judging the
alignment of this document vs. ASON requirements and CCAMP's work, then the
document is not helping either OIF's intention to develop standards
in alignment with ITU and IETF or CCAMP's ability to develop an ASON
solution. We should re-spin the
Liaison to inform OIF that this work has been completed in CCAMP and
to request that OIF's evaluation sections be removed and replaced with
references to the Evaluation document (vs. trying to do multiple-speak which has
us all confused) and expand on the comments (Dimitri's mail which Lyndon has
agreed is very useful). I'll work on it today, and send
later. "Significant" Thanks on
the confusion;-) Deborah From: Sadler,
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] Hi
Deborah, While I do not speak
for the OIF, I can say that the members of the OIF are on record (by motion) to
follow the Requirements and Architecture specified in G.8080, G.7715 and
G.7715.1. Since the final IETF requirements and IETF evaluations documents
were never liaised to the ITU for comment/agreement before they were sent for
publication, I cannot say that they are aligned with the requirements of the
OIF. Regards, From: Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] Hi
Jonathan, I just sent mail to
Lyndon to ask if he felt CCAMP's work was aligned. From your mail below, you do
believe that CCAMP's ASON requirements document and evaluation document meet the
needs of OIF? As the OIF Liaison stated it specified requirements, we
do want to ensure that the work is aligned. Thanks, Deborah From: Sadler,
Jonathan B. [mailto:Jonathan.Sadler@tellabs.com] 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, From: Ong,
Lyndon [mailto:Lyong@Ciena.com] 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 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] 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, From:
owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A,
ALABS 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 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)? 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. 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, CCAMP co-chairs ============================================================The information contained in this message may be privilegedand confidential and protected from disclosure. If the readerof this message is not the intended recipient, or an employeeor agent responsible for delivering this message to theintended recipient, you are hereby notified that any reproduction,dissemination or distribution of this communication is strictlyprohibited. If you have received this communication in error,please notify us immediately by replying to the message anddeleting it from your computer. Thank you. Tellabs========================================================================================================================The information contained in this message may be privilegedand confidential and protected from disclosure. If the readerof this message is not the intended recipient, or an employeeor agent responsible for delivering this message to theintended recipient, you are hereby notified that any reproduction,dissemination or distribution of this communication is strictlyprohibited. If you have received this communication in error,please notify us immediately by replying to the message anddeleting it from your computer. Thank you. Tellabs========================================================================================================================The information contained in this message may be privilegedand confidential and protected from disclosure. If the readerof this message is not the intended recipient, or an employeeor agent responsible for delivering this message to theintended recipient, you are hereby notified that any reproduction,dissemination or distribution of this communication is strictlyprohibited. If you have received this communication in error,please notify us immediately by replying to the message anddeleting 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 ============================================================ |