RE: Second incoming communication from the OIF

"Ong, Lyndon" <Lyong@Ciena.com> Tue, 23 November 2004 22:05 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 RAA11771 for <ccamp-archive@ietf.org>; Tue, 23 Nov 2004 17:05:46 -0500 (EST)
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWiqh-0006MX-MM for ccamp-archive@ietf.org; Tue, 23 Nov 2004 17:09:41 -0500
Received: from majordom by psg.com with local (Exim 4.43 (FreeBSD)) id 1CWiXM-000CYT-U7 for ccamp-data@psg.com; Tue, 23 Nov 2004 21:49:24 +0000
Received: from [12.146.180.45] (helo=w2krtpexg01.ciena.com) by psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CWiXH-000CY1-7u for ccamp@ops.ietf.org; Tue, 23 Nov 2004 21:49:19 +0000
Received: by w2krtpexg01.ciena.com with Internet Mail Service (5.5.2653.19) id <XF210R4D>; Tue, 23 Nov 2004 16:54:59 -0500
Message-ID: <A0B25F46B778974A8B7F06029847681903115F17@w2krtpexg01.ciena.com>
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "'Brungard, Deborah A, ALABS'" <dbrungard@att.com>, Adrian Farrel <adrian@olddog.co.uk>, ccamp@ops.ietf.org
Subject: RE: Second incoming communication from the OIF
Date: Tue, 23 Nov 2004 16:54:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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: 73f7847c44628482de9d5f1018acf469

Hi Deborah,

Just to clear up any potential misunderstanding:

There hasn't been any recent decision on the part of OIF to freeze
its work (as UNI 1.0 goes back to 2001, it's already pretty cold ;o)
The interworking proposal came up very recently, and it was understood that
IETF and ITU-T have no plans to document interworking at this time.

I'm reading into your email a concern with the use of "ASON" in the title
of the project.  The interworking project is likely to cover ITU-T 
G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
account experiences that members have had implementing and testing
protocols.  As you note, GMPLS is being extended to support ASON
as well.  It sounds reasonable to comment that some clarification of
the project definition may be helpful.

This also raises a good point about GMPLS continuing to evolve beyond
RFC 3473.  As the work on GMPLS extensions to support ASON functionality 
continues to develop, this will need to be taken into account.

Cheers,

Lyndon


-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]
Sent: Monday, November 22, 2004 1:36 PM
To: Adrian Farrel; ccamp@ops.ietf.org
Subject: RE: Second incoming communication from the OIF


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