|
Hello Deborah, Again, you make my point. The outgoing
liaison you have included below (https://datatracker.ietf.org/documents/LIAISON/file132.txt)
is the ONLY liaison sent to the ITU for
review/comment on the IETF eval document. It should also be noted that
this outgoing liaison is for draft-ietf-ccamp-gmpls-ason-routing-eval-00, while
-03 is the version that was sent for publication. And if you look at the response from the
ITU (the other liaison you include https://datatracker.ietf.org/documents/LIAISON/file151.doc)
you will note the response a comment section 6 regarding
inclusion of a scenario where multiple Ri announce on behalf of an Li. Inclusion
of this scenario was discussed in the design team and pushed by the “cross-participants”.
Still, Section 6 of the document in the RFC editors queue (http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt)
does not contain such a scenario. It would be interesting to see what a
liaison to ITU for review/agreement would say about this document… But,
until one is sent, it is impossible to say that the documents are completely aligned.
Likewise, it is unwise to say that it is completely aligned with the
requirements of the OIF. Regards, From: Brungard,
Deborah A, ALABS [mailto:dbrungard@att.com] 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): https://datatracker.ietf.org/documents/LIAISON/file151.doc and: https://datatracker.ietf.org/documents/LIAISON/file132.txt 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] 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 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 ============================================================ |