RE: Proposed response to OIF on OSPF ENNI

["Drake, John E" <[e-mail]>]

Is Jonathan showing off the fact that he just completed a typing class?

	-----Original Message-----
	From: Sadler, Jonathan B. [mailto:[e-mail]] 
	Sent: Tuesday, July 25, 2006 9:29 AM
	To: Brungard, Deborah A, ALABS; Ong, Lyndon; [e-mail]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI
	
	

	Hi Deborah,

	 

	It seems that your response centers on three topics:

	1.       The alignment of the IETF architecture/eval documents
with the requirements/architecture of other groups,

	2.       The OIF Draft IA making statements regarding the
identifiers used by GMPLS routing when carried by OSPF, and

	3.       Whether the participants in the design teams did so in
any official capacity on behalf of other groups

	 

	Regarding Topic 1:

	 

	It's too bad that your exhibit makes my point well - that the
text was NOT liaised to the ITU for review/agreement prior to sending it
for publication.  If you look at the liaison you provided:

	-    you will see it says "for information", not for action
meaning there is no intent to find out if it is aligned, and

	-    you will note the email you provided states it was
notifying ITU of publication. Witness the specific text:

	"The CCAMP working group is pleased to inform you of the
_publication_ of RFC 4258"

	 

	Again, I state that the final IETF requirements and IETF
evaluation documents were not liaised to the ITU for review/agreement,
so it is impossible to say if they are aligned with the OIF
requirements.

	 

	To remove any potential receiver confusion what this statement
means, let me put in another way:

	WHEREAS,      the ITU has developed a set of requirements and
architecture for ASON routing commonly known as G.8080, G.7715 and
G.7715.1, and

	WHEREAS,      the members of the OIF are on record that the
requirements and architecture specified in G.8080, G.7715 and G.7715.1
are the requirements and architecture to be followed by the OIF, and

	WHEREAS,      the IETF has been working on documents which
purport to be accurate restatements of the requirements and architecture
specified by ITU for ASON routing, and

	WHEREAS,      the final documents of the IETF have not been
liaised to the ITU for the purposes of review or agreement prior to
publication, allowing determination that they are accurate restatements,


	THEREFORE,   it cannot be said that the documents of the IETF
are aligned with the requirements or architecture specified by the ITU,
and

	THEREFORE,   it cannot be said that the documents of the IETF
are aligned with the requirements or architecture of the OIF.

	 

	Please be aware the reason that the OIF did NOT restate the ITU
Requirements and Architecture documents (unlike CCAMP), and instead went
on record saying that the ITU documents were the requirements and
architecture documents to be followed was to REMOVE the possibility of
OIF-speak, and support convergence on well-defined ITU-speak. This goes
a long way to removing confusion.

	 

	Regarding Topic 2:

	 

	The IETF requirements and evaluation documents don't make any
specific statements about the fitness of IETF protocols for ASON
routing. The OIF document text (which predates even the IETF
requirements document) is making specific statements about OSPF -
statements that are based on Section 10 of G.8080. CCAMP has not
finished (started?) a document that makes any specific statements about
OSPF.

	 

	Again I ask, wouldn't it be better to look at this document
which has been implemented by many vendors, and successfully
interoperability tested many times over many years to see what can be
leveraged instead of starting from scratch?

	 

	Regarding Topic 3:

	 

	While Lyndon and I are participants in the ITU and OIF, we are
not authorized to make statements on behalf of either organization other
than the statements authorized by those organizations.  Our
participation in the design teams were not as official representatives
of the ITU or OIF.  The only way for the documents to be considered
aligned would be to liaise them prior to publication to the ITU or OIF
for review/agreement and wait for the response.  Again, since this was
not done, it is unclear if the documents are in alignment.

	 

	It should also be noted that the OIF has been interested in
setting up a formal OIF-IETF liaison relationship to remove this
misconception, while CCAMP has prevented it.  It seems that the
confusion in the IETF would be lower if the liaison relationship was
formed.  Certainly, this level of confusion does not exist in the ITU
where an OIF-ITU liaison relationship has existed for many years.

	 

	I look forward to reviewing the new liaison text.

	 

	Jonathan Sadler

	 

	
________________________________


	From: Brungard, Deborah A, ALABS [mailto:[e-mail]] 
	Sent: Tuesday, July 25, 2006 9:58 AM
	To: Sadler, Jonathan B.; Ong, Lyndon; [e-mail]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	 

	Hi Jonathan,

	 

	I think you meant OIF below, as ITU and IETF work on ASON has
