RE: Proposed response to OIF on OSPF ENNI
"Ong, Lyndon" <Lyong@Ciena.com> Tue, 25 July 2006 21:21 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ULK-0003fi-E9 for ccamp-archive@ietf.org; Tue, 25 Jul 2006 17:21:30 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ULF-0006py-Hq for ccamp-archive@ietf.org; Tue, 25 Jul 2006 17:21:30 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1G5UFT-000HDg-JX for ccamp-data@psg.com; Tue, 25 Jul 2006 21:15:27 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.1.1
Received: from [63.118.34.24] (helo=ripley.ciena.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from <Lyong@Ciena.com>) id 1G5UFK-000HC4-0C; Tue, 25 Jul 2006 21:15:18 +0000
Received: from mdmail4.ciena.com (HELO mdmxm02.ciena.com) ([63.118.39.27]) by ripley.ciena.com with ESMTP; 25 Jul 2006 17:30:46 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Proposed response to OIF on OSPF ENNI
Date: Tue, 25 Jul 2006 17:10:42 -0400
Message-ID: <0901D1988E815341A0103206A834DA07F1A2CF@mdmxm02.ciena.com>
In-Reply-To: <OFFA1F9E22.BA240709-ONC12571B6.00631DA5-C12571B6.0063E931@netfr.alcatel.fr>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Proposed response to OIF on OSPF ENNI
Thread-Index: AcawFcD5668O9FcgTgiqRfldOQ7h9QAGFTUw
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: Dimitri.Papadimitriou@alcatel.be
Cc: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, owner-ccamp@ops.ietf.org
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 231d7929942febf3be8fd5be2903302f
Hi Dimitri, Regarding the scope, I don't think the scope is that complicated. However, I will reflect to OIF that there is confusion about the scope of the document and as editor will see what I can do to help clarify these. Cheers, Lyndon -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Tuesday, July 25, 2006 11:11 AM To: Ong, Lyndon Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS; Sadler, Jonathan B.; owner-ccamp@ops.ietf.org Subject: RE: Proposed response to OIF on OSPF ENNI lyndon - see my reply to jonathan on this specific point - i can sum'up the evaluation phases lead to different premises and ext. guidelines (in addition to the specific OIF reachability information encoding) hence, these extensions are not reconcilable without reconsidering the protocol evaluation itself - it is the basic reason why i have been so scrupulous in driving this evaluation work as accurate as possible - and the reason why the proposed liaison text directly referred to this Section 4.1 ps: could you answer to my previous post ? on OIF IA scope "Ong, Lyndon" <Lyong@Ciena.com> 25/07/2006 20:01 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, <owner-ccamp@ops.ietf.org> Subject: RE: Proposed response to OIF on OSPF ENNI Hi Dimitri, Well, they could of course become agreed standard codepoints if CCAMP adopted them (unlikely as that appears to be given the past history of CCAMP and any protocol proposals made by other bodies) hence "at this time" seemed like a required note. OIF would of course be very happy if CCAMP agreed to adopt the formats that were implemented during OIF prototype testing, this is still possible :o) Cheers, Lyndon -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Tuesday, July 25, 2006 10:54 AM To: Ong, Lyndon Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS; Sadler, Jonathan B.; owner-ccamp@ops.ietf.org Subject: RE: Proposed response to OIF on OSPF ENNI lyndon - indeed this is mentioned - the concern here can be formulated as follows: section 1.2 of the OIF IA is unclear about positioning and exact intention with the proposed extensions (in Appendix) "These extensions use codepoints in the range reserved by IANA for private and experimental use, and are not agreed standard codepoints at this time. Future developments may result in change to the codepoints and/or formats of these extensions." you wrote: "the statement on codepoints in the appendix was not intended as a statement that the prototype codepoints are expected to become standard; it is recognized that IETF (and ITU) are the standards-generating bodies. This was a general statement allowing for changes or extensions in future experimental activities." the fact that the sentence combines "at this time" and points to potential "standard codepoints" means that we have to warn OIF about implication i.e. if OIF intents to change their status (toward standard codepoints) then the extensions will be de-facto subject to the MPLS/GMPLS change process from the IETF perspective ps: this is also the reason why there is a direct relationship between objective of the document (see previous post) and listed extensions - "Ong, Lyndon" <Lyong@Ciena.com> Sent by: owner-ccamp@ops.ietf.org 25/07/2006 18:55 To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com> cc: "Adrian Farrel" <adrian@olddog.co.uk>, <ccamp@ops.ietf.org>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>, <owner-ccamp@ops.ietf.org> Subject: RE: Proposed response to OIF on OSPF ENNI Hi Dimitri, I completely agree with you that there is much unnecessary hubbub going on. The document does in fact point to IETF (and ITU) for standard extensions to the routing protocols. From the discussion I have the sense that there is some unhappiness with the document focusing on requirements that are still in the process of being addressed within CCAMP, but since it points to the drafts being done here if anything it should focus reader's attention on the work here in CCAMP rather than anywhere else. Cheers, Lyndon -----Original Message----- From: Dimitri.Papadimitriou@alcatel.be [mailto:Dimitri.Papadimitriou@alcatel.be] Sent: Tuesday, July 25, 2006 3:18 AM To: Sadler, Jonathan B.; Ong, Lyndon Cc: Adrian Farrel; ccamp@ops.ietf.org; Brungard, Deborah A, ALABS; owner-ccamp@ops.ietf.org Subject: 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-ev al-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 ============================================================
- Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- Re: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- Re: Proposed response to OIF on OSPF ENNI Tomohiro Otani
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Drake, John E
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- Re: Proposed response to OIF on OSPF ENNI Richard Rabbat
- RE: Proposed response to OIF on OSPF ENNI Drake, John E
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Drake, John E
- shared mesh restoration - e2e recovery signaling … Payam Torab
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- Re: shared mesh restoration - e2e recovery signal… Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Drake, John E
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: shared mesh restoration - e2e recovery signal… Payam Torab
- RE: shared mesh restoration - e2e recovery signal… Dimitri.Papadimitriou
- RE: shared mesh restoration - e2e recovery signal… Payam Torab
- RE: shared mesh restoration - e2e recovery signal… Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI MEURIC Julien RD-CORE-LAN
- Alignment of OIF routing requirements with CCAMP … Adrian Farrel
- Addressing draft [Was: Proposed response to OIF o… Adrian Farrel
- Re: Proposed response to OIF on OSPF ENNI Adrian Farrel
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Drake, John E
- An IETF / OIF liaison relationship Was: (Re: Prop… Loa Andersson
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS