Subject: Proposed response to OIF on OSPF ENNI

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Fri, 21 Jul 2006 09:37:32 -0500

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
<ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-e
val-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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 21 Jul 2006 12:46:56 -0400

Hi Deborah,
 
Just to provide some historical background, the draft text that was
liaised to CCAMP 
was actually designed to align more closely to the ASON evaluation
results than
previous documents.  However, I think it is more in "ASON-speak" than
"GMPLS-speak"
since our starting point was G.7715 and G.7715.1, and maybe that is
leading to some
greater impression of misalignment than there really is.
 
That being said, any specific comments will certainly be looked over
carefully.
 
I'll have more detailed comments in a future message.
 
Thanks,
 
Lyndon

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 7:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =

Dear Jim,

Best regards,

CCAMP co-chairs

---

From: [email-masked]
Date: Tue, 25 Jul 2006 00:42:22 +0200

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" <[email-masked]>
Sent by: [email-masked]
21/07/2006 16:37
 
        To:     <[email-masked]>
        cc:     "Adrian Farrel" <[email-masked]>
        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: Tomohiro Otani <[email-masked]>
Date: Tue, 25 Jul 2006 07:59:35 +0900

Hi Deborah,

In terms of 3, I agree with the description.  As far as I understand,
OIF is looking at intra-domain inter-vendor specification as
their E-NNI signaling & routing.  I have not caught up with the
modification. I think it is not appropriate for us to use the link
state based protocol as an inter-carrier interface of optical networks.

Regards,

tomo

Brungard, Deborah A, ALABS wrote:
> 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.
>  
> 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 
> /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.
> within a carrier’s domain. Requirements for using a link state protocol 
> IETF Working Groups.//
> RFC4258, provide a mapping to ITU terminology which may be helpful reading.
> 
>  
>

---

From: "Ong, Lyndon" <[email-masked]>
Date: Mon, 24 Jul 2006 19:37:08 -0400

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: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, July 24, 2006 3:42 PM
To: Brungard, Deborah A, ALABS
Cc: Adrian Farrel; [email-masked]; [email-masked]
Subject: Re: Proposed response to OIF on OSPF ENNI

hi - 

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" <[email-masked]> Sent by:
[email-masked]
21/07/2006 16:37
 
        To:     <[email-masked]>

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,

the interpretation of the IETF's work, we recommend that you either
 
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.

Best regards,

---

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

Hi Tomo,

Much thanks for the reply. I think this modification to remove the
limitation to intra-carrier was done in version -03. It has been
difficult to follow the different versions.

(CCAMP-Chair hat off/AT&T hat on)
I also have concern with use of a link state routing protocol as an
inter-carrier interface. 

Regards,
Deborah

-----Original Message-----
From: Tomohiro Otani [mailto:[email-masked]] 
Sent: Monday, July 24, 2006 7:00 PM
To: Brungard, Deborah A, ALABS
Cc: [email-masked]; Adrian Farrel
Subject: Re: Proposed response to OIF on OSPF ENNI

Hi Deborah,

Regards,

tomo

al-03.txt. 

> the Table of Contents) includes "/removed "intra-carrier" limitation/"

reading.

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Thu, 27 Jul 2006 16:59:29 -0500

Thanks all for the discussion. I've updated to include:
- our discussion on "alignment" --> amended to say "does not appear to
be aligned"
- reworded item 2 (OSPF ENNI for inter-carrier use) and item 3 (on
addressing, renumbered as item 4 in new proposal) to reflect our
discussion
- added two items based on Dimitri's and Lyndon's exchange: GMPLS Change
Process (new item 3), and concern on the stability of the identified
extensions (item 5)
 
We'll target COB (EST) tomorrow for finalizing-
Deborah
 
============= 2nd proposal=============================
 
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 cooperating on GMPLS ASON
with ITU-T's SG15 for several years and our Design Teams included 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 does not appear to be aligned with
ITU-T's and CCAMP's cooperation on RFC 4258 (Requirements for
Generalized Multi-Protocol Label Switching (GMPLS) Routing for the
Automatically Switched Optical Network (ASON)) or the to-be-published
document,
ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-ev
al-03.txt
<ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-e
val-03.txt> , which is the basis for our on-going routing solutions
work. 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. We use
the term "appear" as after much discussion over the CCAMP mailing list,
we could not determine the relationship with CCAMP's documents. OIF's
Liaison to CCAMP, Lyndon Ong, did re-affirm the statement in the
document, on OIF's intention to provide Implementation Agreements based
on ITU-T and IETF's Standards. In the interests of avoiding divergence,
we advise not to have duplicate requirements documents. If you do have
the need for an OIF document, we suggest in the interests of time for
the three groups, IETF, ITU-T, and OIF, that you directly reference our
ASON work in the corresponding GMPLS OSPF evaluation sections of your
document. If any questions on the interpretation of IETF's work, we
recommend that you either utilize the CCAMP mail exploder or send a
communication.

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. 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 suggesting it can be used as an inter-carrier OSPF
ENNI Implementation Agreement. Regardless of OIF inter-carrier
demonstrations using this protocol, it is technically misleading, both
to your member carriers and the industry, to suggest using an IETF IGP
protocol as an inter-carrier ENNI. The title of the document and the
introduction need to be correctly scoped.

