Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G58Zr-0007FB-Ke for ccamp-archive@ietf.org; Mon, 24 Jul 2006 18:07:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G58Zp-00068H-02 for ccamp-archive@ietf.org; Mon, 24 Jul 2006 18:07:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G58V0-00031v-Da for ccamp-data@psg.com; Mon, 24 Jul 2006 22:02:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [204.154.129.57] (helo=mx4.tellabs.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1G58Ux-00031a-2L for ccamp@ops.ietf.org; Mon, 24 Jul 2006 22:02:00 +0000 Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4.tellabs.com with ESMTP; 24 Jul 2006 22:01:59 +0000 X-SBRS: None X-IronPort-AV: i="4.07,176,1151884800"; d="scan'208,217"; a="58819454:sNHT43399488" Received: from USNVEX1.tellabs-west.tellabsinc.net ([172.23.216.101]) by USNVEX3.tellabs-west.tellabsinc.net with Microsoft SMTPSVC(6.0.3790.0); Mon, 24 Jul 2006 17:01:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6AF6C.C2554A22" Subject: RE: Proposed response to OIF on OSPF ENNI Date: Mon, 24 Jul 2006 16:58:57 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed response to OIF on OSPF ENNI Thread-Index: Acas0Ha/aYxFikOBS5m873SVRoVJxgAACLxQAAHPZJAAnZ89IAACGznwAAEdy+AAA5YHgA== From: "Sadler, Jonathan B." To: "Brungard, Deborah A, ALABS" , "Ong, Lyndon" , Cc: "Adrian Farrel" X-OriginalArrivalTime: 24 Jul 2006 22:01:48.0346 (UTC) FILETIME=[C2A379A0:01C6AF6C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: fcb81a552e93de47ff406e53e992da89 This is a multi-part message in MIME format. ------_=_NextPart_001_01C6AF6C.C2554A22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi Deborah, Lyndon, et al., =20 You mention: >> -- 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.=20 > db> "significant" was not based on "newness" as a feature, it was based on what GMPLS OSPF can > support today. =20 I'd like to point out that carrying Opaque LSAs is not a new extension to OSPF. What is new here is the import/export of GMPLS information between areas. Again, this can be done (and has been done by current implementations) without any change to OSPF. Again, I'd say that this is not significant. =20 Regards, =20 Jonathan Sadler =20 ________________________________ From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]=20 Sent: Monday, July 24, 2006 4:22 PM To: Ong, Lyndon; Sadler, Jonathan B.; ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: Proposed response to OIF on OSPF ENNI =20 below (noted as db>)... =20 Lyndon, do you think the OIF document and CCAMP's ASON Requirements and Evaluation document are aligned? =20 Thanks, Deborah =20 ________________________________ From: Ong, Lyndon [mailto:Lyong@Ciena.com]=20 Sent: Monday, July 24, 2006 3:33 PM To: Brungard, Deborah A, ALABS; Sadler, Jonathan B.; ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah, =20 Here's what I would say is in and not in the OIF document: =20 -- 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.=20 db> "significant" was not based on "newness" as a feature, it was based on what GMPLS OSPF can support today. =20 -- 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? =20 -- 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=20 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. =20 -- 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? =20 I think we're experiencing a significant miscommunication... db> Agree;-) =20 Cheers, =20 Lyndon =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A, ALABS Sent: Monday, July 24, 2006 12:15 PM To: Sadler, Jonathan B.; ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: Proposed response to OIF on OSPF ENNI Hi Jonathan, (and Lyndon), =20 Thanks to both of you for responding. =20 "Significant" was referencing: =20 - 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 =20 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. =20 Deborah =20 =20 ________________________________ From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]=20 Sent: Friday, July 21, 2006 11:34 AM To: Brungard, Deborah A, ALABS; ccamp@ops.ietf.org Cc: Adrian Farrel Subject: RE: Proposed response to OIF on OSPF ENNI Hi Deborah and Adrian, =20 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"? =20 Thanks, =20 Jonathan Sadler =20 ________________________________ From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A, ALABS Sent: Friday, July 21, 2006 9:38 AM To: ccamp@ops.ietf.org Cc: Adrian Farrel Subject: Proposed response to OIF on OSPF ENNI =20 Hi, =20 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. =20 Please comment on the list in the next week. =20 Thanks, Adrian and Deborah =20 =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D Dear Jim, =20 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. =20 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. =20 Specific comments include: 1=2E 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=2E 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.=20 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=2E 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=2E3/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. =20 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. =20 Best regards, Adrian Farrel and Deborah Brungard, CCAMP co-chairs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C6AF6C.C2554A22 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"

Hi Deborah, Lyndon, et al.,=

 

You mention:<= /p>

>> -- G.7715, G.7715.1 and the I= ETF 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. <= /font>

> db> "significant" was not based on "newness" as a feature, it was based on what GMPLS O= SPF can

> support today.=

 

I’d like to point out that carry= ing Opaque LSAs is not a new extension to OSPF.  What is new here is the import/export of GMPLS information between areas.  Again, this can be = done (and has been done by current implementations) without any change to OSPF.&= nbsp; Again, I’d say that this is not significant.=

 

Regards,

 

Jonathan Sadler<= /font>

 

From: Brungard, Deborah A, ALABS [mailto:dbrungard@att.com]
Sent: Monday, July 24, 2006 = 4:22 PM
To: Ong, Lyndon; Sadler, Jon= athan B=2E; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed respon= se to OIF on OSPF ENNI

 

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:Lyong@Ciena.com]
Sent: Monday, July 24, 2006 = 3:33 PM
To: Brungard, Deborah A, ALA= BS; Sadler, Jonathan B.; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed respon= se 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<= /span>

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 EN= NI routing protocols. And, I differ with your view on IETF documents, IETF documents do specify. And this OIF document also specifies - Figure&nb= sp;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 o= nly GMPLS-ASON identified need was if non-unique link IDs (e.g. unnumbered) were supported, an optional TLV was identified which cou= ld be used. Note, GMPLS links are not representing "data plane" (RFC4394 provides a good mapping of terminology). And, this was not ba= sed on the issue which OIF identified in section 4.2, "identifier namespac= es are merged together" in GMPLS.

 

