RE: Second incoming communication from the OIF
"Brungard, Deborah A, ALABS" <dbrungard@att.com> Mon, 22 November 2004 21:47 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24148 for <ccamp-archive@ietf.org>; Mon, 22 Nov 2004 16:47:40 -0500 (EST)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWM5d-00023q-2b for ccamp-archive@ietf.org; Mon, 22 Nov 2004 16:51:21 -0500
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CWLqV-000HIJ-MS for ccamp-data@psg.com; Mon, 22 Nov 2004 21:35:39 +0000
Received: from [192.128.167.69] (helo=almso1.proxy.att.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CWLqS-000HHc-Mj for ccamp@ops.ietf.org; Mon, 22 Nov 2004 21:35:36 +0000
Received: from attrh5i.attrh.att.com ([135.38.62.12]) by almso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id iAMLZ7tf011266 for <ccamp@ops.ietf.org>; Mon, 22 Nov 2004 16:35:35 -0500
Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.13) by attrh5i.attrh.att.com (7.1.006) id 41A0CAEE0003DC72; Mon, 22 Nov 2004 16:35:35 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Second incoming communication from the OIF
Date: Mon, 22 Nov 2004 15:35:35 -0600
Message-ID: <449B2580D802A443A923DABF3EAB82AF084AEC72@OCCLUST04EVS1.ugd.att.com>
Thread-Topic: Second incoming communication from the OIF
Thread-Index: AcTOa2YM2iUW+Ss+Qmy1kEoLVfgHcgCVYP1Q
From: "Brungard, Deborah A, ALABS" <dbrungard@att.com>
To: Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.1
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1
Content-Transfer-Encoding: quoted-printable
Hi Adrian, While this liaison may be considered "for information", it communicates OIF's recognition and concern regarding the incompatibility problems of G7713.2/UNI1.0 (SONET/SDH) with GMPLS, and regretfully (for operators and vendors), it seems OIF is choosing to freeze it's work. While G8080 recognizes multiple protocols may exist, it does not encourage redundant (same) protocol mechanisms for the same capability, and proliferation of interworking functions. Here's a suggested response... ----------------- It is regretful that you consider your SONET/SDH implementation agreements frozen. Considering the (published) UNI1.0 statement: "since the intent of OIF is to develop UNI protocols in close alignment with the IETF work, any changes in GMPLS/LMP proposed standards that could be incorporated in UNI signaling specifications will be included in future versions", we had hoped to cooperatively work with you to minimize the divergence between OIF IA on SONET/SDH and RFC3473 in the best interests for the industry. Noting your lack of a definition of "domain" at this time (re. your 2nd liaison regarding OIF demo results), we question your interpretation (below) of RFC3473 and the title "interworking of ASON-GMPLS network domains". Per G8080, domains are based on functionality e.g. signaling, routing. RFC3473 is a standard signaling interface for use between different vendor equipment and different signaling domains (i.e. ENNI and INNI). Recent work extended to UNI support. And as previously communicated, CCAMP is progressing standards-track ASON-GMPLS (in cooperation with ITU-T) in support of the full set of G8080 call functionalities (i.e. independent call/connection setup and support of multiple connections per call). For your interworking design guidelines, we recommend for you to clarify when referencing a non-standard signaling implementation or standard RFC3473. As a basis for your work, we recommend use of our ASON-GMPLS work to ensure proper interpretation of standard RFC3473's capabilities in support of G8080. We can understand OIF operators' concerns on the potential for mis-interpretation and the need for design guidelines considering the multiplicity of protocols "based on RSVP". Hopefully, as you progress this work, you will reconsider using UNI1.0 protocol mechanisms based on standards-track modifications of RSVP. We look forward to working with you on OIF UNI2.0 using CCAMP's standards track work. ----------- Regards, Deborah -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Friday, November 19, 2004 2:09 PM To: ccamp@ops.ietf.org Subject: Second incoming communication from the OIF A second communication from Jim Jones, Chair of the OIF Technical Committee, lands on my e-doorstep. This communication is helpfully in two files with different formats (one PDF and one PowerPoint). I have reproduced the text below. Again, the real copy can be found at http://www.olddog.co.uk/incoming.htm Adrian === November 5, 2004 Mr. Adrian Farrel, adrian@olddog.co.uk, IETF, CCAMP Working Group Chair Mr. Kireeti Kompella, kireeti@juniper.net, IETF, CCAMP Working Group Chair Re: New OIF Project on Interworking of ASON - GMPLS Network Domains Dear Adrian and Kireeti, I want to inform you of a new work project that was proposed and adopted by the OIF members at our 4Q Technical Committee meetings that took place October 26-28. The project will result in a design guideline document to assist vendors and carriers in optical networks where signaling interworking is required between OIF/ITU-T ASON and GMPLS RSVP-TE. As we have seen in interoperability trials and initial deployments, vendor implementations sometimes use different control plane protocols, depending on the NE requirements and function within a network. The OIF and ASON control plane requirements were written with the knowledge that a network composed of multiple domains could support a heterogeneous set of protocols. An NE that exists at a boundary between network domains may support a different protocol on either side of the boundary (for example OIF UNI on the client side and GMPLS I-NNI on the network side). An interworking design guideline was cited as a high priority by OIF member companies, both carriers and vendors. It is also our understanding that an interworking guide is not currently within the work scope of either IETF CCAMP or ITU-T SG15. An outline of the project plan is provided in the document oif2004.442.01. Although the proposal illustrates an example network configuration (featuring GMPLS as INNI protocol), this is an example only and not meant to restrict interworking considerations to this model. In contrast to OIF Implementation Agreements (IAs), the design guideline will define optional interworking methods between existing optical control plane protocols. This will allow software stack vendors and system vendors to map information, messages and behaviors between different protocols while preserving the required functionality on each side of the interface. We expect the OIF, ITU-T and IETF will continue to work together to minimize or eliminate differences between control plane signaling protocols. Given that different protocols currently exist to meet different requirements, an interworking guide can help ensure straightforward protocol interoperation. We welcome your input on this project and look forward to future collaboration. Sincerely, Jim Jones OIF Technical Committee Chair cc: statements@ietf.org ==== Slide1 Project proposal for interworking of G.8080 - RFC 3473 network domains Contribution Number: oif2004.442.00 Working Group: Architecture & Signaling Title: Project proposal for interworking of G.8080 - RFC 3473 network domains Meeting: 4Q2004 Source: Eve Varma Monica Lazer Hans-Martin Foisel Satoru Okamoto Jonathan Sadler Vishnu Shukla Lyndon Ong Date: October 28, 2004 Abstract: This contribution proposes to initiate a project with the intention of publishing a design guideline document for interworking between OIF/ITU-T ASON control plane interfaces (UNI, E-NNI) and IETF/GMPLS network domains. Notice: This contribution has been created to assist the Optical Internetworking Forum (OIF). This document is offered to the OIF solely as a basis for discussion and is not a binding proposal on the companies listed as resources above. Each company in the source list, and the OIF, reserves the rights to at any time to add, amend, or withdraw statements contained herein. This Working Text represents work in progress by the OIF, and must not be construed as an official OIF Technical Report. Nothing in this document is in any way binding on the OIF or any of its members. The document is offered as a basis for discussion and communication, both within and without the OIF. For additional information contact: The Optical Internetworking Forum, 39355 California Street, Suite 307, Fremont, CA 94538 510-608-5990 phone F info@oiforum.com (c) 2001 Optical Internetworking Forum === Slide2 Contributors and Supporters Alcatel, Jim Jones AT&T - Monica Lazer Avici - Amy Wang Ciena - Lyndon Ong Cisco - Richard Bradford Deutsche Telekom - Hans-Martin Foisel Lucent - Eve Varma NTT - Satoru Okamoto Tellabs - Jonathan Sadler Verizon - Vishnu Shukla . === Slide3 Network graph === Slide4 Project Start Objective: Generate an design guideline document for the interoperability of OIF/ITU-T ASON and IETF/GMPLS network domains Scope E-NNI, I-NNI(GMPLS) and UNI interoperability among these different network architecture approaches Expected Output Design guideline document (technical report) on this topic; not an Implementation Agreement Interaction with other forums and standards bodies Close cooperation with IETF/CCAMP and ITU-T,Q14/SG15 MTNM Interaction with other OIF WG Carrier, OAM&P, Interoperability Why the OIF? Interworking and interoperability among different standardization bodies specifications and standards approaches is a key goal of the Optical Internetworking Forum === Slide5 Project Timeline Project Start: This meeting (Oct 2004) Liaison to ITU and IETF describing project scope and soliciting interest: until next meeting Solicit and receive contributions for 2 quarterly meetings Baseline draft 2nd Quarter 2005 Proposed editor: Hans-Martin Foisel Straw ballot 3rd quarter 2005 Principal ballot 1st quarter 2006 === Slide6 Motivation: Why Now? Broad vendor and carrier support - Strong request from the carrier and vendor members for interworking among network domains, which may use IETF or OIF/ITU-T standards and specifications. Current activities at IETF CCAMP design teams could benefit from this document This document will be based not only on available standards and specifications but also on first practical testing experiences === Slide7 References to Standards Contributions RFC 3471, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description" RFC 3473, "Generalized Multi-Protocol Label Switching (GMPLS)Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions". RFC 3630, "Traffic Engineering (TE) Extensions to OSPF Version 2 ". "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-gmpls-routing-09.txt, work in progress.. OIF-UNI 1.0 Release 2, "OIF-UNI-01.0-R2-Common - User Network Interface (UNI) 1.0 Signaling Specification, Release 2: Common Part" and "OIF-UNI-01.0-R2-RSVP - RSVP Extensions for User Network Interface (UNI) 1.0 Signaling, Release 2" OIF E-NNI 1.0 Signaling, "OIF-E-NNI-Sig-01.0 - Intra-Carrier E-NNI Signaling Specification" === Slide8 References to Standards Contributions ITU-T G.8080/Y.1304, "Architecture for the Automatically Switched Optical Network (ASON)" ITU-T G.7713, "Distributed Call And Connection Management (DCM)".ITU-T ITU-T G.7713.1, "Distributed Call and Connection Management (DCM) based on PNNI".ITU-T ITU-T G.7713.2, "Distributed Call and Connection Management: Signalling mechanism using GMPLS RSVP-TE".ITU-T ITU-T G.7713.3, "Distributed Call and Connection Management: Signalling mechanism using GMPLS CR-LDP" ITU-T G.7715, "Architecture and Requirements for Routing in the Automatic Switched Optical Networks".ITU-T ITU-T G.7715.1, "ASON Routing Architecture and Requirements for Link State Protocols" === Slide9 References to Standards Contributions oif2004.435: Discussion points from routing solutions design team oif2004.383: Project proposal for interworking to RFC 3473 oif2004.357: Interworking of OIF UNI/E-NNI with RFC 3473 GMPLS oif2004.303: IETF draft with comparison of GMPLS and ASON signaling
- Second incoming communication from the OIF Adrian Farrel
- RE: Second incoming communication from the OIF Brungard, Deborah A, ALABS
- RE: Second incoming communication from the OIF Ong, Lyndon
- RE: Second incoming communication from the OIF Kireeti Kompella
- Re: Second incoming communication from the OIF Adrian Farrel
- RE: Second incoming communication from the OIF Ong, Lyndon
- RE: Second incoming communication from the OIF Ong, Lyndon