3.      While OIF's UNI is based on an Informational RFC, RFC3474, which
was not a Standards Track Document, any new extensions to IETF protocols
now need to be reviewed by IETF under the (G)MPLS process. The OSPF
protocol elements in Appendix 1 (as noted in the document) are
experimental. If OIF sees a need for such extensions, OIF needs to bring
the requirements to the IETF. In the interests of a cooperative
relationship between our organizations, we advise against publication
and public demonstrations of experimental extensions to IETF protocols,
based on presumed issues with IETF protocols, with no review by IETF.

4.      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). 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 by OIF. While some pre-standard vendor
implementations do not support this separation, it is unfortunate if
this has been guiding your ASON work as a GMPLS issue and resulting in
divergence on solutions. Discussion on the CCAMP exploder highlighted a
participant's misinterpretation.  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. To avoid these
misunderstandings, we encourage you to share your requirements with us
in as early of a stage as possible to allow us to work towards a
standards track solution.

5.      Concern was raised that even though the codepoints in the
Appendix carry the disclaimer that they are for private and experimental
use, the text in Section 1.2 positions the identified extensions as
stable (and verified in the demos) and only the encoding is subject to
discussion. As OIF has not initiated any GMPLS Change Process on these
extensions, this is very presumptuous. Again, we would recommend against
publication of this document in the public domain.

We request an additional round of communication of this document to the
IETF before OIF approval to allow us to work with you to improve
convergence between OIF and IETF work which, we believe, will be in the
best interests of our groups and the industry.

Best regards,

CCAMP co-chairs

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Friday, July 21, 2006 10:38 AM
To: [email-masked]
Cc: Adrian Farrel
Subject: Proposed response to OIF on OSPF ENNI

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =

Dear Jim,

Best regards,

CCAMP co-chairs

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 28 Jul 2006 12:27:48 -0400

Hi Deborah, Adrian,
 
I am still not happy with the tone of the liaison and some nits (still
don't see why an
OIF document cannot reflect OIF work over the last several years, for
example),
but it is probably best to get a liaison out now since OIF meets next
week.
 
Just for the record, I think many if not all of the specific text points
can be addressed, but
disagree with a number of the broader conclusions, particularly on the
relative
roles of OIF and IETF.
 
Cheers,
 
Lyndon

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brungard, Deborah A, ALABS
Sent: Thursday, July 27, 2006 2:59 PM
To: [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

 
 
Dear Jim,

Best regards,

CCAMP co-chairs

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =

Dear Jim,

Best regards,

CCAMP co-chairs

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Fri, 28 Jul 2006 14:49:25 -0500

It was a difficult balance, as we do hope as you say that going forward
we can be in closer alignment, though we also needed to voice our
concerns on the current content.
 
On the relative roles of OIF and IETF, you can either discuss over the
list or off-line with the co-authors on the (G)MPLS Change Process. And
you may want to re-read Loa's mail on the guidelines for an IETF/OIF
liaison relationship. I took the text from his mail regarding our
concern on OIF modifying an IETF protocol without prior consultation
with IETF. This may be an OIF document, but it will not be of limited
access to members-only, it will be made available on their web site for
non-member access as an Implementation Agreement.
 
Thanks Lyndon for your mails - Good weekend-
Deborah

From: Ong, Lyndon [mailto:[email-masked]] 
Sent: Friday, July 28, 2006 12:28 PM
To: Brungard, Deborah A, ALABS; [email-masked]
Cc: Adrian Farrel
Subject: RE: Proposed response to OIF on OSPF ENNI

Hi Deborah, Adrian,

 
Cheers,
 
Lyndon

 

Dear Jim,

Best regards,

CCAMP co-chairs

Hi,

 
Thanks,
Adrian and Deborah
 
= = = = = = = = = =

Dear Jim,

Best regards,

CCAMP co-chairs