RE: Proposed response to OIF on OSPF ENNI

["Brungard, Deborah A, ALABS" <[e-mail]>]

below (noted as db>)...
 
Lyndon, do you think the OIF document and CCAMP's ASON Requirements and
Evaluation document are aligned?
 
Thanks,
Deborah

________________________________

From: Ong, Lyndon [mailto:[e-mail]] 
Sent: Monday, July 24, 2006 3:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [e-mail]
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. 
db> "significant" was not based on "newness" as a feature, it was based
on what GMPLS OSPF can support today.
 
-- 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.
db> G.7715.1 is on requirements for link state protocols - it does not
define requirements for inter-carrier ENNI routing protocols. And, I
differ with your view on IETF documents, IETF documents do specify. And
this OIF document also specifies - Figure 1 shows it for use between
Carriers. The document may "leave it to the carrier", but OIF claims it
can do. I would presuppose an Implementation Agreement would properly
scope the solution. Inter-carrier was not included in the ASON-GMPLS
routing requirements. Do you think the same solution can be used
inter-carrier?
 
-- 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.
db> GMPLS-ASON did not identify the need to advertise and use in the ERO
a transport plane name (OIF/section 4.2) - unless OIF-speak for a TE
Router is "transport plane name". The only GMPLS-ASON identified need
was if non-unique link IDs (e.g. unnumbered) were supported, an optional
TLV was identified which could be used. Note, GMPLS links are not
representing "data plane" (RFC4394 provides a good mapping of
terminology). And, this was not based on the issue which OIF identified
in section 4.2, "identifier namespaces are merged together" in GMPLS.
 
-- 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".

db> None of the identified "issues for extensions" aligns, and none of
the DDRP protocol elements listed in the Appendix and used for prototype
testing align. If the identified issues do not align, how will IETF
provide extensions? ITU future work?
 
I think we're experiencing a significant miscommunication...
db> Agree;-)
 
Cheers,
 
Lyndon

________________________________

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [e-mail]
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:[e-mail]] 
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [e-mail]
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
<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
============================================================