RE: Proposed response to OIF on OSPF ENNI

["Ong, Lyndon" <Lyong@Ciena.com>]

Hi Dimitri,

Thank you!  I was putting together a response to Deborah's email, but 
actually I think your email clears up a great deal (and to me would be
a much clearer basis for a liaison response to OIF).

- yes, I see that there is some sensitivity to the table in 4.1
- yes, the positioning of the document is ambiguous as to intra or
inter-carrier
and this should probably be discussed at OIF in comment resolution
- please separate out the main text from the appendix documenting
prototyping,
the appendix documents work that was already done experimentally,
whereas the 
main text is intended to reflect the output of IETF and ITU
- 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.

If the liaison could be revised according to this email, IMHO it will be
much
less confusing to OIF.

Cheers,

Lyndon

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Dimitri.Papadimitriou@alcatel.be
Sent: Monday, July 24, 2006 3:42 PM
To: Brungard, Deborah A, ALABS
Cc: Adrian Farrel; ccamp@ops.ietf.org; owner-ccamp@ops.ietf.org
Subject: Re: Proposed response to OIF on OSPF ENNI

hi - 

i looked at the OIF IA document, the below text proposed for liaison
includes most of the concerns

o) section 4.1 provides a table being an interpretation of OSPF that
deserves serious IETF review b/f publication 

o) positioning of this IA is confusing both in terms of scope intra- vs.

inter-carrier (it *seems* applicable to both while using OSPF as
inter-carrier routing protocol is more than questionable if not totally
wrong) and target (requirements (which) ? applicability of demo code ? 
experimental extensions ?)

o) section 1.2 is unclear about positioning of 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." meaning basically that
OIF has decided on its own that the proposed OSPF mechanisms are valid
and that only encoding could be subject to discussion but afaik OIF is
not authoritative for OSPF 

thanks,
- dimitri.







"Brungard, Deborah A, ALABS" <dbrungard@att.com> Sent by:
owner-ccamp@ops.ietf.org
21/07/2006 16:37
 
        To:     <ccamp@ops.ietf.org>
        cc:     "Adrian Farrel" <adrian@olddog.co.uk>
        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