Subject: RE: Second incoming communication from the OIF

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 23 Nov 2004 16:54:57 -0500

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:[email-masked]]
Sent: Monday, November 22, 2004 1:36 PM
To: Adrian Farrel; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Friday, November 19, 2004 2:09 PM
To: [email-masked]
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, [email-masked], IETF, CCAMP Working Group Chair
Mr. Kireeti Kompella, [email-masked], 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: [email-masked]

====
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 [email-masked]
(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

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 24 Nov 2004 08:34:56 -0800 (PST)

Hi Lyndon,

On Tue, 23 Nov 2004, Ong, Lyndon wrote:

> protocols.

Our concern is with the project as a whole.  There are several
deficiencies in G.7713.2 and the OIF UNI; these have been pointed out
many times by CCAMP, and liaised to the ITU, but we are not aware of
any significant changes that have been made to the OIF UNI or to
G.7713.2 to address these problems.  In view of this, it seems
premature to expend effort attempting to build networks that interwork
the OIF UNI with GMPLS since future work to fix the OIF UNI is likely
to have considerable impact on any interworking specifications.  The
real problem (namely, the ASON signaling requirements as well as a UNI
and E-NNI) have also been addressed by CCAMP; to continue work on
G.7713.2, and in fact to use it as the ASON signaling standard at the
UNI and E-NNI seems to us very shortsighted indeed.

The communication says, "We expect the OIF, ITU-T and IETF will
continue to work together to minimize or eliminate differences between
control plane signaling protocols."

Certainly a laudable goal.  Persisting with G.7713.2 and the OIF UNI
without any willingness to adapt these specifications clashes with
this goal.  Working together implies converging -- the IETF took a big
step in this direction by acceding to the ASON signaing requirements
as stated; it doesn't seem that the ITU-T or OIF are willing to take
similar steps.

> As you note, GMPLS is being extended to support ASON

And very importantly, to state the need for more work on this front,
rather than beginning work on convergence at once.

> continues to develop, this will need to be taken into account.

At what stage?  It seems that instead of converging, the object seems
to develop a full suite of competing protocols, and only then take the
GMPLS suite into account.

Kireeti.
-------

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 Nov 2004 17:59:28 -0000

Lyndon,
On another, but related, thread from this communication...

Do you know whether
  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.
refers to just a subset of the ITU-T ASON or to the whole of it?

For example, there is a basic discrepancy between (for example) G.7713.2 and G.7713.3 in
terms of how Call setup is managed. Since the architecture is intended to be entirely
abstract, the initiating UNI-C cannot know whether the responding UNI-C expects to see
independent or piggy-backed Call setup. This same issue applies at E-NNI reference points.

Although it is possible to conceive of ways of managing this type of problem within
network nodes (for example, at the UNI-N) I should think that a basic requirement before
documenting interworking between OIF/ITU-T ASON and GMPLS RSVP-TE is to document
interworking between OIF and ITU-T ASON.

Thanks,
Adrian
----- Original Message ----- 
From: "Kireeti Kompella" <[email-masked]>
To: "Ong, Lyndon" <[email-masked]>
Cc: "'Brungard, Deborah A, ALABS'" <[email-masked]>; "Adrian Farrel"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, November 24, 2004 4:34 PM
Subject: RE: Second incoming communication from the OIF