been tightly coordinated e.g. a quick back search:

	
https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=150

	 

	This mis-match is always the concern when work is duplicated in
other groups.For OIF to be progressing a document identifying issues
with GMPLS for supporting ASON when already CCAMP has finished their
document is not only a misuse of people's time (both in OIF and IETF),
it also causes confusion in the industry (we now have ITU-speak,
CCAMP-speak, and OIF-speak).

	 

	As the hope of the CCAMP's ASON Design Teams was to have a
representation of ITU, OIF, and CCAMP (especially considering Lyndon is
OIF's Liaison to CCAMP (and editor of the OIF document) and you as
chair), if both of you have difficulty judging the alignment of this
document vs. ASON requirements and CCAMP's work, then the document is
not helping either OIF's intention to develop standards in alignment
with ITU and IETF or CCAMP's ability to develop an ASON solution.

	 

	We should re-spin the Liaison to inform OIF that this work has
been completed in CCAMP and to request that OIF's evaluation sections be
removed and replaced with references to the Evaluation document (vs.
trying to do multiple-speak which has us all confused) and expand on the
comments (Dimitri's mail which Lyndon has agreed is very useful). I'll
work on it today, and send later.

	 

	"Significant" Thanks on the confusion;-)

	Deborah

	 

	
________________________________


	From: Sadler, Jonathan B. [mailto:[e-mail]] 
	Sent: Monday, July 24, 2006 5:38 PM
	To: Brungard, Deborah A, ALABS; Ong, Lyndon; [e-mail]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	Hi Deborah,

	 

	While I do not speak for the OIF, I can say that the members of
the OIF are on record (by motion) to follow the Requirements and
Architecture specified in G.8080, G.7715 and G.7715.1.  Since the final
IETF requirements and IETF evaluations documents were never liaised to
the ITU for comment/agreement before they were sent for publication, I
cannot say that they are aligned with the requirements of the OIF.

	 

	Regards,

	 

	Jonathan Sadler

	 

	
________________________________


	From: Brungard, Deborah A, ALABS [mailto:[e-mail]] 
	Sent: Monday, July 24, 2006 4:31 PM
	To: Sadler, Jonathan B.; Ong, Lyndon; [e-mail]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	 

	Hi Jonathan,

	 

	I just sent mail to Lyndon to ask if he felt CCAMP's work was
aligned. From your mail below, you do believe that CCAMP's ASON
requirements document and evaluation document meet the needs of OIF? As
the OIF Liaison stated it specified requirements, we do want to ensure
that the work is aligned.

	 

	Thanks,

	Deborah

	 

	
________________________________


	From: Sadler, Jonathan B. [mailto:[e-mail]] 
	Sent: Monday, July 24, 2006 4:32 PM
	To: Brungard, Deborah A, ALABS; Ong, Lyndon; [e-mail]
	Cc: Adrian Farrel
	Subject: RE: Proposed response to OIF on OSPF ENNI

	Hi Deborah, Lyndon, et al,

	 

	Some additional comments:

	 - The hierarchical model discussed in the draft IA liaised may
be supported without any modifications to OSPF.  As discussed in earlier
emails, it can be implemented solely through the import/export of
information described in Appendix I of G.7715.

	 - The draft IA also recognizes namespace issues exist between
Router ID and the IP Address that messages are sent to (ITU calls this
the RC PC SCN address).  This issue is also discussed in
draft-ietf-ccamp-gmpls-addressing.

	 

	Given that:

	-          CCAMP has a milestone to publish an ASON routing
solution by Nov 2006, 

	-          CCAMP didn't have at the time this was liaised
(doesn't have today?) a working group document, and

	-          the draft IA has been successfully implemented by
more than a dozen vendors and interop-tested many times,

	I would expect that we should be looking at this as
experience/text that could be leveraged...  "Running code..." and all
that...

	 

	Regards,

	 

	Jonathan Sadler

	 

	
________________________________


	From: Ong, Lyndon [mailto:[e-mail]] 
	Sent: Monday, July 24, 2006 2: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.

	 

	-- 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.

	 

	-- 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.

	 

	-- 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".  

	 

	I think we're experiencing a significant miscommunication...

	 

	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
	============================================================
	============================================================
	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
	============================================================
	============================================================
	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
	============================================================
	============================================================
	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
	============================================================