-- the document does not in fact define any standard extensions to the protocols, and points to future work<= /font>

in IETF and ITU to provide these.  Therefore I cannot understand where you say "new extensions to<= /font>

OSPF are specified" and "none...align with the CCAMP's GMPLS-ASON work". 

db> None of the identified "is= sues 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 significa= nt miscommunication...

db> Agree;-)

 

Cheers,

 

Lyndon

 

From:= owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A, ALA= BS
Sent: Monday, July 24, 2006 = 12:15 PM
To: Sadler, Jonathan B.; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed respon= se to OIF on OSPF ENNI

Hi Jonathan, (and Lyndon),

 

Thanks to both of you for responding.<= /span>

 

"Significant" was referencin= g:

 

- supports a (new) hierarchi= cal OSPF model

- supports inter-domain (inter-carrier) OSPF (not supported by today's OSPF)

- identifies namespace issues with GMP= LS OSPF which do not exist, and proposes extensions to "fix"<= /font>

- new extensions to OSPF are specified=

- none of the proposed extensions align with CCAMP's GMPLS-ASON work

 

Did you have another adjective to sugg= est? We were thinking "significant" was rather soft consider= ing the above. Though if it's just ITU-speak differences, why does the OIF liai= son 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=2E [mailto:Jonathan.Sadler@tellabs.com]
Sent: Friday, July 21, 2006 = 11:34 AM
To: Brungard, Deborah A, ALA= BS; ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: RE: Proposed respon= se 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<= /font>

 

From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Brungard, Deborah A, ALA= BS
Sent: Friday, July 21, 2006 = 9:38 AM
To: ccamp@ops.ietf.org
Cc: Adrian Farrel
Subject: Proposed response t= o OIF on OSPF ENNI

 

Hi,

 

We had a communication from OIF on the= ir 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 discuss= ions in Montreal, we have put together the following response.

 

Please comment on the list in the next week.

 

Thanks,

Adrian and Deborah<= /o:p>

 

=3D =3D =3D =3D =3D =3D =3D =3D =3D =3D

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, i= t 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 O= IF participants. Even though a reply was not requested, we are replying, as we strongly recommend that the document not be published for public informatio= n 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-publish= ed: ftp://ftp.isi.edu/internet-drafts/draft-ietf-ccamp-gmpls-as= on-routing-eval-03.txt. Considering notable OIF participants are authors of both these IETF documen= ts (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 expl= oder or send a communication.

 

Specific comments include:

1.<= font size=3D1>      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 requirement= s on and use of OSPF-TE at the ENNI. These three views seem to be inconsistent.<= o:p>

2.  &nbs= p;   The list of changes from the previous version (listed und= er 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-sta= te based protocol to support a hierarchical routing architecture (G.7715.1) wi= thin a carrier’s domain. Requirements for using a link state protocol as an inter-domain protocol between carriers are significantly different. We stro= ngly disagree if you intend to publish this document as an inter-carrier OSPF EN= NI Implementation Agreement claiming alignment with IETF RFCs without review (= or agreement) by any of the IETF Working Groups.

3.<= font size=3D1>      Section 4=2E1/Table 1 and the statement under the table identifying issues with GMP= LS identifier namespaces are not correct. GMPLS identifier namespaces do meet = ASON requirements for namespace separation of the transport plane and control pl= ane (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 revi= ew was the support of independence of functional component to physical locatio= n, this appears to be a key area of misunderstanding on GMPLS. We recommend reviewing RFC3945 (GMPLS Architecture) to understand that the key architect= ure difference between GMPLS and MPLS is the decoupling of the transport plane = and control plane. Additionally, RFC4394, RFC4397, and RFC4258, provide a mappi= ng 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 be= tween 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

=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
The informat=
ion contained in this message may be privileged
and confiden=
tial and protected from disclosure. If the reader<=
/pre>
of this mess=
age is not the intended recipient, or an employee<=
/pre>
or agent res=
ponsible for delivering this message to the
<=
pre>intended rec=
ipient, you are hereby notified that any reproduction,
disseminatio=
n or distribution of this communication is strictly
prohibited. =
If you have received this communication in error,<=
/pre>
please notif=
y us immediately by replying to the message and
deleting it =
from your computer. Thank you. Tellabs
<=
font
size=3D2 face=3D"Courier New">=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
------_=_NextPart_001_01C6AF6C.C2554A22--