Subject: RE: Proposed response to OIF on OSPF ENNI

From: "Sadler, Jonathan B." <[email-masked]>
Date: Mon, 24 Jul 2006 16:38:05 -0500

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:[email-masked]] 
Sent: Monday, July 24, 2006 4:31 PM
To: Sadler, Jonathan B.; Ong, Lyndon; [email-masked]
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:[email-masked]] 
Sent: Monday, July 24, 2006 4:32 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
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:[email-masked]] 
Sent: Monday, July 24, 2006 2:33 PM
To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
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:[email-masked]] 
Sent: Friday, July 21, 2006 11:34 AM
To: Brungard, Deborah A, ALABS; [email-masked]
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
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
============================================================

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Tue, 25 Jul 2006 09:58:24 -0500

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:[email-masked]] 
Sent: Monday, July 24, 2006 5:38 PM
To: Brungard, Deborah A, ALABS; Ong, Lyndon; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,

Regards,

Jonathan Sadler

Hi Jonathan,

Thanks,

Deborah

Given that:

Regards,

Jonathan Sadler

Hi Deborah,

interfaces.

 

Cheers,

Lyndon

Deborah

Hi Deborah and Adrian,

Thanks,

Jonathan Sadler

Hi,

Thanks,

Adrian and Deborah

= = = = = = = = = =

Dear Jim,

Best regards,

CCAMP co-chairs

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 25 Jul 2006 12:30:02 -0400

Hi Deborah,
 
Just to be clear, as editor of the OIF document and co-author of the
eval draft, I still believe
both to be very much in alignment.  And, of course, the OIF document
points directly to
G.7715.1 as well.  There seems to be a perception being encouraged that
there is some
sort of misalignment, but this is not true at all.
 
As to the relative relationships of the groups:  the eval draft and the
solutions draft are both IETF documents.  They are not OIF or ITU
documents, and
decisions made in the drafts are IETF decisions.  Related drafts such as
the
call signaling draft are not even going to be passed through ITU or OIF
for either group 
to review.  I can and do disagree with that decision, but my views are
treated as those
of a single IETF participant with no greater weight than any others'
(maybe less :o(
 
So please, let's confine ourselves to commenting on areas describing
GMPLS (esp. the table
in 4.1) and identification of technical concerns (such as the
inter/intra-carrier scope) 
and not worry about OIF's "intentions" or "alignment", since 
a) this is not an IETF document
b) the document specifically points to IETF/ITU for the protocol
standards. 
 
Cheers,
 
Lyndon

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

Hi Jonathan,

 

Hi Deborah,

Regards,

Jonathan Sadler

Hi Jonathan,

Thanks,

Deborah

Given that:

Regards,

Jonathan Sadler

Hi Deborah,

interfaces.

 

Cheers,

Lyndon

Deborah

Hi Deborah and Adrian,

Thanks,

Jonathan Sadler

Hi,

Thanks,

Adrian and Deborah

= = = = = = = = = =

Dear Jim,

Best regards,

CCAMP co-chairs

---

From: [email-masked]
Date: Tue, 25 Jul 2006 19:16:54 +0200

lyndon - 

don't you think it is a natural reaction to ask OIF intentions when the 
reader is confronted to 3 different objectives stated in the OIF IA

o) list OIF demo extensions (page 5)
o) address OIF requirements (page 4)
o) address G.7715.1 requirements (page 5)

and then question about OIF requirement delta vs G.7715.1 ?

i hope you can help as editor of this document

thanks,
- d.

"Ong, Lyndon" <[email-masked]>
Sent by: [email-masked]
25/07/2006 18:30
 
        To:     "Brungard, Deborah A, ALABS" <[email-masked]>, "Sadler, 
Jonathan B." <[email-masked]>, <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        Subject:        RE: Proposed response to OIF on OSPF ENNI

Hi Deborah,
 
Just to be clear, as editor of the OIF document and co-author of the eval 
draft, I still believe
both to be very much in alignment.  And, of course, the OIF document 
points directly to
G.7715.1 as well.  There seems to be a perception being encouraged that 
there is some
sort of misalignment, but this is not true at all.

So please, let's confine ourselves to commenting on areas describing GMPLS 
(esp. the table
 
Cheers,
 
Lyndon

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.

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

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

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

Hi Deborah,

 

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

Cheers,
 
Lyndon

From: [email-masked] [mailto:[email-masked]] On Behalf 
Of Brungard, Deborah A, ALABS
Sent: Monday, July 24, 2006 12:15 PM
To: Sadler, Jonathan B.; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI
Hi Jonathan, (and Lyndon),

 
 
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

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: [email-masked] [mailto:[email-masked]] On Behalf 
Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 9:38 AM
To: [email-masked]
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. Having 
assembled comments from several people and our discussions in Montreal, we 
have put together the following response.

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-eval-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,

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Jul 2006 13:58:45 +0100

Jon,

Deborah asked your opinion on whether CCAMP's ASON requirements document and 
evaluation document meet the needs of OIF. You say you are unable to make 
this personal evaluation. That is surprising. One would expect that you 
would have some sort of clue as:
- a named contributer and member of the design team for RFC4258
- an author of draft-ietf-ccamp-gmpls-ason-routing-eval
- an active participant in CCAMP where these two documents were last called
- a named contributer to "Draft OIF Specification for E-NNI Routing using 
OSPF (Restructured)"
- the editor of G.7715.

Lyndon has stated that he believes there is good alignment and that the 
objective is alignment.

Will you state your opinion?

Thanks,
Adrian